Site Migration SEO: A Checklist to Protect Your Rankings

Site migration SEO comes down to one discipline: map every URL, redirect it correctly, and watch the data for 30 days before you relax. Migrations are risky but manageable. Sites that implement complete 301 mapping, verify indexability before and after cutover, and monitor closely, rarely lose rankings permanently.

Here is the one-page checklist to work from:

Baseline first. Capture 30 to 90 days of Google Analytics and Search Console data before you touch anything.
Map every URL. One-to-one mapping for every indexed page, not just your top ten.
Redirect with 301s. Server-side, permanent, no chains longer than one hop where you can help it.
Validate on staging. Crawl it, check canonicals, confirm structured data survives.
Run launch-day checks. Indexability, SSL, sitemap submission, Change of Address if you’re moving domains.
Monitor for 30+ days. Daily at first, then weekly, watching for drops that deepen rather than settle.

Expect a short-term dip in the first one to two weeks. Most sites stabilize within about a month, and rankings that are still sliding after day 30 point to a technical problem, not a normal fluctuation.

Pro Tip: Make your new site crawlable 7 to 14 days before you flip the redirects live. This early-launch window lets Googlebot start indexing while you still have time to fix what breaks, instead of finding out on launch day.

Key Takeaways

Site migrations preserve rankings when teams complete full URL mapping, verify indexability at every stage, and monitor closely for at least 30 days past launch.

Point	Details
Baseline before you build	Capture 30 to 90 days of GA4 and Search Console data before touching the current site.
Map every URL individually	Avoid redirecting to the homepage; use one-to-one 301 mapping and 404/410 for removed pages.
Use the early-launch window	Make staging crawlable 7 to 14 days before cutover to surface issues while there’s time to fix them.
Watch the 30-day threshold	A dip that deepens after day 30 signals a technical problem, not normal reindexing.
Get expert coordination when scale demands it	Vertical Brands runs migration audits, redirect QA, and post-launch monitoring for sites where complexity raises the stakes.

Pre-Migration Planning: Goals, Baselines, and Roles
How Do You Build and Test a Migration Staging Site?
What Is the Right Way to Map Redirects During a Migration?
What Should You Check in the First 48 Hours After Launch?
How Do You Monitor a Site After Migration?
Why Do Sites Lose Traffic During Migration?
How Do Domain Moves, HTTPS Changes, and Site Mergers Differ?
How Vertical Runs Migrations
What I’ve Learned From Watching Migrations Succeed and Fail
How Vertical Can Help With Your Site Migration
Frequently Asked Questions
Sources

Pre-Migration Planning: Goals, Baselines, and Roles

Most migration failures are decided weeks before launch, not on launch day itself. The Search Engine Journal analysis of migration traffic drops makes a point worth sitting with: most “permanent” losses trace back to preventable errors baked in during planning, like an incomplete redirect map or a forgotten noindex tag. Get the planning phase right and the rest of the migration gets dramatically easier to execute.

1. Set goals and KPIs before you plan anything else. Decide what “success” looks like in numbers: organic sessions, rankings for your top 20 to 50 keywords, and conversion rate. Then pull 30 to 90 days of baseline data from GA4 and Search Console. Without this, you’ll have no way to tell a normal migration dip from an actual problem three weeks in.

Site migration planning steps diagram

2. Build a full site inventory. Crawl the current site and export every indexable URL, not just the ones in your sitemap. Pair that with a backlink snapshot, a Core Web Vitals baseline, and, increasingly, a check of how your priority pages surface in AI answer engines. There’s no Change of Address equivalent for large language models, so if your brand shows up in AI-generated answers today, note which pages earn that visibility before you move anything.

3. Freeze the scope. Decide explicitly what’s changing and what isn’t. A domain move alone is one project. A domain move plus a CMS swap plus a full redesign is three projects wearing one trench coat, and when something breaks, you won’t know which change caused it.

