An SEO site migration plan is a release-control system for preserving page identity while URLs, domains, routing, rendering, content management, or infrastructure change. Search engines process moves URL by URL, and users, crawlers, links, feeds, caches, and integrations may continue requesting old locations for a long time. The migration succeeds when every valuable old intent reaches an equivalent new destination with coherent signals and observable service behavior.
Google's current site-move guidance recommends preparing the new site, creating a URL mapping, configuring server redirects, and monitoring both old and new URLs. It also warns that crawl load can temporarily increase because crawlers request old URLs and follow them to the new host. Treat mapping, redirect configuration, canonical output, sitemaps, internal-link rewrites, capacity, validation, and rollback thresholds as versioned release artifacts, not a spreadsheet handed over on launch day.
Define migration scope, invariants, and baseline
Inventory every change dimension: scheme, hostname, path, parameter grammar, content identity, template, rendering, navigation, structured data, analytics, hosting, and business rules. When practical, change one major dimension at a time so failures remain diagnosable. A domain move combined with a CMS rewrite, content pruning, localization restructure, and design launch multiplies uncertainty. If changes must coincide, isolate them in flags and testable contracts.
Baseline old-site evidence by route and business cohort: canonical URLs, status, canonical tags, robots policy, titles and headings, primary content fingerprints, structured data, hreflang, internal inlinks, sitemap membership, backlinks where available, organic landing sessions, conversions, crawl frequency, latency, and errors. Define invariants such as preserved page purpose, product identity, language, and availability. Store a signed snapshot so post-launch comparisons use a known reference rather than memory.
| Asset | Required contents | Owner | Release assertion |
|---|---|---|---|
| URL mapping | Old URL, new URL or terminal state, reason, entity ID, confidence, exception | SEO and product owner | Every in-scope old canonical has one reviewed outcome |
| Redirect configuration | Exact and pattern rules, precedence, exclusions, status, version | Platform engineering | No loops, chains, broad traps, or environment leakage |
| New-page contract | Status, canonical, robots, content, links, structured data, locale | Web engineering | Mapped target preserves intended identity and is index-eligible |
| Discovery update | Internal links, hreflang, feeds, sitemaps, references | Content and platform teams | New URLs are direct; old URLs are absent from generated outputs |
| Observability | Cohorts, dashboards, logs, alerts, annotations | SEO and SRE | Old and new hosts remain measurable through stabilization |
| Rollback plan | Triggers, reversible components, authority, data preservation | Release manager | Rollback can restore service without creating URL oscillation |
Build a complete and versioned URL map
Generate the old inventory from logs, sitemaps, analytics, database entities, internal links, known backlinks, feeds, and historical exports. Normalize carefully while preserving raw examples. Map by stable business entity and user intent, not string similarity alone. A discontinued product may map to an exact successor, a useful parent category, or no replacement. Returning 404 or 410 is more honest than redirecting unrelated pages to the home page.
Classify mapping confidence and require review for high-value, ambiguous, many-to-one, and cross-language cases. Detect duplicate old sources converging on a target, targets receiving implausibly many unrelated intents, and targets that redirect again. Version the map in source control or an immutable data store, attach generation logic and approvals, and compile it into server configuration. Preserve manual exceptions as structured rules with owner and expiry rather than undocumented edits.
Implement direct permanent redirects and terminal states
Use server-side permanent redirects for permanent URL changes and send each old URL directly to its final destination. Avoid chains through previous migrations, protocol variants, or locale selectors. Rules should preserve only parameters that remain meaningful and discard tracking or obsolete routing parameters deliberately. Order exact exceptions before broad patterns and test encoded paths, case, trailing slash, query combinations, files, pagination, and malformed inputs.
Keep old hosts, certificates, DNS, redirect infrastructure, and verification operational long enough for users and crawlers to transition. Google recommends retaining redirects generally for at least a year, while longer retention benefits users and old links when feasible. Deleted content should return an accurate 404 or 410. Do not serve a 200 page announcing a move or rely on JavaScript redirects as the primary mechanism when HTTP redirects are available.
Align canonical, robots, links, sitemaps, and alternate signals
Every new target should return its expected status and emit a self-consistent canonical. Rewrite internal links to direct new URLs so users and crawlers do not traverse redirects. Update navigation, breadcrumbs, pagination, hreflang, structured data URLs, Open Graph metadata, API links, XML feeds, ads, email templates, and partner exports. Remove accidental noindex directives and production robots blocks inherited from staging.
Generate new-host sitemaps containing only final canonical URLs, and keep a temporary old-URL sitemap when it materially helps monitor transition under the chosen operational method. Verify old and new Search Console properties and use Change of Address for eligible domain moves. Keep analytics continuity and annotate launch. Ensure page content and purpose remain equivalent; redirects cannot compensate for blank shells, missing products, or altered localization.
Test the release in production-like conditions
Create an automated migration assertion suite from the complete map plus stratified samples. Request old URLs without cookies and verify one hop, correct permanent status, exact final target, no loops, and acceptable latency. Request targets and verify 200 or intended terminal status, canonical, robots, primary content fingerprint, heading, structured data, hreflang, navigation, and asset loading. Crawl the staged new site to find orphan routes, old-host references, and accidental parameter spaces.
Test capacity with the combined workload of direct new-host traffic and old-host requests followed through redirects. Include cache misses, bots, image and asset fetches, DNS, TLS, WAF, rendering, APIs, and log pipelines. Confirm observability before cutover. Run security checks so open-redirect patterns, host-header trust, or query reflection are not introduced by broad migration rules. Freeze mapping and route changes during the final validation window except for controlled fixes.
| Signal | Launch gate | Rollback or stop threshold | First investigation |
|---|---|---|---|
| Redirect validity | All critical and sampled URLs reach approved target in one hop | Loop, broad misroute, or material high-value mapping error | Rule precedence and map version |
| Target availability | Critical templates meet success and latency objectives | Sustained 5xx, saturation, or blank rendered content | Capacity, cache, dependency, deployment |
| Index signals | Canonical, robots, hreflang, and sitemap assertions pass | Sitewide wrong canonical or noindex | Template configuration and environment flags |
| User outcomes | Core journeys, checkout, forms, and locale routing pass | Material transaction or task failure | Application release and data mapping |
| Discovery | New links and sitemaps contain direct new URLs | Generated systems continue publishing old URLs | Source URL builder and cached outputs |
| Observability | Logs and cohorts cover both hosts | Cannot measure status, routing, or business outcomes | Telemetry configuration before further rollout |
Launch in cohorts, monitor transition, and roll back deliberately
Where architecture permits, pilot a representative lower-risk section without assuming it predicts every sitewide issue. During cutover, monitor old and new host traffic, redirect outcomes, response codes, latency, cache, crawl requests, sitemap fetches, canonical mismatches, indexing diagnostics, organic landings, and business tasks by template and cohort. Expect ranking fluctuation while systems recrawl and reprocess URLs; distinguish normal transition from technical failure using release evidence.
Rollback decisions should prioritize service and signal correctness, not short-term ranking noise. Reverting application code while keeping correct redirects may be safer than reversing the URL move. Repeatedly oscillating redirects and canonicals between old and new locations creates more ambiguity. Define which components can roll back independently, who has authority, how new data created after launch is preserved, and how the map remains consistent. Continue monitoring until old requests and critical coverage stabilize.
Run a launch command structure with named decision owners. Engineering owns transport and application health; SEO owns mapping and search-signal assertions; product owners confirm destination equivalence; analytics confirms measurement continuity; support reports user-facing anomalies; and one release manager decides pause, continue, or rollback. Use a timed decision log that records evidence and configuration versions. Predefine communication for partners that still publish old URLs and keep a queue of mapping exceptions discovered after launch, with severity and verification, rather than editing redirect rules directly during a noisy incident.
Key takeaways
- Baseline page identity, signals, traffic, and service behavior before changing URLs.
- Map every old canonical by stable entity and intent, including explicit 404 or 410 outcomes.
- Compile versioned maps into direct server redirects and update all generated references to final URLs.
- Load-test the combined old-plus-new crawl path and verify both properties remain observable.
- Rollback broken components deliberately while avoiding contradictory or oscillating URL signals.
Frequently asked questions
Should removed pages redirect to the home page?
No, unless the home page genuinely satisfies the same intent, which is rare. Redirect to a close equivalent; otherwise return an accurate 404 or 410 and remove internal references.
How long should migration redirects remain?
Google recommends keeping them generally for at least one year. Retaining them longer is often beneficial for users, old links, and slowly revisited URLs when infrastructure allows.
Conclusion
A safe migration is built, tested, and operated like a production release. Version the URL map, prove direct redirects and target equivalence, align every discovery signal, prepare capacity, and monitor old and new cohorts through stabilization. That discipline cannot eliminate normal reprocessing, but it prevents avoidable ambiguity and makes failures recoverable.