Redesigning your website in 2026: what every page needs, and what to do first

A website redesign usually changes how a site looks and almost nothing about what it earns. The ones that pay for themselves do four things: they fix the journey rather than the aesthetics, they make every page answer one question in its first two lines, they load fast enough for the less capable machines now reading the web, and they measure what the site brings in so the spend can be argued for afterwards.

Before any of that, there is a question worth asking out loud. Most of the businesses who ask us for a redesign do not need one yet.

Start here, because the honest answer is often no.

A South West accountancy practice came to us expecting a rebuild. We lifted their search impressions by 73% in six months and did not rebuild the website. We tightened what was already there. The full write-up is in the case note, and the reason it is on our site at all is that it is the least flattering kind of project to publish: the one where we talked a client out of the bigger job.

A UK wedding celebrant on Squarespace had the same instinct. Her site had character and was quiet in search, earning 927 clicks over six months at an average position of 33.1. The fix was one deep, well-structured page on wedding readings, plus internal linking and technical work. Organic clicks grew 6.8 times, up 577%, and the page took position one. That case note is here. No redesign.

So the test. Write down what is actually wrong. If the answers are "it looks dated", "the content is thin" or "nobody can find the pricing", those are content and structure problems, and a redesign is an expensive way to solve them. If the answers are "we cannot add a page without a developer", "it takes four seconds to load on a phone", "the brand has changed" or "the thing we sell is not the thing the site sells", that is a build problem, and a rebuild is the right tool.

The uncomfortable version: a redesign is the most satisfying thing on the list and rarely the most valuable. It feels like progress because you can see it.

It is for turning a brochure into a channel.

DeskLodge is the clearest example we have, and they are happy to be named. They relaunched with a complete rebrand in summer 2025 and needed the Webflow site to match in just under five weeks, in time for the launch party. We rebuilt 23 pages.

The part that mattered was not the pages. Booking a meeting room or a day pass used to mean leaving the DeskLodge site for a third-party system. We brought the booking inside the website, so somebody can browse, choose and pay without the brand changing under them halfway through. Then we tracked every step of it.

Comparing the twelve months after launch with the twelve before: users up 26%, engaged sessions up 30%, phone clicks up 63%, engagement rate from 58.7% to 61.8%, and over £16,000 in online bookings through a revenue stream the business could not previously see at all. Search visibility held steady through a full rebrand, which is usually where redesigns come apart. The whole note is here, figures are the client's own.

Three things that project proves, and they generalise.

A rebrand is the best time to fix the journey, because every page is already on the table and the awkward conversations are already happening. Every time you send a visitor somewhere else to finish, you give them a chance to stop. And if you cannot measure it, you cannot defend the spend twelve months later when somebody asks what the website did.

This is the spec we build to. It is not a style guide. Each item is here because leaving it out costs something specific.

One job. A page that sells a service, answers a question and tells the company story does none of them. If you cannot say in one sentence what a visitor should do next, the page is not finished.

The answer in the first two lines. Not a welcome, not a scene-set. The question the page exists to answer, answered. Our own service pages open with a block called "the short answer" for exactly this reason. It helps a reader who is skimming, and it gives an AI assistant a passage it can lift without having to interpret you. If a machine has to infer your point, it will sometimes infer it wrong, and you will not find out.

A last-updated date, and an honest one. Not the publish date quietly rewritten by a plugin every time someone fixes a typo. A reader uses it to decide whether to trust the page, and so does everything else reading the page. If the content has not changed, leave the date alone.

A named human. Who wrote it, with a link to a real page about that person. Anonymous expertise is not expertise. Our about page is written for this rather than as a formality.

What it costs, or the nearest honest thing. This is the one people fight hardest. HubSpot's AI Search Lab found their pricing pages looked fine to people and were effectively unreadable to AI crawlers, because the important numbers arrived by JavaScript. So models guessed, and the guesses were wrong. They published a plain, factual version covering what each tier costs, what the fees are and when the product is worth it, and accuracy improved for five of their six product areas.

We publish ours on the pricing page. If your prices genuinely depend on scope, publish the ranges and what moves them. Silence is not neutral. Silence means something answers for you.

Proof sitting next to the claim. Not a testimonials page nobody visits. The review, the figure or the case note goes on the page that makes the claim it supports. Reviews do most of their work as sentences rather than stars, because a sentence can be quoted and a number cannot, which is the argument in our piece on reviews and visibility.

Who it is not for. The single most under-used element on any service page. Saying who you are a bad fit for is the fastest trust signal available, it costs nothing, and almost nobody does it. Ours sits under a heading that reads "Are we the right fit?" and it names the people we would turn down.

Links that a person would actually follow. Internal links placed because the next thing is genuinely useful, in the sentence where the reader needs it. Not a related-posts carousel bolted to the bottom. Internal linking is how both readers and crawlers understand what your site is mostly about, and it is the cheapest thing on this list.

One next step. One. A page offering a call, a download, a newsletter and a chat widget is a page that has not decided.

[Structured data](/glossary/schema-markup) that matches what is on the page. Schema markup describing a service that is not there, or FAQs that do not appear to a reader, is worse than none. Google deprecated most FAQ rich results, which made the markup more useful rather than less, because the audience for it changed.

