Site Migration SEO: A Checklist to Protect Your Rankings

A site migration is any change big enough to alter the URLs, hosting, platform, or structure that search engines already know, and every one of them puts your existing rankings at risk. This guide is for founders, marketers, and developers who are about to move a domain, switch to HTTPS, replatform a CMS, redesign, or consolidate two sites into one. It explains what counts as a migration, why poorly run ones lose traffic, and the phased checklist that protects your rankings from planning through launch to recovery. The goal is not zero movement, which is rarely possible, but a fast, controlled recovery instead of a slow, mysterious decline.

The short version

• The single biggest cause of migration traffic loss is a broken or incomplete redirect map, not the migration itself. Map every old URL to its best new match before you touch anything.
• A migration is not just a domain change. Moving to HTTPS, changing URL structure, replatforming, or redesigning all qualify, and each carries its own failure mode.
• Keep URLs identical wherever you can. Every URL you change is a redirect you have to build, test, and hope Google honors.
• Never stack a redesign, a replatform, and a domain change into one launch. When traffic drops, you will not know which change caused it.
• Recovery is measured in weeks, not days. Benchmark before you launch so you can prove what changed and when it came back.

What counts as a site migration?

Any change to the address, technology, or structure of a site that search engines have already crawled and indexed. The word suggests moving house, but in search terms a migration is broader: several very different projects share the same risk profile because they all change signals Google has learned to trust.

The common types are worth naming, because people underestimate the smaller ones. A domain change moves you from one hostname to another. An HTTPS migration moves every URL from http to https, which is technically a URL change on every page. A URL or structure change alters paths, folders, or the way pages are organized. A replatform swaps the CMS or framework underneath, often changing URL patterns and rendering as a side effect. A redesign changes templates, layout, and internal linking even when URLs stay the same, and our redesign SEO checklist covers exactly how to keep those signals intact. A consolidation merges two or more sites, or many pages into fewer, into a single property.

Each of these touches something Google relies on. To understand why that matters, it helps to know that Google runs in separate stages of crawling, indexing, and ranking, which our explainer on how Google Search works walks through in full. A migration can disrupt any of those stages at once, which is what makes it risky.

Why do migrations lose rankings when they go wrong?

Almost always because a signal Google trusted got broken, not because the content got worse. Rankings are built on accumulated signals tied to specific URLs: links, click history, and index entries. Move or break those URLs carelessly and the signals scatter.

The recurring failure modes are predictable. Redirects are missing, so old URLs return a 404 and their link equity evaporates. URLs change without a mapping, so Google cannot connect the old page to its replacement. Content gets dropped during the move, so pages that used to rank no longer exist. Crawling is accidentally blocked, often by a staging robots.txt that shipped to production. And the new site introduces performance or rendering problems that were never tested against real search behavior.

None of these is exotic. They are the same handful of mistakes repeated across projects, which is exactly why a checklist works so well against them.

What is a redirect map, and why is it the heart of the plan?

A redirect map is a spreadsheet that pairs every old URL with the single best new URL it should point to, so a 301 can carry the old page's authority to its replacement. It is the most important artifact in any migration, and the one most often rushed. For the fuller 301 vs 302 comparison, including where 307 and 308 fit in, see our dedicated guide.

Every backlink, every bookmark, and every index entry points at an old URL. A permanent 301 redirect tells search engines the page moved for good and consolidates its signals to the destination. Skip the redirect and that authority is lost. Point it at the wrong page, for example redirecting every missing URL to the homepage, and Google often treats it as a soft 404 and passes little value.

Build the map from a real inventory, not from memory. Pull your live URLs from your sitemap.xml, a site crawl, Search Console, and your analytics, then match each one to its closest equivalent on the new site. One old URL, one new URL, one hop. No chains. When there is no true equivalent, decide deliberately: redirect to the most relevant parent page, or let it return a clean 404 if the content is genuinely gone.

Which migration types carry the most risk?

The ones that change the most signals at once. A pure HTTPS move is low risk when handled correctly; a domain change combined with a replatform is high risk because two independent systems change together. The table below maps each type to its main danger and the one step that matters most.

