Website Migration SEO: Build the Control System Before You Move

The pre-migration audit should answer a decision question: which existing search-visible assets must be preserved, intentionally consolidated, or deliberately retired, and what evidence supports each choice?

Start with a crawl that records every current 200 URL and the technical fields needed for later comparison. Join that inventory to Search Console query and page data, analytics, backlink exports, XML sitemaps, and known business-critical pages.

The result is not just a crawl file; it is a baseline that identifies which URLs currently receive search demand, which attract external references, which are internally prominent, and which may be discoverable even when recent traffic is low.

For URL changes, the audit also establishes the redirect candidates. A page with a clear successor can be mapped for a 301, while a page with no equivalent needs a content decision rather than an automatic redirect.

Pages that would otherwise end as 404 responses should be distinguished from pages that are intentionally retired with no suitable replacement; the migration team needs that distinction before development writes rules.

Any unexpected 404 outcome on a mapped page is then a test failure rather than an ambiguous editorial decision. Next, capture ranking URL ownership: for each important query or topic, record the page currently surfaced so post-launch movement can be traced to a specific old-new relationship.

Then inventory template-generated SEO output such as canonical tags, robots directives, breadcrumbs, structured data, title logic, pagination, and internal linking. The owner of this baseline should be the SEO lead, but developers and content owners must sign off on fields they control.

The deliverable is a reconciled migration inventory with disposition, destination, evidence, owner, and validation status for each important URL group.

Redirect mapping should be treated as a relevance decision first and an implementation task second. For every URL that is changing, decide whether the new site contains a genuinely equivalent destination, a broader but still useful successor, a consolidated replacement, or no suitable replacement at all.

Where a relevant successor exists, a direct 301 is the normal migration mechanism. Where no relevant destination exists, forcing the URL to an unrelated page can make the migration record look complete while creating poor user and search behaviour.

Mapping at scale works best when the team separates predictable patterns from exceptions. Stable path transformations can be handled by tested rules, while restructures involving changed taxonomy, merged content, or renamed products require page-level review.

Existing redirects must be incorporated into the map before new rules are layered on. The final intended state should point each historical source directly to the final destination rather than creating chains.

A practical validation pass happens in two stages. Before launch, test the redirect file against a representative and high-value sample. Within 24 hours of release, run the production validation and create an exception list owned jointly by SEO and development.

Crawl the entire source list and confirm that each expected 301 resolves to the mapped destination, every unexpected 404 is triaged, and no rule sends broad groups to an irrelevant page. Severity should be determined by search value, link value, and scale of the affected pattern.

Staging is where the future production state can be tested without asking search engines or users to absorb the consequences of an unfinished build. The first control is access: staging should not become an unintended public indexable copy.

The second control is comparability. Crawl staging with the same fields used for the production baseline and compare URL coverage, status codes, canonicals, robots directives, title output, internal links, structured data, and crawl depth by template.

The production robots.txt file and XML sitemap should be prepared before launch rather than improvised during deployment. Canonical logic deserves template-level review because one CMS rule can change the signal across every page of the same type.

The same is true for metadata generation, pagination, breadcrumb output, and structured data. Performance should be reviewed as an implementation property rather than assumed from the design prototype; new themes, scripts, rendering choices, and asset delivery can change user experience materially.

Launch approval should therefore require a written exception list. Any known difference between current production and staging should be either intentional and approved, or treated as a blocker when it affects critical discovery, indexation, canonicalisation, or destination behaviour.

The output of staging QA is not a vague statement that SEO has checked the site. It is a comparison showing which expected behaviours passed, which failed, who owns remediation, and which accepted differences are intentional product decisions.

The first 30 days after launch should operate as a controlled observation and triage period. The migration owner needs a single exception queue fed by Search Console, live crawls, analytics, server or redirect evidence where available, and the approved migration map.

Do not treat every fluctuation as a defect. Instead, define action triggers around behaviours that contradict the plan: priority URLs returning unexpected 404 responses, destination pages carrying wrong canonicals or noindex directives, source redirects resolving somewhere other than the mapped target, important page groups becoming materially deeper, or sustained loss of impressions concentrated in a specific migration cohort.

Search Console data can show whether old and new URL groups are being discovered and surfaced, while analytics helps identify where commercial traffic changed. A live crawl within 48 hours should verify production output against staging acceptance criteria and the pre-migration baseline.

Subsequent reviews should group issues by cause. If many pages share the same wrong canonical, fix the template. If one redirect rule creates the wrong destination pattern, fix the rule. If only retired content disappears, confirm that this matches the approved disposition rather than treating the decline as unexpected.

The goal is to shorten the distance between evidence and ownership. Every exception should have a source URL or page group, expected behaviour, actual behaviour, severity, owner, and resolution status. That turns post-launch monitoring into a decision system instead of a dashboard-watching exercise.

A platform migration changes the software that generates search-facing output, so the main risk is systemic rather than page-by-page. Compare what each template produced before the move with what the new CMS will produce after it.

That includes canonicals, title construction, robots directives, breadcrumb markup, pagination behaviour, sitemap inclusion, internal navigation, image handling, and structured data. A difference may be intentional, but it should never be accidental.

E-commerce templates require particular attention because product, category, filter, variant, and discontinued-item behaviour can be generated centrally by the platform. Content-heavy sites have similar exposure in category, tag, author, and archive templates.

When the old archive path contains /page/2 and the new archive path uses ?page=2, the migration is not merely a cosmetic CMS change; it has altered historical URLs and requires explicit mapping decisions.

Content field transfer is another common failure point. Metadata stored in custom fields on the old platform may not populate the equivalent fields in the new CMS, leaving pages with fallback values after launch.

The owner for each template should therefore approve both visible content and SEO output. The acceptance artifact is a template matrix showing current behaviour, intended new behaviour, field source, redirect implications, and test result. This keeps broad platform defaults from silently overriding page-level intent.

A domain migration changes the address through which search engines and external sites reference the business, so sequencing and traceability matter more than trying to make every other change at the same time.

Begin with the old-domain inventory and backlink evidence. Identify which historical URLs have a legitimate new-domain equivalent and implement a direct 301 relationship for those pairs. High-value external links should be reviewed separately because a direct update at the referring source, when realistically obtainable, removes dependence on the redirect for future visits and crawling.

Verify both properties in Search Console before the move. Once production redirects are working as intended, use the Change of Address process where it applies to the domain migration. Avoid combining the domain switch with unnecessary taxonomy, content, design, and information-architecture changes if those can be sequenced separately; fewer simultaneous variables make diagnosis easier.

Keep the old domain under your control and continue monitoring it because external references and crawler requests may persist. The domain migration record should connect old URL, new URL, redirect status, external-link priority, indexation observation, and owner.

That lets the team distinguish a broken transfer path from a broader reprocessing period. Recovery should be evaluated by cohorts and by the new domain's ability to surface the intended successor pages, not by a single domain-level metric.