Website Replatforming Risk Register

Purpose

Use this risk register to turn replatforming concerns into owned delivery items. Each row should make the risk explicit, show how it would be detected, identify who owns it, define the evidence needed before launch and record what should be monitored afterwards.

Who This Is For

• Technical leads planning a React, Next.js or headless CMS replatform.
• Technical SEO consultants responsible for migration risk and launch protection.
• Product, content and agency teams that need a shared view of what could fail at launch.

When to Use This

• Before a platform decision is locked.
• During discovery, content modelling and redirect planning.
• At launch readiness review, before DNS, routing or deployment changes go live.
• During the first post‑launch monitoring window.

How to Use This Resource

Treat each row as a working risk item, not as a passive checklist line. Confirm the failure mode, assign an owner, collect evidence, define a launch gate and decide what will be monitored after release.

Risk Register

The register is designed to be worked through in planning meetings, not read as a static checklist. Each risk should either be assigned, evidenced and controlled, or explicitly accepted before the launch plan is treated as safe.

URL and Redirect Integrity

• Failure mode: Legacy URLs are not mapped to stable destination URLs, or redirects are added at the wrong layer of the Next.js stack.
• Warning sign: Redirect rules are incomplete, chained, temporary, case‑sensitive where they should not be, or owned by no single person.
• Impact: Loss of equity, crawl waste, broken backlinks, lost conversions and avoidable support noise.
• Owner: Technical SEO lead with engineering support.
• Evidence required: A source URL export, destination mapping, status‑code test results, chain checks and exception log.
• Launch gate: Critical legacy URLs return the intended final 200 page through one permanent redirect or a documented exception.
• Post‑launch monitoring: Track 404s, redirect chains, server logs, Search Console crawl errors and high‑value referral URLs.

Rendered HTML and Crawlability

• Failure mode: The new React or Next.js templates rely on client‑side rendering for search‑critical content, links or metadata.
• Warning sign: View‑source output, fetched HTML or crawler captures lack headings, body copy, product data, internal links or canonical metadata.
• Impact: Crawlers may discover weaker pages than users see, making ranking, indexing and AI retrieval less reliable.
• Owner: Front‑end lead and technical SEO lead.
• Evidence required: Rendered HTML comparisons from old and new templates, crawler output and server‑rendered page checks.
• Launch gate: Search‑critical content, links, metadata and schema are present in crawler‑visible HTML before hydration.
• Post‑launch monitoring: Compare fetched HTML, rendered DOM, index coverage and crawl behaviour across priority templates.

Metadata and Canonical Signals

• Failure mode: Titles, descriptions, canonical URLs, Open Graph data or hreflang equivalents are lost, duplicated or normalised incorrectly.
• Warning sign: New templates generate default metadata, self‑canonicals are missing, or canonical URLs point to staging, querystring or old‑domain variants.
• Impact: Search engines receive weaker page identity signals and may consolidate or display the wrong pages.
• Owner: Technical SEO lead, content model owner and front‑end lead.
• Evidence required: Template‑level metadata inventory, old and new crawl comparison and canonical validation for key routes.
• Launch gate: Priority pages preserve or deliberately improve titles, descriptions and canonical signals.
• Post‑launch monitoring: Monitor title rewrites, canonical selections, duplicate clusters and unexpected indexed URL variants.

Structured Data and Schema Parity

• Failure mode: Schema exists on old templates but is missing, weaker, invalid or unsupported on the new platform.
• Warning sign: JSON‑LD generation is not linked to CMS fields, visible evidence is absent, or validation is left until after launch.
• Impact: Entity clarity, eligibility for supported rich result features and machine‑readable page context can degrade.
• Owner: Technical SEO lead and front‑end lead.
• Evidence required: Old and new JSON‑LD capture, visible‑content mapping, Rich Results Test checks and Schema Markup Validator checks.
• Launch gate: Structured data is valid, specific, visible‑content backed and mapped from reliable CMS fields.
• Post‑launch monitoring: Watch Search Console enhancement reports, validation errors and schema drift on edited content.

CMS Content Model Gaps

• Failure mode: The headless CMS lacks fields for metadata, schema, canonical controls, summaries, image alternatives or launch‑critical editorial states.
• Warning sign: Editors need developer tickets for routine SEO controls, or fields are hidden inside generic rich text.
• Impact: Search‑critical content becomes inconsistent, slow to fix and difficult to govern after launch.
• Owner: Content architect, technical SEO lead and CMS developer.
• Evidence required: Content model review, field mapping, editorial workflow test and sample entries for each page type.
• Launch gate: Editors can manage the agreed controls with validation, sensible defaults and preview support.
• Post‑launch monitoring: Review changed entries, missing‑field reports, preview failures and metadata fallback usage.