4. Assign ownership. Someone owns the redirect map. Someone owns DNS changes. Someone watches Search Console daily for the first two weeks. Someone reaches out to your highest-value backlink sources to request updated links. Write these names down before launch, not during the panic after.

5. Clean house before you move. Removing thin, outdated, or duplicate content ahead of a migration matters more in 2026 than it used to. A significant domain move can now trigger a broader quality reassessment, and content that search engines tolerated quietly on your old domain can drag down trust signals on the new one if you carry it over unchanged.

Planning Task	Owner	Timing
Capture baseline analytics	SEO lead	30 to 90 days pre-launch
Full URL and backlink inventory	SEO / dev	4 weeks pre-launch
Scope freeze document	Project lead	Before build begins
Content cull and consolidation	Content team	Before staging build
DNS TTL reduction	Dev / IT	24 to 48 hours pre-cutover

Keep the scope-freeze document visible to every team touching the project.
Revisit your KPI list weekly during the build phase; priorities shift as deadlines approach.
Don’t skip the AI-surface snapshot even if it feels speculative today.

Pro Tip: Lower your DNS time-to-live to 300 seconds or less 24 to 48 hours before cutover, and schedule the actual switch during your lowest-traffic window. A five-minute DNS propagation delay during peak hours can cost you more than a week of clean redirects will earn back.

How Do You Build and Test a Migration Staging Site?

Run your staging environment fully blocked from public indexing while development is underway, then flip that switch deliberately. The Semrush migration checklist treats staged testing as a core phase, and for good reason: this is where you catch the errors that would otherwise surface as ranking losses two weeks after launch.

Block staging with a password wall or IP restriction during active development, but make sure your process allows controlled access for Googlebot once you’re ready for real validation. A common mistake here is leaving a blanket noindex tag or a disallow rule in robots.txt active straight through launch, silently keeping your new site invisible while you wonder why nothing is indexing.

1. Run the technical audit. Check crawlability, robots.txt rules, meta robots tags, rel=canonical implementation, hreflang if you run multiple language or region versions, structured data against Schema definitions, Core Web Vitals scores, and SSL configuration end to end.

2. Adopt the early-launch pattern. Make the new site crawlable 7 to 14 days before cutover rather than the moment redirects go live. This pattern has become standard operator practice precisely because it surfaces crawl errors, broken templates, and indexing issues while you still have runway to fix them.

Hands typing near locked server cabinet

3. Run your test cases. Spot-check URL inspections in Search Console, validate your XML sitemap structure, test redirect behavior directly on staging, confirm canonical tags point where they should, and check rendering on JavaScript-heavy templates. A validator like the one at Validator will catch structured-data breaks that a visual check misses entirely.

4. Fix internal links before launch, not after. Every internal link should point to the final new URL, never to a URL that will itself redirect. A homepage that links to twelve category pages, each of which link to old-format product URLs that then redirect, creates redirect chains you built yourself. Updating internal linking structures as part of the build, rather than patching them after launch, keeps crawl paths clean from day one.

Test with a real user-agent crawl, not just an automated bot simulation.
Confirm HTTPS is fully active on staging before you test any redirect behavior tied to protocol.
Check mobile rendering separately from desktop; templates diverge more often than teams expect.

Pro Tip: Pair a controlled Screaming Frog crawl with Search Console’s URL Inspection tool on staging before you touch a single redirect. If Google can’t confirm a page is indexable in isolation, flipping redirects to it will not fix that.

What Is the Right Way to Map Redirects During a Migration?

Every indexed URL needs a specific destination, and “just redirect it to the homepage” is the single most damaging shortcut in migration work. Google’s own site-move documentation is explicit that one-to-one mapping, not blanket redirection, is what preserves ranking signals. When a page has genuinely been removed with no replacement, serve a proper 404 or 410 instead of forcing traffic to an unrelated homepage. Google reads mass homepage redirects as a soft-404 pattern, and it can undermine trust across your entire redirect map, not just the affected URLs.

