SEO & migrations
Website migration without losing SEO: the actual checklist
A website migration loses rankings when URLs change and nothing tells search engines where the pages went. That is nearly the whole failure mode — and it is entirely preventable with a URL inventory, a one-to-one 301 redirect map, correct canonicals, and two weeks of watching Search Console after launch. This guide is the ordered checklist we run on every migration, including what to do before, during, and after the switch.
On this page
Why migrations lose rankings
Search engines rank URLs, not websites. Every ranking you have is attached to a specific address that has accumulated links, history, and trust. When a migration changes those addresses — new platform, new structure, new domain — and the old URLs start returning 404, that accumulated equity doesn’t transfer. It evaporates. Google sees thousands of dead pages and a set of brand-new ones with no history.
The fix is old, boring, and completely effective: a 301 permanent redirect from every old URL to its new counterpart. A 301 tells search engines “this page moved here — transfer the history.” Migrations that do this page-by-page typically see a dip of days to a few weeks and full recovery; migrations that skip it can lose the traffic permanently. Everything else in this guide is scaffolding around that one mechanism.
The most common real-world failure isn’t skipping redirects entirely — it’s the lazy version: redirecting every old URL to the new homepage. Google treats mass homepage redirects as soft-404s, and the page-level equity still dies. The redirect map must be one-to-one: old service page → new service page, old post → new post.
Before the move: inventory everything
You cannot redirect URLs you don’t know exist. Before anything is built, assemble the complete list of URLs that matter, from four sources — because each one catches pages the others miss:
- Crawl the live site (Screaming Frog or any crawler) — everything linked and reachable.
- Google Search Console → Performance, last 12 months — every URL that actually received search clicks or impressions, including ones nothing links to anymore.
- Analytics landing pages, last 12 months — URLs that receive traffic from anywhere (email, social, ads, bookmarks).
- Your existing sitemap.xml and any old redirect rules already in place — chained redirects from a previous migration are the classic silent killer.
Merge, dedupe, and rank by traffic and backlinks. The top slice — usually 10–20% of URLs carrying 90%+ of the search value — gets hand-verified mapping; the long tail can be pattern-mapped. While you’re in there, record each key page’s title, meta description, and H1: the new site should preserve or consciously improve them, not regenerate them from a template. This is also the moment to fix structure — our AI-SEO service treats a migration as the cheapest opportunity you will ever get to install a clean entity graph and structured data, since everything is being rebuilt anyway (the method is in our AI-era SEO guide).
The redirect map
The redirect map is a two-column spreadsheet: old URL → new URL, one row per page, status 301 (permanent), never 302 (temporary). Rules that keep it fair:
- One hop only. Old → new, directly. If the old site already had redirects, point the original URLs at the final destination too — chains of 2+ hops leak equity and slow crawls.
- Closest equivalent, not homepage. If a page has no true counterpart, redirect to the nearest relevant category or hub; only genuinely obsolete pages should 404 or 410.
- Keep the map alive. It ships with the site (server config, middleware, or hosting rules) and stays in place for years — old backlinks never stop arriving.
- Include the boring variants. http→https, www/non-www, trailing-slash — every variant should resolve in one hop to one canonical form.
Alongside redirects, three tags must be right on the new site: canonicals (every page self-canonical to its final URL — a canonical pointing at the old domain or a staging URL is a launch-week classic), hreflang if you run multiple languages (reciprocal pairs, like the EN/ES structure on this site), and noindex removal — staging sites are built noindexed, and shipping that tag to production is the single most catastrophic and most common migration bug. It belongs on the launch-day checklist in bold.
Launch day, in order
- Freeze content changes on the old site 48 hours before — the crawl you migrate from must match reality.
- Deploy the new site with the full redirect map live from the first minute.
- Remove noindex (meta tag, X-Robots-Tag header, and robots.txt disallow) — verify all three, they hide in different layers.
- Spot-check the top-50 URL list by hand: each old URL 301s in one hop to the right new page, each new page returns 200 with a self-canonical.
- Submit the new sitemap.xml in Google Search Console (and add a new GSC property first if the domain changed, plus the Change of Address tool for domain moves).
- Re-verify analytics, conversion tracking, and form submissions fire on the new pages — a migration that keeps rankings but silently drops lead tracking still loses you the leads.
- Purge CDN caches so nobody is served a stale mix of old and new.
After: the two-week watch
The first two weeks decide whether the dip is a blip or a cliff. Watch three panels in Search Console: Coverage/Indexing (are new URLs being indexed? are 404s spiking?), Performance (compare clicks week-over-week against the pre-launch baseline, per top page — not just sitewide), and Redirect health (re-crawl your own top-500 list with a crawler and fix any 404 or chain it finds). A temporary 10–20% dip for one to three weeks is normal while Google re-crawls; a 50% drop that keeps falling means something structural — usually a leftover noindex, a broken redirect pattern, or canonicals pointing at the wrong host.
This is also where hosting quality shows up: if the new server is slower than the old one, you migrated into a rankings headwind. Speed is a ranking input and a conversion input — the business case is in our Core Web Vitals guide — and it is a core reason our builds ship static-first on infrastructure we manage directly rather than on shared platform hosting like the setups we compare in OptimoWeb vs GoDaddy and vs Wix.
The full checklist
- Crawl old site + GSC 12-month URLs + analytics landing pages + old sitemap → master URL inventory.
- Record titles/descriptions/H1s of top pages; preserve or consciously improve on the new build.
- Build a one-to-one 301 map (one hop, closest equivalent, no homepage dumping); include protocol/www/slash variants.
- Verify canonicals self-reference final URLs; hreflang pairs reciprocal; structured data upgraded while you’re in there.
- Launch: redirects live minute one, noindex removed in all three layers, sitemap submitted, tracking verified, CDN purged.
- Domain change only: new GSC property + Change of Address tool.
- Weeks 1–2: daily GSC coverage + performance vs baseline; re-crawl top-500; fix 404s and chains same-day.
- Keep the redirect map in place permanently.
Most of this is discipline, not genius — which is exactly why it gets skipped when a migration is rushed. If you are moving off a platform to a site you own, the migration is the moment your new build either inherits years of SEO equity or starts from zero. We run this checklist on every move, whether it is a professional-services firm leaving a page builder, a restaurant escaping a platform, or a store replatforming onto headless commerce. Start a project and the inventory is step one.
Questions
FAQ
Will I lose Google rankings if I redesign or migrate my website?
Only if URLs change and nothing maps the old addresses to the new ones. Rankings attach to URLs; a one-to-one 301 redirect map transfers that equity to the new pages. Done properly, a migration typically shows a small dip for one to three weeks while Google re-crawls, then recovers. Done without redirects — or with everything dumped on the homepage — the lost equity can be permanent.
What is a 301 redirect and why does it matter so much?
A 301 is a permanent redirect: it tells browsers and search engines that a page has moved to a new address and that the old page’s history — links, trust, ranking signals — should transfer. It is the single mechanism that carries SEO equity through a migration. Use 301 (permanent), not 302 (temporary), and map each old URL to its closest new equivalent in one hop.
How long does SEO take to recover after a migration?
With a clean one-to-one redirect map, correct canonicals, and a submitted sitemap, expect a dip of roughly one to three weeks while search engines re-crawl and reconcile — larger sites take longer than small ones. A drop that exceeds ~30–50% or keeps falling after two weeks signals a structural problem: usually a leftover noindex tag, broken redirect patterns, or canonicals pointing at the old host.
Do I need to redirect every single old URL?
Every URL that has traffic, backlinks, or search impressions — which you find by merging a site crawl with 12 months of Search Console and analytics data. The high-value slice gets hand-verified one-to-one mapping; the long tail can be pattern-mapped. Genuinely obsolete pages with no equity can return 404/410, but never mass-redirect everything to the homepage — Google treats that as soft-404s.
What is the most common migration mistake?
Shipping the staging site’s noindex to production. Staging environments are correctly built with noindex (meta tag, X-Robots-Tag header, robots.txt), and forgetting to remove all three layers at launch silently deindexes the new site. The runners-up: redirect chains left over from previous migrations, and canonicals still pointing at the staging or old domain. All three are five-minute checks on launch day.
Where this applies
Industries this matters most for.
Put this into practice
We'll scope it clearly — including telling you when the simpler path is the right one. One operator, the full open-source stack, built so you own what we ship.