Check this page with an assistantOpens a chat asking it to summarise this article and name the evidence behind each claim.
Claude opens with the prompt on your clipboard: Anthropic does not support prefilled prompts on the web, and we would rather copy it than ship a button that drops it.
Why Redesigns Lose Traffic (It Is Almost Never the Design)
Rankings do not live in your color scheme or your hero image. They live in your URLs, your content, and the internal links that connect them. Redesigns lose traffic when URLs change without redirects, when the copy that earned the rankings gets rewritten or deleted, or when a noindex tag from the staging site ships to production. All three failure modes are preventable before launch.
This is the mental model that makes everything else in this guide obvious: Google is nearly blind to the visual layer and obsessive about the information layer. It indexed a specific address, holding specific words, linked from specific other pages. Change the address and the old ranking points at a dead end. Change the words and the page has to earn its position again with new copy. Break the internal links and Google loses the map it used to understand which pages matter.
The reason this is worth saying plainly is that most redesign projects are run by people optimizing the visual layer, which is their job. Nobody on the design team is assigned to the information layer unless someone assigns them. The rest of this playbook is that assignment, written down.
Before Anything Moves: The Inventory
Before a single template changes, export every indexed URL and its clicks from Search Console, crawl the current site to capture titles and headings, and mark which pages earn traffic today. The rule is simple: you cannot protect what you have not listed. Pages with rankings get preserved or redirected, never silently dropped.
The Search Console export is the backbone. The performance report tells you which URLs received impressions and clicks over the last twelve months, and that list is your protected inventory: every row on it represents a ranking someone would have to rebuild from scratch if it disappears. Add a crawl of the live site with any standard crawler to capture each page's title tag, H1, and internal links, because those are the elements a rewrite quietly destroys.
Then triage. Pages with meaningful clicks are untouchable: they keep their URL or get a mapped redirect, and their copy changes only deliberately. Pages with impressions but few clicks are candidates for improvement, not deletion. Pages with neither can be dropped, but as a recorded decision rather than an accident of the new sitemap. If you want the fuller version of this triage across an entire site, the small business SEO checklist covers it outside the redesign context.
The inventory has a second job: it is your acceptance checklist for launch day. Every protected URL either resolves or redirects on the new site, verified row by row, before anyone celebrates.
The Redirect Map: One Row Per Old URL
Every old URL gets a 301 redirect to its closest equivalent on the new site: one hop, no chains, and no blanket redirect to the homepage, which Google treats as a soft 404 and drops from the index. Where a URL can stay identical, keep it identical. The best redirect is the one you never need.
The map itself is unglamorous: a spreadsheet with the old URL in one column and the new URL in the next, one row per old address from your inventory. The discipline is in the phrase closest equivalent. A retired service page redirects to the service that replaced it, not to the services index. A merged blog post redirects to the post that absorbed it. When there is genuinely no equivalent, a clean 404 or 410 is more honest than a homepage redirect, because Google treats irrelevant redirects as soft 404s either way and the homepage version wastes the crawl.
Two mechanical rules keep the map healthy. First, one hop: if the old URL redirects to an address that itself redirects, flatten the chain so every old URL lands directly on its final destination. Second, sweep for the silent URL changes platforms introduce on their own, like added trailing slashes or lowercased paths, which need rows in the map just like deliberate moves do.
While the map is being built, the copy rewrite is usually happening in parallel, and this is where the second failure mode sneaks in. On every page in your protected inventory, preserve the title tag and the H1 unless you have a specific reason to change them. Those two elements carry a disproportionate share of what the page ranks for, and a well-meaning rewrite that freshens them is indistinguishable, to Google, from replacing the page.
The Launch-Week Checklist
| Check | When | What failure looks like |
|---|---|---|
| Staging noindex tag removed from every template | Launch hour | Pages vanish from Google over the following days, the classic site not showing up on Google emergency |
| robots.txt allows crawling on production | Launch hour | The staging disallow rule ships live and Google stops fetching the site entirely |
| Redirect map deployed and spot-checked by hand | Launch day | 404 spikes appear in Search Console within days |
| XML sitemap regenerated and resubmitted | Launch day | Google keeps crawling the old sitemap's dead URLs while discovering new pages slowly |
| Internal links point at new URLs directly, not through redirects | Week one | Every click and crawl takes an extra hop, and redirect chains accumulate quietly |
| Search Console coverage report watched daily | Week one | Indexing errors climb and nobody notices until traffic follows |
| Page speed compared against the old site | Week one | The new templates are heavier and every page loads slower than what it replaced |
| Rankings on the money queries tracked | Weeks one to four | A gradual slide signals lost relevance from changed content, not a technical glitch |
The first two rows deserve the pre-launch rehearsal. A staging site is supposed to carry a noindex tag and a blocking robots.txt, which is exactly why they end up in production: they were correct yesterday. Make removing both a named line item in the launch runbook with a named owner, not a thing everyone assumes someone checked. International redesigns also need a page-pair migration: validate reciprocal locale clusters with the hreflang guide instead of translating redirects and hoping the annotations follow.
What Recovery Looks Like When Something Slips
Small dips while Google recrawls the new site are normal and commonly settle within weeks. A sustained slide means a specific loss: find which pages lost clicks in Search Console, compare the old and new versions of those pages, and restore what changed, whether that is copy, headings, or internal links. Never respond by redesigning again. Respond by diffing.
The diagnostic sequence matters because panic produces the wrong fixes. Open Search Console's performance report, compare the weeks after launch to the weeks before, and sort pages by click loss. The damage is almost never evenly spread; it concentrates in a handful of pages, and those pages tell you which failure mode you shipped. If the losers all return 404s, the redirect map has holes. If they resolve fine but slid down the rankings, pull the old version from the Wayback Machine or your backup and diff the copy, the title, the H1, and which pages link to them. What changed is what broke.
This page-by-page comparison is a narrow version of a full search visibility audit, and running the systematic version after a rocky launch often surfaces problems the redesign merely exposed rather than caused. And when the diff shows a page lost ground because the rewrite genuinely thinned it out, rebuilding it follows the same process as refreshing any decayed post: restore the substance that ranked, then improve it. Once traffic is stable again, a Growth Map built from the post-launch Search Console data is the natural next step, because it ranks which recovered pages are worth building on first.
Questions People Ask Before a Relaunch
- Does redesigning a website hurt SEO?
Not inherently. Google barely reacts to visual changes; it reacts to changed URLs, changed content, and changed internal links. A redesign that keeps URLs stable, preserves the copy on ranking pages, and ships without a stray noindex tag typically holds its traffic. The losses people attribute to redesigns are almost always losses from one of those three changes going out unmanaged.
- Do I need 301 redirects if my URLs stay the same?
No. Redirects exist to forward equity from an old address to a new one, and if the address never changes there is nothing to forward. The catch is verifying that URLs truly stay identical: a trailing slash added by the new platform, a change in letter case, or www versus non-www all count as different URLs to Google. Crawl the new site and diff its URL list against the old one before you trust the word same.
- How long does it take rankings to recover after a redesign?
When redirects are correct and content is preserved, the small dips that come with recrawling commonly settle within a few weeks. Recovery takes longer when the content itself changed, because Google is not just re-mapping addresses, it is re-evaluating rewritten pages against everything else that ranks. The more you changed beyond the visual layer, the longer the re-evaluation runs.
- Should I redesign and migrate platforms at the same time?
Avoid it if you can. A platform migration changes URLs and templates, a redesign changes layout and copy, and doing both at once means that when traffic drops you cannot tell which change caused it. Sequence the layers: migrate with the design and content held constant, confirm traffic is stable, then redesign. Slower on the calendar, far faster to debug.