Faster than you think, and the reason has changed.

Page speed used to be a ranking consideration and a bounce-rate problem. Both still apply. What is new is that a growing share of the things reading your website are considerably less capable than Googlebot. Many will not wait for a slow page. Many will not run your JavaScript at all.

HubSpot put a pre-rendering service in front of their pages rather than rebuilding anything. Load time went from over two seconds to around 70 milliseconds, and OpenAI's crawl volume doubled. They did not write better pages. They made the same pages reachable.

Here is the test, and it takes under a minute. Turn JavaScript off in your browser and load your own homepage. Whatever is still on the screen is roughly what a lot of these systems see. On plenty of sites the prices vanish, the service list vanishes, and sometimes the page goes white.

If that happens, nothing else on your marketing plan matters this quarter. You can write the best page in your sector and it will do nothing, because the thing reading it gave up before the words arrived. We work technical foundations first, always, and this is the reason rather than a preference.

Two practical notes. Core Web Vitals are a reasonable proxy for how a page feels to a human and a poor proxy for how it behaves for a crawler, so check both, and here is the plain English version of what they measure. And if your site is built as a single-page application, JavaScript SEO is not an optional extra on the project, it is the project.

The pages nobody wants to build.

Two of HubSpot's seven experiments were content, and both are copyable by a business with no developer.

The first was glossary pages: short, plain definitions of the core terms in their field, one idea per page, nothing sold. Reported result, a 36% lift in visibility, with those pages outperforming the rest of the site by 15% and ranking for hundreds of keywords within months. The reasoning is worth understanding rather than copying blindly. Language models hold concepts as positions on a kind of map, so the business that explains what a thing means sits near that thing.

I have a caveat on this one, and it is ours. We built an SEO glossary years ago, long before anyone was talking about answer engines. The page explaining the local pack ranks at position 3.3 for its main term. Across all its queries it took 2,695 impressions last month at an average position of 7.6, and nought clicks.

That is the argument for building these pages, not against. Ranking and being visited have come apart. A glossary page now earns its place by being the thing that gets quoted, not the thing that gets clicked, which is a different job and needs to be measured differently. We wrote about what to measure instead.

The second was use case pages, each tying one capability to one industry and one specific situation. Not "CRM software", closer to "how a car dealership follows up test drive enquiries". Reported result: more than 15,000 ChatGPT crawls within 30 days and 92% of those pages cited within months. The team said 92% was higher than they expected, and I believe them.

The reason it works is that the shape of the question changed. A Google search is three words. A question typed into an AI assistant is a paragraph full of context about one person's specific situation. Generic pages do not match specific situations. Uncomfortably narrow pages do.

If you take one instruction from this section: write down what you already explain on the phone twice a week, and build a page for each. That is your content plan, and it is better than the one a keyword tool will give you, because a keyword tool reports what has volume, not what the four people a month who actually buy are asking.

Redesigns lose traffic in boring, preventable ways.

URLs change and nobody maps the old ones to the new ones, so every link anyone has ever built points at a 404. This is the single most common way a good-looking new site earns less than the ugly old one. Redirect strategy is a day of work that protects years of it, and our migration guide covers the rest.

Content gets "tidied" during the rebuild and the pages that were actually ranking get shortened into something that reads better and says less.

Staging gets indexed, or the live site goes out still blocking crawlers from the staging config. One line in one file can hide an entire website, which is why we wrote a guide to checking yours.

Tracking goes in last and badly, so the first three months after launch cannot be compared with anything.

There is a pre-launch checklist here covering the lot. Work through it before the launch date, not during the launch week.

llms.txt is a proposed file you add to your site to tell AI systems how to read it. The idea spread quickly because it sounds obviously sensible. Plenty of agencies started recommending it, and it was on our own list too, as a low-priority job.

HubSpot tested it. Not a single bot crawler attempted to visit the file. Not fewer than expected. None.

I mention it in a piece about redesigning websites because it is the cheapest possible lesson. An idea spread across an entire industry on the strength of making sense, and a straightforward test found nothing there. The test I now apply, including to things we say: who ran it, what happened, and what did they find that they did not want to find. No answer to the third one and it is not evidence.

The same scepticism applies to anything on a redesign quote described as future-proofing. Ask what it was tested against.

1. 01Decide whether to rebuild at all. Write down what is actually wrong. If the list is content and structure, fix those and keep the money.
2. 02Fix what machines can reach. JavaScript off, load your homepage, see what survives. Then speed. Nothing downstream works if this does not.
3. 03Fix the pages that already earn. The ones with traffic, the ones sales teams send to people. Apply the page spec above to those first.
4. 04Then rebuild, if you still need to. With the redirect map written before the build starts rather than after.
5. 05Build the narrow pages. Glossary entries and specific use cases. The dull ones.
6. 06Measure what it brings in. Not positions. Enquiries, bookings, revenue, and which page produced them.

Steps two, three and five are most of the value and none of the excitement. That is usually how it goes.

If you want to know whether your site needs rebuilding or tightening, that is a short conversation and we will tell you straight. Book a discovery call and we will look at it together.