How to redesign a website without losing your SEO.

A redesign that keeps its URLs, keeps its content and ships a tested redirect map typically moves organic traffic by a few percent for a few weeks. A redesign that changes all three at once, with no map and no pre-launch crawl, is the one that loses a large share of its traffic and spends months getting it back. The difference is rarely budget or platform — it is which of those three things you actually changed, and whether anybody checked before the DNS switch.

What a redesign changes, and what each change risks

Risk compounds. Changing two of these rows in one release is far harder to diagnose afterwards than changing them in two releases a month apart.

Does a redesign actually cost you rankings?

Not by itself. Google ranks URLs, not visual designs — a site that changes its colours, typography and layout while keeping the same URLs, the same page titles and the same body copy has changed almost nothing that a search engine measures. What costs rankings is the work that usually travels alongside a redesign: new URLs, rewritten or deleted content, a new CMS that drops your metadata, and redirects written the week of launch.

The scale of the downside is worth knowing before you decide how careful to be. An analysis of 1,052 domain migrations published by SALT.agency in June 2026 found a median recovery time of 304 days, with only about 23% of sites back to their pre-migration traffic within 90 days and 13.9% still not fully recovered after three years. That is the worst case — those are domain moves, the highest-risk category in the table above — but it is the case a redesign drifts into when the URL structure changes and nobody owns the redirect map.

Why does traffic drop after a redesign?

In our experience, almost every post-launch drop traces back to one of seven causes, and the first two account for most of them. First: URLs changed and old ones now return 404, so every ranking and every backlink pointing at them is discarded. Second: the staging site's noindex tag or its blocking robots.txt shipped to production, which quietly removes the whole site from the index within days.

The rest: content trimmed during the redesign, so pages that ranked on depth no longer have it; every old URL redirected to the homepage rather than to its closest equivalent, which search engines treat as a soft 404 rather than a signal transfer; internal links lost when a navigation is simplified, cutting the crawl paths to deep pages; a performance regression from a heavier front end; and structured data left behind in the old templates, taking rich results and AI citations with it.

Each of these is trivially preventable and expensive to find afterwards, because they all present the same way — traffic falls, and the cause is invisible from the front end.

Should you change your URLs at all?

If you can avoid it, avoid it. A URL change is the single most expensive decision in a redesign, and it is optional far more often than people assume: a new design, a new CMS and even a new framework can all ship on the existing URL structure. Every URL you keep is a redirect you do not have to write, test, monitor and maintain for the next year.

There are cases where changing is right — a structure built on query strings, a taxonomy that no longer matches what you sell, language paths added for a multilingual rollout, or slugs that describe an old product line. When that is genuinely the situation, change them once, deliberately, with a full map, and accept the recovery window rather than pretending it will not happen.

What makes a redirect map that actually holds?

One row per old URL, one 301 to the closest equivalent page, one hop, no chains. Build the list from four sources rather than one: a full crawl of the live site before it comes down, the pages Search Console reports as receiving impressions, the pages analytics shows receiving traffic, and the pages with external backlinks. Any of those four alone will miss URLs the others catch.

Google's own site-move documentation is explicit on the two details teams get wrong. Use permanent redirects — 301 or 308 — because permanent redirects do not cause a loss of PageRank, and keep them in place "for as long as possible, generally at least 1 year", because signals are reassigned per URL over time rather than all at once. Google also notes the move is processed URL by URL, so a small to medium site takes a few weeks for most pages to settle and a large one takes longer.

Test the map against the crawl before the DNS switch, not after. Every old URL should return exactly one 301 and land on a page that answers the same question — a redirect to the homepage is not a redirect, it is a deletion with extra steps.

What has to be checked before launch day?

Eight things, and all of them are faster to verify than to repair. Confirm robots.txt allows crawling and no noindex survived from staging. Confirm every page carries its intended title, meta description and self-referencing canonical. Confirm the heading order is still a real outline rather than styled divs. Confirm the structured data blocks moved across and validate them.

Then: confirm internal links still reach every page you care about, confirm images kept their alt text, submit a fresh sitemap of the new URLs, and run the redirect map against the old crawl until it returns zero 404s and zero chains. On a site with a few hundred URLs this is an afternoon. Done a week after launch instead, it is a month of recovery.

How long should recovery take, and when should you worry?

It depends entirely on which row of the table you changed. Same domain and same URLs: expect noise for a few days and no meaningful change. Same domain, new URLs, clean redirect map: expect a dip and a return over roughly four to eight weeks as Google reprocesses each URL. New domain: expect months, and use the Search Console Change of Address tool, which only works domain to domain — it is explicitly not for path changes within a site — and which Google maintains the relationship for only 180 days.

Worry when a drop keeps deepening after the third week, when Search Console's coverage report shows a rising count of 404s or "crawled – currently not indexed", or when impressions fall for queries whose landing page still exists and still ranks nothing. Those three signals mean something is broken rather than settling, and every week spent waiting is a week of recovery added.

What should a redesign improve, not just preserve?

Preserving traffic is the floor, not the objective — a redesign that keeps every ranking and changes nothing else was an expensive repaint. The rebuild is the cheapest opportunity you will get to fix the things that are structural: page weight and Core Web Vitals, a heading and schema structure that answer engines can lift a clean passage from, and the conversion path itself, since more traffic to a page that does not convert is not a win.

The practical order is: protect what ranks, then improve what it does when someone arrives. Teams that reverse those two — redesigning for conversion first and treating SEO as a launch-week checklist — are the ones that end up on the wrong end of the recovery numbers.

Sources

The migration guidance and recovery figures above come from these sources, checked July 2026. The pre-launch checklist and the risk table are our own.

• Google Search Central — Site moves with URL changes ↗

  Google's own migration documentation: use 301/308, permanent redirects do not lose PageRank, keep redirects at least one year, moves are processed URL by URL.

• Google Search Console Help — Change of Address tool ↗

  Domain-to-domain only, requires 301s already in place, and Google keeps the relationship between old and new site for 180 days.

• SALT.agency — Only 27% of domain migrations recover in 90 days ↗

  Study of 1,052 domain migrations published June 2026: median recovery 304 days, roughly 23% recovered within 90 days, 13.9% not fully recovered after three years.