← Back to blog

Site Migration SEO Checklist: Protect Rankings During Your Move

August 20, 2026
Site Migration SEO Checklist: Protect Rankings During Your Move

Follow a phased site migration SEO checklist and you protect your rankings and recover any dip within weeks, not months. The five phases are: pre-migration benchmarking, staging and build testing, URL mapping and redirects, launch-day verification, and post-migration monitoring.

  • Pre-migration: lock scope, benchmark analytics, crawl every URL, map redirects.
  • Staging: block indexing, run technical audits, validate canonicalization.
  • URL mapping: build a one-to-one 301 redirect plan.
  • Launch day: flip DNS, verify redirects, submit sitemaps.
  • Post-migration: monitor traffic, rankings, and crawl errors for 30 to 90 days.

Quick take: even a well-executed migration usually causes a short, visible dip in traffic for one to four weeks. Keep old-domain redirects live for at least 180 days, which is how long Google's Change of Address signal-forwarding stays active.

Key Takeaways

A phased site migration SEO checklist, executed in order from benchmarking through 90-day monitoring, prevents most preventable ranking losses and shortens recovery time.

PointDetails
Benchmark before you touch anythingExport GA4, GSC, and crawl data so you have a clear before-and-after comparison.
Build a one-to-one redirect mapPrioritize by traffic and backlinks; never bulk-redirect to the homepage.
Extract logs for large sitesSites over 10,000 URLs need a 90-day server-log cross-check against the crawl export.
Monitor for at least 90 daysCheck daily in week one, then weekly, then rebaseline at day 90.
Consider a hand-coded rebuildKirk & Co pairs migration execution with custom-coded builds for Indiana local businesses.

Table of Contents

Site Migration SEO Checklist: The Launch-Day TL;DR

Hand this to your project manager or developer before cutover. Each item is one task, one owner, one deadline.

  1. Export GA4 and Google Search Console data for the last 90 days (Owner: SEO, Due: T-14 days).
  2. Run a full Screaming Frog crawl of the live site and save the export (Owner: SEO, T-14).
  3. Build the 1:1 redirect map in a shared spreadsheet (Owner: SEO/Dev, T-10).
  4. Confirm staging is blocked from public indexing (Owner: Dev, T-7).
  5. Validate canonical tags and schema on staging templates (Owner: SEO, T-5).
  6. Freeze the redirect map. No more edits without sign-off (Owner: Project lead, T-2).
  7. Set DNS TTL to 300 seconds or lower ahead of cutover (Owner: Dev, T-1).
  8. Hold the old domain and hosting active, don't cancel anything (Owner: Dev, T-0).
  9. Flip DNS, confirm redirects fire, submit the new sitemap in GSC (Owner: Dev/SEO, T-0).
  10. Spot-check 20 random URLs plus your top 50 traffic pages for correct status codes (Owner: SEO, T-0).
  • Keep this list pinned in Slack or your project tool during launch week.
  • Assign a single decision-maker for the rollback call before you start.

Pro Tip: Copy this list into a shared checklist tool the week before launch so nobody is hunting for it during the actual cutover.

Why Do Site Migrations Put SEO At Risk?

Search engines treat a migration as a fresh signal to interpret. Even a technically clean move often produces a temporary dip while Google recrawls and reassesses the new URLs, and most of that loss traces back to missing redirects or accidental crawl blocks rather than anything algorithmic. Done right, a migration can actually improve rankings, particularly when it fixes page speed or mobile usability problems the old site had.

Different migration types carry different risk profiles:

  • Domain change: highest risk. Requires filing Google's Change of Address tool and rebuilding trust signals.
  • CMS swap: risk concentrated in template changes that break canonical tags, schema, or internal linking.
  • Redesign only (same domain/URLs): lower risk, but watch for content thinning and lost internal links.
  • URL restructure: moderate to high risk; needs the most rigorous redirect mapping.
  • HTTP to HTTPS: generally low risk if handled with clean 301s and updated internal links.
  • Site consolidation: requires careful handling of duplicate content and canonical signals across merged domains.
  • International/hreflang migrations: high complexity; every hreflang cluster needs re-validation post-launch.

