When to Redesign Your Website — and When Not To

A redesign feels like a design decision and is usually a migration. If the URLs change, Google treats it as a site move, and it publishes what that costs: a period of fluctuation while it recrawls and reindexes, measured in weeks for a medium site and longer for a large one.

That is a real bill, payable up front, in the currency you are usually trying to grow. It can absolutely be worth paying. But it should be paid for a limitation you can name, not for a feeling that the site looks old.

What Google says a site move actually does

Google's site move documentation, updated 20 August 2026, is unusually plain about the disruption.

On timing:

"For medium-sized websites, it can take a few weeks or more for Google to gradually start showing the new URLs instead of the old ones (and for larger sites, even longer)."

On what happens meanwhile:

"With any significant change to a site, you may experience ranking fluctuations while Google recrawls and reindexes your site."

and

"Note that the visibility of your content in Search may fluctuate temporarily during the move. This is normal and a site's rankings will settle down over time."

Read the whole set together. The disruption is expected, it is temporary, and it is measured in weeks rather than days. None of that is a reason never to move a site. It is a reason to know what you are buying before you sign.

The cheapest risk reduction available

Keep the URLs. A visual redesign on the existing URL structure is not a site move. Google recrawls pages whose content changed, which it does anyway; there are no redirects to get wrong, no old URLs to map, and nothing to recover from if someone forgets a section.

When new URLs are proposed as part of a redesign, ask what the new structure buys. Often the honest answer is tidiness — and Google states elsewhere that it "generally doesn't look at the structure of URLs to work out the structure of a site", which we went through in the e-commerce SEO guide. Tidiness is a fine reason to change URLs on a site with no traffic. It is a poor reason on a site with some.

Reasons that justify a rebuild

Each of these is a limitation with a consequence attached, which is the test:

• It is not accessible, and the fixes are structural rather than cosmetic. Not a preference — a legal and practical constraint covered in our accessibility guide.
• It fails Core Web Vitals in the field and cannot be fixed incrementally, usually because the performance problem is the architecture. Our Core Web Vitals guide covers how to tell the difference.
• The CMS blocks the people who need to publish. If marketing has to ask a developer to change a heading, the site is costing you throughput every week — and going headless makes that worse, not better.
• It cannot support what the business now needs — a second language, a new product line, a storefront, a member area.
• It is built on something nobody will maintain, or on a stack whose runtime is past end of life. That is a maintenance conversation before it is a design one.

Notice what is not on that list. "It looks dated" is a judgement, and a real one — but it is usually satisfied by a visual refresh on the same structure, at a fraction of the cost and none of the risk.

The test that settles most of these arguments

Write down the three things the current site prevents you from doing. Not things you dislike — things it prevents.

If you can fill all three lines, you have a rebuild. If you can fill one, you have a project. If you cannot fill any, what you have is a preference, and the honest response is a refresh: new typography, new imagery, a rewritten homepage, a better contact flow. Same URLs, same CMS, no migration, a fraction of the budget.

Most sites we are asked to rebuild have three or four identifiable problems rather than a general condition. A hero image that is the Largest Contentful Paint and is not optimised. A navigation that cannot be used with a keyboard. A contact form that silently fails. A category page that links to nothing. Each is days rather than months, and fixing them usually delivers most of what the redesign was supposed to deliver.

If you are moving URLs anyway

Do it properly, because the recoverable version and the unrecoverable version look identical on launch day.

1. Export every URL with traffic or inbound links before anything changes. Search Console and your analytics both have this.
2. Map each one to its closest equivalent. Not to the homepage — that is the most common shortcut and the most damaging.
3. Use permanent, server-side redirects. Google recommends "HTTP permanent redirects if possible, such as 301 and 308" and server-side over client-side.
4. Move everything at once on a small site. Google recommends "moving all URLs on your site simultaneously instead of moving one section at a time", and allows a phased move for larger sites because it "can make it easier to monitor, detect, and fix problems faster."
5. Keep the redirects forever. They are not a launch-week measure.
6. Watch Search Console for a full month, expecting fluctuation rather than being alarmed by it.

Where we say no

We will not quote a rebuild for a client who cannot name what the current site prevents. We would rather do a refresh at a tenth of the price than take a budget for a migration nobody needed.

We will not change URLs without a mapped redirect plan agreed in advance. A redesign that loses a site's search traffic is not a redesign, it is an outage with a new colour scheme.

And we will say when the problem is the content rather than the container. A site that does not convert because nothing on it answers a buyer's question will not convert after a rebuild either — our website development guide sets out how we scope that honestly.

If you want an outside read on whether you need a rebuild or three fixes, send us the site and we will tell you which — including when the answer is that you should spend the budget somewhere else.