An SEO migration is not a design project with a technical appendix. It is a controlled change to a working acquisition system. URLs, internal links, content, structured data, rendering, analytics and conversion paths all carry accumulated value. Alter several at once without a plan and it becomes difficult to tell whether lost performance came from redirects, indexation, tracking, messaging or demand.
The objective is not to preserve every historical URL at any cost. It is to preserve the search intent, authority signals and commercial journeys that make organic search valuable. Some pages should be consolidated or retired. The difference between sensible consolidation and preventable loss is evidence, mapping discipline and a launch process that allows fast correction.
This SEO website migration checklist is designed for redesigns, CMS changes, domain moves, HTTPS changes and site consolidations. The details vary, but the risk-management logic does not.
Start with a migration brief and a revenue baseline
Before anyone changes templates, define what is changing and what is deliberately staying stable. Record the old and new domains, protocol, subdomains, URL rules, CMS, navigation, content scope, international targeting, analytics implementation and release date. Name one owner for SEO decisions and one for deployment decisions. Ambiguous ownership is a common source of avoidable launch errors.
Next, build a baseline from at least the prior 8–12 weeks, with year-on-year context where seasonality matters. Segment organic performance by landing page, device, country and conversion type. Export Search Console clicks, impressions, queries and indexed-page signals; export analytics sessions, engaged visits, form submissions, calls, demos, ecommerce revenue or CRM pipeline where available.
Do not use sessions alone as the success measure. A migration can preserve informational traffic while damaging the few pages that create qualified demand. The measurement approach in this SEO-to-revenue attribution framework is useful here: keep search visibility, on-site conversion and downstream commercial outcomes visible as separate layers.
Worked example: prioritise URLs by commercial exposure
Consider a clearly labelled hypothetical B2B software site. Its 90-day organic export shows the following landing-page groups:
| Page group | Organic sessions | Qualified leads | Lead-to-opportunity rate | Average opportunity value |
|---|---|---|---|---|
| Product and solution pages | 12,000 | 180 | 30% | £8,000 |
| Industry pages | 6,000 | 54 | 25% | £8,000 |
| Blog and guides | 42,000 | 84 | 15% | £8,000 |
Estimated organic opportunity value is calculated as qualified leads × lead-to-opportunity rate × average opportunity value. Product pages contribute 180 × 0.30 × £8,000 = £432,000. Industry pages contribute £108,000. Blog content contributes £100,800. Although the blog provides 70% of sessions, product and industry pages account for roughly 84% of estimated opportunity value.
The implementation consequence is concrete. Put all product and industry URLs in the highest migration tier. Require one-to-one redirect testing, content parity review, conversion-event tests and a named business approver before launch. Blog URLs can still matter, but they should not receive the same triage priority merely because their traffic is larger. This is not a revenue forecast; it is a practical way to direct limited QA time toward commercial risk.
Build the URL inventory before designing redirects
Export URLs from multiple sources: XML sitemaps, a full crawl, Search Console landing pages, analytics landing pages, server logs if available, CMS exports and backlink tools. Each source exposes a different blind spot. A sitemap may omit old linked pages; analytics may omit low-traffic pages with valuable backlinks; a crawl may miss orphaned URLs.
Deduplicate the list and add fields that support decisions: current status code, canonical, title, organic clicks, sessions, conversions, revenue or pipeline, backlinks, indexability, page type, target URL and migration action. Keep query strings only when they represent a genuinely distinct, indexable page. Tracking parameters should normally be normalised rather than mapped as unique content.
Classify every meaningful old URL as one of four actions:
- Keep: retain the URL where possible, especially for high-value evergreen pages.
- Redirect: use a permanent server-side redirect to the closest equivalent new page.
- Consolidate: merge genuinely overlapping pages into the strongest destination.
- Retire: return 404 or 410 only when there is no relevant replacement and the page has no material value to preserve.
A redirect is not a substitute for relevance. Sending ten discontinued service pages to the home page is usually unhelpful to visitors and weakens the signal of what replaced the old content. Map by intent, topic and next action. If two old pages become one stronger guide, make the new guide visibly cover both subjects and update its internal links accordingly. A prior SEO cannibalisation audit can be valuable before consolidation because it distinguishes duplication from separate intent.
Validate redirects as a system, not a sample
Use 301 redirects for permanent URL replacements. Configure them at the server, CDN or application layer appropriate to the stack, and avoid client-side JavaScript redirects for migration-critical paths. Google’s guidance on Search Central is a useful primary reference when implementation questions arise; platform behaviour and documentation can change, so developers should verify the current guidance rather than rely on a historic checklist.
Test the complete old-URL export against the staging environment or a protected production endpoint. For each row, capture the old status, redirect status, final destination, final status, canonical and indexability. The required pattern is simple: old URL → one 301 → relevant final URL returning 200. Flag chains, loops, 302s where a permanent move is intended, redirects to irrelevant pages, and destinations blocked by robots rules or marked noindex.
Also test URL variants: HTTP and HTTPS, www and non-www, trailing slash rules, uppercase paths, encoded characters and common parameter patterns. A migration often fails at these edges because the team only tested the neat URLs in the mapping sheet.
Protect technical SEO and answer-ready content
Run a crawl of staging and compare it with the old site. Check canonical tags, robots meta directives, robots.txt, XML sitemap URLs, pagination, hreflang where relevant, structured data, mobile rendering, page titles, headings, image alt text and internal links. Staging sites are commonly protected with noindex or authentication; those protections must be removed intentionally at launch, not assumed to disappear.
Confirm that canonical tags are self-referential on the final preferred URLs unless there is a deliberate consolidation. Ensure the XML sitemap contains only canonical, indexable 200-status URLs. Submit it after launch through the relevant tools; Bing also provides resources through Bing Webmaster Tools.
For answer engine optimisation, preserve the substance that made pages useful: direct answers, precise definitions, source-backed claims, visible authorship where appropriate and clear heading structure. Do not assume schema alone will recover lost content. If a redesign turns a detailed service page into sparse brand copy, the redirect may work perfectly while relevance declines. Treat content parity as a business decision, not a cosmetic one. For stronger answer-oriented pages, apply the principles in this citation-worthy content playbook.
Control launch sequencing and analytics
Freeze non-essential releases during the migration window. Deploy redirects, templates, content and measurement changes in a known sequence, then record the exact release time. Avoid combining a domain move, major information-architecture rewrite, new cookie banner and conversion-form rebuild if it can be staged. Each additional simultaneous change makes diagnosis slower.
Before DNS or production cutover, test analytics in staging or a controlled environment. Verify page views, consent behaviour, form events, phone tracking, ecommerce events, CRM source capture and paid-media destination URLs. Preserve the old analytics property and annotations; do not overwrite history. If URL structures change, create a lookup table so reporting can compare old and new page groups rather than falsely treating a renamed path as a new acquisition channel.
At launch, run a short operational checklist:
- Confirm the preferred domain, HTTPS certificate and CMS environment are live.
- Test the highest-value old URLs, key templates, forms, checkout or booking paths and thank-you events.
- Crawl the production site for accidental noindex directives, broken canonicals, 4xx/5xx errors and internal-link failures.
- Publish the new XML sitemap and verify the correct Search Console property.
- Check that robots.txt does not block critical sections or essential resources.
Monitor by exception for the first month
In the first 48 hours, focus on technical breakage: server errors, redirect failures, robots blocking, noindex pages and missing analytics events. During the next two weeks, review index coverage, crawl patterns, organic landing-page clicks, branded versus non-branded queries and conversions daily or near-daily. Then move to weekly comparisons against the pre-launch baseline and the appropriate prior-year period.
Create thresholds in advance. For example, investigate when a tier-one page has zero tracked organic sessions for two consecutive days, when redirect errors exceed an agreed count, or when qualified leads fall materially without a matching change in demand. Thresholds are triggers for diagnosis, not evidence that the migration caused the change.
When performance drops, inspect in order: tracking, availability, indexability, redirects, canonicals, internal links, rendered content and query demand. Revert only changes you can explain. Panic edits frequently create more moving parts and extend recovery time.
FAQ and conclusion
How long should redirects remain live?
Keep permanent redirects for as long as the old URLs have backlinks, bookmarks, referral traffic or plausible search value. In practice, that is often measured in years, not weeks. Review their value periodically, but avoid removing them simply because the launch is over.
Should every old page redirect?
No. Redirect pages with a close, useful replacement. Retire obsolete pages with no relevant destination, particularly thin utility URLs. The key is to avoid forcing users and crawlers onto an unrelated page.
Can rankings fluctuate after a well-run migration?
Yes. Search systems need to recrawl and process changed URLs and signals. A well-run process reduces avoidable risk; it cannot promise identical rankings or revenue every day.
What is the single most important migration deliverable?
A complete, decision-ready URL map tied to commercial value. It tells developers what to redirect, gives QA a test plan and gives marketers a way to interpret post-launch results.
Conclusion: Treat a migration as a measured operational change, not a one-night launch. Baseline commercial performance, map URLs by intent, test every important redirect, protect indexability and conversion tracking, then monitor exceptions with discipline. That approach will not eliminate uncertainty, but it gives the team the evidence and control needed to protect organic revenue while the site improves.