The SEO Checklist for Website Migrations That Protect Your Rankings

Website migrations are high-stakes operations. Change the wrong thing, skip a redirect, or launch without a crawl comparison, and months of organic growth can disappear overnight. Industry data consistently shows that even well-planned migrations cause a temporary traffic dip. Poorly planned ones cause permanent damage. The difference between a dip and a disaster is preparation.

This checklist breaks the migration process into three phases: pre-migration, launch day, and post-migration monitoring. Each phase has specific deliverables, and skipping any of them increases the risk of organic traffic loss. At Gorilla Marketing, we’ve managed migrations across CMS replatforms, domain changes, HTTPS moves, and site redesigns. The process below is what we use internally, refined from real projects where the stakes were seven figures of annual organic revenue.

What Counts as a Website Migration?

A migration is any change that forces search engines to re-evaluate how they crawl, index, or rank your site. That includes:

Domain changes – moving from one domain to another (including brand name changes)

Protocol changes – HTTP to HTTPS

CMS replatforming – switching from one content management system to another (WordPress to Shopify, custom-built to HubSpot, etc.)

Site redesigns – structural changes that alter URL paths, navigation, or information architecture

Domain consolidation – merging multiple domains or subdomains into one property

International restructuring – moving from subdirectories to subdomains or vice versa

Each type carries different risk levels. A protocol change with no URL restructuring is relatively low-risk. A full CMS replatform with new URL structures, a new domain, and a redesign happening simultaneously? That’s a high-wire act.

The common mistake is treating a redesign as “just a design project.” If URLs change, if page templates change, if navigation changes, if content gets removed or reorganized, it’s a migration. And it needs the same rigor as any other migration, even if nobody on the dev team calls it one.

Why Do Migrations Hurt Organic Traffic?

Understanding the mechanism helps you prevent the damage. When Google crawls your site and finds that URLs it has indexed no longer exist, or exist at different locations, it needs to re-process every affected page. That re-processing takes time, and during that window, rankings fluctuate.

Several things happen simultaneously:

Redirect processing lag. Even with perfect 301 redirects in place, Google doesn’t transfer all ranking signals instantly. There’s a processing period where the old URL’s authority is gradually assigned to the new one. During that period, rankings can drop.

Crawl budget reallocation. A migration forces Googlebot to recrawl your entire site. If your site has thousands of pages, that recrawl doesn’t happen in a day. Pages that were previously indexed and ranking may temporarily disappear from the index while Google works through the queue.

Lost internal link equity. If your internal linking structure changes during the migration, the way PageRank flows through your site changes too. Pages that previously received strong internal link signals might suddenly be orphaned or buried deeper in the architecture.

Content changes. If the migration includes a content overhaul (new copy, removed pages, restructured sections), Google is evaluating what is essentially a different page at the same URL. That re-evaluation can cause temporary ranking shifts even without URL changes.

Backlink disruption. External sites link to specific URLs. If those URLs change and redirects aren’t in place, you lose the link equity those backlinks were passing. This is often the single biggest source of permanent traffic loss after a migration.

A well-executed migration minimizes each of these factors. A poorly executed one stacks them all on top of each other.

Phase 1: Pre-Migration (4–8 Weeks Before Launch)

This is where migrations are won or lost. The work you do before the launch date determines whether recovery takes weeks or months. Cut corners here, and no amount of post-launch firefighting will make up for it.

Have You Benchmarked Everything That Matters?

Before you change anything, document what you have. You can’t measure the impact of a migration if you don’t know where you started.

Organic traffic baseline. Pull at least 12 months of organic traffic data from GA4, broken down by landing page. Export it. You’ll need this for post-migration comparison. Include revenue or conversion data attributed to organic search.

Ranking positions. Export your current keyword rankings for all tracked terms. Include the URL that ranks for each keyword. After migration, you’ll need to verify that the correct URLs are still ranking.

Google Search Console data. Export impressions, clicks, average position, and CTR by page and by query. GSC data is only retained for 16 months, so if you don’t export it now, you lose the baseline permanently.

Backlink profile. Run a full export from Ahrefs, Semrush, or Majestic. Document every URL that receives external links, the number of referring domains, and the anchor text distribution. This becomes your redirect priority list – pages with strong backlink profiles need perfect redirects.