Migration type	Main risk	Key step
Domain change	Lost link equity if redirects fail	A complete 301 map, plus Search Console Change of Address
HTTP to HTTPS	Mixed content and duplicate URLs	Redirect every http URL to https and update internal links
URL or structure change	Broken internal links and orphaned pages	A one-to-one redirect map and updated internal links
Replatform or CMS change	Changed URL patterns and rendering gaps	Preserve URLs where possible; verify rendered HTML
Redesign	Lost content and weakened internal linking	Keep content parity; audit links before and after
Consolidation	Merged pages competing or losing relevance	Map each source URL to the single best target

Read the table as a warning system: the more rows a single project touches, the more you should separate the changes into phases.

What should you do before the migration?

Everything that lets you measure, map, and rehearse before anything goes live. The pre-migration phase is where migrations are won, because once you launch, you are reacting rather than planning. Work through these groups in order.

Benchmark. Record current organic traffic, rankings for your priority keywords, top landing pages, and indexed page count. Export Search Console performance data. Save this snapshot somewhere permanent, because it is the only way to prove what changed after launch.

Inventory and crawl. Crawl the live site to capture every indexable URL. Cross-check that list against your sitemap.xml, Search Console, analytics, and your backlink data, so you catch pages a crawler alone would miss. The URLs with the most links and traffic are the ones you protect most carefully.

Map the redirects. Build the one-to-one 301 map from that inventory. Match every old URL to its best new destination, flag the pages with no equivalent, and decide each case on purpose rather than by default.

Prepare staging. Build the new site on a staging environment protected by noindex or authentication, never a live URL Google can crawl. Verify templates, metadata, canonical tags, and structured data there. Confirm the main content renders in the raw HTML, not only after JavaScript runs.

Plan the launch. Choose a low-traffic window, line up the people who can deploy and roll back, and write the launch checklist so nothing depends on memory at the moment it matters. Google's Search Central documentation is the reference to keep open while you plan.

What happens on launch day?

You deploy the redirects, open the site to crawlers, and verify every critical signal before you walk away. Launch day is mechanical if the preparation was thorough, and chaotic if it was not. Work the list top to bottom.

Deploy the redirects. Push the full 301 map so every old URL resolves to its new destination in a single hop. Spot-check your highest-value pages by hand, then crawl the old URL list to confirm each one returns a 301 to the right place, not a 404 or a chain.

Fix indexing signals. Update canonical tags to point at the new URLs. Publish an accurate sitemap.xml containing only canonical, indexable pages, and submit it in Search Console. Confirm internal links point directly at final URLs rather than routing through redirects.

Unblock crawling. Remove the staging noindex and confirm the production robots.txt allows crawling of everything that should rank. This is the step teams forget most often, and a single blocking line can hide the entire site from Google.

Verify. Run URL Inspection on your most important pages to confirm they are reachable and indexable. For a domain change, submit the Change of Address tool in Search Console and verify both properties. Watch server logs and error rates for the first hours after launch.

What do you monitor after launch?

Coverage, rankings, errors, and performance, in that order of urgency, for several weeks. The post-launch phase is where you catch the problems that only appear at scale, and where patience matters as much as vigilance. Some ranking movement is normal while Google re-crawls and re-assesses the new URLs.

Watch coverage. Track the Search Console Pages report for a rise in crawl errors, 404 responses, or new indexing exclusions. Confirm the new URLs are being indexed and the old ones are dropping out gradually as their redirects are followed.

Track rankings and traffic. Compare organic traffic and priority keyword positions against your pre-migration benchmark. Expect a dip; watch its depth and duration. A shallow dip that recovers over a few weeks is normal, while a steep drop that keeps falling signals a real problem to diagnose.

Fix errors fast. Resolve broken redirects, chains, and unexpected 404 pages as they surface. Repair internal links that still point at old URLs. Each fix shortens the recovery.

Watch performance. Monitor Core Web Vitals on the new templates, because a redesign or replatform can introduce loading and stability regressions that were fine in testing but degrade under real traffic. Our SEO audit guide sets out the full post-launch review if you want a structured pass.

