The SEO Site Migration Checklist That Protects Your Rankings (Domain, CMS, or Redesign)

Every website migration is, from Google's perspective, a site it has to meet again. New URLs, a new server response, sometimes a new domain entirely — the crawler doesn't inherit trust automatically, it re-evaluates. That re-evaluation window is where rankings get lost, and it's almost never because the new site is worse. It's because nobody built a plan to carry signals across the gap.

This is what an SEO site migration checklist is actually for: not predicting the unpredictable, but sequencing a known set of technical steps so Google can reconnect old authority to new URLs with as little friction as possible. Treated this way, migration risk stops being a mystery reserved for SEO consultants and becomes a project management problem — one a marketer without deep technical training can execute using an audit tool to do the heavy lifting.

Why Website Migrations Put Your Rankings at Risk

When a URL changes, moves to a new domain, or gets served from a different CMS, Google has to recrawl it, reprocess its content, and reassign the ranking signals it had previously attached to the old address. Until that reprocessing finishes, rankings for the migrated pages sit in a kind of limbo — some hold steady, some dip temporarily, and some drop hard if the technical handoff was sloppy.

Traffic loss after migration is common enough that it should be budgeted for, not feared into paralysis. Industry benchmarks — including Semrush's migration research — put typical short-term organic traffic dips in a wide range depending on execution quality, from barely noticeable to severe, with well-planned migrations landing on the lower end and rushed ones on the higher end. The site migration SEO risk isn't the migration itself; it's skipping the benchmarking, redirect mapping, and verification steps that let Google map old equity to new URLs quickly.

The rest of this article is that safety net, organized into three phases: what you lock down before anything changes, what you verify the moment the new site is live, and what you watch in the weeks after.

What Counts as a Website Migration?

Not every site change carries the same risk, so it helps to know which category you're in before applying the checklist.

• Domain migration — moving from one domain to another (rebrand, acquisition, ccTLD consolidation). Highest risk, requires the Change of Address tool.
• CMS migration — replatforming from, say, WordPress to a headless CMS or Shopify. URL structures often change even when content doesn't.
• Website redesign — new templates, navigation, or design system on the same URLs and domain. Lower risk if URLs stay identical, but redesign SEO risk climbs fast if information architecture changes alongside the look.
• HTTP to HTTPS — a protocol change that Google treats as a URL change, requiring redirects even though the content is untouched.
• URL restructure — changing folder structure, slugs, or removing/adding subdomains without changing the domain itself.

Each type triggers a version of the same core problem: URLs Google has indexed no longer exist in that exact form. The checklist below applies regardless of which type — or combination — you're dealing with.

Phase 1: Pre-Migration — Benchmark and Plan

Everything in a website migration checklist that happens after launch depends on what you record before launch. Skip this phase and you'll have no way to tell whether a post-launch traffic dip is expected fluctuation or a real problem.

Full Site Crawl and URL Inventory

Start with a complete crawl of the current site using a tool like Screaming Frog, or run a full Rankevra audit to get an indexed URL inventory without configuring crawl settings manually. The goal is a definitive list of every URL Google currently indexes — not just the pages in your CMS, but orphaned pages, old campaign landing pages, paginated archives, and anything still pulling in organic traffic. Missing even a handful of URLs at this stage means they'll have no redirect destination later, and each one becomes a silent 404 that erodes both user trust and link equity.

Benchmark Rankings, Traffic, and Technical Health

Export your current Google Search Console data — queries, clicks, impressions, and average position — for at least the past three to six months. Pull the equivalent traffic, conversion, and landing page reports from GA4. Then run a baseline technical audit to document existing issues: broken links, duplicate titles, missing meta descriptions, slow Core Web Vitals scores. This baseline matters for two reasons. First, it tells you what was already broken so you don't blame the migration for pre-existing problems. Second, it becomes your comparison point after launch — without it, "traffic dropped" is just a feeling, not a diagnosis.

Build the 1:1 URL Redirect Map

This is the step that determines whether a migration is smooth or brutal. Map every old URL to its closest, most topically relevant new equivalent — not a blanket redirect to the homepage. If a product page moves, it should redirect to the new version of that specific product page, not the category page or the homepage. This URL mapping preserves the topical relevance and link equity that Google associated with the original page. Google's own guidance on site moves is explicit that redirects should point to the most equivalent page, and that mapping everything to a single destination is one of the fastest ways to lose the ranking signal you're trying to protect.

Phase 2: Launch Day — Verify Before You Celebrate

The new site being live isn't the finish line — it's the point where a launch day SEO checklist matters most, because errors introduced here compound for weeks if they go unnoticed.