Crawl snapshot. Run a full site crawl using Screaming Frog or a similar crawler. This gives you a complete URL inventory, including response codes, canonical tags, meta robots directives, hreflang tags, and internal linking structures. Export everything. This is your source of truth.

Indexed page count. Check the site: operator in Google and your GSC index coverage report. Know exactly how many pages Google has indexed before migration.

Have You Built a Complete URL Map?

This is the single most important deliverable in any migration. Every URL on the current site needs a mapped destination on the new site. No exceptions.

Build a spreadsheet with these columns:

Pages with significant backlinks or organic traffic get the highest priority. Every one of those needs a 1:1 redirect to the most relevant equivalent on the new site. Don’t redirect everything to the homepage. That’s a soft 404 in Google’s eyes and wastes all the topical relevance those pages built.

For pages you’re intentionally removing, decide between a 301 redirect to the next best page and a 410 (gone) response. If the page has backlinks or traffic, redirect it. If it’s genuinely obsolete with no link equity, a 410 is cleaner than a misleading redirect.

Is Your Content Migration Plan Documented?

Content often gets lost or altered during migrations, especially during CMS replatforms where templates change. Before launch, verify:

All page titles and meta descriptions are migrated or rewritten for the new structure

H1 tags are preserved or intentionally updated

Image alt text hasn’t been stripped (this happens constantly during CMS migrations)

Structured data (schema markup) is carried over to the new templates – confirm JSON-LD blocks aren’t dropped during the template swap

Internal links within body content still point to valid URLs (not the old URL structure)

If you’re pruning content as part of the migration, document what’s being removed and why. Content pruning can actually help organic performance by eliminating thin or duplicate pages. But removing pages that drive traffic or hold backlinks without redirecting them is a different story entirely.

Have You Addressed Image SEO?

Images get overlooked in migrations more than almost anything else. New CMS platforms often change image URL structures, strip alt text during content import, or serve images from a different CDN or subdomain.

Check that:

Image URLs are either preserved or redirected (especially if images rank in Google Image Search)

Alt text is carried over from the old site

Image file names haven’t been replaced with auto-generated hashes

Image sitemaps are included in the new XML sitemap

If your site gets meaningful traffic from image search, this isn’t optional. It’s a redirect mapping exercise in its own right.

Have You Configured the Staging Environment Correctly?

Your staging site needs to be invisible to search engines. This sounds obvious, but it goes wrong regularly. If the staging site gets indexed before launch, you’ll end up with duplicate content issues and potentially the staging domain outranking your live site.

Add noindex, nofollow meta tags to every page on staging

Block crawlers via robots.txt on the staging domain

Password-protect the staging environment if possible

Confirm that no canonical tags on the staging site point to the staging domain – they should either be absent or point to the live domain

Before launch, remove all of these restrictions. One of the most common post-migration disasters is launching the new site with noindex tags still in place because someone forgot to remove the staging configuration.

Have You Set Up Redirect Rules?

With your URL map complete, implement the redirects. Use 301 (permanent) redirects for all URL changes.

Key rules:

No redirect chains. If page A already redirects to page B, and page B is moving to page C, update the redirect so A goes directly to C. Chains waste crawl budget and dilute link equity with each hop.

No redirect loops. Test every redirect before launch. A loop (A redirects to B, B redirects to A) will block both pages from being indexed.

Redirect at the server level, not via JavaScript. JavaScript redirects aren’t reliably followed by all crawlers and don’t pass link equity the same way server-side 301s do. This matters especially for sites with JavaScript rendering considerations.

Test with trailing slashes and without. Make sure both /page/ and /page resolve correctly.

HTTPS variants. If you’re also moving to HTTPS, ensure HTTP versions redirect to HTTPS versions of the new URLs, not the old ones.

What About Hreflang and International Targeting?

If your site has hreflang tags (multiple language or regional versions), the migration is significantly more involved. Every hreflang annotation needs to be updated to reference the new URL structure. If domain A signals domain B as its Spanish equivalent, and domain A’s URLs all change, the hreflang relationship breaks unless both sides are updated.

