Schema Markup Migration Checklist (Site Redesign / CMS Migration)

A site redesign or CMS migration is one of the highest-risk events for structured data specifically, and it's rarely treated with the same rigor as URL redirects or content migration. Schema has no visible fallback — a template rebuild can silently drop, corrupt, or disconnect JSON-LD without a single visible rendering issue, which means a migration can look completely successful in QA while quietly destroying months of entity-disambiguation work. This is the checklist that keeps that risk to a minimum.

Before touching anything, document what schema currently exists and where. Crawl the live site and extract every JSON-LD block, noting which schema types appear on which templates, which entities carry an @id, and which sameAs arrays, author references, and publisher references exist. This becomes the baseline you're migrating against — without it, there's no way to confirm the new site preserves what the old one had, only a vague sense that "schema is probably fine."

Pay specific attention to the entity graph itself: which Organization and Person @id values exist, and everywhere they're referenced from. This is the part most migrations lose without anyone noticing, because a template rebuild naturally focuses on visible content and layout, not on preserving an invisible cross-referencing structure between JSON-LD blocks.

For every template being rebuilt, explicitly map which schema type(s) it needs to carry, and confirm the new template's data layer actually has access to every field required — headline, author, publisher, dateModified, and the rest, per the Article schema guide in this series. A common migration failure: a new template renders visually correctly using a subset of the old CMS fields, while fields the old schema relied on (a structured author reference, a specific image field) get dropped from the new content model entirely, silently removing the ability to populate that schema property no matter how carefully the template code is written afterward.

Preserve @id values exactly during migration — the same URL fragments (https://example.com/#organization, https://example.com/#person) should carry over to the new site rather than being regenerated, since a changed @id breaks the effective continuity of the entity even if the schema itself is otherwise identical. This matters most when a migration also changes the domain or URL structure; plan @id continuity as a deliberate migration decision, not an incidental side effect of however the new templates happen to generate identifiers.

Before launch, run every representative template through the Schema.org validator and Google's Rich Results Test on staging, not just a visual QA pass. Compare staging output directly against the pre-migration audit from Phase 1 — same schema types present, same @id values, same sameAs arrays, same entity connections. This is also the point to confirm structured data survives correctly if the new site changes rendering strategy — a migration to a JS-heavy framework introduces the client-side-rendering risks covered in the dedicated JS-rendered-sites article in this series, and staging is where that needs to be caught, not production.

If the migration involves a URL structure change, confirm mainEntityOfPage and any self-referential canonical-adjacent schema properties point at the new URLs, not stale references to the old structure — this is a detail easy to miss when redirects handle the visible canonical tag correctly but schema-level URL references are generated from a different, unpatched code path.

Immediately after launch, spot-check a representative sample of pages across every template type with Rich Results Test and the Schema.org validator, the same way covered in the testing-tools article in this series. Don't rely solely on the staging validation from Phase 3 — production data, real content, and real CDN or caching behavior can surface issues staging didn't, particularly around timing-sensitive JS-rendered schema.

Google Search Console's structured data reports will reflect the migration's actual impact over the following days and weeks as Google recrawls the site, per the timelines covered in the how-long-to-see-results article in this series. Monitor this closely for the first month post-migration specifically — a coverage drop or new class of error appearing here is the clearest signal that something in the migration broke schema at scale, even if every page you spot-checked manually looked fine.

Disconnected entities — a Person or Organization schema that existed as an @id reference pre-migration reappears post-migration as a disconnected inline object, or disappears from certain templates entirely, because the new template's author/publisher rendering logic was rebuilt without preserving the reference pattern. Missing articleBody or wordCount — these fields require pulling actual content into the schema, and a new template that renders content differently (a different CMS field, a different content-block structure) can lose this without anyone noticing since it doesn't affect the visible page. Broken sameAs arrays — URLs hardcoded in the old template that never got migrated to the new content model, silently vanishing rather than throwing an error. And subtype regressions — a specific ProfessionalService or BlogPosting type quietly reverting to generic Organization or Article because the new template's type-selection logic wasn't rebuilt with the same specificity as the old one.

The underlying pattern across all of this: structured data needs to be an explicit, tracked deliverable in a migration project plan — with its own audit, its own mapping, its own staging validation, and its own post-launch monitoring — rather than an assumed side effect of "the new site looks right." Every other category of technical SEO work (redirects, canonical tags, sitemap accuracy) gets this treatment during a migration as standard practice; schema markup deserves the same discipline, precisely because its failures are invisible until someone deliberately checks for them.