SEO Migration Checklist

Kal Wiggins ·

This is the checklist we actually work from. It’s ordered by when each thing has to happen, and it’s opinionated about the two or three items that matter far more than the rest — because on every migration we’ve run, and one we ran on our own site, the same small set of decisions determined the outcome.

It applies to any move that changes URLs: a platform migration, a domain change, a redesign that alters URL patterns. The examples lean ecommerce because that’s what we do, and because ecommerce sites have the most URLs to lose.

Before anything: the inventory

The migration will be judged on whether every old URL ends up somewhere sensible. That requires knowing every old URL, and the obvious shortcut doesn’t work.

  • Crawl the live site in full. Screaming Frog or equivalent, following every internal link, including paginated and filtered pages. This is your primary list.
  • Pull every URL with traffic from analytics for the last twelve months.
  • Pull every URL with impressions from Search Console for the same period.
  • Pull every URL with backlinks from Ahrefs, Semrush or Search Console’s links report.
  • Union the four lists. That’s your inventory.
  • Do not build the inventory from the sitemap. Sitemaps are incomplete on almost every established site — orphaned pages, retired campaign URLs, discontinued products, tag and author archives, filtered category variants. On sites of any age, the crawl finds 20–40% more URLs than the sitemap knows about, and because those are the oldest, they’re the ones most likely to hold links.

Record the baseline

Without this, every post-launch conversation is an argument instead of a measurement.

  • Organic sessions and revenue by month, twelve months back.
  • Top 100 pages by organic traffic and top 100 by backlinks — these overlap less than you’d expect, and the second list is the one people forget.
  • Current rankings for the terms that matter, with URLs.
  • Conversion rate and average order value from organic.
  • Core Web Vitals from field data (Search Console), not a one-off lab run.
  • A full crawl export of the old site, archived. You will want to look things up later.

The redirect map

This is most of the work and most of the outcome.

  • Every URL in the inventory gets a destination — its closest equivalent on the new site.
  • No bulk redirects to the homepage. Google treats a redirect to an irrelevant page as a soft 404 and discards the equity. Products with no equivalent and no backlinks can return 410. Anything with links goes to the nearest relevant category or replacement.
  • Preserve intent, not just topic. A category page redirects to a category page; a product to a product or its replacement; a blog post to the closest post, not the blog index.
  • Build for both trailing-slash forms. Some platforms treat /page/ and /page as the same URL; some don’t; some redirect layers match literally with no normalisation. A map that covers one form silently loses half of everything and passes a spot check. We learned this the expensive way — see below.
  • Eliminate chains. If an earlier migration left A→B, the new map must go A→C directly. Run a chain check on the finished map; it’s a short script.
  • Watch the rule budget. Some hosts cap redirect rules, and some cap them lower than documented. Cloudflare Pages, for example, applies far fewer dynamic (wildcard) rules than its documentation states — we measured the real ceiling against production after rules past it silently stopped working. Know your platform’s actual limits before you design around them.
  • Test every rule programmatically against staging. Not a sample. Every URL, both slash forms, asserting a 301 to the expected destination and a 200 at the end of it.

The trailing-slash bug we found on our own site

Earlier this year we discovered that four backlinks to this site — including one from a DR 92 domain — were landing on 404 pages. The redirect rules existed. They were correct. They matched /old-url/ and the links pointed at /old-url, and the hosting layer matched literally.

Nothing in a normal audit flagged it, because spot-checking the slashed form returned a perfect 301. It was only visible when we tested the backlink URLs exactly as they were written. Every redirect map we build now covers both forms explicitly, and this checklist exists partly because of that afternoon.

Preserve what the platform was doing for you

  • Carry over titles and meta descriptions. Don’t regenerate them from templates at migration time — a wholesale rewrite makes it impossible to separate a design effect from a copy effect afterwards.
  • Rebuild structured data. Product, breadcrumb, review, organisation and FAQ markup are easy to lose in a theme or platform change. Validate on staging.
  • Check canonical tags, especially on paginated and faceted category pages, where new-platform defaults are frequently wrong.
  • Check hreflang if you serve multiple regions or languages. It’s fragile and rarely tested.
  • Keep internal links pointing at final URLs, not at redirects. A migration is the moment to update them.
  • Migrate reviews deliberately. They usually live in an app or plugin, they don’t come across by default, and they carry review structured data.

