Skip to content

Checklist · 10 min read

Site Migration SEOMoving house without losing the post

Diagrams
02
Tools
03
Sections
08

The short answer

A website migration is any significant change to a site's domain, URLs, platform, structure or design that can affect how search engines crawl, index and rank it. Migration SEO protects existing visibility through a full URL inventory, one-to-one redirect mapping, pre-launch testing on staging, careful launch checks and close monitoring for several weeks afterwards.

Why migrations go wrong

Migrations are where years of accumulated search equity can be lost in an afternoon. Rarely through one dramatic error. More often through a hundred small ones: a section without redirects, a template that drops its title tags, a staging site's noindex left in place, internal links still pointing at old URLs, content quietly trimmed during the redesign.

The root cause is usually organisational. Migrations are run as design or engineering projects, with SEO consulted late or not at all. The single most valuable thing an SEO lead can do is be involved from the first planning meeting, when scope, URL structure and timelines are still open.

A migration is not finished when the new site launches; it is finished when search engines agree that it has.

Know what kind of migration you are running

Risk varies enormously by type. Changing a visual theme without touching URLs or content is low risk. Moving domain, platform and URL structure at the same time, while rewriting content, is the highest-risk change most websites ever make.

Fig. 01 · Scorecard

Relative risk by migration type

Bars show relative emphasis, not measured data

Weights express relative risk in our planning, not measured outcomes. Combining several types multiplies risk; separate them where you can.

Our strong advice: do not change everything at once if you can avoid it. Moving platform first and changing URLs later, or vice versa, makes problems easier to diagnose and limits the damage if something goes wrong. Business pressures sometimes make this impossible, but it should be argued for.

Phase 1: Planning and inventory

Checklist

0/7

Before any build work

The URL inventory must be complete, not just what a crawl finds today. Old URLs that still receive links or appear in sitemaps, campaign landing pages, PDFs and image URLs all matter. Backlink data is especially important: a URL with valuable external links that is not redirected throws those links away.

Capture copies of the old site's key templates too, either through an archive crawl or saved HTML. After launch, the most common question is 'what did this page used to say?', and having the answer to hand turns days of guesswork into minutes of comparison.

Phase 2: Redirect mapping

The redirect map is the heart of the migration. Every old URL that has value should 301 redirect to the most relevant new URL, in a single hop. One-to-one mapping where content continues; closest relevant page where it is merged; 404 or 410 where it is genuinely retired with no equivalent.

  • Avoid redirecting large numbers of old URLs to the home page; search engines may treat that as a soft 404.
  • Avoid chains: if old URLs already redirect, map them straight to the final new destination.
  • Preserve query-parameter URLs that matter, or map them deliberately.
  • Include images and documents with search traffic or links.
  • Test the map with real requests before launch, not just a spreadsheet review.

Phase 3: Pre-launch testing on staging

Crawl the staging site as a search engine would and compare it with the old site. The comparison should be systematic, template by template, not a scroll through the home page.

Checklist

0/10

Staging checks

Communicating with the business

Migrations fail politically as well as technically. If leadership expects traffic to rise on launch day, a normal period of fluctuation can trigger panic, rushed changes and blame. Set expectations in writing before launch: what is normal, how long stabilisation may take, which metrics will be watched and what would trigger the rollback plan.

Agree a launch freeze. During the first weeks after launch, avoid further structural changes, large content edits or new redirects unless they fix a confirmed problem. Each extra change makes it harder to tell which change caused which effect, and slows recovery.

Name the decision-makers in advance: who can approve a fix out of hours, who can authorise a rollback, and who communicates status to stakeholders. In the moment, clarity about roles matters more than any tool.

Phase 4: Launch

Fig. 02 · Timeline

Migration timeline around launch

Durations vary by site size. The weeks after launch matter as much as the weeks before.
  • Confirm robots.txt and meta robots on the live site.
  • Test a sample of redirects from every section, including high-value URLs.
  • Submit the new XML sitemap; keep the old sitemap available briefly so old URLs are recrawled and redirects discovered.
  • For a domain change, use the change of address tool in Search Console where applicable.
  • Check analytics is recording sessions and conversions.

Phase 5: Monitoring and recovery

Some fluctuation after a migration is normal while search engines recrawl and reprocess. What is not normal is a sustained drop in a specific section, a surge in 404 errors, or important pages missing from the index. Monitor daily at first, then weekly, comparing against benchmarks by section.

Self-diagnostic

0/5

Post-launch diagnosis

If traffic falls after launch, work through these in order.

  1. 01Is the live site free of noindex tags and robots.txt blocks on important sections?

    If yes: Move on to redirects. If no: Fix immediately; this is the most damaging error.
  2. 02Do old high-value URLs redirect in one hop to relevant new pages?

    If yes: Signals should be transferring. If no: Correct the redirect map for affected sections.
  3. 03Is the drop concentrated in one section or template?

    If yes: Compare that template's content, links and tags with the old version. If no: Check site-wide issues: rendering, canonicals, performance.
  4. 04Are 404 errors rising in Search Console?

    If yes: Add missing redirects, prioritising URLs with links or traffic. If no: Look at content and intent changes instead.
  5. 05Was content removed or significantly rewritten?

    If yes: Lost content may explain lost rankings; restore what mattered. If no: Give it time while monitoring closely.

Keep redirects in place for the long term. Removing them a few months after launch, to tidy configuration, throws away the links that still point to old URLs. For international sites, read international SEO; for the broader project, see website redesign and the SEO audit checklist.

Key takeaways

  1. 01Involve SEO from the first planning meeting, not after design sign-off.
  2. 02Avoid combining domain, platform and URL changes at once where possible.
  3. 03A complete URL inventory and a one-hop, relevance-based redirect map decide the outcome.
  4. 04Test staging template by template, and check robots and noindex on the live site within the first hour.
  5. 05Monitor by section for weeks after launch and keep redirects in place for the long term.

Frequently asked

Will I lose rankings when I migrate my website?
Some temporary fluctuation is common while search engines recrawl and reprocess the site. Well-planned migrations with complete redirect mapping, preserved content and careful testing usually recover. Significant, lasting losses usually come from missing redirects, lost content, blocked crawling or several risky changes made at once.
How long does it take for SEO to recover after a migration?
It varies with site size, the type of migration and how cleanly it was executed. Small, clean migrations may settle within weeks; large domain and structure changes can take months. Monitor by section against your benchmarks and investigate any area that does not recover.
How long should I keep redirects after a migration?
Keep them for the long term, ideally indefinitely. External links, bookmarks and old references continue to point at old URLs for years. Removing redirects after a few months throws away those signals and sends visitors to error pages. The maintenance cost of keeping them is small.
Should I redirect all old pages to the home page?
No. Redirect each old URL to the most relevant new page. Mass redirects to the home page can be treated as soft 404s, losing their signals, and they frustrate visitors. If a page has no relevant equivalent and no value, return a 404 or 410 instead.

Published by Fabulous.Media, a network of specialist marketing agencies. Updated 9 October 2026. Platform features change often; check current official documentation before acting on platform-specific detail.

Read next

Prefer a specialist to do this with you? The network has a house for every discipline in this library.

Request an Introduction