Website Migration SEO Checklist: Relaunch Without Losing Rankings

Ask any SEO consultant what causes the worst traffic collapses they have seen, and almost none of them will name an algorithm update. They will name a relaunch — a redesign, a replatform, a domain change — that went live on a Friday afternoon with nobody checking the redirects.

The frustrating part is that migration losses are almost entirely preventable. They are not caused by anything mysterious; they are caused by a small, well-known set of mistakes made under deadline pressure. This checklist covers all of them, in the order the work actually happens.

---

Know Which Kind of Migration You Are Running

The word "migration" covers five very different projects with very different risk profiles.

Type	What changes	Risk
Design refresh	Visuals only, URLs and content unchanged	Low
Protocol or host change	HTTP to HTTPS, or new hosting	Low to medium
URL structure change	New paths, same domain	High
Platform or CMS change	New system, usually new URLs and templates	High
Domain change	Everything moves	Very high

The single best risk-reduction decision available to you: do not combine types. Changing the platform, the URL structure and the design at once means that when traffic drops, you cannot tell which change caused it. Separate them by four to six weeks and every problem becomes diagnosable.

---

Phase 1: Benchmark Before You Touch Anything

You cannot detect damage you have no baseline for. Two weeks before launch, capture and archive:

1. A full crawl of the current site — every URL with its status code, title, meta description, H1, word count, canonical and internal inlink count.
2. Search Console export — 16 months of clicks, impressions and average position, by page and by query.
3. Analytics export — sessions, conversions and revenue by landing page for the last 12 months.
4. Backlink export — every referring domain and the exact URL it points to. These are the pages you must never break.
5. Rank tracking snapshot for your top 100 keywords.
6. Core Web Vitals baseline for each major template.

Store these as dated files. When someone asks in six weeks whether traffic is actually down, you want data, not recollection.

---

Phase 2: Build the Redirect Map

The redirect map is the migration. Everything else is secondary.

• Map old URL to new URL one to one. Every indexed old URL gets a specific, relevant destination.
• Use 301, not 302. Temporary redirects do not transfer signals reliably over the long term.
• Never redirect everything to the homepage. Search engines treat irrelevant mass redirects as soft 404s and the accumulated equity is lost.
• Eliminate chains. Old A to new B is fine; A to B to C loses value and crawl efficiency. If earlier redirects already exist, flatten them so every legacy URL points directly at the final destination.
• Cover the long tail. Pattern-based rules handle bulk paths, but manually map your top 200 URLs by traffic and every URL with a backlink.
• Do not redirect to a 404 or a noindex page. Validate every destination before launch.
• Decide about genuinely retired content. If a page has no equivalent, redirect to the closest relevant parent — or return 410 deliberately if it has no traffic and no links.

Test the redirect map on staging with an automated crawl of every old URL. A spreadsheet that has never been executed is a hypothesis, not a plan.

---

Phase 3: Preserve What Made Pages Rank

A redesign that keeps the URLs but discards the content still loses rankings. Preserve, page by page:

• Title tags and meta descriptions — do not let a new CMS regenerate them from templates.
• Heading structure — H1s in particular are frequently downgraded to styled divs during redesigns.
• Body content and word count. Cutting text to fit a cleaner design is the most common self-inflicted migration injury.
• Structured data — Product, FAQ, LocalBusiness, Article markup all need to be reimplemented, not assumed.
• Internal links. Update them to point at new URLs directly rather than relying on redirects.
• Canonical tags and hreflang — regenerate for the new URL structure and verify the pairs are reciprocal.
• Image filenames and alt text, which carry image search traffic that is easy to lose silently.

---

Phase 4: Staging Checks That Prevent Disasters

Two mistakes account for a large share of catastrophic launches, and both are trivially preventable:

1. The staging noindex tag going live. Staging sites are correctly blocked from indexing — and then that block ships to production. Verify the live robots.txt and the meta robots tag on the first three pages within minutes of launch. This one mistake has cost more traffic than every algorithm update combined.
2. Staging URLs in production. Absolute links to staging.example.com in navigation, canonicals or sitemaps leak into the index. Crawl the production build for the staging hostname before and after launch.

Also verify on staging: redirects respond 301, HTTPS certificate valid for all hostnames, the XML sitemap lists only new canonical URLs, and pagination and faceted rules survived the rebuild.

---

Phase 5: Launch Day Runbook

1. Launch early in the week and early in the day. Never on a Friday — you need people available for 48 hours.
2. Within 15 minutes: check robots.txt, meta robots on key templates, and that the homepage returns 200.
3. Within one hour: run the full old-URL list through a crawler and confirm every one returns 301 to a live 200 destination.
4. Within two hours: submit the new XML sitemap in Search Console, and for a domain change submit the Change of Address.
5. Same day: verify analytics and consent tracking are firing, confirm structured data validates, and spot-check the twenty highest-traffic pages by hand.
6. Same day: keep the old sitemap accessible for a few weeks so search engines rediscover old URLs and process the redirects faster.