Should you change your URLs during a migration?

Only when you have a real reason, because every URL you change is a redirect you have to build, test, and rely on Google to honor. The safest migration changes as few URLs as possible. Keeping them identical removes an entire category of risk.

There are legitimate reasons to change URLs: a genuinely better structure, removing dated or messy paths, or consolidating duplicates. When the reason is real, the payoff can outlast the short-term cost. But changing URLs for cosmetic tidiness during an already-risky move is rarely worth it. If a replatform lets you preserve the existing URL patterns, take that option even if the new system would prefer its own.

When you do change them, the redirect map absorbs the risk. That is why the map is non-negotiable: it is the bridge that lets Google carry a page's history from the old address to the new one. Our technical SEO guide covers how canonical and redirect signals interact if you want the underlying mechanics.

What are the most common migration mistakes?

A short list of avoidable errors accounts for most migration failures. Knowing them in advance is half the defense, because every one is easier to prevent than to diagnose after traffic falls.

• Redirecting every old URL to the homepage instead of its true equivalent, which Google often treats as a soft 404.
• Shipping the staging robots.txt or a blanket noindex to production, hiding the new site from search entirely.
• Leaving redirect chains in place, so a URL hops through two or three stops before reaching its destination and leaks equity along the way.
• Forgetting to update internal links, so the whole site still points at old URLs that only resolve through redirects.
• Dropping content during a redesign, so pages that earned rankings simply cease to exist with no replacement.
• Skipping the benchmark, so when traffic moves you cannot tell recovery from decline.

Every item on that list is caught by the phased checklist above. None requires special tooling, only the discipline to work in order and verify each step.

When should you not migrate everything at once?

Whenever a single launch would combine a redesign, a replatform, and a domain change, because bundling them makes diagnosis impossible. This is the most important restraint in the whole process, and the one teams break most often under deadline pressure.

The logic is simple. If traffic drops after a launch that changed your URLs, your templates, and your platform simultaneously, you have no way to isolate the cause. Was it a broken redirect, a rendering regression, a lost internal link, or a thinner page? You cannot tell, so you cannot fix it efficiently. Separating the changes into sequenced launches, with a stabilization period between each, keeps the variables isolated and the diagnosis fast.

When not to sequence: a small site with a handful of pages and few backlinks can often absorb a combined change safely, and the overhead of phasing would cost more than it saves. The bigger and more established the site, the more you gain from separating the moves, which is one reason a high-stakes migration often sits inside a wider SEO services engagement rather than being handled as a one-off task. Google's Search Essentials is worth revisiting before any large change, since a migration is also a chance to confirm the fundamentals still hold.

How long does recovery take, and what does a good outcome look like?

Weeks, not days, and a good outcome is a shallow dip that returns to the benchmark rather than a permanent step down. Google has to re-crawl the new URLs, follow the redirects, and re-assess the pages, and that takes time proportional to your site's size and crawl frequency. That is a recovery window, not a growth one: a site with existing authority regains lost ground faster than a new site earns the same ground for the first time, and our guide to how long organic results normally take covers the fuller timeline for a site starting from scratch.

Judge success against the snapshot you took before launch, not against your hopes. Priority keywords returning to their previous positions, the new URLs replacing the old ones in the index, and organic traffic climbing back to its baseline are the signals that the migration held. If several weeks pass with no recovery, the problem is almost always a specific broken signal you can find: an unfollowed redirect, a blocked path, or a lost page. Our technical SEO checklist is a useful diagnostic pass when a migration refuses to recover.

The habit worth building is treating every structural change as a migration, however small it looks. A folder rename, an HTTPS switch, or a template overhaul all deserve a benchmark, a redirect plan, and a monitoring window, because the sites that survive migrations are the ones that never assume a change is too minor to break something. This week, before any move is on the calendar, export your current organic traffic, top landing pages, and priority keyword rankings into a saved benchmark file. That single snapshot is what will let you tell a routine dip from a real problem the day you finally launch.