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 AUTHORITY PRESERVATION AUDIT.
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
- 1Create a page-level evidence register before changing URLs, templates, navigation, rendering, or indexation controls
- 2Use an authenticated staging crawl to verify discoverability, canonicals, internal links, metadata, and response behavior before release
- 3Approve redirect destinations while the new information architecture is still being designed, not during the final launch rush
- 4Prepare owners, alerts, rollback criteria, and verification checks for the first 72-hour production window
- 5Measure internal-link changes separately because a working page can still lose the pathways that previously supported its prominence
- 6Assess recrawling and index updates by URL group and template rather than assuming every migrated page will move through the same sequence
- 7Require a documented staging acceptance decision that compares the replacement build with the current-site evidence
- 8Validate canonical and structured-data output by template during a CMS change without treating either item as a guaranteed ranking lever
- 9Consider a section-based release when limiting the scope of each production change is worth the added operational complexity
- 10Use the first 30 days to verify stability, isolate defects, and build a supported correction backlog where needed
1Create the Current-Site Evidence Register
Begin with one shared register that describes the current site at URL and template level. The register should be usable by SEO, development, analytics, content, and release owners, so each migration decision can be traced to evidence rather than memory.
Workstream 1: Organic landing pages. Export pages receiving search impressions or visits, then add business-critical pages that may not currently attract much traffic. Record query themes, clicks, impressions, average position, indexation state, and the intended treatment of each URL.
Workstream 2: External-link destinations. Record referring pages and domains against the exact URLs they reference. When a linked URL changes, document a 1:1 destination unless an approved consolidation provides a more relevant replacement.
Workstream 3: Internal discovery. Crawl navigation, breadcrumbs, contextual links, pagination, category modules, and related-content systems. Save inbound-link counts, source URLs, anchor context, and the templates responsible for generating those paths.
Workstream 4: Template signals. Inventory canonicals, robots directives, titles, primary headings, structured-data types, and other repeatable outputs by page template. The purpose is comparison and defect detection, not an assumption that any single element guarantees visibility.
Workstream 5: Performance and measurement. Save available Core Web Vitals data, analytics behavior, conversion events, and page-type performance so production changes can be separated from tracking failures.
The previously published planning allowance of 2-3 working days may suit a medium-sized site, but the actual effort should be set from URL volume, template variety, data access, and the number of systems changing.
2Turn Staging Review Into a Release Decision
The AUTHORITY PRESERVATION AUDIT (APA) is a structured review of your new site conducted against your SIGNAL STACK before the site goes live. Think of it as a quality gate - a set of criteria your new build must pass before you authorise the go-live.
The APA has four components:
Component 1: Redirect Map Completeness Check. Every URL in your SIGNAL STACK's URL Authority Map must have a corresponding 301 redirect mapped to the most logically equivalent page on the new site. If a URL is being consolidated, the redirect should point to the parent category or the closest topical equivalent - not the homepage. Homepage-default redirects are a signal of a lazy migration and Google treats them as soft 404s over time.
Component 2: Content Parity Verification. For your top 20 organic landing pages, do a side-by-side content comparison between the old and new versions. Check word count, heading structure, internal link count, structured data presence, and primary keyword usage. Any significant reduction in content depth on a high-traffic page is a ranking risk before you've even launched.
Component 3: Canonical and Indexation Audit. Crawl your staging environment and verify that: canonical tags point to the correct final URLs (not staging URLs), the robots.txt on staging blocks indexation (to prevent accidental indexation), and no noindex meta tags are accidentally applied to pages that should be indexed.
Component 4: Internal Link Destination Verification. Using your internal link architecture diagram from the SIGNAL STACK, spot-check that the pages receiving the most internal links in your new build still receive a comparable volume of internal links.
A CMS migration that restructures navigation menus can quietly eliminate hundreds of internal links overnight - this is one of the most underdiagnosed causes of post-migration ranking deterioration.
The APA should be completed and signed off by your SEO lead at least one week before the planned launch date. If it cannot be completed in time, the launch should be delayed. No exceptions. A one-week delay costs nothing compared to six months of traffic recovery.
4Approve URL Destinations Before Development Is Finished
Redirect planning belongs inside information-architecture work because the treatment of every existing URL affects content scope, navigation, user continuity, and the handling of external references. Leaving those decisions until deployment compresses review into the period when mistakes are hardest to unwind.
Decision 1: Classify the current inventory. Mark each URL as Preserve, Redirect, Consolidate, or Retire, then record the approved destination and the reason for the treatment.
Decision 2: Challenge avoidable changes. A stable and useful address may be worth retaining when changing it produces no clear user or technical benefit. Poor structures can still be replaced, but the benefit should be explicit.
Decision 3: Validate the map against the release candidate. Confirm that destinations exist, loops are impossible, patterns do not conflict, parameters are handled intentionally, and avoidable chains are collapsed.
Decision 4: Test production implementation. Bulk-check the live rules, final destinations, host variants, case behavior, protocols, and trailing slashes. Investigate any 302 response where the approved treatment calls for a 301 permanent move.
5Control the First 72 Hours With a Written Release Runbook
Use the selected 72-hour production window as an operational runbook with named owners, escalation routes, evidence requirements, and agreed rollback triggers. The purpose is rapid verification, not a claim that every migration problem appears during this period.
Hour 0: Confirm production access. Verify DNS or routing, TLS, page rendering, forms, robots behavior, authentication state, and the ability to reach critical templates from more than one device or network.
Hour 1: Verify redirects. Test 20-30 high-priority cases across organic landing pages, externally linked URLs, folders, host variants, and parameter patterns. Each approved permanent move should return 301 and finish on the intended destination.
Hour 2: Complete applicable search-platform actions. For a qualifying domain move, use the relevant Search Console process after ownership and production access are confirmed. Submit the current XML sitemap and inspect five priority pages for accessibility and declared canonicals.
Hour 4: Validate measurement. Confirm analytics collection, consent behavior, lead or commerce events, and channel attribution. Do not diagnose a search decline until the team has ruled out tracking failure.
Day 1: Crawl the priority inventory in production. Intended pages should return 200. Escalate unexpected 4xx responses, blocked resources, accidental noindex directives, or incorrect canonicals while rapid repair or rollback remains practical.
Days 2-3: Compare visibility by page and template. Focus on missing landing pages, broad section changes, and loss of recorded search presence rather than isolated query movement.
Day 7: Review indexing evidence. Inspect Search Console page indexing, sitemaps, and representative URLs for unexpected exclusions or errors. The source draft used a 2-4 week transition range for old-URL reporting; treat it as an operating reference that varies by site, not a guaranteed schedule.
6Rebuild Internal Discovery Intentionally
Internal links require their own migration workstream because a new site can preserve pages and redirects while changing how those pages are discovered and prioritized within the architecture. Menus, breadcrumbs, category templates, related-content blocks, pagination, and contextual links should be compared as systems rather than checked one link at a time.
Stage 1: Identify priority destinations. Use the current crawl to list the 10-20 pages with the strongest inbound internal-link support, then add pages that are important to users or the business even when they are not current hubs.
Stage 2: Record the support pattern. Save source pages, anchor context, placement, navigation references, breadcrumb routes, and the modules that create repeated links.
Stage 3: Compare the release candidate. Review inbound-link counts, source diversity, and placement for each equivalent page. A reduction can be intentional, but it needs an explanation and a plan when an important pathway disappears.
Stage 4: Test generated systems. Confirm that breadcrumbs, related items, categories, filters, pagination, and other CMS-driven modules create direct links to the approved final URLs without duplicating or orphaning content.
7Use the First 30 Days to Separate Reprocessing From Defects
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 needs to be active before you hit publish to determine 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.
8Select a Full or Section-Based Release From Operational Risk
A full cutover shortens the period in which old and new systems coexist, but every production defect can affect the whole site at once. A section-based release adds coordination, mixed-state testing, and temporary complexity while reducing the number of pages exposed in each change. Neither method replaces baseline evidence, staging approval, or rollback planning.
A full cutover may be suitable when: - The site is under 500 URLs - The move does not combine extensive domain, URL, template, and CMS changes - The team has tested the release process and rollback path - The current-site register and staging acceptance record are complete - The agreed rollback can be executed within two hours when its trigger is met
A section-based release may be preferable when: - The site contains more than 1,000 URLs - Several major technical systems are changing together - Sections use materially different templates or rendering paths - Broad disruption would be difficult for the organization to absorb - The team needs production evidence before releasing the highest-value sections
Start with a lower-risk section that still exercises the same code, templates, redirects, canonicals, internal-link modules, analytics, and deployment path expected later. Move supporting and informational sections only after the earlier release meets its acceptance criteria, then release the most important commercial areas.
The value of staging is a smaller decision boundary, not a promised performance result. Findings from stage one should change the configuration or checklist before stage three reaches the same systems.
9What Most Guides Get Wrong
The main weakness in many migration checklists is not the absence of familiar tasks. It is the absence of relationships between them. A redirect may be technically valid but topically poor. A page may return successfully while its canonical, main content, internal-link support, or analytics implementation has changed. A sitemap may list a URL that navigation and templates no longer expose.
Treat the project as preparation, controlled release, and verification. Preparation defines what should remain equivalent and what may change. The release phase tests the approved production behavior.
Verification compares observed results with the saved evidence. Keeping those phases distinct makes later changes easier to trace and prevents a technically functioning deployment from being mistaken for a completed migration.
10Why Correct Status Codes Are Not Enough
A previously published internal account described a migration where redirects, sitemap submission, and basic crawl checks appeared correct, while organic traffic remained lower for almost three months.
The later investigation found that a breadcrumb implementation had removed hundreds of links from informational pages to commercially important category pages.
The account is anecdotal and should not be treated as a benchmark. Its practical value is the diagnostic lesson: technical availability can remain intact while the site-wide structure changes. A migration review therefore needs the former internal-link graph, the destinations that depended on it, and a comparison of equivalent paths in staging and production.
A module that renders successfully can still alter destination coverage, anchor context, or the pages receiving repeated support.
11A 30-Day SEO Migration Work Plan
Planning days 1-3
Assemble the current-site evidence register for organic URLs, external-link destinations, internal discovery, template outputs, performance, and analytics
Outcome: One controlled baseline showing what should be preserved, what may change, who owns each decision, and which evidence will be compared after release
Mapping days 4-7
Classify existing URLs, approve relevant destinations, reconcile the redirect register with content and architecture decisions, and remove unexplained gaps
Outcome: A production-ready redirect specification with documented preservation, consolidation, retirement, ownership, and validation decisions
Testing days 8-14
Use authenticated desktop and mobile crawls to reconcile intended URLs, 4xx responses, canonical targets, rendered links, metadata, and orphan status against the baseline
Outcome: A prioritized release-candidate defect register with blocking items repaired or formally preventing approval
Approval days 15-17
Complete the staging acceptance review, including side-by-side checks for the top 20 pages, template controls, redirect coverage, and internal prominence
Outcome: A documented go-live decision with named approvers, evidence for every criterion, and explicit treatment of unresolved exceptions
Release day 18
Deploy the approved build, confirm critical journeys and redirect behavior, refresh search-platform inputs, prove analytics collection, and capture the first production crawl
Outcome: A measurable production release with verified priority journeys, current search-platform inputs, accountable owners, and usable rollback evidence
Launch days 19-21
Execute the 72-hour runbook across accessibility, redirects, crawl errors, canonicals, analytics, landing pages, indexation evidence, and priority queries
Outcome: Rapid identification and correction of production defects before the same issue affects additional templates or release stages
Verification days 22-30
Review scheduled evidence by URL group, investigate deviations from the baseline, and assign fixes to the responsible redirect, template, content, rendering, tracking, or internal-link owner
Outcome: A defensible closeout decision or an evidence-ranked correction queue with accountable owners and affected URL groups