Here is the uncomfortable truth the typical website migration checklist won't say out loud: most migration traffic losses are self-inflicted, and they happen because teams treat migrations as a technical deployment problem rather than an authority transfer problem. The standard advice — set up 301 redirects, update your sitemap, submit to Search Console — is correct in the same way that wearing a seatbelt is correct. It's the baseline, not the strategy.
When I started working through complex site migrations for founders and operators who had built years of organic authority, I noticed a pattern. The sites that recovered fastest weren't the ones with the most technically perfect redirects. They were the sites whose teams had understood, documented, and deliberately preserved every signal Google was using to evaluate their authority before a single URL changed.
That shift in framing — from technical deployment to authority transfer — is what this guide is built on. You will get the complete pre-, during-, and post-migration checklist here. But more importantly, you will get two frameworks we developed specifically to make migrations recoverable when things go sideways: the SIGNAL STACK and the The AUTHORITY PRESERVATION AUDIT is a named pre-migration phase.
These are not academic concepts. They are the actual tools we use when a site's organic revenue is on the line. If your migration is months away, use this guide to build your plan.
If it's weeks away, use it as a diagnostic. If it's happening now — read the monitoring and triage sections first.
When I started working through complex site migrations for founders and operators who had built years of organic authority, I noticed a pattern. The sites that recovered fastest weren't the ones with the most technically perfect redirects. They were the sites whose teams had understood, documented, and deliberately preserved every signal Google was using to evaluate their authority before a single URL changed.
That shift in framing — from technical deployment to authority transfer — is what this guide is built on. You will get the complete pre-, during-, and post-migration checklist here. But more importantly, you will get two frameworks we developed specifically to make migrations recoverable when things go sideways: the SIGNAL STACK and the The AUTHORITY PRESERVATION AUDIT is a named pre-migration phase.
These are not academic concepts. They are the actual tools we use when a site's organic revenue is on the line. If your migration is months away, use this guide to build your plan.
If it's weeks away, use it as a diagnostic. If it's happening now — read the monitoring and triage sections first.
Key Takeaways
- 1Use the SIGNAL STACK framework to pre-capture authority signals before you touch a single URL
- 2The crawl-shadow technique lets you test your new site's SEO health without going live prematurely
- 3Redirect mapping is not a post-migration task — building it before launch is the single highest-leverage action you can take
- 4Most traffic loss happens in the 72-hour window after go-live — your monitoring setup needs to be active before you hit publish
- 5Internal links are often the invisible casualty of migrations — they deserve their own audit phase
- 6Google's re-crawl timeline after a migration is not linear, and treating it linearly is why most sites see prolonged ranking dips
- 7The AUTHORITY PRESERVATION AUDIT is a named pre-migration phase that most checklists skip entirely
- 8Structured data and canonical tags are the two most commonly corrupted elements during a CMS switch
- 9A staged migration approach — migrating by site section — dramatically reduces risk compared to full-site cutover
- 10Post-migration, your first 30 days of monitoring is more important than the migration itself
1The SIGNAL STACK Framework: Capture Authority Before You Touch Anything
Before a single URL changes, your job is to build an exhaustive inventory of every SEO signal your current site has accumulated. We call this the SIGNAL STACK — a structured document that becomes your baseline, your migration brief, and your recovery reference all in one.
The SIGNAL STACK has five layers:
Layer 1: URL Authority Map. Export every page currently driving organic traffic using Search Console data combined with your crawl tool of choice. For each URL, record impressions, clicks, average position, and the top three queries it ranks for. This is not optional. You cannot protect what you haven't measured.
Layer 2: Backlink Profile Snapshot. Pull a full backlink export and filter to referring domains pointing to specific internal URLs — not just your homepage. These deep links are your most fragile equity assets. Any URL that has external links pointing to it must have a 1:1 redirect mapped before go-live, no exceptions.
Layer 3: Internal Link Architecture Diagram. Crawl your existing site and export the internal link structure. Note which pages receive the most Internal links are often the invisible casualty — these are your authority hubs, and your new site architecture must replicate or improve on their internal link equity.
Layer 4: Structured Data Inventory. Document every schema type deployed across your site — Article, FAQ, Product, BreadcrumbList, Organisation. During a CMS migration, structured data is the element most likely to silently disappear or corrupt. Having a complete inventory means you can audit against it post-migration.
Layer 5: Core Web Vitals Baseline. Pull your current CWV data by page type — homepage, blog posts, product pages, category pages — from Search Console's Page Experience report. Your new site must meet or exceed these baselines before you consider going live.
Building the SIGNAL STACK typically takes 2-3 working days for a medium-sized site. That time investment pays back in the recovery speed you gain when you have a complete before-and-after comparison available immediately after launch.
The SIGNAL STACK has five layers:
Layer 1: URL Authority Map. Export every page currently driving organic traffic using Search Console data combined with your crawl tool of choice. For each URL, record impressions, clicks, average position, and the top three queries it ranks for. This is not optional. You cannot protect what you haven't measured.
Layer 2: Backlink Profile Snapshot. Pull a full backlink export and filter to referring domains pointing to specific internal URLs — not just your homepage. These deep links are your most fragile equity assets. Any URL that has external links pointing to it must have a 1:1 redirect mapped before go-live, no exceptions.
Layer 3: Internal Link Architecture Diagram. Crawl your existing site and export the internal link structure. Note which pages receive the most Internal links are often the invisible casualty — these are your authority hubs, and your new site architecture must replicate or improve on their internal link equity.
Layer 4: Structured Data Inventory. Document every schema type deployed across your site — Article, FAQ, Product, BreadcrumbList, Organisation. During a CMS migration, structured data is the element most likely to silently disappear or corrupt. Having a complete inventory means you can audit against it post-migration.
Layer 5: Core Web Vitals Baseline. Pull your current CWV data by page type — homepage, blog posts, product pages, category pages — from Search Console's Page Experience report. Your new site must meet or exceed these baselines before you consider going live.
Building the SIGNAL STACK typically takes 2-3 working days for a medium-sized site. That time investment pays back in the recovery speed you gain when you have a complete before-and-after comparison available immediately after launch.
Document every URL driving organic traffic before touching the site architecture
Map all backlinks to specific internal URLs — deep links are your most at-risk equity
Crawl and export your full internal link structure as a pre-migration baseline
Inventory all structured data types by page template to prevent silent corruption
Record Core Web Vitals by page type so you have a performance benchmark for the new build
The SIGNAL STACK document becomes your migration brief and your post-launch diagnostic tool
Two to three days spent on this phase can save weeks of post-migration recovery
3The Crawl-Shadow Technique: Test SEO Health Without Going Live
The crawl-shadow technique is one of the most underused pre-migration methods available to any SEO practitioner. The concept is straightforward: you run a full technical SEO crawl against your staging environment — with authentication credentials if needed — to simulate what Googlebot would discover if the site were live today.
Most teams don't do this because they assume the staging environment isn't 'real enough' to crawl meaningfully. That assumption is wrong and it's costly. The staging environment is where you will find the problems you absolutely cannot afford to discover after go-live.
Here is how to execute the crawl-shadow technique:
Step 1: Configure your crawl tool to ignore the robots.txt on staging (since staging should be blocked to real crawlers, you need to override this for your test crawl). Most enterprise crawl tools support this configuration.
Step 2: Set the crawl to simulate Googlebot's crawl behaviour — desktop and mobile user agents separately — since your new site may perform differently across device types.
Step 3: After the crawl completes, run the following specific checks: 4xx errors on URLs that should be live, redirect chains longer than two hops (every additional hop in a chain dilutes link equity), orphaned pages with no internal links pointing to them, pages returning the wrong canonical tag, pages with missing or duplicate title tags, and pages with missing H1 tags.
Step 4: Cross-reference your crawl output against your SIGNAL STACK. Any URL in your SIGNAL STACK's URL Authority Map that returns a 4xx in the crawl is a critical issue requiring resolution before launch.
The crawl-shadow technique typically surfaces between 15 and 40 distinct technical issues on sites that have already been through a developer review. This is not a commentary on developer quality — it's a reflection of the fact that SEO-specific technical requirements are frequently outside a developer's default checklist.
Run the crawl-shadow at least twice: once when the new build is 'feature complete' and once within 48 hours of the planned go-live date. Issues found in the second crawl that weren't present in the first indicate regressions introduced during final development work.
Most teams don't do this because they assume the staging environment isn't 'real enough' to crawl meaningfully. That assumption is wrong and it's costly. The staging environment is where you will find the problems you absolutely cannot afford to discover after go-live.
Here is how to execute the crawl-shadow technique:
Step 1: Configure your crawl tool to ignore the robots.txt on staging (since staging should be blocked to real crawlers, you need to override this for your test crawl). Most enterprise crawl tools support this configuration.
Step 2: Set the crawl to simulate Googlebot's crawl behaviour — desktop and mobile user agents separately — since your new site may perform differently across device types.
Step 3: After the crawl completes, run the following specific checks: 4xx errors on URLs that should be live, redirect chains longer than two hops (every additional hop in a chain dilutes link equity), orphaned pages with no internal links pointing to them, pages returning the wrong canonical tag, pages with missing or duplicate title tags, and pages with missing H1 tags.
Step 4: Cross-reference your crawl output against your SIGNAL STACK. Any URL in your SIGNAL STACK's URL Authority Map that returns a 4xx in the crawl is a critical issue requiring resolution before launch.
The crawl-shadow technique typically surfaces between 15 and 40 distinct technical issues on sites that have already been through a developer review. This is not a commentary on developer quality — it's a reflection of the fact that SEO-specific technical requirements are frequently outside a developer's default checklist.
Run the crawl-shadow at least twice: once when the new build is 'feature complete' and once within 48 hours of the planned go-live date. Issues found in the second crawl that weren't present in the first indicate regressions introduced during final development work.
Crawl your staging environment to simulate Googlebot discovery before go-live
Override robots.txt blocking in your crawl tool to access the staging site
Test both desktop and mobile Googlebot user agents separately
Flag all redirect chains longer than two hops — each hop dilutes passing link equity
Identify orphaned pages with zero internal links before they go live with no crawl pathway
Cross-reference crawl output against your SIGNAL STACK URL Authority Map for gap analysis
Run the crawl-shadow twice: at feature completion and 48 hours before go-live
4Redirect Mapping: Why This Is a Strategy, Not a Task
Most teams treat redirect mapping as a task that happens after the new site is built. In reality, redirect mapping should be a strategic output of the information architecture phase — completed before development begins, not after.
When you build your redirect map retroactively, you are making decisions about URL structure and content consolidation under time pressure, often just days before launch. Those decisions directly affect how link equity flows through your new site and which pages Google will prioritise for re-indexation. Making them under pressure produces worse outcomes.
Here is a strategic redirect mapping process that changes the order of operations:
Phase 1 — URL Audit and Classification. Using your SIGNAL STACK, classify every existing URL into one of four categories: Preserve (URL structure stays the same), Redirect (URL changes, redirect to equivalent page), Consolidate (multiple pages merging into one — all should redirect to the merged destination), or Retire (page removed with no equivalent — redirect to closest topical parent).
Phase 2 — IA-First Mapping. Before development, share your URL classification with your information architect or developer. The new site's URL structure should be designed around minimising the number of Redirect and Consolidate decisions needed. Every preserved URL is one less redirect chain to maintain.
Phase 3 — Redirect Map QA. Once your map is built, run it through a redirect validation tool to confirm all destination URLs actually exist in the new build, no circular redirects are present, and no redirect chains exceed two hops. A redirect from old URL to an intermediate URL to a final URL is acceptable. Three or more hops is not.
Phase 4 — Redirect Implementation Verification. After go-live, use a bulk redirect checker to confirm every redirect in your map is returning the correct status code. It is common for server configuration issues to cause redirects to return 302 (temporary) instead of 301 (permanent) — a mistake that significantly slows equity transfer.
When you build your redirect map retroactively, you are making decisions about URL structure and content consolidation under time pressure, often just days before launch. Those decisions directly affect how link equity flows through your new site and which pages Google will prioritise for re-indexation. Making them under pressure produces worse outcomes.
Here is a strategic redirect mapping process that changes the order of operations:
Phase 1 — URL Audit and Classification. Using your SIGNAL STACK, classify every existing URL into one of four categories: Preserve (URL structure stays the same), Redirect (URL changes, redirect to equivalent page), Consolidate (multiple pages merging into one — all should redirect to the merged destination), or Retire (page removed with no equivalent — redirect to closest topical parent).
Phase 2 — IA-First Mapping. Before development, share your URL classification with your information architect or developer. The new site's URL structure should be designed around minimising the number of Redirect and Consolidate decisions needed. Every preserved URL is one less redirect chain to maintain.
Phase 3 — Redirect Map QA. Once your map is built, run it through a redirect validation tool to confirm all destination URLs actually exist in the new build, no circular redirects are present, and no redirect chains exceed two hops. A redirect from old URL to an intermediate URL to a final URL is acceptable. Three or more hops is not.
Phase 4 — Redirect Implementation Verification. After go-live, use a bulk redirect checker to confirm every redirect in your map is returning the correct status code. It is common for server configuration issues to cause redirects to return 302 (temporary) instead of 301 (permanent) — a mistake that significantly slows equity transfer.
Build your redirect map before development begins, not as a last-minute pre-launch task
Classify all existing URLs into Preserve, Redirect, Consolidate, or Retire categories
Minimise redirect and consolidation decisions by designing the new URL structure around preserved URLs
Validate your redirect map against destination URLs to catch dead-end redirects before launch
Confirm all redirects return 301 status codes — 302s delay equity transfer significantly
Redirect chains longer than two hops are an equity dilution risk and should be collapsed
Keep your redirect map as a living document — update it whenever URLs change post-migration
5Go-Live Protocol: The 72-Hour Window That Determines Recovery Speed
The 72 hours immediately following a migration go-live is the highest-risk window in the entire process. This is when Google's crawler begins discovering your new URL structure at scale, when redirect chains are stress-tested by real traffic, and when any issues with canonicalization or indexation signals become visible.
Your go-live protocol needs to be a structured sequence, not a free-for-all.
Hour 0 — DNS and Deployment. Switch DNS, confirm SSL certificate is active on the new domain or URL structure, and verify the site is loading correctly across device types. Do not proceed until this is confirmed.
Hour 1 — Redirect Spot-Check. Manually test a sample of 20-30 redirects covering your highest-equity URLs. Confirm they return 301 status codes and land on the correct destination pages. Fix any issues immediately.
Hour 2 — Search Console Actions. If you are migrating domains (not just restructuring URLs on the same domain), use Search Console's Change of Address tool immediately. Submit your updated XML sitemap. Request indexation of your five highest-priority pages using the URL Inspection tool.
Hour 4 — Analytics Baseline. Confirm that your analytics tracking is firing correctly on the new site. A migration that breaks analytics tagging leaves you blind during the most important monitoring window. Check goal/conversion tracking specifically — this is the most commonly broken element.
Day 1 — Crawl Verification. Re-run a focused crawl against the live site targeting only your SIGNAL STACK's top URLs. Confirm they are all returning 200 status codes. Any 4xx errors on these priority pages must be escalated and fixed within hours, not days.
Day 2-3 — Ranking Monitoring. Pull rank tracking data for your priority keyword set. Some fluctuation is expected and normal. What you are watching for is complete de-indexation of previously ranking pages — this indicates an indexation configuration problem that needs immediate diagnosis.
Day 7 — Search Console Coverage Report. Check the Coverage report for any significant spikes in 'Excluded' or 'Error' status URLs. A healthy migration will show your old URLs transitioning from 'Submitted and indexed' to 'Redirect' status over the course of 2-4 weeks.
Your go-live protocol needs to be a structured sequence, not a free-for-all.
Hour 0 — DNS and Deployment. Switch DNS, confirm SSL certificate is active on the new domain or URL structure, and verify the site is loading correctly across device types. Do not proceed until this is confirmed.
Hour 1 — Redirect Spot-Check. Manually test a sample of 20-30 redirects covering your highest-equity URLs. Confirm they return 301 status codes and land on the correct destination pages. Fix any issues immediately.
Hour 2 — Search Console Actions. If you are migrating domains (not just restructuring URLs on the same domain), use Search Console's Change of Address tool immediately. Submit your updated XML sitemap. Request indexation of your five highest-priority pages using the URL Inspection tool.
Hour 4 — Analytics Baseline. Confirm that your analytics tracking is firing correctly on the new site. A migration that breaks analytics tagging leaves you blind during the most important monitoring window. Check goal/conversion tracking specifically — this is the most commonly broken element.
Day 1 — Crawl Verification. Re-run a focused crawl against the live site targeting only your SIGNAL STACK's top URLs. Confirm they are all returning 200 status codes. Any 4xx errors on these priority pages must be escalated and fixed within hours, not days.
Day 2-3 — Ranking Monitoring. Pull rank tracking data for your priority keyword set. Some fluctuation is expected and normal. What you are watching for is complete de-indexation of previously ranking pages — this indicates an indexation configuration problem that needs immediate diagnosis.
Day 7 — Search Console Coverage Report. Check the Coverage report for any significant spikes in 'Excluded' or 'Error' status URLs. A healthy migration will show your old URLs transitioning from 'Submitted and indexed' to 'Redirect' status over the course of 2-4 weeks.
Treat the 72 hours post-go-live as a structured monitoring protocol, not passive observation
Manually test 20-30 high-equity redirects within the first hour of launch
Submit the Change of Address tool in Search Console immediately for domain migrations
Verify analytics and conversion tracking is firing before assuming monitoring is operational
Run a targeted live crawl of priority URLs within 24 hours to catch critical 4xx errors early
Ranking fluctuation in the first week is expected — de-indexation of key pages is the critical signal to watch
Check Search Console Coverage report at day 7 for a clear picture of indexation transition progress
6Internal Link Recovery: The Invisible Casualty of Every Migration
If you asked ten SEO practitioners what the most commonly overlooked element of a site migration is, the majority would say redirect mapping or structured data. In our experience, the correct answer is internal link architecture — and specifically, the way migrations quietly destroy carefully built internal link equity without anyone noticing until rankings deteriorate weeks later.
Here is how it typically happens: a CMS migration restructures the navigation menu. The old site had a rich mega-menu with contextual internal links throughout. The new site has a simplified navigation. Nobody explicitly removed any redirects. But the new site now has significantly fewer internal links pointing to the pages that previously received the most equity — and Google's understanding of those pages' importance within the site's topical architecture changes accordingly.
Your internal link recovery process should happen in parallel with redirect mapping, not after it.
Step 1 — Identify Authority Hubs. Using the internal link data from your SIGNAL STACK crawl, identify the 10-20 pages that receive the highest volume of internal links on your current site. These are your authority hubs — the pages Google has been repeatedly told, via your own site's link signals, are your most important content.
Step 2 — Map Hub Preservation. For each authority hub, document: how many internal links it receives, which pages link to it, and what anchor text those links use. This map becomes your blueprint for replicating the internal link structure on the new site.
Step 3 — New Site Internal Link Audit. After your crawl-shadow, pull the internal link data for your authority hub equivalents on the new site. Any hub that receives meaningfully fewer internal links in the new build needs to be addressed — either by adding contextual links from content pages or by updating navigation elements.
Step 4 — Programmatic Link Health. If your site uses programmatic internal linking (related posts, breadcrumbs, category navigation), confirm these are functioning correctly on the new site and generating the expected internal link volumes. These are the most commonly broken internal link systems during CMS migrations.
Here is how it typically happens: a CMS migration restructures the navigation menu. The old site had a rich mega-menu with contextual internal links throughout. The new site has a simplified navigation. Nobody explicitly removed any redirects. But the new site now has significantly fewer internal links pointing to the pages that previously received the most equity — and Google's understanding of those pages' importance within the site's topical architecture changes accordingly.
Your internal link recovery process should happen in parallel with redirect mapping, not after it.
Step 1 — Identify Authority Hubs. Using the internal link data from your SIGNAL STACK crawl, identify the 10-20 pages that receive the highest volume of internal links on your current site. These are your authority hubs — the pages Google has been repeatedly told, via your own site's link signals, are your most important content.
Step 2 — Map Hub Preservation. For each authority hub, document: how many internal links it receives, which pages link to it, and what anchor text those links use. This map becomes your blueprint for replicating the internal link structure on the new site.
Step 3 — New Site Internal Link Audit. After your crawl-shadow, pull the internal link data for your authority hub equivalents on the new site. Any hub that receives meaningfully fewer internal links in the new build needs to be addressed — either by adding contextual links from content pages or by updating navigation elements.
Step 4 — Programmatic Link Health. If your site uses programmatic internal linking (related posts, breadcrumbs, category navigation), confirm these are functioning correctly on the new site and generating the expected internal link volumes. These are the most commonly broken internal link systems during CMS migrations.
Internal link architecture is the most commonly overlooked migration casualty — and one of the most damaging
Identify your 10-20 authority hub pages using pre-migration crawl data before the new site launches
Document the anchor text patterns of your highest-traffic internal links — these are SEO signals, not just navigation
Compare internal link volumes in your crawl-shadow output against your pre-migration baseline
Programmatic internal link systems — related posts, breadcrumbs — must be verified as functional on the new CMS
Navigation simplification is a legitimate UX goal but it must be offset by richer contextual linking in content
Any authority hub receiving significantly fewer internal links on the new site is a ranking risk before launch
7Post-Migration Monitoring: Your First 30 Days Are More Important Than the Migration Itself
The migration isn't complete when the site goes live. It is complete when your organic traffic and ranking positions have stabilised at or above pre-migration levels. Until that point, you are in active recovery mode — and your monitoring setup determines how quickly you can detect, diagnose, and resolve issues.
Here is the monitoring stack that matters in the first 30 days:
Rank Tracking — Daily. Track your top 50 target keywords daily for the first two weeks, then move to weekly once stability is confirmed. Look for patterns rather than individual fluctuations — if a cluster of pages on the same template all drop simultaneously, that's a template-level technical issue. If a single page drops, it's a page-level issue.
Search Console Coverage — Weekly. Check the Coverage report every week for the first month. Watch specifically for any growth in the 'Excluded: Duplicate without user-selected canonical' category — this indicates canonicalization problems on your new site that are causing Google to make its own canonical decisions.
Organic Traffic — Daily for Landing Pages. Pull a landing page report from your analytics platform filtered to organic traffic only. Compare week-over-week for your top 20 pages. A page that was receiving consistent organic traffic before migration and receives none after is either de-indexed, has a broken redirect, or has a serious technical issue.
Core Web Vitals — Weekly. The new site's CWV performance should be checked weekly during the first month. New deployments often include performance regressions introduced after the initial build — particularly if marketing tags, chat widgets, or image formats were added during QA.
Backlink Monitoring — Bi-Weekly. Check if any referring domains are updating their links to point to your new URLs. This is a positive signal when it happens organically. More importantly, monitor for any referring domains that are now pointing to broken URLs — contact those webmasters to request a link update.
The 30-day monitoring period also tells you whether a staged recovery plan is needed. If traffic is tracking at or above pre-migration levels by day 30, your migration was a success. If it's materially below baseline, use your SIGNAL STACK as the diagnostic starting point — the gap between what the signals were before migration and what they are now will tell you precisely where to focus recovery efforts.
Here is the monitoring stack that matters in the first 30 days:
Rank Tracking — Daily. Track your top 50 target keywords daily for the first two weeks, then move to weekly once stability is confirmed. Look for patterns rather than individual fluctuations — if a cluster of pages on the same template all drop simultaneously, that's a template-level technical issue. If a single page drops, it's a page-level issue.
Search Console Coverage — Weekly. Check the Coverage report every week for the first month. Watch specifically for any growth in the 'Excluded: Duplicate without user-selected canonical' category — this indicates canonicalization problems on your new site that are causing Google to make its own canonical decisions.
Organic Traffic — Daily for Landing Pages. Pull a landing page report from your analytics platform filtered to organic traffic only. Compare week-over-week for your top 20 pages. A page that was receiving consistent organic traffic before migration and receives none after is either de-indexed, has a broken redirect, or has a serious technical issue.
Core Web Vitals — Weekly. The new site's CWV performance should be checked weekly during the first month. New deployments often include performance regressions introduced after the initial build — particularly if marketing tags, chat widgets, or image formats were added during QA.
Backlink Monitoring — Bi-Weekly. Check if any referring domains are updating their links to point to your new URLs. This is a positive signal when it happens organically. More importantly, monitor for any referring domains that are now pointing to broken URLs — contact those webmasters to request a link update.
The 30-day monitoring period also tells you whether a staged recovery plan is needed. If traffic is tracking at or above pre-migration levels by day 30, your migration was a success. If it's materially below baseline, use your SIGNAL STACK as the diagnostic starting point — the gap between what the signals were before migration and what they are now will tell you precisely where to focus recovery efforts.
Run daily rank tracking for the first two weeks post-migration across your priority keyword set
Check Search Console Coverage weekly — growth in Duplicate or Excluded categories indicates technical issues
Monitor organic landing page traffic daily and investigate any page with zero post-migration organic traffic
Core Web Vitals can regress after launch due to added third-party scripts — monitor weekly
Track referring domains pointing to broken URLs and contact webmasters to request link corrections
Use your SIGNAL STACK as the diagnostic framework if traffic doesn't recover by day 30
Distinguish between individual page drops and template-wide drops — the cause and fix are completely different
8Should You Migrate All at Once or in Stages? The Decision Framework
The conventional advice on migration approach is to do everything at once — a single cutover on a planned date. This approach minimises the period of dual-site complexity and is logistically simpler. It is also the approach most likely to produce a significant, site-wide traffic event if something goes wrong.
A staged migration — migrating by site section over a planned schedule — is more complex to manage but dramatically lowers your risk profile. Here is a decision framework for choosing the right approach for your specific situation.
Choose a Full Cutover When: - Your site is under 500 URLs - You are migrating domains without significant URL restructuring - Your development team has executed multiple successful migrations before - Your SIGNAL STACK and APA are fully complete before the migration date - You have a clear rollback plan that can be executed within two hours if a critical issue is discovered
Choose a Staged Migration When: - Your site has more than 1,000 URLs - You are simultaneously changing domain, URL structure, and CMS - Your site has multiple distinct content sections with different technical templates - Your organic traffic is a significant revenue driver where a multi-week drop would cause material business impact - Your development team has limited migration experience
For a staged migration, the recommended sequence is: migrate your lowest-traffic sections first (this is your live testing ground), then migrate supporting pages (About, Contact, legal pages), then migrate blog and content pages, and finally migrate your highest-traffic commercial pages last — only after you have confirmed the earlier stages are stable.
The staged approach gives you live data on how your redirect configuration, canonical setup, and CMS templates perform under real Googlebot crawling before you risk your highest-value pages. Issues discovered in stage one are resolved before stage three. This is the most risk-aware approach available for complex migrations.
A staged migration — migrating by site section over a planned schedule — is more complex to manage but dramatically lowers your risk profile. Here is a decision framework for choosing the right approach for your specific situation.
Choose a Full Cutover When: - Your site is under 500 URLs - You are migrating domains without significant URL restructuring - Your development team has executed multiple successful migrations before - Your SIGNAL STACK and APA are fully complete before the migration date - You have a clear rollback plan that can be executed within two hours if a critical issue is discovered
Choose a Staged Migration When: - Your site has more than 1,000 URLs - You are simultaneously changing domain, URL structure, and CMS - Your site has multiple distinct content sections with different technical templates - Your organic traffic is a significant revenue driver where a multi-week drop would cause material business impact - Your development team has limited migration experience
For a staged migration, the recommended sequence is: migrate your lowest-traffic sections first (this is your live testing ground), then migrate supporting pages (About, Contact, legal pages), then migrate blog and content pages, and finally migrate your highest-traffic commercial pages last — only after you have confirmed the earlier stages are stable.
The staged approach gives you live data on how your redirect configuration, canonical setup, and CMS templates perform under real Googlebot crawling before you risk your highest-value pages. Issues discovered in stage one are resolved before stage three. This is the most risk-aware approach available for complex migrations.
Full cutover is appropriate for smaller sites with experienced teams and complete pre-migration documentation
Staged migrations are strongly recommended for sites over 1,000 URLs or those combining multiple changes simultaneously
Migrate lowest-traffic sections first to gather real-world signal data before risking high-value pages
A staged approach lets you identify and fix template-level issues before they affect your commercial pages
Both approaches require the full SIGNAL STACK and APA — staging doesn't replace preparation
Define your rollback criteria in advance: what specific signal triggers a decision to pause the migration
Staged migrations take longer but produce measurably better outcomes for complex, high-traffic sites