The worst phone call in this business starts the same way every time. A business owner launched a beautiful website redesign three weeks ago, everyone loved it, and the phone has gone quiet. Not slower. Quiet. When we pull up Search Console, the impressions chart falls off a cliff on launch day and never comes back up.
It is almost never the design. Pulling off a website redesign without losing SEO is not a design problem at all — it is a bookkeeping problem. Every URL that ranked is an asset, and a migration either transfers those assets carefully or drops them on the floor. The difference between a site that dips 12 percent and recovers by week six, and one that loses 60 percent permanently, is a spreadsheet somebody either built or did not.
Key takeaways
- A normal redesign costs 10–25% of organic traffic in the first 30 days. Full recovery takes 2–8 months depending on how much changed.
- Crawl and export before anyone writes code. You cannot redirect URLs you never recorded, and the old site disappears the moment you launch.
- Every changed URL gets a 301 to its closest equivalent — never a bulk redirect to the homepage, which Google treats as a soft 404.
- Update internal links to point at the new URLs directly. Redirects are a safety net, not a substitute.
- The single most common killer is a staging noindex tag or robots.txt disallow shipping to production. Assign one named owner to remove it.
- Pages that generate traffic should not be rewritten without checking the data first. Redesign the template, not the copy that ranks.
Why redesigns cost rankings in the first place
Google does not rank your website. It ranks individual URLs, and it has spent years accumulating signals about each one: which queries it answers, how people behave when they land there, which other sites link to it. That accumulated understanding is attached to the address, not to your brand.
A redesign disturbs that in three ways, and it helps to separate them because they carry very different risk.
- Address changes. The URL moves. Unless a 301 tells Google where it went, the accumulated authority is stranded at an address that no longer resolves. This is the highest-risk change and the most recoverable when handled properly.
- Content changes. The page still exists at the same address but says something different. Google has to re-evaluate whether it still answers the queries it used to rank for. Moderate risk, and entirely self-inflicted when the rewrite was optional.
- Structural changes. Navigation, internal linking and information architecture shift, which changes how authority flows through the site. Low risk individually, but it compounds with the other two.
Do all three at once — new URLs, new copy, new architecture — and you have not migrated a website, you have launched a new one and asked Google to treat it as the old one. Some sites get away with it. The ones that do not are the ones that make the phone call.
Before anyone touches code: four exports
This is the step that gets skipped, and it is the only one that is genuinely impossible to do later. The moment the new site goes live, the old one is gone — along with the record of what it contained.
- A full crawl of the live site. Run Screaming Frog or Sitebulb and export every indexable URL. Crucially, this catches URLs that are being crawled and ranked but never appeared in your sitemap — orphaned pages, old campaign landing pages, PDFs. Those are exactly the ones nobody remembers to redirect.
- Twelve months of page-level performance data. Export from Search Console and Analytics. You need clicks, impressions and conversions per URL, because the entire redirect priority order comes from this file. A page with 40 conversions a year and a page with zero are not equally important, and without the export you will treat them as if they were.
- A backlink audit. Which external sites link to which of your pages. A page with no traffic but three strong editorial backlinks is a genuine asset, and it is the kind that gets deleted in a content cull because nobody looked.
- Your highest-converting pages, named explicitly. Not a vague sense of which pages matter — a written list. This becomes the do-not-touch list during the content phase, and it is the list you check first on launch day.
The URL map is the migration
Everything else is commentary. The URL map is a spreadsheet with one row per old URL and, at minimum, four columns: the old address, the new address, the redirect type, and the annual clicks that URL earned. Sort it by that last column and you have your priority order and your QA order in one artifact.
Build it by crawling both sites — the live one and the staging build — and comparing the two lists. Do not build it from memory or from the sitemap. Redesigns change URLs in ways nobody intends: a trailing slash gets added, a CMS inserts a category folder, uppercase silently becomes lowercase, a platform starts appending a file extension. Every one of those is a different address as far as Google is concerned, and every one of them is invisible until you diff the crawls.
| Situation | What to do | Why |
|---|---|---|
| URL unchanged | Nothing — but verify with a crawl diff | "Unchanged" is an assumption until two crawls agree |
| URL changed, page equivalent exists | 301 to the closest equivalent | Transfers accumulated authority to the successor |
| Two old pages merged into one | 301 both to the merged page | Consolidates signals rather than splitting them |
| Page deleted, had traffic or backlinks | 301 to the nearest relevant page | Recovers value that would otherwise be discarded |
| Page deleted, no traffic and no links | Let it 404 cleanly | An irrelevant redirect is worse than an honest 404 |
| No equivalent page anywhere | 301 to the parent category, not the homepage | Bulk homepage redirects are treated as soft 404s |
Redirect rules that preserve authority
Four rules cover most of the damage we see.
Use 301, not 302. A 301 is permanent and passes authority. A 302 is temporary and tells Google to keep the old URL indexed. Development teams reach for 302 because it is easier to reverse, and then it never gets changed.
Redirect once, never in a chain. Old URL to new URL, one hop. Chains — where A redirects to B which redirects to C — waste crawl budget and dilute the signals passing through. Chains appear when a site has been redesigned more than once and the old redirect rules were never flattened. If this is your second or third rebuild, audit the existing rules before adding to them.
Point every redirect at the closest equivalent. A page about drain repair should redirect to the drain repair page, not to the services index and not to the homepage. Bulk redirects to the homepage are the single laziest migration move available, and Google's response is to treat them as soft 404s and discard most of the value.
Update internal links directly. This one gets ignored because redirects make it invisible — the links still work, so nobody notices. But a link pointing at a redirected URL passes its authority through an extra hop, and it signals a site that has not been maintained. Find and replace old URLs across navigation, body content, footers and CTAs. Redirects are the safety net for external links you cannot control. Your own links you can control, so control them.
What to keep, change, and leave alone
The rule is short: content that generates traffic does not get changed without looking at the data first.
This runs directly against how redesigns usually feel. There is a strong instinct to rewrite everything, because the old copy looks dated next to the new design. But the page that has ranked third for "emergency plumber Etobicoke" for two years is ranking for reasons that are partly invisible to you, and rewriting it on aesthetic instinct is gambling with an asset that pays monthly.
A practical division:
- Leave alone: body copy, headings and page titles on your top 20 pages by clicks and conversions. Redesign the template around them. New typography, new layout, new imagery, same words.
- Improve carefully: pages ranking on page two. There is real upside in expanding these, and limited downside. Add rather than replace.
- Rewrite freely: pages with no traffic, no rankings and no backlinks. This is most of the site on most sites, and it is where the redesign energy should go.
The same discipline applies to page titles and meta descriptions. If a title is earning clicks, it is doing its job regardless of whether it fits the new brand voice. Our post on design mistakes that damage SEO covers the adjacent version of this problem, where the design itself is the thing suppressing performance.
The staging trap that de-indexes whole sites
If you read nothing else here, read this section. It is the most common catastrophic failure and the easiest to prevent.
Staging sites are blocked from search engines during development — correctly so, because you do not want a half-finished build competing with your live site. That block is implemented as a noindex meta tag, a robots.txt disallow rule, a server-level X-Robots-Tag header, or some combination.
When the staging build gets pushed to production, those settings come with it. They are configuration, not visible content, so nothing looks wrong. The site is beautiful. Every stakeholder signs off. Google cannot see any of it.
By the time rankings visibly collapse, one to three weeks have usually passed, and recovery takes considerably longer than the outage did. We have been called in to diagnose this more times than any other single migration failure, and the fix is always trivial — which is what makes it so expensive.
Two safeguards. First, assign one named person a single explicit task: remove the noindex and the robots.txt disallow at launch. Not "the dev team will handle it" — a person, by name, with that one item. Second, have someone other than that person verify it independently within an hour of launch. It takes ninety seconds and it is the highest-return ninety seconds in the entire project.
Launch day: the 90-minute checklist
Run this in order, immediately after the site goes live. All of it fits in an afternoon.
- Check robots.txt. Load
yoursite.com/robots.txtin a browser. Confirm there is noDisallow: /on the root. - Check for noindex. View source on the homepage and three interior pages. Search for "noindex". It should not appear. Check the response headers too, not just the HTML.
- Spot-check redirects. Take your top 20 URLs by clicks from the map and request each old address. Confirm a single 301 landing on the intended page — not a chain, not a 404, not the homepage.
- Verify canonicals. Each page should have a self-referencing canonical pointing at the new URL. Canonicals left pointing at staging URLs are a quieter version of the noindex problem.
- Submit the new XML sitemap in Search Console, and confirm it contains the new URLs and none of the dead ones.
- Confirm analytics and tag manager are firing on the new templates. Tracking code is routinely lost in a rebuild, and without it you cannot measure the recovery you are about to monitor.
- Check Core Web Vitals on a handful of templates. New designs frequently ship heavier than what they replaced, and page speed is the one ranking factor a redesign can improve or degrade overnight — see our notes on how images affect website speed.
- Request indexing for the homepage and top pages via URL Inspection to accelerate the recrawl.
The first 90 days: what normal looks like
A dip is not a failure. Panicking at week two and reverting a migration is how a temporary dip becomes a permanent one. Here is the curve to measure against:
| Window | What is normal | What to do |
|---|---|---|
| Days 1–7 | Rankings fluctuate, crawl activity spikes | Watch Search Console coverage for 404 and redirect errors daily |
| Weeks 2–4 | Traffic down 10–25%, bottoming out | Fix every crawl error. Resist the urge to change anything else |
| Weeks 5–8 | Impressions begin trending back up | This is the checkpoint that matters. Direction over absolute numbers |
| Weeks 9–12 | Approaching or exceeding the old baseline | Start improving rather than repairing |
| Month 3+ | Still flat or falling | Something is broken. Re-audit indexing, redirects and canonicals |
Complex migrations on larger sites can legitimately take up to eight months to fully recover, so a big site still short of baseline at month four is not automatically in trouble. The diagnostic signal is the shape of the impressions curve, not its height. Rising slowly is fine. Flat at week eight is not.
Already launched and lost traffic? Start here
If the redesign has shipped and the traffic is gone, the order of investigation matters — most people start with the hardest possibility and never reach the easy one that is actually the cause. Work through it in this sequence, because it runs cheapest and most likely first.
- Confirm Google can see the site at all. Check robots.txt for a root disallow, view source for a noindex tag, and check response headers for an X-Robots-Tag. Then run a
site:yourdomain.comsearch. If your page count has collapsed, this is your answer and it is a one-line fix. - Check Search Console coverage. Look at the Pages report for a spike in "Excluded" or "Not indexed" URLs. The reason given there usually names the problem outright.
- Test your top 20 old URLs by hand. Pull them from your pre-launch performance export, request each one, and record what actually happens. Chains, 404s and homepage redirects will surface immediately.
- Compare old and new content on your best pages. If a page that ranked has lost half its word count or had its H1 and title rewritten, that is a likely cause and it is reversible.
- Check canonicals. Canonical tags still pointing at staging URLs, or at the old domain, will suppress the new pages while looking completely normal in the browser.
The one thing not to do is revert. A rollback means the site migrates twice, doubling the disruption and destroying the evidence you need to diagnose the first move. Fix forward. If you did not run a pre-launch crawl and no longer know what the old URLs were, Search Console's 16-month performance export and the Wayback Machine will reconstruct a usable portion of the list — incomplete, but enough to recover the pages that were actually earning.
Migration mistakes we get called in to fix
- No pre-launch crawl. The old URLs were never recorded, so the redirect map has to be reconstructed from Search Console fragments and the Wayback Machine. Recoverable, but expensive and never complete.
- Everything redirected to the homepage. Fast to implement, treated as a soft 404, discards most of the authority it was supposed to preserve.
- Redirect chains from a previous rebuild. Third redesign, three layers of rules, nobody flattened them. Crawl budget bleeds away on hops.
- Staging noindex shipped to production. The classic. Invisible to everyone reviewing the site, fatal to rankings.
- Content culled without checking backlinks. Pages with no traffic but strong external links get deleted in a tidy-up, and the link equity goes with them.
- Tracking dropped in the rebuild. Analytics never reinstalled, so there is no data to diagnose the drop with once someone notices it.
- Reverting at week two. The dip was normal, the panic was not, and now the site has migrated twice.
Planning a rebuild in Toronto
A migration done properly is unglamorous work: crawls, spreadsheets, a redirect map nobody will ever look at again, and ninety minutes of checks on launch day. It is also the difference between a redesign that pays for itself and one that quietly costs you a year of lead flow.
If you are weighing a rebuild, our post on redesign versus a new website is the right place to start, because the cheapest migration is the one you do not need. When a rebuild is the right call, Creative Scope handles web design and the SEO migration as one project rather than two, and keeps the site maintained afterward so the next rebuild is smaller.
Call (905) 746-9209 or get in touch and we will tell you what your current site is actually earning before anyone talks about replacing it.
For related reading, see our guide to design mistakes that hurt SEO, our monthly maintenance checklist, or keep reading the blog.
