The SEO Migration Release Checklist: Redirects, Canonicals, and Rollback Gates

Treat a URL migration like a production release: map destinations, test redirects and canonicals, set launch gates, and monitor what actually changed.

A migration is a release, not a redirect spreadsheet

A site migration can look deceptively small in a ticket: change a domain, reorganize a product directory, or move documentation to a new framework. The implementation may be a few rewrite rules. The search consequences are not. Crawlers must rediscover destinations, reconcile canonical signals, and update their understanding of which URLs should appear in results. Users and external links still arrive at old addresses. Internal navigation, feeds, sitemaps, and structured data may all contain stale paths.

The mistake is treating a successful deployment as proof of a successful migration. A green build confirms that code compiled; it does not confirm that a valuable old URL still resolves to the right page. Instead, make the migration a versioned release with a mapping contract, executable tests, staged rollout, and explicit recovery criteria. This guide describes a workflow for GitHub-managed sites, but the reasoning also applies to CMS and edge-routing platforms.

Google's site-move documentation recommends preparing a URL mapping, testing the new site, applying redirects, and monitoring old and new properties. It warns that rankings may fluctuate while URLs are recrawled and reindexed. No prelaunch checklist can guarantee rankings. It can prevent many avoidable technical errors.

First, decide whether this is actually a URL migration

Separate three projects that often get bundled together. A hosting migration can preserve every public URL while changing infrastructure. A URL migration changes addresses, such as a domain, subdomain, protocol, or path. A content redesign changes page meaning, information architecture, or templates. Combining all three makes it harder to explain a later traffic change.

If public URLs remain identical, do not create a redirect map merely to make the project feel complete. Focus on response parity, rendering, metadata, robots directives, performance, and analytics continuity. If URLs change, map them. If the business also wants to redesign the site, consider staging that work separately. Google's guidance recommends changing one thing at a time and, for some large sites, moving a less volatile section first.

Write a release contract before touching production: which hostnames and paths are in scope; which URL patterns are intentionally retired; which pages must preserve search eligibility; who approves exceptions; and how long the old infrastructure must serve redirects. This prevents engineering from calling the migration complete while the content team still expects old pages to exist.

Build a source-to-destination inventory, not a list of guesses

Start with the current XML sitemap, CMS exports, internal crawl, analytics landing pages, Search Console page performance, and server logs where available. No single source is exhaustive. A sitemap expresses preferred discovery URLs, not every URL people or crawlers have requested. Logs can reveal legacy paths absent from current navigation. Search Console can identify pages with impressions or links. Prioritize business-critical and historically visited pages, but do not ignore the long tail merely because it is absent from a top-100 export.

Use one row per old URL. Useful fields are source_url, destination_url, disposition, reason, owner, priority, and test_status. The disposition should be moved to equivalent content, consolidated into a genuinely relevant page, intentionally removed, or unchanged. A blank destination must be an explicit editorial decision, not a missing spreadsheet cell.

• Equivalent move: a canonical-tags guide becomes a new guide at another path. Redirect to the new guide.
• True consolidation: two overlapping documentation pages merge into one complete resource. Redirect both only after confirming the new page answers both intents.
• Removed without replacement: an obsolete event page has no meaningful successor. Return 404 or 410, rather than forcing visitors to the homepage.
• Unchanged: the URL stays stable. Test its response, canonical, and indexability parity instead of inventing a redirect.

Reject duplicate source URLs with conflicting destinations and cycles in which A redirects to B while B redirects to A. Flag unrelated source pages mapped to one generic destination. Google cautions that irrelevant mass redirects can be treated as soft 404s. Preserving page intent matters more than creating a cosmetically complete spreadsheet.

Define HTTP behavior as a contract

For a permanent move, use a server-side 301 or 308 when supported and appropriate. Google's redirect guidance treats permanent server-side redirects as strong signals toward the target URL. A 302 or 307 communicates a temporary move. These codes are not interchangeable for every client, especially where non-GET requests or APIs are involved.