Coordinate international migrations carefully. If only one regional site is migrating, the other sites’ hreflang annotations still need updating to point to the new URLs. Miss this and you’ll see indexing confusion across all regional properties.

Have You Aligned PPC and Paid Media?

This gets missed constantly. If you’re running Google Ads, Meta Ads, or any other paid campaigns, those ads point to specific landing page URLs. When those URLs change, your ads break. Broken landing pages mean disapproved ads, wasted spend, and a sudden drop in paid traffic layered on top of any organic disruption.

Before migration:

Export all active ad landing page URLs

Map them to new URLs

Schedule ad updates to go live simultaneously with the migration

Pause campaigns temporarily if you can’t coordinate the timing

If organic traffic dips during the migration window (it will), having paid channels running smoothly provides a revenue safety net. Losing both organic and paid traffic at the same time is an avoidable disaster.

What’s the Impact on Local SEO?

If your business has physical locations with Google Business Profiles, local landing pages, or local citations (directory listings), a domain or URL change affects all of them.

Update the website URL in every Google Business Profile

Update NAP (name, address, phone) citations across directories if the domain changes

Ensure local SEO landing pages are included in the redirect map

Verify that location-specific schema markup reflects the new URLs

Citation inconsistencies after a migration can suppress local pack visibility. If you have dozens or hundreds of locations, this is a project within the project.

Have You Planned the Backlink Response?

Run your backlink audit before migration. Identify your top referring domains and highest-value backlinks. After migration, you’ll want to:

Verify redirects are handling inbound link equity correctly

Reach out to high-value linking sites and ask them to update their links to the new URLs (redirects work, but direct links are stronger)

Disavow any toxic links identified during the audit rather than redirecting them to the new site

Strong link building practices before and after migration accelerate recovery. A site that enters a migration with a healthy, diverse backlink profile recovers faster than one that was already struggling.

Phase 2: Launch Day

Launch day should be anticlimactic. If the pre-migration work was thorough, launch is just flipping the switch. But there are still critical checks to run in real time.

Is the Redirect Map Live and Working?

Test a sample of redirects immediately after launch. Prioritize:

Top 50 pages by organic traffic

Top 50 pages by backlink count

All service/product pages

All pages with active PPC campaigns pointing to them

Use Screaming Frog in list mode. Feed it your old URLs and verify every one returns a 301 to the correct new URL. Any that return 404s, 302s, or redirect to the wrong destination need fixing immediately.

Have You Submitted the New XML Sitemap?

Your XML sitemap should contain only the new URLs. Don’t leave old URLs in the sitemap. Submit the updated sitemap to Google Search Console immediately after launch.

If your site is large, consider submitting a separate sitemap containing just the redirected URLs for the first few weeks. This helps Googlebot discover and process the redirects faster.

Is Robots.txt Correct?

Check the live robots.txt file on the new site. Verify it isn’t blocking anything that should be crawlable. One of the most common migration disasters is a robots.txt file that still contains staging-environment disallow rules, effectively telling Google not to crawl the entire site.

Are Canonical Tags Pointing to the Right Place?

Every page on the new site should have a self-referencing canonical tag pointing to its own new URL. Watch for:

Canonical tags still pointing to old URLs

Canonical tags pointing to the staging domain

Missing canonical tags entirely

A quick crawl of the live site immediately after launch will catch these.

Is Google Analytics Tracking?

Verify that GA4 is firing on every page of the new site. Check the real-time report in GA4. If you see zero active users on a weekday afternoon, something is broken. Common issues:

Tracking code not installed on the new template

Tag Manager container not firing

Filters excluding the new domain

Cross-domain tracking configuration not updated

Losing analytics data during a migration is painfully common and completely preventable.

Have You Verified GSC Properties?

If the domain has changed, you need a new Google Search Console property for the new domain. If you’re moving from HTTP to HTTPS, you need a new property for the HTTPS version (or verify the domain-level property covers both).

Use the Change of Address tool in GSC if you’re changing domains. This tells Google directly that the site has moved and accelerates the transition of signals from the old property to the new one.

DNS and TTL Considerations

