SEO migration checklist: the full sequence before, during and after a replatform

An SEO migration succeeds or fails on three things: a complete inventory of the URLs you have today, a redirect map that sends every one of them to its closest equivalent with a single 301, and a baseline of traffic and rankings taken before launch so you can tell within a week whether anything broke. Everything else on this checklist supports those three. Google's own documentation splits the job into a move without URL changes and a move with URL changes, and the second is where almost all of the risk lives.

This page covers the full sequence for a replatform, a redesign or a domain change: what to do in the weeks before, the launch day order of operations, and what to verify afterwards.

Four to six weeks before: the baseline

You cannot diagnose a drop without a before picture. Capture all of this and store it somewhere outside the site being replaced.

• A full crawl of the live site. Every URL with its status code, title, meta description, canonical, index directive, word count and internal link count.
• Every URL Google knows about. Export the Search Console page indexing report and the sitemaps, and add server log URLs and analytics landing pages for the last twelve months. Crawls miss orphan pages that still earn traffic.
• Performance data, exported. Sixteen months of Search Console queries and pages, and twelve months of analytics landing page data. Search Console only keeps a rolling window, so an export taken now is the only record you will have later.
• Rank positions for your tracked terms, dated.
• Your backlink profile, so you know which URLs carry links and must never be allowed to 404.

Then rank the inventory. Sort by organic entrances and by referring domains, and mark the top pages. Those are the URLs that get checked by hand on launch day rather than by sample.

Three to four weeks before: the redirect map

The redirect map is a two column list: old URL, new URL. Build it from the full inventory, not from the new sitemap, because a map built from the new site only covers pages that survived.

• One row per old URL. No gaps. A URL with no row is a 404 waiting to happen.
• Map to the closest equivalent page, never to the homepage as a default. Google treats a mass redirect to an irrelevant page as a soft 404, so the value is lost either way.
• Use 301 for anything permanent. Google's redirect documentation explains which types are treated as permanent.
• One hop only. If the old site already contains redirect chains, flatten them so every old URL in the chain points directly at the final destination.
• Decide on parameters, trailing slashes, uppercase and protocol as rules, then check that the rules do not collide with the handwritten rows.
• Handle retirements honestly. A page with no equivalent and no value returns 410 or 404. A page with no equivalent but real links redirects to the nearest useful parent.

Situation	Correct handling
Page exists in a new location	301 to the new URL
Several old pages merged into one	301 all of them to the merged page
Page split into several	301 to the one that matches the old search intent best
Category or tag page removed	301 to the nearest surviving category, or 410 if it was thin and unlinked
Product discontinued, replacement exists	301 to the replacement product
Product discontinued, no replacement	Keep a page explaining it and linking alternatives, or 410

Two weeks before: the new build

Test on staging, with the staging site locked behind authentication rather than robots.txt alone, so nothing leaks into the index. Check each item against the old site, not against a style guide:

• Titles, meta descriptions and headings carried across, template by template.
• Body copy kept. A redesign that quietly cuts page content is the most common cause of a traffic drop blamed on the migration.
• Canonical tags self referencing and absolute.
• Internal links pointing at new URLs directly, including navigation, footer, breadcrumbs and in body links.
• Structured data present on every template that had it, and validating.
• hreflang annotations rebuilt and pointing at live new URLs.
• Rendering checked with JavaScript disabled, if the new build is a single page application. Content that only exists after a client side fetch is the second most common cause of a drop.
• robots.txt written for production, not copied from staging.
• XML sitemaps generated for the new URLs, and a temporary sitemap of the old URLs ready to submit so the redirects get crawled quickly.
• Analytics and Search Console tagging in place, with goals and events rebuilt.

Run the redirect map against staging with a list crawler before launch. Every row should return a single 301 to a 200 page. Fix every chain, every loop and every row that lands on a redirect.

Launch day, in order

• Deploy, then immediately re-check robots.txt and the index directives on the live domain. A stray noindex left in a template is the single most expensive mistake available on launch day.
• Run the redirect map against production. All rows, not a sample.
• Crawl the live site in full and compare the URL count, status codes and titles to the baseline crawl.
• Check the top pages by hand, the ones you marked earlier.
• Submit the new sitemaps in Search Console, and the old URL sitemap too.
• For a domain change, use the Change of Address tool once the redirects are live, and add the new property first.
• Confirm analytics is recording on every template, including checkout or enquiry completion.
• Leave the old server answering. Redirects only work while something serves them, so plan for at least a year.

The first month

Expect movement in the first weeks while Google recrawls and reprocesses. Work from data rather than from the shape of a graph:

• Daily for two weeks: the page indexing report for new errors, crawl stats for spikes in 404 and 5xx responses, and server logs for the URLs bots are requesting that you did not map.
• Weekly: Search Console clicks and impressions by page group against the baseline, so a drop can be traced to a template rather than guessed at.
• Weekly: rank positions for the tracked terms, and the new URL for each one. A page that lost position often shows the wrong URL ranking.
• By week four: the new URLs should dominate the indexing report and the old sitemap can be removed once its URLs are reported as redirects.

If a page group has not recovered after a month, check three causes in this order: the new template is thinner than the old one, the internal links that pointed at those pages were dropped in the new navigation, or the redirect lands somewhere that does not match what the page used to answer.

This page covers replatforms, redesigns and domain changes. For a move to HTTPS or a change of hosting with no URL changes, follow the baseline, launch day and monitoring sections and skip the redirect map. For merging two sites into one, this sequence applies and the consolidation decisions are documented in Google's guidance on consolidating duplicate URLs.

Where people get stuck on SEO migration checklist

How long does it take for rankings to settle after a migration?

Most sites see the bulk of reprocessing within two to four weeks, and large sites take longer simply because recrawling every URL takes longer. Judge the move on week four data, and investigate anything specific immediately rather than waiting.

Should I keep the old URLs redirecting forever?

Keep them for at least a year, and keep the ones with external links indefinitely. Redirects cost almost nothing to serve, and the links pointing at those old URLs keep arriving.

Is it safe to redesign and change URLs at the same time?

It is done routinely, and separating them makes diagnosis much easier. If you can ship the URL change first and the new design a few weeks later, any movement has one obvious cause.

Do I need a new Search Console property?

Yes for a new domain or a protocol change. Add and verify it before launch, keep the old property, and compare the two during the handover.

What if traffic drops and the checklist is clean?

Compare the new pages to the old ones on content depth and internal links first, then check that the ranking URL for each tracked term is the one you intended. Those two account for most drops that survive a clean technical check.

A check that is new since your last migration

Your redirect map protects the links you can see. After the launch there is a second thing to verify: what an assistant says about your pages now. An answer that quoted an old URL, an old product name or an old price may keep doing so while the new site settles.

Add it to the first month. Before launch, ask ChatGPT, Gemini and Perplexity your five main buyer questions and save the replies with their sources. Ask again at day thirty. AI Knows Us runs the same questions for both rounds and keeps both sets, so you can see which cited pages changed and which still point to the old structure.