---

Phase 6: The First Month

Some ranking volatility after a large migration is normal. The pattern to expect is a dip of one to three weeks followed by recovery to previous levels, and often above them if the new site is faster.

• Days 1–7: check Search Console coverage daily for new 404s and unexpected exclusions. Fix broken redirects immediately.
• Week 2: compare indexed URL counts old versus new. A large shortfall means discovery problems, not ranking problems.
• Week 3–4: compare per-page clicks against your pre-launch baseline. Investigate individual pages that lost more than 30%.
• Ongoing: keep redirects in place permanently. Removing them after six months undoes the migration.

---

If Traffic Drops, Diagnose in This Order

1. Indexability. Is anything noindexed or robots-blocked that should not be? This is the first and most common cause.
2. Redirects. Crawl the old URL list again — broken and chained redirects are the second most common cause.
3. Content parity. Compare word counts and headings before and after for the affected pages.
4. Internal linking. Did navigation change and orphan a section of the site?
5. Speed. Compare Core Web Vitals against baseline — new frameworks frequently ship heavier JavaScript.
6. Rendering. If the rebuild moved to a client-rendered stack, verify content appears in the raw HTML, as covered in our JavaScript SEO rendering audit.

Work the list in order. Most migration recoveries are completed at step one or two.

---

The 20-Point Migration Checklist

1. Full crawl of the old site archived.
2. 16 months of Search Console data exported.
3. Analytics and revenue by landing page exported.
4. Backlink list exported and linked URLs flagged.
5. Rank tracking snapshot taken.
6. Core Web Vitals baseline recorded per template.
7. One-to-one redirect map built for every indexed URL.
8. Top 200 URLs and all linked URLs mapped manually.
9. Redirect chains flattened.
10. Redirect map tested on staging by crawl.
11. Titles, descriptions and headings preserved.
12. Body content preserved without silent trimming.
13. Structured data reimplemented and validated.
14. Internal links updated to new URLs directly.
15. Canonicals and hreflang regenerated and reciprocal.
16. Staging noindex and robots.txt block removed at launch.
17. No staging hostnames present in production HTML.
18. New XML sitemap submitted; old sitemap kept temporarily.
19. Change of Address filed for domain migrations.
20. Daily monitoring for the first week, weekly for the first month.

Domain Changes Have Their Own Rules

Moving to a new domain is the only migration type where you also lose the accumulated trust attached to the old hostname. Everything in this guide still applies, plus five additional steps:

1. File the Change of Address in Search Console immediately after launch, with both properties verified. This is not optional — it is the signal that tells Google the move is deliberate.
2. Keep the old domain registered for years, not months. The redirects have to keep working, and letting the domain lapse hands your backlink profile to whoever buys it next.
3. Contact your top 20 linking sites and ask them to update the URL. Direct links carry more weight than redirected ones, and the twenty most valuable are worth an hour of outreach.
4. Update everything you control off-site: social profiles, Google Business Profile, directory listings, email signatures, invoices, ad accounts and analytics property settings.
5. Expect three to six months for full stabilisation, and communicate that to stakeholders before launch rather than during the dip.

---

The Process Side Nobody Documents

Most failed migrations are not technical failures — they are process failures. Four practices prevent the majority of them:

• Name one accountable owner for SEO continuity, with authority to delay launch. If nobody can say no, the redirect map ships untested.
• Freeze content changes for two weeks before and after launch, so that content edits are not confounded with migration effects.
• Write the rollback plan first. Know exactly how to revert DNS, restore the previous build and re-enable old redirects — and how long each takes.
• Get sign-off on the redirect map from whoever knows the business, not only from whoever built the site. Developers know URL patterns; marketers know which campaign landing page still receives paid traffic.

The most expensive migration mistakes are made in the last 48 hours, under pressure, by people who were not in the planning meeting. A written runbook is the cheapest insurance available.

---

Migrating Multi-Language Sites

International sites double the failure surface. Beyond the standard checklist, verify that hreflang annotations are regenerated for the new URL structure and remain reciprocal in both directions, that each language version redirects to the same language version rather than defaulting to English, and that language subfolders or subdomains keep the same structure as before unless changing it is the explicit goal of the project.

The most common multi-language migration failure is subtle: redirects that collapse all localised versions to a single default page. Traffic from every non-primary market drops simultaneously, and because the total looks like a general dip nobody isolates the pattern for weeks. Segment your post-launch monitoring by language from day one.

---

Audit Before and After — Same Tool, Same Settings

The most valuable migration artefact is a pair of comparable audits: one a week before launch, one the day after. Run both with identical settings so the differences are real differences rather than measurement noise.

Run a free audit with WebSEO Auditor to capture your pre-migration baseline today, then re-run it on launch day to catch problems within hours instead of weeks.