Hands arranging network cables at patch panel

1. Build the map from your crawl, not your memory. Take the full indexable URL export from your pre-migration audit and assign a destination to every single row. Gaps here become traffic losses later.

2. Use server-side 301 or 308 redirects exclusively for permanent moves. Skip 302 redirects, meta-refresh redirects, and JavaScript-based redirects. They don’t pass signals reliably and Google may simply ignore them for indexing purposes.

3. Keep hops short. A redirects to B redirects to C redirects to D is a chain that slows crawling and can leak ranking signal at each hop. Resolve every chain down to a single hop pointing straight at the final URL, and cap anything unavoidable at under three hops.

4. Test at scale, not by sampling ten URLs and calling it done. Run redirect checks through Screaming Frog or a custom script against your entire list, then cross-reference server logs to confirm Googlebot is actually following the redirects you built. Spot-check a representative sample directly in Search Console’s URL Inspection tool.

5. Rebuild your canonical strategy from scratch. New pages need new canonical URLs pointing to themselves. Don’t assume an old canonical annotation will carry over correctly, especially if your CMS or URL structure changed alongside the domain.

Never disallow crawling of the old domain during the transition window. Google needs to crawl it to discover and follow your redirects.
Log every redirect rule in a spreadsheet with source URL, destination URL, and redirect type, so you have an audit trail if something goes wrong.
Recheck your redirect map against updated content; a page that changed topic entirely should not inherit its old page’s rankings by redirect alone.

Pro Tip: Keep the old domain live and crawlable, even after cutover. Blocking or letting it expire early cuts off the exact signal path 301 redirects rely on to consolidate rankings onto the new domain.

What Should You Check in the First 48 Hours After Launch?

Cutover has an order, and skipping steps out of sequence is how sites end up indexed with broken canonicals or invisible behind a stray noindex tag. Work through it in this sequence:

Enable redirects across the full map you tested on staging.
Verify SSL is active and serving correctly on every URL pattern, not just the homepage.
Remove staging blocks. Strip any noindex tags, password walls, or robots.txt disallow rules left over from development.
Submit your new sitemap in Search Console immediately after the site is live and crawlable.
File Change of Address in Search Console if you’re moving between domains. This step only applies to full domain-level moves, not path or subdomain changes, and it should happen after redirects are already live and verified working.

Once you’re live, run immediate checks: Coverage reports in Search Console for indexability, a redirect-status sample across your highest-traffic URLs, server health and capacity under real load, sitemap ingestion status, and any new messages flagged in Search Console.

In the first 24 hours, prioritize fixing:

Redirect chains that slipped through staging testing.
Missing canonical tags on templates that didn’t get updated correctly.
Accidental noindex tags or robots.txt rules carried over from staging.
CDN edge configuration issues routing traffic incorrectly at scale.

Set up hourly checks for day one, then daily checks for the first two weeks. Loop in stakeholders on this cadence so nobody is surprised by a dip they weren’t told to expect. Keep your old domain registered and active, and preserve your redirects for at least 180 days, ideally 12 months or longer, since the Change of Address tool itself only actively forwards signals for about 180 days, and organic traffic on old URLs can persist well beyond that window.

How Do You Monitor a Site After Migration?

Monitoring cadence matters as much as the checks themselves. Watch hourly for the first 24 hours, daily through day 14, weekly from day 15 through day 90, and monthly for at least 12 months after that. Migrations don’t resolve on a fixed schedule, and staying attentive past the obvious first month is what separates a full recovery from a slow leak nobody caught.

Build a dashboard covering:

Organic sessions in GA4, segmented by landing page so you can spot which URL clusters are underperforming.
Search impressions and indexed page count in Search Console, tracked against your pre-migration baseline.
Crawl errors and redirect errors, ideally pulled from both Search Console and raw server logs.
Core Web Vitals, since a migration that quietly slows page speed can offset any SEO gains from the move itself.