The target should normally return 200, serve intended content, and declare its own canonical URL. A redirect to a page that redirects again adds latency and failure surface. Google's crawler status-code reference explains that Googlebot generally follows up to ten redirect hops, but that is not an engineering target. Aim for one hop. Keep unavoidable chains short, document them, and test the final response.

Test with an actual GET as well as a header request. A header-only request is useful for quick inspection, but some stacks treat HEAD differently from GET. Test the initial redirect response without following it and also verify the final status and destination with redirects enabled. Preserve these results in a release report so the reviewer can compare expected and actual behavior.

Preserve meaningful query parameters when the destination needs them, but do not blindly forward sensitive or irrelevant parameters. Normalize trailing slashes, case, encoding, and protocol according to the site's canonical policy. A rule that works for /products/ may not work for /products, percent-encoded paths, or an old URL with a query string.

Check canonical, indexability, and sitemap signals together

A successful redirect is only one signal. On the destination, inspect the HTML rel="canonical", robots meta tag, any X-Robots-Tag header, and HTTP response. A page can return 200 and still be excluded by noindex. It can also declare a canonical pointing back to a retired URL. Google describes redirects and canonical annotations as strong signals, while sitemap inclusion is weaker; consistency matters.

For each destination that should be indexable, require a self-referencing canonical, no accidental noindex, and a discoverable internal link where appropriate. Update navigation, breadcrumbs, related-content links, hreflang references, structured-data URLs, and image or document links. A sitemap is not a substitute for repairing internal links. Google's canonicalization guidance warns against specifying different preferred URLs through different methods.

Build the new sitemap from intended canonical destinations, not redirect sources. Check that its XML is valid, each listed URL belongs to the intended property, and each listed indexable page resolves correctly. Update lastmod only when the page meaningfully changes. Google says a sitemap does not guarantee crawling or indexing, and it does not use priority or changefreq as ranking or crawl-priority controls. A sitemap is a discovery aid, not a recovery switch.

For a domain move, verify old and new Search Console properties and review whether the Change of Address tool applies. It is not required for every path migration. Keep old redirects active long enough for users and crawlers to find the new addresses; Google generally recommends at least a year and notes that keeping them longer can help users with old links.

Turn the mapping into pull-request checks

Store the URL map as a versioned artifact beside routing configuration. A pull request should make the old-to-new relationship reviewable before deployment. A CI job can validate the map without accessing customer data or production credentials. Reject duplicate sources, malformed absolute URLs, unsupported destination hosts, cycles, and mappings to a generic homepage without an explicit exception.

Run a staging crawl against a deployment preview. For each high-priority source URL, record first status, redirect target, hop count, final status, and final canonical. Compare the observed target with the approved map. For unchanged URLs, compare status, canonical, and robots directives with the baseline. For new destinations, test title, primary content, and links. The aim is not to freeze every word; it is to catch missing or mismatched pages before release.

A useful CI result is a compact exception report: source URL → expected target → actual target → failure reason. Fail the build for loops, off-domain redirects not on an allowlist, missing critical destinations, and unexpected sitewide indexing blocks. Route lower-risk issues, such as an extra redirect hop on a rarely visited legacy URL, through a documented review policy. Severity should reflect both technical impact and page importance.

See Vixqo's GitHub-native SEO guide for the broader case for versioning search changes, and its automation safety framework for deciding which actions require human approval. A migration illustrates why an automated agent should propose, validate, and verify changes instead of simply editing routing files and announcing success.

Choose rollout gates before the first redirect goes live

Make launch criteria explicit. The exact thresholds depend on site size and risk; these are example policy gates, not industry benchmarks. Require every designated critical URL to reach the approved target and return the expected response. Require zero redirect loops, zero unintended cross-host redirects, and zero newly introduced sitewide indexing blocks. Allow a documented queue of noncritical exceptions only with a named owner and deadline.