Internal Linking

• Failure mode: Navigation, breadcrumbs, related content and contextual links change without preserving topic relationships or crawl paths.
• Warning sign: Priority pages become deeper, repeated anchors point to different intents, or old contextual links are dropped during template migration.
• Impact: Important pages lose crawl support, topical context and user paths to commercial pages.
• Owner: Technical SEO lead, content lead and front‑end lead.
• Evidence required: Old and new internal link crawl, navigation map and priority‑page link comparison.
• Launch gate: Important service, resource, article and case‑study routes remain discoverable through meaningful links.
• Post‑launch monitoring: Track orphaned pages, crawl depth changes, broken internal links and anchor text drift.

XML Sitemaps and Robots Rules

• Failure mode: Sitemaps omit new routes, include invalid legacy routes or conflict with robots directives.
• Warning sign: Generated sitemap data is not updated after CMS changes, or robots rules are copied from staging.
• Impact: Search engines may miss important pages or crawl pages that should stay private.
• Owner: Engineering lead and technical SEO lead.
• Evidence required: Generated sitemap output, robots.txt, valid route data and staging‑to‑production rule comparison.
• Launch gate: Sitemap and robots output match the launch route plan and environment.
• Post‑launch monitoring: Monitor submitted sitemap counts, blocked URLs, unexpected indexed pages and crawl stats.

Performance and Core Web Vitals

• Failure mode: The replatform improves architecture but introduces heavier JavaScript, layout instability, image regressions or slower server responses.
• Warning sign: New templates pass visual review but fail Lighthouse, field data risk checks or synthetic comparisons.
• Impact: User experience and search performance signals can weaken, especially on key landing pages.
• Owner: Front‑end lead and performance owner.
• Evidence required: Before‑and‑after Lighthouse runs, field‑data context, bundle analysis and image delivery checks.
• Launch gate: Known regressions are fixed or accepted with owners, scope and follow‑up dates.
• Post‑launch monitoring: Watch CrUX, Search Console Core Web Vitals, synthetic monitoring and conversion‑sensitive pages.

Analytics and Conversion Tracking

• Failure mode: Analytics, consent behaviour, enquiry tracking or conversion events change during the migration.
• Warning sign: Traffic appears to drop because tracking changed, or conversions disappear while form submissions still arrive.
• Impact: The team may misread launch impact and make poor recovery decisions.
• Owner: Analytics owner and engineering lead.
• Evidence required: Tracking plan, tag validation, consent checks, event comparison and test conversions.
• Launch gate: Core events and consent behaviour are verified in production‑like conditions.
• Post‑launch monitoring: Compare sessions, source attribution, conversions and event volumes against expected launch variance.

Editorial Preview and Publishing Workflows

• Failure mode: Editors cannot safely preview, schedule or validate entries before launch, especially with draft mode or cached content.
• Warning sign: Preview shows different content from production, draft state leaks, or published changes require manual cache clearing.
• Impact: Content fixes slow down when the launch team most needs control.
• Owner: CMS owner and front‑end lead.
• Evidence required: Preview workflow test, draft and published entry comparison, cache invalidation behaviour and editorial acceptance checks.
• Launch gate: Editors can preview and publish search‑critical changes without developer intervention.
• Post‑launch monitoring: Monitor failed previews, stale content, publishing delays and emergency edit requests.

Rollback and Post‑Launch Monitoring

• Failure mode: The team has no agreed rollback threshold, monitoring pack or route‑level evidence after launch.
• Warning sign: Launch notes focus on deployment success rather than search, content and conversion health.
• Impact: Small failures persist too long, and serious failures become harder to diagnose.
• Owner: Delivery lead, engineering lead and technical SEO lead.
• Evidence required: Monitoring dashboard, known‑risk log, escalation paths and rollback decision criteria.
• Launch gate: The launch plan includes owners, monitoring windows, rollback criteria and communication routes.
• Post‑launch monitoring: Review route health, Search Console signals, logs, analytics, redirects and conversion data at agreed intervals.

Common Failure Patterns

• Redirects are treated as an SEO task after engineering has already changed routing.
• Rendered HTML is checked in the browser but not compared from crawler‑visible output.
• Structured data exists on the old templates but is not mapped into the new CMS model.
• Preview and publishing workflows are approved visually without confirming canonical, robots, sitemap or schema behaviour.
• Launch monitoring starts after traffic has already dropped, rather than before the change window.