Robots, sitemaps and Search Console

  • Unblock robots.txt on production. Staging is normally blocked wholesale. Shipping that block live is a classic launch mistake, and it’s expensive.
  • Generate the new XML sitemap and confirm it lists only final, canonical, 200 URLs — no redirects, no noindex pages.
  • Keep the old sitemap available briefly after launch. Crawlers use it to discover the redirects faster.
  • Verify the new property in Search Console ahead of time if the domain or protocol changes, and use the Change of Address tool for domain moves.
  • Submit the new sitemap on launch day.

Pre-launch verification

Run on staging, before the DNS change:

  • Full redirect test — every rule, both slash forms, no chains.
  • Every template type renders correctly: home, category, product, content, search, account.
  • Titles, descriptions, canonicals and structured data present on a sample of each template.
  • Analytics and conversion tracking fire.
  • Core Web Vitals on the new templates are at least as good as the old.
  • Robots.txt and meta robots are production-ready, not staging.

Launch day

  • Lower DNS TTL a day or two ahead so you can reverse quickly.
  • Deploy, then immediately re-run the redirect test against production. Production can behave differently from staging.
  • Watch 404s and 5xx errors continuously for the first 48 hours.
  • Confirm orders (or conversions) are flowing.
  • Submit the sitemap; request indexing on your most important pages.

After launch

  • Week 1: 404 reports daily. Every new 404 with traffic gets a redirect.
  • Weeks 2–6: Coverage report, rankings on priority terms, organic sessions against the baseline. Expect a 10–20% dip; expect it to bottom out and recover.
  • Week 6: if the dip is still deepening, treat it as a redirect problem until proven otherwise. Re-run the full test against production.
  • Keep the old site accessible, not serving, for a month. When something turns out to be missing, you’ll want to look it up.
  • Leave redirects in place indefinitely. Backlinks don’t expire, and neither should the rules that catch them.

The three that matter most

If you do nothing else on this list: build the inventory from a crawl rather than the sitemap, map every URL to its closest equivalent rather than to the homepage, and test both trailing-slash forms before launch. Those three account for most of the difference between migrations that hold their rankings and migrations that spend a year recovering.

The rest of the migration — the catalog remodelling, the data that doesn’t transfer, choosing a destination — is in our full ecommerce migration guide, and the ecommerce migration checklist covers the whole project ordered by what goes wrong. If you’d rather have it run for you, that’s what our migration services are — and the redirect map is the part we’re most particular about.

Frequently Asked Questions

What is an SEO migration?
The set of work that protects search rankings when a site changes in a way that alters its URLs, structure or platform — a replatform, a domain change, a redesign that changes URL patterns, or a move to HTTPS. The core of it is the redirect map: making sure every old URL sends visitors and search engines to its closest new equivalent. Around that sit canonicals, structured data, sitemaps, robots rules and a baseline to measure against.
How do I build a redirect map?
Start with a complete inventory of old URLs — a full crawl of the live site, every URL with a visit or impression in the last twelve months, and every URL in your backlink profile. Not the sitemap, which is incomplete on almost every established site. Map each URL to its closest equivalent on the new site, never to the homepage in bulk. Then test every rule against staging, in both trailing-slash forms, before launch.
Do trailing slashes matter for SEO?
For redirects, enormously. Platforms and hosting layers disagree about whether /page/ and /page are the same address, and some redirect systems match literally with no normalisation. A redirect map that covers one form and 404s the other silently loses half of everything — and passes a casual spot check. We found exactly this on our own site: backlinks from a DR 92 domain landing on 404s because the rule matched the slashed form only.
How much traffic will we lose in a migration?
A well-executed migration typically dips 10–20% for four to six weeks and then recovers to baseline or better. That settling period is normal. A dip still deepening at week six is not normal. It indicates a real problem, and the cause is almost always redirects — missing, chained, or behaving differently in production than they did in testing.
Should we change URLs during a migration?
Only if you have to. Every URL change costs some settling time, and changing structure at the same time as platform means you cannot separate the two effects afterwards. On some moves it is unavoidable — Shopify enforces /products/ and /collections/ prefixes, for example. When URLs must change, keep titles, meta descriptions and content as stable as possible so at least those variables are held constant.
What about redirect chains?
Avoid them. If a previous migration left rules pointing A to B, the new map must point A directly to C rather than relying on A to B to C. Chains leak authority at each hop and are eventually abandoned by crawlers. Run the finished map through a chain check before launch. It is a five-minute script and it catches a class of problem that otherwise surfaces months later.