Most platform migrations we get called in to triage have the same shape: traffic was healthy pre-launch, traffic dropped 30 to 80 percent at launch, and the team is now in the painful phase of asking what went wrong. The pattern is consistent enough that we've turned the prevention work into a defined seven-stage methodology — one we run from the moment a client is considering a replatform, not from the moment the new site goes live.
The methodology's organizing principle is canonical preservation: every URL, every redirect, every schema entity, every internal link, and every external signal that pointed at the old site must have a defined, lossless mapping to the new site by launch day. Where canonical preservation fails, traffic drops. Where it holds, the launch can be near-invisible from a search-traffic perspective.
Here are the seven stages, what each protects, and where the failure modes typically hide.
Stage 1: Pre-migration audit
Before any platform decision is final, we run a complete pre-migration audit of the existing site. The audit covers:
URL inventory. Every indexed URL, with current traffic, current ranking, current internal link weight, and current external link inbound count. This is the "what we have to preserve" inventory.
Schema inventory. Every structured data type currently emitted, with the page templates that emit each.
Content inventory. Every meaningful page of content, with its content depth, last-updated date, and any unique data the page surfaces (case studies, datasheets, FAQ blocks, etc.).
External signal inventory. Backlink profile, citations, social profiles, knowledge-graph relationships — anything that points at the existing site.
The inventory is the source of truth for the rest of the methodology. Stages 2 through 7 each refer back to it.
Stage 2: Platform choice and architecture alignment
The new platform is not just a vehicle for the migration — it's an architectural decision that shapes what's preservable. The questions we walk through at this stage:
Does the new platform support the URL structures we need? Some platforms (Shopify in particular) impose URL patterns that may not match the old structure. Where they can't, we plan the redirect map up front.
Does the new platform support the schema we need? Some platforms generate schema automatically (with varying quality); some require custom work. We don't accept "schema later" as a launch plan.
Does the new platform support the internal linking structure we need? Faceted nav, breadcrumbs, related products, content-to-product cross-links — all of these need to be designed before launch, not improvised after.
This is also the stage where the BigCommerce vs Shopify for B2B kind of comparison conversation happens. The platform decision changes what's possible later.
Stage 3: URL mapping and redirect strategy
This is the load-bearing stage of any migration. Every URL in the pre-migration inventory must have a defined target on the new site. The targets fall into one of three categories:
Preserved URLs — the same path on the new site, no redirect needed.
Mapped URLs — a different path on the new site, requires a 301 redirect.
Retired URLs — the page is going away. The redirect targets the closest semantic equivalent (a category page, a parent page, or the homepage as a last resort). Avoid mass-redirecting everything to the homepage; that's a soft-404 trigger.
For each mapped URL, the redirect type matters: 301 (permanent) for canonical handoff, not 302 (temporary). The redirect must be a single hop — no redirect chains that pass through two or three intermediate URLs before reaching the destination.
The redirect map is finalized before the new platform is built, not after. Building the new site without a clear redirect map invites the failure mode where the new URLs don't have semantic equivalents to the old.
Stage 4: Schema, content, and metadata parity
Every page that's preserved or mapped must carry its schema, content, and metadata forward. The parity checklist per page:
Title tag — preserved or improved, never silently stripped.
Meta description — preserved or improved.
H1 — preserved unless there's an editorial reason to change.
Body content — preserved at least to the depth it had pre-migration. Migrations are often paired with content rewrites; if so, the rewrite must not strip the content thinner.
Schema — all structured data preserved or upgraded. A migration is the moment to upgrade schema, not to lose it.
Internal links — every inbound internal link from elsewhere on the site updated to the new URL.
The mistake to avoid: trusting that "the CMS will handle it." Most migrations involve at least one CMS-side translation step where content is normalized or transformed, and the transformation often silently drops fields the SEO team needed preserved.
Stage 5: Pre-launch staging audit
Before launch, the staging environment is audited the same way the production site will be audited post-launch. The audit covers:
Crawling the staging site to confirm every preserved/mapped page loads correctly with its expected content, title, meta, H1, and schema.
Spot-checking the redirect map by hitting a sample of old URLs and confirming they 301 to the right new URLs.
Validating schema with the Rich Results Test and the Schema.org validator.
Checking robots.txt, XML sitemaps, and canonical tags for the new site — and confirming the staging robots.txt won't accidentally be promoted to production.
Confirming that AI engine user-agents (ChatGPT-User, PerplexityBot, ClaudeBot, GoogleOther) are allowed in the new robots.txt.
Running a Core Web Vitals pass on representative templates.
The staging audit is the last chance to catch a structural problem cheaply. Catching it post-launch is several times more expensive.
Stage 6: Launch execution
Launch day has its own discipline. The execution checklist:
DNS cutover at a planned, low-traffic window (typically overnight in the brand's primary market).
301 redirect map activated at the cutover moment — not "shortly after" or "by end of day."
Submit the new sitemap to Google Search Console and Bing Webmaster Tools immediately at launch.
Verify the redirect map by hitting a sample of old URLs and confirming the 301s are firing.
Monitor Search Console for indexing errors hourly for the first 24 hours, daily for the first week.
Monitor Core Web Vitals on real-user metrics, not just lab data.
Monitor analytics for any unexpected traffic shape changes — sharp drops on specific page types often indicate a redirect or content gap missed by the staging audit.
Launch day is not the moment for new feature work. Launch day is the moment for verification of work already done.
Stage 7: Post-launch validation and recovery
The first 30 to 90 days post-launch are where the migration is either confirmed successful or where the recovery work happens. The post-launch validation pass covers:
Indexing convergence. Google's index transitions from old URLs to new URLs over several weeks. Monitor the shift; flag any URLs that aren't transitioning.
Ranking continuity. For tracked keywords, the new URLs should hold ranking. Any rankings that don't transition are flagged for investigation — usually a content parity issue or an internal-linking issue.
Traffic shape. Compare day-of-week and hour-of-day traffic patterns pre- and post-launch. Differences often indicate either a redirect gap or an unintended page-type change.
Citation share for AI engines. AI engines have their own indexing cadence. Citation share typically dips for two to four weeks post-launch, then recovers — if the content and schema parity were preserved. If it doesn't recover, there's a structural issue to address.
The full methodology, with the per-stage artifacts and the platform-specific patterns, is on migration SEO methodology.
Where canonical preservation most often fails
In the migrations we triage after the fact, the failure modes cluster:
Redirect map gaps — URLs that existed pre-migration and have no redirect target on the new site, returning 404s or being redirected en masse to the homepage.
Content depth loss — the new platform's CMS truncated long-form content during import, or the rewrite paired with the migration thinned the content unintentionally.
Schema regression — the new platform's schema generation is shallower than the old site's, dropping properties that engines were using.
Internal link breakage — internal links updated only at the navigation level, leaving in-body links pointing to old URLs.
Robots.txt accident — the staging robots.txt (typically
Disallow: /) accidentally promoted to production at launch.AI user-agent blocking — the new robots.txt blocks AI engine crawlers that the old site allowed, causing AI citation rate to drop quietly.
Canonical tag conflicts — the new platform emits canonical tags that point to URLs different from the actual URLs, fragmenting the index.
Each of these is preventable in the methodology above. Each is expensive to fix after the fact.
When the methodology pays off most
Migrations vary in scope. A flat HTML site to WordPress is a different project than a Magento 1 site to BigCommerce or a custom platform to Shopify Plus. The seven-stage methodology runs the same in all of them, but the relative weight of each stage shifts. For high-content sites with deep editorial archives, content parity (stage 4) is the dominant risk. For high-SKU catalogs, URL mapping (stage 3) is the dominant risk. For sites with rich structured data, schema parity is the dominant risk.
For teams planning a migration, the right time to engage the SEO methodology is at platform selection — stage 2 — not at staging. The decisions made at platform selection shape what's possible at every later stage.
The cornerstone view is on migration SEO methodology. The audit-side framing — when a migration didn't go well and the diagnostic work is the priority — is on SEO audit services.
If you have a migration in flight or in the planning stages and want a methodology-led second opinion, we'd like to hear from you.
Frequently Asked Questions
What is the main topic of this article?
This article covers the core concepts, practical tips, and best practices related to the subject matter discussed throughout the post, giving you a comprehensive understanding from start to finish.
Who is this content intended for?
This content is intended for beginners and intermediate readers who want to deepen their knowledge, as well as experienced practitioners looking for a helpful reference or refresher.
How can I apply what I have learned here?
You can apply the information by following the step-by-step guidance provided in the sections above. Start with the fundamentals, practice consistently, and refer back to key points as needed.
Are there any prerequisites I should know before reading?
No formal prerequisites are required. A basic familiarity with the general subject area is helpful, but the article is written to be accessible to a wide range of readers regardless of experience level.
Where can I learn more about this topic?
To explore further, consider consulting reputable industry resources, official documentation, and authoritative guides. Expanding your reading across multiple trusted sources will give you a well-rounded perspective.
How often is this information updated?
This post is reviewed and updated regularly to reflect the latest developments, best practices, and changes in the field, ensuring the information you read remains accurate and relevant.
Your 7-Stage Canonical Preservation Checklist for SEO Migrations
Use the following checklist to track completion of every critical step across the seven stages of your migration. Each item maps directly to a specific protection objective — a missed checkbox here corresponds to a documented failure mode that triggers post-launch traffic loss.
Stage 1: Pre-Migration Audit
- Complete URL inventory compiled, including traffic, rankings, internal link weight, and external inbound link counts for every indexed URL
- Schema inventory documented, with structured data types mapped to the page templates that emit them
- Content inventory completed, noting content depth, last-updated dates, and any unique data assets such as case studies, datasheets, or FAQ blocks
- External signal inventory finalized, covering backlink profile, citations, social profiles, and knowledge-graph relationships
- Inventory confirmed as the shared source of truth for all subsequent stages
Stage 2: Platform Choice and Architecture Alignment
- New platform evaluated for URL structure compatibility against the existing URL inventory
- Platform-imposed URL constraints identified (such as Shopify path patterns) and redirect map drafted to compensate where structures cannot match
- Schema support on the new platform confirmed, with custom implementation planned before launch where automated output is insufficient or absent
- "Schema later" explicitly removed as an acceptable launch condition
Stage 3: Redirect Map Construction
- One-to-one redirect mapping created for every URL in the pre-migration inventory carrying meaningful traffic, ranking, or inbound link equity
- Redirect chains identified and collapsed to single-hop 301 redirects wherever possible
- High-value URLs confirmed to redirect to the closest topically equivalent destination rather than the homepage
- Redirect map reviewed against the external signal inventory to verify every backlink target is covered
Stage 4: Internal Link Preservation
- All internal links on the new site audited to point to new destination URLs, not to redirect-chain intermediaries
- Navigation, footer links, sidebar links, and in-content links each reviewed separately as distinct link surfaces
- Crawl performed on staging environment to surface any broken internal links before launch
Stage 5: Schema and Structured Data Parity
- Every structured data type from the Stage 1 schema inventory verified to be present and valid on the new platform
- Rich result test run on representative new-platform page templates for each schema type
- No schema type present pre-migration is absent at launch without a documented, deliberate decision
Stage 6: Pre-Launch Technical Validation
- Staging crawl completed using a production-equivalent crawl configuration
- Canonical tags verified to point to the correct new URLs, with no self-referencing canonicals pointing back to old-platform domains
- Robots.txt and meta robots directives confirmed to allow indexing of all intended pages on the new platform
- XML sitemap generated, validated, and confirmed to include all high-priority destination URLs
- Page speed and Core Web Vitals benchmarked on staging and compared to pre-migration baselines
Stage 7: Launch-Day and Post-Launch Monitoring
- Google Search Console property configured and verified for the new domain or path structure before launch
- Updated XML sitemap submitted to Search Console immediately at launch
- Crawl monitoring scheduled for the first 24 hours post-launch to catch any redirect failures or indexing blocks introduced during cutover
- Traffic, impressions, and ranking data monitored daily for a minimum of four weeks against pre-migration baselines
- Any URL returning a non-200 or non-301 status code that was mapped in the redirect inventory flagged and resolved within 24 hours of detection
Running this checklist in sequence — beginning at Stage 1 before the platform decision is finalized, not after the build is complete — is what separates a migration that is near-invisible to search traffic from one that produces the 30 to 80 percent post-launch drops described in the triage cases that motivated this methodology.