Large e-commerce catalogs and multi-location local sites carry extra exposure because a single broken redirect pattern can touch thousands of product or location pages at once, not just one landing page.

How Do You Prepare For A Site Migration Before Launch?

Pre-migration planning is where most recoverable losses actually get prevented. Skipping this phase to save a week almost always costs a month later.

Freeze scope in writing. Decide exactly what changes: domain, CMS, design, or URL structure. Write down what does not change. Bundling a redesign, a CMS swap, and a URL restructure into one release makes it nearly impossible to isolate what caused a ranking drop if something goes wrong. Backlinko's migration research points to this failure to isolate variables as one of the most common causes of slow recovery.

Capture your baseline. Before anything moves, export:

MetricWhere To Pull ItWhy It Matters
Organic sessions, top landing pagesGoogle Analytics 4Your recovery yardstick post-launch
Indexed URLs, top queries, click dataGoogle Search ConsoleDetects indexation loss early
Full crawl and URL inventoryScreaming FrogSource list for your redirect map
Keyword rankingsSemrushTracks ranking movement by URL
Core Web VitalsPageSpeed InsightsConfirms speed doesn't regress
Referring domains and top backlinksSemrush or your link toolProtects link equity during the move

Crawl everything, and know when to go deeper. A full Screaming Frog crawl gives you the URL inventory your redirect map is built on. But a crawler only sees what it can find by following links. For sites over 10,000 URLs, Google's own guidance says to extract server log files and cross-reference them against a 90-day lookback, since Googlebot often visits orphaned or deep pages a standard crawl never reaches.

Build the redirect map and rollback plan now, not later. Start your one-to-one URL map immediately, prioritizing pages with the most traffic, conversions, and backlinks. Define exactly what triggers a rollback (a traffic drop past a set threshold, a spike in 404s, a broken checkout flow) and who has the authority to pull that trigger.

Hands arranging sticky notes for redirect mapping

Pro Tip: Export your GSC and GA4 data as CSVs and store them in the same folder as your redirect map. When someone asks "what did the old page rank for?" three weeks after launch, you want that answer in thirty seconds.

What Should You Test On Staging Before Going Live?

Staging is your last chance to catch a mistake before it becomes visible to Google. Two rules govern this phase: keep staging invisible to search engines, and make it functionally identical to what production will look like.

  • Password-protect staging or block it with a noindex meta tag and a disallow rule, then confirm neither of those ever gets deployed to production by accident.
  • Prepare your production-ready robots.txt and XML sitemap now so the swap on launch day is a simple file replacement, not a rebuild under pressure.
  • Run a full crawl of staging to check canonical tags point to the correct new URLs, not leftover staging URLs.
  • Validate hreflang clusters if you run international pages, since a broken hreflang tag can quietly serve the wrong page to the wrong region for weeks before anyone notices.
  • Confirm schema markup survived the template change using the Schema Markup Validator against representative page types (product, article, local business, FAQ).
  • Verify GA4 tags fire correctly and that a Search Console property is ready to be verified for the new domain or subdomain.
  • Check Core Web Vitals on staging pages with PageSpeed Insights before launch, not after.

A common question here is PageSpeed Insights versus GTmetrix: both measure load performance, but PageSpeed Insights pulls real Chrome User Experience Report field data alongside lab data, which makes it the better read on how Google itself is likely to score your Core Web Vitals. GTmetrix gives you more granular waterfall detail for debugging exactly which asset is slow.

Pro Tip: Crawl staging using an authenticated Screaming Frog session (basic auth or cookie-based login) so the crawler can actually see past the password wall instead of returning a wall of 401 errors.

How Do You Map URLs And Set Up Redirects Correctly?

