Putting SEO governance around a high-risk website migration

A migration is a chain of decisions, not a launch-day checklist

Large redesigns and CMS changes touch architecture, rendering, templates, content, analytics and infrastructure at the same time. SEO risk often appears between teams: everybody completes their own task, but no one owns the behaviour of the whole system.

My role was to make that risk visible early and give delivery teams controls they could actually use across Umbraco, Drupal and custom platforms.

I joined the work before the new site became difficult to change

I established the baseline, reviewed architecture and prototypes, defined redirect and canonical requirements, and tested representative templates in staging. Requirements were written for the people implementing them, with examples, acceptance criteria and named owners.

• Priority URL and template baselines
• Redirect mapping and edge-case testing
• Rendered-content, metadata and structured-data QA
• Launch controls, monitoring and issue triage

The baseline was organised around what could actually break

Rather than export one enormous list of URLs and hope for the best, I grouped the estate by template, purpose, organic contribution and migration behaviour. Priority examples became test cases for content, metadata, canonicalisation, internal linking, structured data, rendering and analytics.

That gave the team a practical comparison set. If an issue appeared after launch, we could determine whether it affected one page, one template or the implementation rule behind thousands of URLs.

The difficult work was making trade-offs visible before launch

Design, content and engineering decisions often had legitimate reasons behind them. My job was not to stop change; it was to explain the search consequence clearly enough for the team to choose deliberately. When a requirement created risk, I offered a test, an alternative or an acceptance criterion rather than a generic warning.

A decision log captured what would change, who had approved it and how it would be checked. That reduced circular conversations and made launch readiness a shared delivery question instead of an SEO sign-off at the end.

Governance made the strategy durable

Playbooks, QA reports and joined-up working sessions created a shared view of what had to remain stable and what was intentionally changing. That gave developers clearer specifications and gave stakeholders a way to make trade-offs without relying on vague SEO warnings.

After launch, the same baseline and page groups were used to check what actually shipped, identify unexpected behaviour quickly and distinguish temporary movement from implementation faults.

Launch day was a controlled handover, not the end of the project

Checks were ordered by impact and dependency: availability, status codes, redirects, crawl controls, canonicals, priority content, analytics and then broader template coverage. Issues were recorded with evidence, severity and ownership so the team could fix the most consequential problems first.

Post-launch monitoring compared new behaviour with the agreed baseline. This made it easier to recognise normal reprocessing, isolate implementation faults and resist the temptation to undo unrelated work because one aggregate graph moved.

The value was control over uncertainty

The programme reduced avoidable risk and made post-launch diagnosis faster. More importantly, it left the delivery team with a repeatable migration method rather than a one-off audit that disappeared after launch.

The lesson is to make SEO part of delivery governance

The best migration work happens before a crawler reaches the new site. When requirements, representative tests and owners are agreed early, SEO becomes one of the ways the programme defines quality rather than a late list of defects.

The reusable asset is not the checklist itself. It is the habit of connecting every material risk to an example, a responsible team, a test and a decision.