If the migration involves DNS changes (new hosting, new CDN, new domain), reduce the TTL (Time to Live) on your DNS records at least 48 hours before migration. A lower TTL means DNS changes propagate faster. Set it to 300 seconds (5 minutes) before migration, then increase it back to normal (3600+ seconds) once everything is stable.

This reduces the window where some users see the old site and others see the new one.

Phase 3: Post-Migration Monitoring (Weeks 1–12)

The migration isn’t done when the site launches. It’s done when organic traffic has recovered to pre-migration levels (or better). That recovery takes anywhere from two weeks to six months, depending on the migration’s scope and how clean the execution was.

What Should You Monitor Daily in Week 1?

Crawl stats in GSC. Watch for spikes in crawl activity (good – Google is processing the migration) or sudden drops (bad – something is blocking the crawler). Check the crawl stats report daily for the first week.

404 errors. Monitor GSC’s page indexing report and your server logs for 404 spikes. Every 404 that was supposed to be a 301 is a leaked redirect that needs fixing.

Indexed page count. Check how many pages Google has indexed on the new site. Compare against your pre-migration baseline. A steep drop in indexed pages means something is preventing discovery or indexing.

Organic traffic. Track daily organic sessions in GA4. Expect a dip. The question is how deep and how long. A 10-20% dip in the first two weeks is normal for a well-executed migration. A 50%+ drop signals a problem that needs immediate diagnosis.

What Does the First Month Look Like?

Weeks 1–2: Crawl activity spikes as Google processes redirects and discovers new URLs. Rankings fluctuate. Traffic typically dips 10-30% even in clean migrations. Don’t panic, but do monitor.

Weeks 3–4: Indexing stabilizes. The new URLs start replacing old ones in search results. Rankings begin to settle. If traffic hasn’t started recovering by the end of week 4, something is likely wrong with redirects, canonical tags, or indexing directives.

What Are Realistic Recovery Timelines?

Recovery time depends on migration scope:

These are ranges from well-executed migrations. A botched migration with missing redirects, broken canonical tags, and lost content can take six months or more to recover – if it fully recovers at all.

How Do You Run a Post-Migration SEO Audit?

Two weeks after launch, run a full site crawl and compare it against your pre-migration crawl snapshot. Check for:

Missing pages. Any URL from the old site that isn’t accounted for (either live on the new site or properly redirected).

Redirect chains. Pages that redirect through two or more hops before reaching the final destination.

Broken internal links. Links within body content or navigation that point to old URLs instead of new ones.

Missing metadata. Pages where title tags, meta descriptions, or H1 tags weren’t carried over.

Orphaned pages. New pages that exist but aren’t linked from anywhere in the site’s navigation or internal linking structure.

Crawl errors. Any 5xx errors, soft 404s, or pages returning unexpected status codes.

Core Web Vitals changes. New templates or hosting can affect load times and interaction metrics. Flag any major regressions in LCP, INP, or CLS and address them before they compound ranking losses.

What If Traffic Doesn’t Recover?

If organic traffic is still down 30%+ after six weeks, escalate the diagnosis:

Check redirect coverage. Are all high-traffic old URLs properly redirecting? Use server logs to find old URLs still receiving traffic that aren’t being redirected.

Check for noindex leaks. Crawl the site and check for pages accidentally tagged with noindex. This is the number-one migration killer. A single misconfigured template directive can deindex thousands of pages.

Check canonical tag accuracy. Are canonical tags pointing to the correct URLs? Cross-domain canonicals left from the staging environment can prevent indexing.

Check Google’s indexing. Use the URL Inspection tool in GSC on specific pages that lost rankings. Is Google seeing the page correctly? Is it indexed? Is there a canonical mismatch?

Check backlink redirect chains. Are your most valuable backlinks still passing equity? If a backlink points to old URL A, which redirects to old URL B, which redirects to new URL C, that double redirect is diluting the signal. Flatten those chains.

Check for content changes that hurt. If the migration included a content overhaul and specific pages lost rankings, the new content may not satisfy the same search intent the old content did. Compare the old cached version (if available) against the new page.

How Does a Migration Affect AI and LLM Citations?

This is a factor most migration checklists don’t cover. Large language models (ChatGPT, Google’s Gemini, Claude, Perplexity) build their knowledge bases by training on and retrieving web content. When your URLs change, the association between your content and those models’ reference data can break.

