Most migrations lose traffic not because the new site is worse, but because nobody owned the SEO handover: URLs changed without redirects, titles reset to defaults, and the sitemap went stale the day the DNS flipped. The losses are avoidable. The short version: a site migration done with a disciplined checklist – benchmarked before, mapped cleanly, monitored daily for a month – can hold rankings through a replatform, and this guide gives you that checklist as agencies and in-house teams run it in 2026. When the stakes justify it, pairing with an experienced SEO partner for the migration window is the cheapest insurance you will ever buy.
—
Table of Contents
What Counts as a Site Migration
Any change that materially alters how search engines see, fetch, or understand your site qualifies. That includes the obvious full replatforms and the sneaky partial ones that teams routinely underestimate:
- Platform migration: moving CMS – WordPress to Shopify, custom build to Webflow, or any legacy system to a modern stack.
- Domain migration: rebranding to a new domain, or consolidating multiple domains into one.
- Protocol and subdomain changes: HTTP to HTTPS finalization, www to non-www, or moving a blog from blog.domain.com to domain.com/blog.
- URL structure changes: reworking slug patterns, category trees, or pagination – often more disruptive than a platform swap because every URL changes at once.
- Design and template overhaul: same URLs but new templates frequently reset headings, internal links, structured data, and metadata by accident.
- Server and hosting moves: new infrastructure usually escapes SEO damage, but server-side rendering changes, caching layers, and security rules can quietly break crawling.
Scope determines risk. The more of these happening simultaneously, the harder attribution becomes when something dips – so stage what you can, and never combine a replatform with a domain change and a URL restructure in a single cutover unless there is no alternative.
Before the Migration: The Pre-Launch Checklist
Everything on the old site that search engines value must be inventoried while it is still live, because there is no going back to measure after cutover. This benchmark capture is the step teams skip and spend six months regretting.
1. Capture the full SEO baseline (2-4 weeks before)
- Export Search Console data: queries, pages, impressions, clicks, and positions for the last 12-16 months.
- Crawl the entire site with Screaming Frog or Sitebulb – every URL with its title, meta description, H1, canonical, indexability status, and inbound internal link count.
- Export current rankings for money keywords from your rank tracker, dated and archived.
- Back up analytics views and conversion definitions so post-migration reporting compares like-for-like.
- Save the full backlink profile export from your link index – you will need it to prioritize redirect targets.
2. Freeze and document content and templates
Stop publishing on the old site a week before cutover if feasible – content added late often fails to migrate. Meanwhile, document which template types exist, which structured data they carry, and which pages earn the majority of organic entrances. On most sites, 10-15 percent of URLs drive 80 percent of organic traffic; those pages get white-glove treatment and manual QA.
3. Prepare the staging environment properly
The staging site must be identical in content and markup, but invisible to search engines: authentication-gated or robots.txt-disallowed, with a sitewide noindex as belt-and-suspenders. Every year, sites leak staging duplicates into the index and then wonder why duplicate content issues appear after launch. Confirm the staging block, then verify Google has never indexed the staging hostname before it touches production data.
4. Audit the new site before it inherits anything
Run a full technical audit on staging as if it were a stranger’s website: indexability, canonical logic, heading structure, structured data, page speed, internal linking, and template-level metadata. This is effectively a technical SEO audit of the new build – and finding problems here is ten times cheaper than finding them in week two of a live rankings slide.
| Timing | Task | Owner | Done When |
|---|---|---|---|
| T-4 weeks | Capture SEO baseline (GSC, crawl, rankings, links) | SEO | Exports archived and dated |
| T-3 weeks | Build URL inventory and redirect map draft | SEO + Dev | 100% of indexed URLs mapped |
| T-2 weeks | Full technical audit of staging build | SEO | All priority issues fixed |
| T-1 week | Content freeze; QA money pages on staging | Content | Top pages manually verified |
| T-3 days | Redirect map staged and tested on staging | Dev | Zero chains, zero loops in test |
| T-1 day | Rollback plan documented; comms aligned | PM | Everyone knows the go/no-go gates |
URL Mapping and Redirect Architecture
The redirect map is the single highest-stakes artifact of any migration. Its job: every URL that exists today lands on the closest equivalent URL tomorrow, in one hop, forever.
Build the map from indexed URLs, not from the sitemap alone
Your source list must include every indexed URL (from Search Console and the crawl), every URL with external backlinks, and every URL that converts – not just what the current sitemap happens to list. Missed URLs become 404s, and 404’d pages with backlinks throw away their equity permanently.
Map to the closest equivalent, one-to-one where possible
Redirect by relevance, not by convenience. Sending every old URL to the homepage is the classic migration sin – Google treats it as soft-404 behavior and drops the rankings those pages earned. Product-to-product, post-to-post, category-to-category; where a true equivalent is gone, map to the closest parent or hub, and only fall back to the homepage as a last resort.
One hop, no chains, no loops
Chained redirects (A to B to C) leak equity at each hop, slow crawlers, and break in unpredictable ways when one link in the chain is later edited. Test the staged map for chains and loops before launch – a crawler pointed at a test list of old URLs will trace each hop. The full 301-vs-302 decision framework, rules for redirecting redirected URLs, and post-migration redirect hygiene live in the guide to redirect management.
| Scenario | Correct Mapping | Wrong Mapping (Common) |
|---|---|---|
| Product URL changed slug | Old product URL 301 to new product URL | Redirecting all products to the shop homepage |
| Blog moved to /blog/ path | Old post URL 301 to /blog/post-slug/ | Trailing-slash variants left unmapped |
| Category merged into another | Old category 301 to surviving category | Leaving the old category as a live 200 duplicate |
| Page truly discontinued | 301 to closest parent or hub page | 410/404 with no equity transfer |
| Domain consolidation | Every legacy URL 301 to its match | Blanket domain-root redirect for everything |
Launch Day Checklist
Cutover day is a controlled sequence, not a big bang. Run these checks in order, and hold the go/no-go gate at each step:
- Backup everything on the old site – files, database, and a full HTML crawl snapshot – before anything changes.
- Verify staging is noindexed, then deploy. The moment the new site goes live, immediately remove the noindex and robots.txt block. A live site that launches with staging blocks still in place is the most common self-inflicted migration outage in SEO.
- Confirm HTTPS, www/non-www, and trailing-slash variants all resolve to one canonical form per URL, with clean certificate chains.
- Activate the redirect map and spot-check 50 URLs across templates – manually in a browser with redirect tracing on, including your 20 highest-traffic pages.
- Upload the new XML sitemap to Search Console the same day, containing only final, canonical, 200-status URLs. Sitemap construction rules are in the guide to XML sitemap best practices.
- Run URL Inspection on priority pages to confirm Google’s first fetch of each sees a live, indexable, canonical-consistent page.
- Verify robots.txt on the new host points at the live sitemap and blocks nothing that matters – syntax and examples in the guide to robots.txt for SEO.
- Smoke-test conversion paths: forms, checkout, and tracking fire correctly. An SEO-perfect launch that breaks revenue is still a failed launch.
The First 30 Days: Monitoring and Recovery
Expect turbulence. Even clean migrations show 1-3 weeks of ranking volatility while Google recrawls, re-evaluates, and reweights the new architecture. The monitoring cadence that catches problems while they are still cheap:
- Daily, weeks 1-2: Search Console coverage and crawl stats for error spikes; rank tracker for money keywords; server logs for Googlebot 4xx/5xx rates; redirect log for hits on unmapped URLs.
- Weekly, weeks 3-4: compare clicks and impressions against the baseline export at page level, not just in aggregate; crawl the new site fully and diff it against the pre-launch crawl.
- Ongoing: watch for index bloat emerging from new templates – leftover facet, tag, or parameter patterns are explained in the guide to fixing index bloat.
| Symptom in Weeks 1-4 | Likely Cause | First Response |
|---|---|---|
| Pages drop to “Discovered – not indexed” | Crawl pressure from redirect volume | Verify redirects resolve in one hop; resubmit sitemap |
| Sitewide deindexing | noindex or robots block left from staging | Remove block same hour; request indexing on money pages |
| 404 spikes on old URLs | Gaps in the redirect map | Extend map from GSC and log data; deploy additions |
| Rankings slide on money pages | Content or internal link differences in new templates | Diff new vs old HTML; restore missing elements |
| Duplicate title/description explosion | Template defaults overwrote metadata | Re-import metadata from baseline export |
| Traffic fine, conversions zero | Tracking or form breakage | Fix analytics and conversion paths immediately |
Set expectations with stakeholders in writing before launch: a 10-20 percent temporary dip inside the first fortnight is normal and recovers; a continuous decline past week four is a defect list, not volatility. Teams that freeze after launch – no fixes, no monitoring – convert temporary dips into permanent losses; teams that treat week one as a QA sprint typically land above baseline within 4-8 weeks, which is precisely why migrations are a core service line for technical Digimau engagements rather than an afterthought handed to whoever launched the site.
Common Migration Mistakes That Cost Rankings
- No baseline, no attribution: without archived exports you cannot distinguish migration damage from normal seasonality – and you cannot prove recovery. Capture the baseline even if the timeline is tight.
- Homepage-bound redirects: mapping every unmatched URL to the homepage reads as soft-404 behavior and burns equity. Map to the closest equivalent.
- 302s used for permanent moves: temporary redirects pass weaker consolidation signals and Google keeps the old URL alive longer. Permanent changes get 301s.
- Letting staging into the index: an indexed staging hostname creates a duplicate site that competes with production for weeks. Gate it before data ever lands there.
- Big-bang cutover of everything at once: replatform, domain, and URL restructure in one day makes every dip undiagnosable. Stage what you can.
- Switching off the old sitemap and forgetting the new one: the new sitemap is Google’s fastest map of what changed. Submit it on day one and monitor its processing.
- Deleting redirect maps after “enough time”: old URLs keep earning links and type-in traffic for years. Redirects from a migration are permanent infrastructure, not a temporary patch.
Frequently Asked Questions
How long does SEO recovery take after a website migration?
A clean migration typically shows 1-3 weeks of volatility with recovery to baseline within 4-8 weeks. Migrations with mapping gaps or template regressions can take 3-6 months, with recovery time tracking how quickly defects are found and fixed.
Will changing my domain ruin my SEO?
Not if executed correctly. A domain migration with complete one-to-one redirects, updated backlink outreach to key referrers, and Search Console change-of-address can retain most rankings. Losses usually come from incomplete redirect maps, not from the domain change itself.
Should I use 301 or 302 redirects for a migration?
Use 301s for permanent moves – which migrations almost always are. 302s signal temporariness, pass weaker consolidation signals, and leave old URLs alive in the index longer than intended.
How do I migrate a website without losing traffic?
Benchmark everything first, map every indexed and backlinked URL to its closest equivalent with single-hop 301s, audit the new build on staging, remove all staging blocks before launch, submit the new sitemap immediately, and monitor Search Console daily for the first month with a defect-response plan.
Is it normal to lose rankings after migrating to a new platform?
Short-term volatility is normal even on clean migrations. Sustained losses are not – they indicate redirect gaps, missing metadata, content differences in new templates, or internal link structure changes that need to be diffed and fixed.
What should I do with old URLs after a migration?
Redirect them permanently – one hop to the closest equivalent page. Do not delete redirect rules after a few months; old URLs accumulate links and direct traffic indefinitely, and every unmapped old URL is thrown-away equity.
How do I tell Google my website address has changed?
For domain moves, use Search Console’s Change of Address tool after the 301 redirects are live, and submit the new domain’s sitemap. The redirects carry rankings; the tool accelerates Google’s processing of the move.
What is the biggest SEO mistake in website redesigns?
Assuming “same content, new design” needs no SEO oversight. New templates routinely reset titles, headings, canonicals, structured data, and internal links. Redesigns need the same baseline, mapping, and QA discipline as replatforms.
Should I migrate everything at once or in stages?
Stage what you can. Separating platform, domain, and URL-structure changes into phases makes every ranking movement attributable and fixable. Simultaneous cutovers multiply risk and destroy diagnostic clarity.
How do I test redirects before launch day?
Stage the full redirect map on the destination server, then crawl a test list of old URLs with a redirect-tracing crawler. Zero chains, zero loops, and every URL landing on a 200-status equivalent means the map is launch-ready.
Related Articles
Keep reading with these guides:
