Search guide
Site migrations, and the four ways they usually go wrong
Almost every catastrophic traffic loss we get called about is a redesign. Not a penalty, not an update. Somebody rebuilt the site and nobody mapped the old URLs to the new ones.
12 min read · 7 steps · By Aman Mishra · Written August 2026
What you end up with
A recorded baseline, a complete redirect map tested before launch, a first hour checklist, and a way to tell whether the post launch dip is normal.
Have these ready
- A full crawl of the current site
- Search Console and analytics access
- Somebody who can edit redirects after launch
What it takes
12 min to read
7 steps, in the order below. Skip to the one you are stuck on.
The single most reliable way for a business to lose most of its organic traffic is to launch a new website.
Not because new websites are bad. Because the person building it was hired to make it look better, and nothing in that brief includes the two hundred URLs the old site had.
-
Record the baseline before anything changes
You cannot tell whether a migration went wrong without knowing what normal looked like. This is the step that is impossible to do afterwards.
This step cannot be done later, which is why it is first.
Before launch, export and save: twelve months of Search Console performance data by page and by query, twelve months of analytics traffic by landing page, your current rankings for the terms you care about, and a full crawl of the site.
Save it somewhere outside the site. A folder with a date on it.
Without this you cannot answer the question everybody asks three weeks after launch, which is whether traffic is actually down and by how much. Comparing against memory produces arguments rather than answers.
-
Crawl the old site and export every URL
Every page, including the ones nobody remembers. The forgotten pages are usually the ones holding links.
Run a crawler over the live site and export the complete URL list.
Complete matters. Not the pages in the navigation. Every page: old blog posts, landing pages from campaigns that ended, PDFs, category pages, tag pages, paginated series, and the pages somebody built in 2021 for a partnership that no longer exists.
Cross-check the crawl against your Search Console page list and your analytics landing pages, because a crawl only finds pages that are linked from somewhere. Pages that receive traffic without being linked internally are exactly the ones nobody remembers, and they are disproportionately likely to have external links pointing at them.
-
Build the redirect map one URL at a time
Every old URL points at the closest equivalent new page. Redirecting everything to the homepage is the single most damaging shortcut available.
A spreadsheet with two columns: old URL, new URL.
Every old URL gets a destination, and the destination is the closest equivalent page. A blog post goes to the same blog post at its new address. A service page goes to the equivalent service page.
The shortcut that causes the damage is redirecting everything to the homepage. It is quick, it produces no 404s, and Google treats a redirect to an irrelevant page as a soft 404, so the ranking history is lost anyway. You have replaced a clear signal with a misleading one.
Where there is genuinely no equivalent page, decide deliberately: nearest relevant page, or a 404. Check for external links first, because a page with links deserves a real destination.
-
Test the redirects on staging before launch
A redirect map that has never been run is a spreadsheet. Test it against the exported list and check every one resolves in a single hop.
An untested redirect map is a document, not a redirect map.
Run the exported old URL list against staging and check three things for each.
It resolves. Not a 404, not a loop.
It is a 301. Permanent, not temporary. Temporary redirects tell Google not to transfer anything, and they get left in place for years.
It is one hop. Old URL straight to final destination. Chains accumulate when a site has been migrated more than once, and every hop loses a little and slows the crawl.
Fix everything that fails here. Fixing it after launch is the same work done under pressure with traffic falling.
-
Run the first hour checks
Robots file, noindex tags, canonicals, analytics, and a sample of redirects. The staging site blocking search engines is the classic and it happens constantly.
In order, immediately after go-live.
Robots.txt. The staging file blocking all crawlers is the most common serious migration error there is, and it will not be noticed by anyone testing the site in a browser.
Noindex tags. Same problem, page level. Check the source of several templates, not just the homepage.
Canonical tags. Should point to the new URLs, and to themselves. Canonicals still pointing at the old domain happen more often than you would expect.
Analytics and conversion tracking. Rebuilt sites lose tracking scripts routinely. Submit a test enquiry and confirm it appears.
A sample of redirects, live. Twenty from the list, including three deep pages nobody would think of.
Set a calendar reminder for the same checks a week later, because deployments after launch reintroduce these.
-
Submit the new structure and watch the right reports
New sitemap, old sitemap kept temporarily, and Search Console coverage watched daily for the first fortnight.
Generate and submit the new XML sitemap in Search Console.
Keep the old sitemap available for a few weeks if you can. It gives Google a list of the old URLs to recrawl and discover the redirects, which speeds up processing.
If the domain changed, use the change of address tool.
Then watch, daily for the first fortnight: the coverage report for a rise in 404s or excluded pages, the performance report for impressions by page, and your server logs if you have access, which show what is actually being crawled rather than what has been processed.
-
Know what a normal dip looks like
Some movement is expected and recovers. Knowing the difference between that and a real problem prevents both panic and complacency.
Some movement after a migration is expected. Knowing the shape prevents both panic and complacency.
Normal. A dip of some size in the first two weeks, recovering steadily over four to eight weeks on the same domain, longer on a new domain. Rankings moving around before settling near where they were.
Not normal. Traffic falling and staying flat for more than a month. Specific important pages disappearing entirely rather than moving. A rising 404 count in Search Console. Impressions holding steady while clicks collapse, which usually means titles and descriptions were rewritten badly.
If you see the second pattern, go back to the redirect map first. In our experience it is the cause considerably more often than anything else, and it is the one thing that is still fixable weeks later.
When you have done all 7
A recorded baseline, a complete redirect map tested before launch, a first hour checklist, and a way to tell whether the post launch dip is normal.