Watch for specific warning signs rather than vague unease. No crawl activity on the new domain after two weeks is a red flag. Rankings that keep sliding after day 30, rather than stabilizing, typically point to a technical issue rather than normal reindexing lag. Old URLs still appearing in search results without a working redirect, and a sudden drop in referring domains, both deserve immediate attention.

Verify redirects first when troubleshooting. It’s the most common root cause and the fastest to confirm or rule out.
Check indexability and canonical rules second.
Investigate server and CDN errors third.
Review backlinks and manual actions last, since these move slower and are rarely the cause of an immediate drop.

Compare everything against your baseline exports rather than gut feeling.

Why Do Sites Lose Traffic During Migration?

Nearly every serious traffic loss during a migration traces back to one of a short list of preventable mistakes, and most of them are visible in a proper pre-launch audit if someone actually looks.

Missing or incorrect 301 redirects, leaving pages to 404 silently.
Redirect-to-homepage as a default, which Google treats as a soft-404 signal across your whole map.
Redirect chains that slow crawling and dilute signal transfer.
A noindex tag or blocked robots.txt left active on the new site at the moment of cutover, effectively hiding it from search entirely.
Internal links and sitemaps left pointing at old URLs, wasting crawl budget and splitting signals between old and new.
Bundling a CMS swap, a domain move, and a full redesign into one release, which makes it nearly impossible to isolate what broke when something does.
Server or CDN misconfiguration causing a spike in crawl errors right when Google is trying hardest to reindex your site.

The recurring pattern across migration post-mortems is not a mystery bug or an algorithm penalty. It’s a redirect that never got mapped, a noindex tag someone forgot to remove, or three unrelated changes shipped at once with no way to tell which one caused the drop.

Prevention is a full pre-move audit, a frozen scope, staged testing before launch, redirect verification at scale, and clean baseline snapshots you can compare against later. None of this is complicated. It’s just easy to skip under deadline pressure, and skipping it is exactly what shows up in the traffic charts three weeks later.

How Do Domain Moves, HTTPS Changes, and Site Mergers Differ?

Not every migration carries the same risk profile, and the specific type you’re running determines which tools and safeguards actually apply.

Scenario	Key Precheck	Search Console Action	Post-Move Priority
Domain-to-domain move	Verify both old and new domain properties	File Change of Address after redirects are live	Confirm signal forwarding and monitor indexing
HTTP to HTTPS	Confirm SSL is fully active before redirecting	Update canonical tags to HTTPS versions	Test for mixed-content errors
Subdomain or path-level move	Note that Change of Address does not apply here	Rely entirely on redirects, not COA	Monitor crawl behavior closely, since no COA signal exists
Site merge or consolidation	Plan phased moves rather than one bulk switch	Avoid chaining multiple COA submissions	Watch for duplicate content between merged sections

Domain-to-domain moves are the scenario Google’s Change of Address tool was built for, but it only works at the full domain level and only after your redirects are already live and functioning. Subdomain changes and path-level restructuring don’t qualify, which means your entire signal transfer rests on the redirect map itself.

HTTPS migrations carry their own risk: HTTPS is a confirmed ranking signal, but only if the certificate is active and consistent before you redirect, with canonical tags updated to match and no mixed-content warnings left unresolved.

If you’re consolidating multiple domains into one, resist the urge to submit several Change of Address requests back to back. Phase the moves and let each one settle before starting the next.

Pro Tip: If you’re migrating onto a previously owned or purchased domain, check its history on the Wayback Machine and pull its backlink profile before committing. A domain with a spammy past or a manual action history can quietly work against you no matter how clean your new site is.

How Vertical Runs Migrations