If an LLM was trained on content at your old URLs, that association doesn’t update in real time. New content at new URLs needs to be re-crawled and re-indexed by both traditional search engines and any AI retrieval systems that reference live web data.

Three things help:

Maintain clean redirects. AI retrieval systems that follow links (like Perplexity) will follow your 301s the same way Googlebot does.

Preserve your content’s structure. If a page was being cited by LLMs, don’t drastically change the content during migration. Keep the substance; update the URL.

Resubmit to indexing APIs. If you use IndexNow or Google’s Indexing API, submit your new URLs immediately. The faster search engines index your new structure, the faster AI systems that depend on fresh search data will pick it up.

LLM citation isn’t something you can directly control, but a clean migration with preserved content gives you the best shot at maintaining whatever AI visibility you’ve built.

How Do You Coordinate a Phased Migration?

Not every migration needs to happen all at once. For large sites (10,000+ pages), a phased approach reduces risk by limiting the blast radius of any single mistake.

Phase by section. Migrate one directory or content type at a time. Move /blog/ first, monitor for two weeks, then move /products/, then /services/. Each phase gets its own redirect map, its own monitoring window, and its own rollback plan.

Phase by priority. Migrate your highest-traffic, highest-revenue pages first. Get those right, confirm recovery, then move to lower-priority sections.

Phase by risk level. If part of the migration involves URL changes and part doesn’t, do the no-change portion first. That way, you’re only monitoring one variable at a time.

The downside of phased migration is timeline. It takes longer. But for e-commerce SEO sites with thousands of product pages and significant organic revenue, the reduced risk usually justifies the extended schedule.

What Should Your Migration Team Look Like?

Migrations fail when they’re treated as a dev-only project. The minimum team includes:

SEO lead – owns the redirect map, benchmarking, monitoring, and recovery plan

Development lead – implements redirects, handles DNS, manages the CMS migration

Content lead – verifies content integrity, metadata migration, and internal links

PPC/paid media lead – updates ad landing pages and campaign URLs

QA – tests the staging environment against the pre-migration crawl snapshot

Project manager – coordinates timing, communication, and rollback decisions

If your technical SEO team isn’t involved from day one of migration planning, you’re already behind.

The Non-Negotiable Checklist (Summary)

Pre-migration:

[ ] 12-month organic traffic and revenue baseline exported

[ ] Full keyword ranking export with URL mapping

[ ] GSC data exported (impressions, clicks, CTR, position by page)

[ ] Backlink profile audited and exported

[ ] Full site crawl completed and saved

[ ] Complete URL redirect map built (1:1 mapping)

[ ] Redirect chains identified and flattened

[ ] Content migration verified (titles, metas, H1s, alt text, internal links)

[ ] Image URLs and alt text migration confirmed

[ ] Structured data carried over to new templates

[ ] Staging environment blocked from indexing

[ ] Hreflang annotations updated (if applicable)

[ ] PPC landing page URLs updated

[ ] Local citations and Google Business Profiles updated

[ ] High-value linking sites identified for outreach

Launch day:

[ ] Redirects tested on top-priority URLs

[ ] New XML sitemap submitted to GSC

[ ] Robots.txt verified (no staging blocks)

[ ] Canonical tags audited on live site

[ ] GA4 tracking confirmed

[ ] GSC property verified (new domain/protocol if applicable)

[ ] DNS TTL reduced pre-launch, restored post-launch

Post-migration:

[ ] Daily crawl stats and 404 monitoring (week 1)

[ ] Indexed page count compared to baseline

[ ] Organic traffic tracked daily, compared to baseline

[ ] Full site crawl at two weeks, compared to pre-migration snapshot

[ ] Redirect chain audit

[ ] Internal link integrity check

[ ] Core Web Vitals comparison

[ ] Backlink outreach to update high-value links

[ ] Six-week recovery assessment (escalate if 30%+ down)

Migrations don’t have to be traumatic. They’re traumatic when they’re treated as IT projects with SEO bolted on at the end. When SEO owns the process from planning through recovery, most sites recover within the expected window and some come out stronger. Get the preparation right, monitor relentlessly after launch, and give the recovery the time it needs.