The redirect map is the single highest-leverage document in the entire migration. Get it wrong and you lose link equity, rankings, and crawl budget all at once.

RuleWhat To DoWhat To Avoid
Mapping ratioOne old URL to one new URL wherever possibleBulk-redirecting thousands of pages to the homepage
Redirect type301 for permanent movestemporary redirects for permanent changes
Parameterized URLsMap to the cleanest equivalent new URLLeaving query strings unhandled and creating duplicate paths
Canonical tagsVerify every new URL's canonical points to itselfCopy-pasted canonicals pointing to old or wrong URLs

Consolidating several old pages into one new page is fine, but document which page absorbed which backlinks so you can point outreach or disavow efforts at the right target later. Pagination needs the same care: redirect paginated URLs to their new equivalents rather than collapsing them all onto page one, which strands users and crawlers deep in a category with no path back.

Implementation varies by stack. On WordPress, a redirect plugin or .htaccess rules work for smaller sites; on Shopify or headless setups, redirects typically live in platform-native redirect tools or edge functions at the CDN layer (Cloudflare Workers, Vercel Edge Config). Whichever stack you use, QA every redirect on staging before launch, then spot-check the same URLs again once live.

Pro Tip: Sort your redirect map by backlink count first, traffic second. A page with ten high-authority backlinks and modest traffic deserves the same priority as your top traffic page.

What Do You Check In The First Hours After Launch?

Launch day is a sequence, not a checklist you can do in any order. Work through it in this sequence:

  1. Flip DNS and confirm the new site resolves for your team and at least one outside network.
  2. Confirm redirect rules are live by testing your top 50 traffic pages plus 20 random URLs for correct status codes.
  3. Swap in the production robots.txt, making sure it no longer disallows crawling.
  4. Submit the new XML sitemap in Google Search Console.
  5. Remove any noindex tags that leaked from staging into production templates.
  6. Verify GA4 events are firing correctly on live pages, not staging.
  7. Verify your Search Console property for the new domain or URL structure and run URL Inspection on a handful of key pages.
  8. Confirm internal links point to new URLs, not old ones through a redirect chain.
  9. Decide, based on a pre-agreed threshold, whether anything triggers an immediate rollback.

Have your rollback decision-maker and a communication channel ready before you start, not after something breaks.

Pro Tip: Test redirects from an incognito browser and a mobile device separately. Cached sessions on your work laptop will lie to you about what's actually live.

How Long Should You Monitor SEO After A Migration?

Recovery windows vary, but a disciplined monitoring cadence catches problems while they're still cheap to fix. Check daily for the first week, weekly through week four, then biweekly out to the 90-day mark, where you rebaseline against your pre-migration numbers.

Watch these signals closely:

  • Indexed page count in Google Search Console, compared against your pre-migration total.
  • Organic sessions and top landing pages in GA4.
  • Ranking trajectory for your top commercial keywords in Semrush.
  • Core Web Vitals scores, since template or hosting changes can quietly regress speed.
  • Crawl error reports for spikes in 4xx or 5xx status codes.

When something looks wrong, work through it in order:

  1. Check for redirect chains (A to B to C) and collapse them into single-hop 301s.
  2. Confirm canonical tags on affected pages point to themselves, not stale URLs.
  3. Re-crawl with Screaming Frog to find any broken redirects the launch-day spot check missed.
  4. Check Search Console's Change of Address status if you moved domains; that signal window runs 180 days from filing.

A large or persistent drop past 30 days without recovery usually points to a bigger structural issue: lost backlinks, thin content on migrated pages, or an indexation block still live somewhere.

Pro Tip: Set a calendar reminder for day 90, not just day 30. Some ranking recoveries genuinely take that long, and panicking at day 20 leads to unnecessary changes.

Which Tools And Templates Do You Actually Need?

