Replatforming is one of the few projects that can erase years of search equity in a weekend. New site goes live, old URLs return 404s, internal links point nowhere, and three weeks later organic traffic is down forty per cent and nobody is sure why.
It is almost entirely preventable. Here is the process we run on every migration, including the checklist we hand to clients.
Why migrations lose traffic
Search engines rank URLs, not businesses. When a URL disappears, the signals attached to it (links, history, relevance) disappear with it unless you explicitly tell the engine where they moved. Most traffic loss comes from four mistakes:
- URLs change without one-to-one 301 redirects
- Content that ranked gets consolidated, trimmed or rewritten out of existence
- Internal linking structure changes, so authority stops flowing to the pages that need it
- Technical regressions: client-side rendering, blocked resources, broken canonicals, noindex left on from staging
Before you touch anything
The work that decides the outcome happens before development starts.
Crawl and benchmark
Crawl the existing site completely and export every URL with its status, title, canonical, word count and inbound internal links. Pull twelve months of Search Console data so you know which URLs actually earn impressions and clicks. That dataset is your baseline and your safety net.
Identify the pages that matter
Usually a small share of URLs drive most organic value. Those pages get special treatment: their content survives substantially intact, their URL ideally stays the same, and they get checked individually after launch.
Map every URL
Build a redirect map from every old URL to its most relevant new equivalent. Not to the homepage, redirecting everything to the homepage is treated as a soft 404 and throws the equity away.
During the build
- Keep URL structures unchanged wherever there is no strong reason to change them
- Server-render content so crawlers see it without executing JavaScript
- Carry over titles, meta descriptions, headings and structured data for priority pages
- Preserve the internal linking to priority pages, or strengthen it
- Block the staging site from indexing, and put a launch-day check on removing that block
Launch day
Deploy redirects at the same moment as the new site, not the next morning. Then verify rather than assume:
- Crawl the old URL list against the new site and confirm every one returns a 301 to a 200
- Check for redirect chains and loops, each old URL should resolve in a single hop
- Confirm robots.txt and meta robots are production values, not staging ones
- Submit the new XML sitemap in Search Console
- Spot-check priority pages for rendered content, canonicals and structured data
The first eight weeks
Some volatility is normal while engines recrawl and reprocess. What is not normal is a sustained drop on specific pages. Monitor at page level, not site level, because aggregate numbers hide the problems.
Watch Search Console coverage reports for spikes in 404s or excluded pages, compare priority-page rankings weekly against the baseline, and keep the old site crawl so you can diagnose anything unexpected. Most issues found in the first fortnight can be fixed before they cost you anything meaningful.
The migration checklist
- Full crawl of the old site, exported and archived
- Twelve months of Search Console and analytics data exported
- Priority pages identified and signed off
- Complete one-to-one redirect map, reviewed by someone who knows the content
- New site server-renders all indexable content
- Titles, metas, headings and schema carried over for priority pages
- Staging blocked from indexing; unblock step on the launch plan
- Redirects deployed at the same moment as the site
- Post-launch crawl of old URLs confirms single-hop 301s
- New sitemap submitted; page-level monitoring in place for eight weeks
Done properly, a migration should be neutral to positive for search, faster pages and cleaner structure usually help. If you are planning one, talk to us before you pick a launch date.