For a large site, a pilot section can expose routing mistakes with a smaller blast radius. For a small or medium site, moving all related URLs together may provide a more coherent user experience. Google's migration documentation discusses both patterns and cautions that a pilot is not necessarily representative of the full move. Decide based on infrastructure, URL dependencies, and observability rather than a universal percentage rollout formula.

Freeze unrelated template experiments during the most sensitive part of the migration if feasible. Keep a record of the deploy SHA, redirect-map version, sitemap version, and the moment traffic began reaching the new URLs. Without that record, teams can debate whether a traffic change came from redirects, a title rewrite, a JavaScript release, or an analytics tag that stopped firing.

Monitor two kinds of success after deployment

Technical success is observable immediately: old URLs redirect to approved destinations, new pages return correct status codes, canonicals and robots rules are correct, and navigation does not leak retired paths. Re-run mapping tests against production after DNS and edge caches have settled. Compare representative mobile and desktop rendered pages, especially if the move changed frameworks.

Search transition takes longer. Track old and new properties in Search Console, crawl and indexing errors, sitemap processing, impressions and clicks by URL group, and landing-page activity in analytics. Keep old and new URL groups together in reporting; otherwise a drop in old URLs can be mistaken for a loss even when successors gain traffic. Watch brand and nonbrand query mix alongside raw totals.

Do not declare causal improvement because one week's impressions rose. Seasonality, demand shifts, reporting delays, and concurrent releases complicate attribution. The same caution applies to AI search visibility: a URL migration can alter which address is cited, but a sampled assistant response is not proof that the migration increased recommendation share. For a measurement framework, read what Google and Bing actually report.

Set a review rhythm: immediate technical smoke tests; daily checks during the initial transition; then weekly trend reviews until the migration stabilizes. Escalate clusters of unexpected not-found responses, broad noindex incidents, wrong canonical selection, or sustained server errors. Google notes that temporary search fluctuations are normal, so distinguish ordinary recrawling from reproducible technical failures.

Define rollback by failure type, not by anxiety

Rollback sounds simple until old and new URLs have both been exposed to users and crawlers. Reverting application code may be appropriate for a broken template, while reversing every redirect can create a second URL move. Keep the ability to restore a known-good build, but define targeted remediation paths: fix a bad redirect map; restore a missing destination; remove accidental noindex; repair canonical tags; or temporarily disable an unsafe routing rule.

Reserve a broad rollback for severe conditions such as a sitewide outage, incorrect cross-domain routing, or widespread content inaccessibility that cannot be repaired quickly. If the problem is a handful of mappings, a forward fix is usually less disruptive than toggling the entire migration back and forth. Every remediation should produce a new deploy identifier and test run, not an undocumented manual change.

After an incident, preserve the failed mapping, observed responses, and root cause in the repository. That evidence improves future tests. For a complementary framework on separating signal from noise, see SEO experimentation without theater.

A practical release checklist to copy

• Before development: define scope, export current URLs, capture high-value pages, and record baseline response, canonical, indexing, and search data.
• Before review: approve the map; mark removals explicitly; verify destination content and query-parameter policy.
• Before merge: test loops, chains, targets, cross-host rules, canonicals, robots directives, internal links, and sitemap consistency in preview.
• At launch: record commit and deployment identifiers, enable permanent redirects, and smoke-test critical URLs on production.
• After launch: verify Search Console properties where applicable, monitor errors and URL-group traffic, and fix reproducible defects without mistaking normal transition volatility for failure.
• At closeout: archive the final map, exceptions, monitoring notes, and lessons; retain useful redirects rather than deleting them as soon as dashboards stabilize.

Primary references and next step

This playbook draws on Google's site migration guide, redirect documentation, canonicalization guidance, HTTP status-code behavior, and sitemap overview. Example release gates are an operational template, not a Google requirement or promise of traffic retention.