CMS migration SEO requirements: what to specify before the build

Separate the platform move from every other change

Record whether the project changes the CMS only, or also changes URLs, domains, templates, navigation, content, rendering or analytics. A CMS swap with stable output has a different risk profile from a rebuild that changes all of these at once. Where practical, sequence major changes so a later problem has fewer possible causes.

Make an inventory of current URL patterns, page types, language variants, structured data, indexation rules, redirects and editorial exceptions. Include pages generated by filters or taxonomy, not just the pages visible in the main navigation. The inventory becomes the set of behaviours the new platform must reproduce or intentionally change.

Write requirements around the published page

Editors need controls, but crawlers and visitors see the output. Specify expected status codes, canonical URLs, headings, primary text, link markup, meta titles and descriptions, structured data, robots directives, sitemaps and international annotations where relevant. Identify which fields are editorial, which are derived and which are fixed at template level.

For example, “the CMS has an SEO field” is not an acceptance criterion. “An editor can set a canonical URL for a product variant, and the rendered HTML contains exactly one canonical pointing to the approved destination” is testable. Use representative real URLs and awkward edge cases in the brief.

• Can editors change slugs without silently breaking old links?
• Are internal links stored as references that can follow a page move, or as hard-coded URLs that need auditing?
• Can a page be unpublished without creating an irrelevant redirect or a soft 404?
• Do pagination, filters, search results and empty taxonomies behave as agreed?
• Can the team inspect the final rendered HTML, not only a visual preview?

Protect the content model, not just the copy

A legacy page may combine product specifications, comparison detail, FAQs and a conversion route. A new component system can scatter or remove those elements while preserving the headline. Map the purpose and essential evidence of each valuable template before content is imported.

Define how images, captions, downloadable documents, author information and related-content links are migrated. Decide what to retain, rewrite, merge or retire. This is editorial judgement, not a bulk import setting. Keep a record of pages whose search purpose will change so post-launch movement can be interpreted.

Prove URL and redirect behaviour before release

If URLs change, create an old-to-new map using crawl data, analytics, Search Console and the CMS inventory. Map each useful old URL to a genuinely relevant destination. Test parameter variants, case, trailing slash, subdomains and files. Redirect rules need an owner and a repeatable validation method; a spreadsheet alone does not make them work.

Google recommends preparing a URL mapping and testing the new site before a move. Its guidance also treats a move as a per-URL process, so do not expect one launch-day check to prove the migration is finished. Keep old properties and redirect infrastructure available for monitoring.

Use template-level acceptance tests

Build a staging sample with an important page, an ordinary page and an edge case for each template. Crawl it and compare rendered output with the agreed specification. Check the homepage too, but do not let it stand in for the whole site. Test the links and content that a user sees only after interaction.

The final test pack should show each check, the expected result, the actual evidence, an owner and a severity. A sitewide noindex directive, missing canonical logic or inaccessible navigation is a release blocker. A minor metadata issue on a retired page may be fixable later. Agree that threshold before the launch window.

Handover an operating standard

After launch, monitor indexation, crawl errors, landing pages and conversions by template and URL group. Separate technical leading indicators from search outcomes that take longer to settle. Keep a decision log of deliberate content and architecture changes so that later changes are not misdiagnosed as platform faults.

The migration is not complete when the new CMS can publish. It is complete when the team can safely create, change and retire pages without recreating the same search problems. Give editors examples, approval rules and an escalation path for unusual pages.