Five tools cover nearly every phase of a migration and each earns its place for a specific reason.

  • Google Search Console: indexation status, Change of Address filing, URL Inspection, crawl error reports.
  • Google Analytics 4: traffic benchmarking before and after, landing page performance, conversion tracking through the transition.
  • Screaming Frog: full-site crawls, URL inventory, canonical and redirect auditing on both staging and production.
  • PageSpeed Insights: Core Web Vitals and field data to confirm speed didn't regress after the rebuild.
  • Semrush: ranking tracking by URL and backlink mapping so you know what link equity is riding on each redirect.

Beyond the tools, build three documents before launch: a redirect spreadsheet with old URL, new URL, and priority tier; a launch-day verification sheet matching the sequence above; and a rollback runbook naming the decision-maker and the exact rollback steps. A website audit checklist is worth running alongside your pre-migration crawl to catch issues a redirect map alone won't surface.

ToolBest Used InWhy
Screaming FrogPre-migration and stagingBuilds your URL inventory and catches canonical errors
Google Search ConsolePre-migration through post-launchBaseline, Change of Address, indexation tracking
PageSpeed InsightsStaging and post-launchConfirms Core Web Vitals hold up
SemrushPre-migration and monitoringTracks rankings and backlinks by URL

What Are The Most Common Migration Mistakes?

Most migration disasters trace back to a short list of repeat offenders:

  • Missing 301s on pages that had real traffic or backlinks.
  • Redirecting everything to the homepage instead of matching content.
  • Staging left indexable because a noindex tag or password wall got skipped.
  • Schema markup and metadata lost in a template change nobody double-checked.
  • Backlinks never remapped, or a disavow file left behind on the old domain.

Run these checks on staging and again within 24 hours of launch:

  1. Crawl for orphaned pages with no internal links pointing to them.
  2. Spot-check schema on your top ten templates with the Schema Markup Validator.
  3. Confirm robots.txt on production allows crawling, not the staging version.
  4. Pull a Search Console crawl stats report to catch sudden spikes in errors.

If traffic drops after launch, fix in this order: crawl blocks first, broken redirects second, lost metadata and schema third. Crawl blocks stop everything downstream, so they get triaged first every time.

When And Why Should You Extract Server Logs?

For any site over 10,000 URLs, extract server logs and cross-reference a 90-day Googlebot lookback against your crawl export and redirect map. Crawlers only follow links; logs show what Googlebot actually visited, including orphaned or deep pages a standard crawl misses.

  • Filter log files for the Googlebot user agent specifically, not all bot traffic.
  • Cross-reference hit URLs against your existing redirect map to flag gaps.
  • Prioritize any high-frequency Googlebot URL that's missing a redirect entry.

Pro Tip: Most log-parsing tools can export straight to CSV, which makes a VLOOKUP against your redirect spreadsheet a five-minute job instead of a manual hunt.

Lessons From Hands-On Migrations

The recurring failure isn't technical complexity, it's bundling too many changes into one release and losing the ability to isolate what caused a drop. Keep old-domain redirects live well past launch, and don't cancel hosting the moment DNS flips. A few non-obvious controls, like locking the redirect map before build starts, have saved more projects than any single audit tool.

Kirk & Co: Hand-Coded Migration Support For Indiana Businesses

Most migration guides assume you have an in-house dev team ready to execute redirect maps, staging audits, and launch-day verification on a Saturday morning. Kirk & Co builds that execution into the process itself. Every site is hand-coded rather than assembled from a template, which means the redirect logic, schema, and Core Web Vitals work get built in from day one instead of patched on after a slow, generic build.

Kirk-co

For contractors, home service businesses, retailers, and nonprofits across Indiana, that means a migration or rebuild that preserves your local SEO signals while actually fixing the speed and design problems that hurt conversions in the first place. Kirk & Co's website maintenance and support plan covers the post-launch monitoring window too, so nobody's stuck manually checking crawl reports at week six. If you're planning a move and want a team that treats the checklist as the baseline, not the finish line, start with a look at custom website development and get a scope conversation on the calendar before you lock a launch date.

Sources