Website migration checklist

What counts as a website migration?

A migration is any change that alters the addresses search engines already have on file, or the platform serving them. That covers replatforming (WordPress to a headless build, Shopify to WooCommerce), moving to a new domain, consolidating several sites into one, switching from HTTP to HTTPS, changing URL structure, or restructuring an information architecture so pages move to new paths.

A visual reskin that leaves every URL exactly where it was is not a migration and does not need this checklist. The moment a single indexed URL changes address, you are migrating — and the work below applies proportionally to how many URLs move.

Step 1 — Inventory every URL before anything changes

Build one spreadsheet that is the single source of truth for the whole project. Pull URLs from four places, because no single source is complete: a full crawl of the current site, the XML sitemap, Search Console’s indexed pages report, and analytics for the last 12 months. Crawls miss orphaned pages that still rank; sitemaps miss pages nobody remembered to list; analytics catches pages with traffic that the sitemap forgot.

For each URL record: current address, page type or template, organic sessions and enquiries over 12 months, number of referring domains, and current indexation status. That last set of columns is what turns a flat list into a priority order — the pages with external links and enquiry history are the ones a mistake actually costs you.

Step 2 — Map old URLs to new ones, one to one

Every URL in the inventory needs a decision: keep the same address, redirect to a specific new address, or intentionally retire. Write the destination for every redirect explicitly. The two failure modes that cause most post-migration traffic loss are redirecting large groups of pages to the homepage, and chained redirects where an old URL points to another old URL that points somewhere else.

Redirect to the closest equivalent page, not the nearest category. If a page genuinely has no successor, decide deliberately whether it returns 410 (gone, and you mean it) or redirects to the most relevant parent. Document the reasoning in the sheet, because six months later nobody remembers why a URL was retired.

Where a URL genuinely stays the same, mark it as such rather than leaving the cell blank. A blank cell is indistinguishable from an unfinished decision when you are checking coverage at 2am before a cutover.

Step 3 — Preserve what search engines already trust

Carry over the signals that took years to earn. Title tags and meta descriptions for pages that rank should move across deliberately rather than being regenerated by a template. Heading structure and the substantive body content on money pages should survive — a page that ranks on 900 words and loses 500 of them in a redesign has changed in a way that search engines notice.

Check structured data separately. If the current pages carry Organization, LocalBusiness, Article, FAQPage or Product markup, the new templates need equivalent markup describing the same visible content. Also carry across canonical logic, hreflang if present, and any noindex rules that exist on purpose — losing a deliberate noindex is how staging content and thin pages end up indexed.

Step 4 — Crawl staging before anyone sees it

Run a full crawl of the staging site and diff it against the inventory. You are checking that every mapped redirect resolves in a single hop to a live 200 page, that no page is missing a title or an H1, that internal links point at new URLs rather than relying on redirects, and that no page is orphaned from navigation.

Confirm staging itself is blocked from indexing while it is public, and — critically — that the block is removed at cutover. A staging site that launches with its noindex still attached is one of the most expensive and most common migration mistakes, and it is invisible until traffic disappears.

Check the mobile rendering and Core Web Vitals of the new templates at this stage too. Migration is when template-level performance regressions get baked in, and they are far cheaper to fix before launch than after.

Step 5 — Cutover with a rollback plan

Pick a launch window when your team is available to watch, not a Friday evening. Before switching, lower the DNS TTL well in advance so a rollback propagates quickly if you need it. Have the previous site restorable — a rollback plan you never use costs a few hours; not having one costs days.

Immediately after cutover, verify a sample of redirects live, confirm the new site returns 200 for key pages, check robots.txt is the production version rather than the staging one, and submit the new XML sitemap in Search Console. For sites with meaningful revenue, migrating one template or section at a time contains the blast radius of any single mistake.

Step 6 — Monitor for a defined window afterwards

Watch crawl errors, 404 reports, indexed page counts and rankings for high-value terms daily for the first fortnight, then weekly. Rising 404s usually mean a redirect was missed or an internal link was left pointing at a retired URL. A falling indexed count means pages are not being discovered — check the sitemap, internal linking and robots rules in that order.

Expect some ranking movement. A well-executed migration commonly sees short-term volatility that settles as search engines recrawl and reprocess the new structure; recovery is measured in weeks to months, not days. Anyone promising an exact recovery date is guessing. What you can control is whether the volatility has a cause you introduced.