A migration that goes well usually follows the same flow regardless of scale: discovery and baselines, then mapping and staging, then validation, then cutover, then monitoring and remediation. What separates a clean recovery from a slow bleed is usually discipline in that order, not any single clever technical trick.

Outsourcing coordination tends to make sense once complexity crosses a few clear thresholds:

Sites with more than 100,000 indexed URLs, where manual redirect mapping becomes error-prone at scale.
eCommerce sites where checkout and product funnels are revenue-critical and can’t tolerate an extended dip.
Multi-domain consolidations, where signal transfer, canonical strategy, and Change of Address sequencing all interact.

Above those thresholds, coordinated execution across SEO, development, and monitoring tends to shorten the recovery window considerably compared to a single person juggling the whole project alone.

What I’ve Learned From Watching Migrations Succeed and Fail

The migrations that go wrong rarely fail because of something exotic. They fail because someone assumed a redirect map was “close enough,” mapped a cluster of old URLs straight to the homepage to save time, or forgot that a noindex tag from staging was still sitting live on launch day. Freeze your scope. Test every redirect, not a sample you feel good about. Keep the old domain crawlable even after cutover, because that’s the exact channel Google uses to consolidate your signals onto the new site.

If you check one thing in the first 72 hours, check indexability. A beautifully redirected site that Google can’t index because of a leftover robots.txt rule is functionally invisible, and that mistake is shockingly common.

Expect a dip. That part is normal and it says nothing about whether your migration succeeded. What matters is whether that dip stabilizes by day 30 or keeps getting worse. The first is recovery. The second is a technical problem you haven’t found yet, and it’s still findable if you keep looking.

How Vertical Can Help With Your Site Migration

If you’re staring down a migration and the checklist above feels like a lot to run in-house while also keeping the business running, that gap is exactly where a coordinated team earns its keep. Vertical Brands handles migration planning, technical implementation, redirect quality assurance, and post-launch monitoring under one roof, rather than splitting the work across a developer, a freelance SEO, and whoever has time to check Search Console this week.

Vertical Brands

A migration readiness review from Vertical Brands starts with a full URL audit against your existing site, builds out a complete redirect plan before a single line of code changes, and flags the risk points specific to your setup, whether that’s a large eCommerce catalog, a multi-domain consolidation, or a straight domain move with a tight deadline. If you’re planning a migration in the next few months, request a baseline snapshot and redirect plan from Vertical Brands before you set a launch date, not after.

Frequently Asked Questions

Will my rankings drop after a site migration?

Most sites see a short-term dip in the first one to two weeks as Google reindexes new URLs. This is normal and usually stabilizes within 30 days. A drop that keeps getting worse past that point almost always means a technical issue, most often a missing redirect or an accidental noindex tag.

How long should I keep old redirects active?

Keep redirects live for at least 180 days, matching the window Google’s Change of Address tool uses to forward signals, though 12 months or longer is safer for sites with strong historical backlink profiles.

Does Change of Address replace the need for 301 redirects?

No. Change of Address is a domain-level signal that tells Google you’ve moved, but it only works after your 301 redirects are already live and it doesn’t apply to subdomain or path-level changes at all. Your redirect map does the actual work of transferring rankings.

What’s the biggest cause of traffic loss during migration?

Incomplete or incorrect redirect mapping, particularly the shortcut of redirecting everything to the homepage instead of building one-to-one mappings for each URL. Close behind that is a leftover noindex tag or blocked robots.txt rule carried over from staging.

Should I migrate a large site all at once or in phases?

For sites beyond roughly 100,000 URLs or multi-domain consolidations, phased migration reduces risk considerably. It isolates problems to a smaller batch of URLs and gives you a clean opportunity to fix issues before rolling the same mistake out across the entire site.

How do I handle backlinks during a migration?

Your 301 redirects carry most link equity automatically if implemented correctly, but reaching out to your highest-value backlink sources to request a direct link update to the new URL adds an extra layer of protection, especially for links that matter most to your rankings.