Site Migration SEO Checklist
Use this site migration SEO checklist to protect URLs, redirects, indexability, search traffic, and rollback decisions before, during, and after launch.
A site migration is a controlled change to a site’s platform, domain, protocol, information architecture, URL structure, or rendering system. It is complete only when users, crawlers, and analytics can reach the intended content through stable routes and the team can prove that valuable visibility survived.
Checklist: site migration SEO. Timebox: begin 6–12 weeks before launch for a medium site; reserve the final 5 business days for a change freeze, launch day for staffed validation, and at least 4 weeks for active monitoring. Owner: one migration lead accountable for the whole release, supported by named engineering, SEO, analytics, content, and infrastructure owners.
Why this checklist exists, and why it runs here
This release-control layer in the SEO process consumes crawl and index evidence from the technical baseline audit , keep/merge/remove decisions from the content inventory and audit , and the destination hierarchy from the topical map and information architecture . Those outputs must exist before redirects or staging can be judged.
Run it after the destination structure is approved but before production routes are frozen. If it runs earlier, the team maps redirects to destinations that may still change. If it runs later, routing, templates, analytics, or launch communications may already be too expensive to correct safely.
The redirect map is the single highest-risk artefact because it joins old routes to new ones. Each valuable old URL should go one-to-one to the closest destination that preserves its purpose. Never use the homepage as a catch-all: it frustrates visitors and disguises missing destinations.
Inputs and outputs
Outputs are the contract with launch operations. A spreadsheet without owners, evidence, or acceptance conditions is not a handoff.
| Direction | Artefact | Acceptance condition |
|---|---|---|
| Input | Baseline URL inventory | Joins crawl, sitemap, analytics, Search Console, backlink, CMS, and server-log sources; records status, canonical, index state, traffic, links, template, and owner. |
| Input | Destination architecture | Gives every retained or consolidated topic one approved destination URL and identifies deliberate removals. |
| Input | Analytics baseline | Preserves at least 28 comparable days by landing page, directory, device, country, channel, conversion, and revenue where available; notes seasonality and active campaigns. |
| Input | Release architecture | Documents DNS, CDN, origin, rendering, robots, canonical, sitemap, structured-data, consent, tag-manager, and cache behavior. |
| Output | Approved redirect map | Contains normalized source, final destination, rationale, owner, test result, and exception status for every changing URL. |
| Output | Staging acceptance record | Records pass, fail, or not applicable for routes, templates, metadata, links, rendering, analytics, accessibility, performance, and crawler access. |
| Output | Launch runbook | Gives every action an owner, exact sequence, planned time, validation evidence, escalation route, and rollback dependency. |
| Output | Monitoring dashboard | Compares launch behavior with the signed baseline and segments results by page value and directory. |
| Output | Migration decision log | Records launch approval, exceptions, incidents, fixes, rollback decisions, and timestamps in one durable location. |
Ready to Monitor Your AI Visibility?
Track how AI chatbots mention your brand across ChatGPT, Perplexity, and other platforms.
The checklist
Every item states what, why, how, tool, and an observable done-when condition. Replace a threshold only with a stricter rule or a documented baseline-based one.
Phase 1: pre-migration inventory
1. Build the union URL inventory. What: combine every discoverable old URL from crawls, XML sitemaps, analytics, Search Console, backlink exports, CMS records, paid campaigns, and server logs. Why: no single source contains every valuable or requested URL; a page absent from navigation may still have links, traffic, or contractual importance. How: normalize protocol, host, case, trailing slash, parameters, and encoded characters while retaining the raw source value. Deduplicate only after recording where each URL was found. Tool: crawler, CMS export, analytics, Search Console, backlink data, and logs. Done when: every source is dated, every row has a normalized URL and discovery source, duplicates are resolved, and source totals reconcile with the final inventory.
2. Classify the disposition of every URL. What: label each URL keep, move, merge, remove, or investigate. Why: redirects cannot be mapped correctly until the content decision is explicit. How: combine traffic, conversions, backlinks, index state, content quality, business need, and intent; record the evidence and approving owner. Tool: inventory workbook and content audit. Done when: 100% of in-scope URLs have one disposition, an owner, a destination or removal reason, and no unresolved “investigate” row remains at freeze.
3. Capture the signed baseline. What: preserve pre-launch organic sessions, clicks, impressions, conversions, revenue, indexed URLs, crawl errors, response codes, uptime, and performance for priority templates and directories. Why: without a dated comparison point, normal variation and migration damage look alike. How: export at least 28 comparable days, annotate campaigns and seasonality, and identify priority URLs that require daily review. Tool: analytics, Search Console, crawler, rank data, and monitoring. Done when: the baseline is read-only, reproducible, segmented, timestamped, and approved by SEO and analytics owners.
Phase 2: redirect mapping
4. Map sources one-to-one wherever possible. What: assign each moved or merged old URL to the closest new URL with the same primary intent. Why: a precise destination preserves continuity for the visitor and gives crawlers a coherent replacement signal. How: compare topic, product, geography, language, and task; map merges to the surviving page and document deliberate removals. Never map unmatched URLs to the homepage. Tool: redirect-map workbook, inventory, and destination crawl. Done when: every changing source has exactly one approved outcome, every destination is relevant and in scope, and homepage catch-all mappings equal zero.
5. Validate redirect mechanics before launch. What: test status codes, destinations, query behavior, case variants, protocol, subdomains, trailing slashes, files, and campaign URLs. Why: a correct-looking spreadsheet can still produce loops, chains, wildcards that swallow valid pages, or destinations that return errors. How: generate the staging or proxy rules, request every source, follow hops, and compare the final URL with the approved map. Tool: automated HTTP test, crawler, and server configuration review. Done when: 100% of mapped sources reach the approved 200 destination in one permanent redirect hop; loops, chains, temporary redirects, and error destinations are zero.
6. Reconcile canonicals, links, and sitemaps with redirects. What: make the canonical URL
, internal links, hreflang references, structured data, feeds, and XML sitemaps point directly to final URLs. Why: redirecting old URLs while continuing to publish them creates conflicting migration signals and wastes crawler requests. How: crawl every reference source and compare normalized targets with the redirect map. Tool: crawler, rendered HTML, sitemap parser, and configuration diff. Done when: final pages self-canonicalize unless an approved exception says otherwise, internal references to redirected URLs are zero, and new sitemaps contain only canonical 200 URLs.
Phase 3: staging validation
7. Test staging without making it publicly indexable. What: crawl the complete staging release while preventing search engines from indexing the environment. Why: the team needs crawler-level evidence without allowing a duplicate site into search results. How: use access control for external crawlers, then run an authenticated internal crawl with JavaScript rendering where the production site depends on it. Treat a staging block as temporary release configuration, not something to copy blindly into production. Tool: authenticated crawler, browser, and response-header inspection. Done when: the expected staging inventory is crawlable by the test team, unauthorized public indexing is blocked, and the production launch checklist explicitly removes staging-only controls.
8. Verify templates and priority journeys. What: test representative pages from every template plus navigation, search, forms, signup, checkout, localization, pagination, filters, and error pages. Why: a homepage pass cannot reveal a canonical bug on product pages or a broken consent state that suppresses analytics. How: create a device-and-template matrix, test clean and returning sessions, and record screenshots or response evidence for each result. Tool: browser, accessibility checker, structured-data validator, analytics debugger, and transaction tests. Done when: every in-scope template and primary journey passes on the agreed browsers and devices, with zero critical defects open.
9. Compare staging with the approved contracts. What: diff titles, descriptions, headings, canonicals, robots directives, structured data, internal links, response codes, content, and analytics tags against the old site and destination specification. Why: platform migrations often lose metadata or change rendering even when the visible copy appears intact. How: crawl old production and staging with matched settings, segment differences by template, and approve intended changes only. Tool: crawl-diff report and source inspection. Done when: every material difference is either corrected or listed as an approved change with owner and reason; accidental noindex, canonical, content, and tracking changes equal zero.
10. Freeze the release candidate. What: freeze the URL inventory, redirect map, route definitions, canonical and robots rules, sitemap generation, analytics and consent setup, DNS/CDN plan, and unrelated production deployments. Why: a test result applies only to the version tested. How: tag the release artefacts, restrict changes to the incident path, and require retesting of anything affected by an emergency edit. Tool: deployment system, change log, and approval record. Done when: one immutable candidate is named, access is restricted, all exceptions have an owner, and every post-freeze change carries a test result.
Phase 4: launch day
11. Execute one owned runbook. What: deploy routing, application, DNS/CDN, analytics, sitemaps, and monitors in the approved order. Why: parallel unsequenced changes make failures hard to isolate and rollback unsafe. How: one migration lead calls each step, the assigned operator records completion, and validators test the evidence before the next dependent step. Tool: runbook, deployment logs, DNS checks, and shared incident channel. Done when: each line has an actual time, operator, result, and evidence link, and no dependency is marked complete on verbal assurance alone.
12. Run the launch smoke test. What: test the homepage, robots file, sitemaps, at least one URL per template, every priority journey, analytics receipt, and a stratified sample of redirect sources. Why: the fastest safe response comes from detecting a broad failure before caches and crawlers spread it. How: test from outside the production network, use desktop and mobile, verify both server-delivered HTML and rendered output, and compare with the frozen expectations. Tool: crawler, browser, HTTP client, analytics real-time view, and transaction monitor. Done when: critical pages return the intended status and content, priority redirects reach their exact destinations, analytics events arrive with correct URLs, and all launch-blocking checks pass.
13. Submit and verify discovery signals. What: publish the final sitemaps, confirm robots and canonical behavior, and request inspection for a small set of priority URLs. Why: clean discovery signals help crawlers encounter the destination set without treating submission as a guarantee of indexing. How: submit each production sitemap once, inspect representative new URLs, and record Google’s reported canonical and index state. Tool: Sitemaps and Indexing and URL Inspection . Done when: sitemaps are reachable and contain the frozen canonical inventory, representative inspections show no production block or wrong canonical, and every warning has an owner.
Phase 5: post-launch monitoring
14. Watch the first 72 hours as an incident window. What: monitor uptime, 5xx, 4xx, redirect failures, latency, crawl volume, analytics receipt, conversions, sitemap processing, and priority journeys continuously or at the shortest practical interval. Why: infrastructure and routing defects surface quickly, while search performance takes longer and should not be used as the only launch alarm. How: compare with the signed baseline, segment by template and directory, and route alerts to an on-call owner. Tool: logs, analytics, crawler, Uptime Monitors
, and incident dashboard. Done when: the dashboard has no unexplained launch-critical alert, each incident has an owner and timestamp, and 24-, 48-, and 72-hour reviews are signed.
15. Continue search and index monitoring after stability. What: track page-level clicks, impressions, index state, selected canonicals, crawl errors, directory performance, and conversion outcomes for at least four weeks. Why: crawling, canonical selection, and index replacement lag behind infrastructure validation. How: compare like-for-like windows, separate moved URLs from unchanged controls, and investigate clusters rather than reacting to one day’s total. Tool: Google Search Pages , Directory View , URL Inspection, analytics, and logs. Done when: priority destinations are discoverable and indexable, old URLs consistently resolve to approved destinations, unexplained losses have tickets, and ownership moves into the normal reporting cadence.
Tools in AmICited
AmICited provides launch evidence and monitoring surfaces; the approved redirect map and deployment logs remain the operational source of truth.
| Product tool | Use during migration | Deep link | Evidence to retain |
|---|---|---|---|
| Sitemaps and Indexing | Submit the production sitemap, review reported warnings or errors, and request indexing for a limited priority set. | Open Sitemaps and Indexing | Sitemap URL, submission time, status, warnings, sampled requests, and owner. |
| URL Inspection | Sample new priority URLs and verify Google’s index verdict, selected canonical, mobile usability, and rich-results result. | Open URL Inspection | Inspected URL, time, verdict, declared and selected canonical, last crawl, and follow-up. |
| Google Search Pages | Compare page-level clicks, impressions, CTR, and position after launch, then inspect an anomalous row. | Open Google Search Pages | Comparison dates, filters, affected URLs, absolute change, baseline context, and ticket. |
| Directory View | Detect whether a loss is concentrated in a moved directory or template rather than sitewide. | Open Directory View | Directory, depth, date range, affected page set, and named hypothesis. |
| Uptime Monitors | Check the homepage and critical URLs every one to five minutes and validate transactions where a simple HTTP response is insufficient. | Open Uptime Monitors | Monitor configuration, status history, latency, incident start and end, and response owner. |
Stay Updated on AI Visibility Trends
Get the latest insights on AI mentions, brand monitoring, and optimization strategies.
Decision rules
These are release guardrails, not universal search-engine thresholds. Agree them before launch and tighten them where risk requires it.
| Signal | Acceptable | Bad | Required decision |
|---|---|---|---|
| Redirect-map coverage | 100% of changing in-scope URLs have an approved outcome | Any priority URL unmapped; more than 1% of all in-scope changing URLs unresolved | Hold launch until mapped or explicitly removed. |
| Redirect behavior | One permanent hop to the exact approved 200 destination | Any loop; any chain on a priority URL; more than 0.5% of tested sources differ from the map | Block launch or roll back the routing change. |
| Homepage catch-all | 0 unrelated redirects to the homepage | Any old URL mapped to the homepage only because no destination was chosen | Reject the map and decide a relevant destination or honest removal. |
| Production availability | Baseline availability and latency maintained | Two consecutive 5-minute periods with homepage or primary journey unavailable, or p95 response time above twice baseline for 15 minutes | Invoke incident response; roll back if not corrected inside the pre-agreed recovery window. |
| Server errors | Below 0.5% of requests and no priority-page cluster | 5xx reaches 2% for 10 minutes, or any sustained failure blocks a primary journey | Roll back unless the fault is isolated and safely reversible inside 15 minutes. |
| Priority URL responses | 100% return their intended 200 or mapped permanent redirect | Any priority URL returns 4xx, 5xx, loops, or reaches an unrelated page | Treat as launch-critical and correct immediately. |
| Analytics receipt | Events and page URLs match the signed test within 15 minutes | No production data for 15 minutes, duplicate page views above 5% in the validation sample, or conversion events lose URL attribution | Pause dependent marketing; roll back tracking or release if reliable measurement cannot be restored. |
| Sitemap quality | 100% of entries are canonical, indexable 200 URLs | Any sitemap entry redirects or errors; more than 1% blocked or non-canonical | Correct and resubmit; investigate generator-wide patterns immediately. |
| Search visibility | Review against matched baseline and unchanged controls | After the first 7 days, priority-page clicks or impressions are down 30% while unchanged controls are stable; or a moved directory is down 20% for 3 consecutive comparable days | Open a migration incident and diagnose routing, canonical, rendering, and index state before changing content. |
Rollback restores a known good service state; it does not reverse ordinary search fluctuation. The launch authority applies the agreed rules and records the evidence.
Deliverable
Hand over one versioned migration control pack accessible to engineering and SEO. Use a workbook or database for row-level records, a runbook for launch actions, and a dashboard for live measures.
It must contain the frozen inventory and source reconciliation; approved redirect map with owners and tests; matched old, staging, and new crawls; metadata, canonical, robots, sitemap, hreflang, structured-data, link, and analytics diffs; signed baseline and priority cohorts; launch runbook and recovery procedure; numerical rollback rules and decision owner; and the 24-, 48-, and 72-hour evidence with four-week monitoring ownership.
The migration lead must be able to identify the exact release, prove every critical test, reconstruct each routing decision, and assign every exception. Otherwise the pack is incomplete.
What goes wrong
The redirect map uses only the current sitemap. Orphans, campaign URLs, backlinks, and previously indexed routes disappear, so every spreadsheet row passes while real requests fail.
The homepage becomes the default destination. Users land somewhere irrelevant, crawler signals become ambiguous, and missing content is disguised as implementation progress.
Redirects work, but references stay old. Navigation, hreflang, canonicals, structured data, and sitemaps keep sending crawlers through unnecessary hops and conflicting destinations.
Staging protection reaches production. A copied noindex, authentication rule, robots block, or CDN policy destroys indexability
. Require an explicit removal step and external test.
The team validates only the homepage. A shared template can misconfigure thousands of pages while the homepage passes. Sample every template and crawl rules at scale.
Unrelated releases ship together. When platform, analytics, consent, navigation, checkout, and CDN changes share a window, failures become difficult to isolate or reverse.
Search is judged too early or broadly. Site totals hide broken directories and one volatile day prompts unnecessary fixes. Compare moved cohorts, unchanged controls, directories, and matched windows.
Rollback is debated during the outage. A good plan names thresholds, decision maker, recovery time, commands, data consequences, and validation sequence before launch.
Next phase
Once the first 72 hours are stable, the next step is continuous refresh and iteration . It needs the signed baseline, final URL mapping, launch annotations, directory cohorts, known exceptions, incident history, and named owners from this checklist. Without those inputs, a later traffic loss cannot be separated reliably into migration damage, ordinary demand change, content decay, or measurement failure.
Keep the redirect map and migration annotation permanently. Move non-critical findings into the normal reporting cadence with a severity, hypothesis, owner, due date, and verification method.
Frequently asked questions
When should the SEO team join a site migration?
Before routes, templates, and platform constraints are fixed. SEO needs enough time to inventory current URLs, preserve valuable destinations, influence the new information architecture, define redirect behavior, and agree measurable launch and rollback rules.
Should old URLs redirect to the homepage when there is no direct replacement?
No. Redirect an old URL to the closest page that satisfies the same user intent. If no relevant destination exists and the content should not be preserved, return an honest 404 or 410 rather than sending users and crawlers to an unrelated homepage.
How long should migration redirects remain in place?
Keep permanent redirects for as long as old URLs may still receive visits, links, bookmarks, or crawler requests. Treat them as durable routing infrastructure, not launch scaffolding to remove after a few weeks.
What should be frozen before migration launch?
Freeze the approved URL inventory, redirect map, canonical and robots rules, sitemap generation, analytics and consent configuration, DNS and CDN changes, and unrelated production releases. Emergency fixes follow the named change-control path.
When should a migration be rolled back?
Use criteria agreed before launch. Roll back for failures such as sustained unavailability, widespread 5xx responses, broken primary journeys, missing analytics, or routing defects that affect a material share of priority URLs and cannot be corrected safely inside the agreed recovery window.
More tutorials in this section
Ready to put it into practice?
Free check · 7-day trial · no credit card