Check for Stray Noindex Tags and Staging Canonicals

The single most common launch-day disaster is a staging environment's noindex tag or canonical reference making it into production. Development environments are almost always set to noindex to keep Google from crawling unfinished work, and if that tag — or a canonical tag still pointing at a staging subdomain — survives the push to the live site, Google will deindex pages that were ranking fine the day before. Crawl the live site immediately after launch and check every template type for this specific issue before anything else.

Test Redirects, Sitemaps, and Internal Links

Spot-check a representative sample of your redirect map, confirming each 301 redirect resolves in a single hop with no chains, and that none default to 302s if the move is permanent. Submit the new XML sitemap through Search Console, and update your robots.txt to make sure it's not still blocking crawlers from the sections that matter. Finally, update internal links throughout the site to point directly at new URLs rather than relying on redirects to catch every internal click — redirect chains slow crawling and dilute equity even when they technically work.

Confirm Analytics and Search Console Are Tracking Correctly

Verify your GA4 tracking code fires correctly on the new templates and that goals or conversion events still register. If this is a domain migration, this is also the moment to submit the Change of Address tool request in Search Console, which tells Google to transfer ranking signals from the old domain to the new one over a defined window.

Phase 3: Post-Migration — Monitor and Fix Fast

Post-migration SEO monitoring is where most teams either catch problems early or let them fester for months. Check Search Console coverage reports, indexed page counts, and top query rankings weekly for the first 30 days, then biweekly through day 90.

What's Normal vs. What's a Red Flag

Some fluctuation is expected: rankings moving up or down a handful of positions, or traffic dipping 10-15% for a week or two, is typical recrawl noise. A red flag looks different — a specific set of pages returning 404s in Search Console coverage reports, a sudden and sustained drop in indexed page count, or a query that held a top-5 position for months disappearing from the top 50 entirely. The pattern to watch for is sustained decline versus temporary wobble; if a metric hasn't recovered within two to three weeks, treat it as a real problem, not noise.

Common Migration Mistakes That Tank Rankings

These are the highest-impact, most avoidable site migration mistakes, and nearly all of them trace back to skipping a step in Phase 1 or 2:

• Redirecting every old URL to the homepage instead of its closest equivalent
• Using 302 (temporary) redirects for changes that are actually permanent
• Redirect chains — old URL to interim URL to final URL — that waste crawl budget and dilute equity
• Losing metadata, structured data, or schema markup during template rebuilds
• Leaving staging robots.txt rules in place, blocking crawlers from the live site
• Forgetting to update internal links, leaving the site reliant entirely on redirects

How Long Does It Take to Recover Rankings After a Migration?

Ranking recovery after migration typically plays out over a few weeks to a few months, depending on site size and how clean the execution was. Smaller sites with a tight, accurate redirect map often stabilize within two to four weeks. Larger or more complex sites — especially domain migrations — can take two to three months for Google to fully reprocess and reassign signals, a range consistent with Semrush's benchmarking data. A checklist-driven migration with a clean redirect map, verified launch-day checks, and active monitoring consistently recovers faster than one where problems are discovered ad hoc weeks after the fact.

Frequently Asked Questions

Do I need 301 redirects for every old URL? Yes, for any URL that's indexed or receiving traffic. A 301 signals a permanent move and transfers ranking signals; a canonical tag, by contrast, tells Google which of two live, similar URLs is the preferred version — they solve different problems and aren't interchangeable.

When should I use Google's Change of Address tool? Only for domain migrations, after 301 redirects are live and verified. It supplements redirects by explicitly telling Google to shift signals to the new domain, and Google notes the transfer process runs over roughly a 180-day window.

Should I migrate my whole site at once or in stages? For large sites, a staged migration — moving sections incrementally — reduces risk and server load, and gives you a chance to catch mapping errors before they affect the entire site. Smaller sites can usually move in a single push if the redirect map is thoroughly tested beforehand.

How do I know if my migration went wrong? Sustained drops in indexed pages, disappearing top rankings, or a Search Console coverage report full of new 404 or noindex errors are the clearest signs — not brief, self-correcting dips in the first week or two.

Run the Numbers Before You Touch Anything

A migration only becomes risky when it's improvised. Before a developer pushes anything live, run a pre-migration audit in Rankevra — Analyze. Create. Rank. to establish your baseline: current crawl errors, ranking positions, and a full page inventory. Once the new site is live, re-run that same audit and compare it directly against the baseline to catch broken redirects, stray noindex tags, or missing pages while they're still cheap to fix. That comparison — not guesswork — is what separates a migration that holds its rankings from one that spends months clawing them back.