A site migration is one of the highest-risk events in SEO, and schema markup is consistently the most overlooked part of the migration checklist. Redirects get mapped. Meta tags get transferred. Canonical URLs get reviewed. Schema markup gets forgotten until Search Console starts showing a surge of rich result errors two or three weeks after launch. Here is how to prevent that from being your experience.

Why Migrations Break Schema

Schema markup breaks during migrations for predictable, preventable reasons:

  • The new theme or CMS template does not include the old schema output
  • Absolute URLs in @id values are hardcoded to the old domain or URL structure
  • Plugin-based schema (Yoast, Rank Math, etc.) does not migrate settings automatically to the new platform — a particular concern for healthcare and regulated-industry sites where schema types are tightly specified
  • Content type changes during the redesign — a blog post page becomes a product page — make existing schema types incorrect
  • URL structure changes break sameAs references, breadcrumb item paths, and isPartOf links that were valid before
  • The canonical URL changes but the url property in the schema block still points to the old URL structure
  • JavaScript rendering changes cause markup that was previously in the initial HTML to load conditionally, making it invisible to Googlebot’s first crawl pass

Any one of these is enough to strip rich results from pages that had them. A full platform migration can trigger all of them simultaneously across every page on the site.

Pre-Migration: Audit What You Have

Before touching a single file on the new build, run a complete schema audit of the existing site. The goal is a documented inventory — not a quick scan, but a thorough record of:

  • Every schema type in use, mapped to the page templates that render them
  • All @id values and the URL patterns they follow
  • All sameAs external references, per entity type
  • Which pages currently produce rich results, pulled from the Search Console Enhancements report
  • Which pages have schema errors pre-migration — these are items to fix during the rebuild, not carry forward

Screaming Frog’s ‘Custom Extraction’ feature can crawl the existing site and export all JSON-LD blocks to a CSV. This gives you the before-state to compare against the post-migration output. Do this before the migration starts, and keep the export as a reference document throughout the build process. It is the standard I follow on every migration-scope engagement at Salterra.

The URL Change Problem

URL changes are the largest single source of post-migration schema breakage. Every absolute URL in structured data needs to update when URLs change. That means:

  • @id values on every entity — these are identity anchors, not just links; a broken @id creates a new, disconnected entity rather than updating the existing one
  • url properties on WebPage, Article, Product, and other entities
  • isPartOf references back to the WebSite entity
  • Breadcrumb item URLs in BreadcrumbList
  • Image URLs in ImageObject entities
  • contentUrl in AudioObject and VideoObject entities — including podcast episode entities

Template-driven markup updates all pages when the template changes. Hand-coded, page-level markup requires page-by-page intervention. This is one of the strongest arguments for template-driven JSON-LD as an architectural decision — migration resilience alone justifies it before any other consideration.

Domain Migrations

A domain migration — moving from one domain to another, not just restructuring URLs — has additional entity considerations beyond standard redirects and URL updates:

  • Update all @id values to use the new domain; the old-domain @id references a different entity in Google’s graph
  • Update any sameAs entries that point back to the old domain
  • Update external sources — Wikidata, Wikipedia, social profile ‘website’ fields — that reference the old domain as a sameAs target; this takes time and cannot all be done simultaneously, but start with the highest-priority sources
  • If the Organization or Person entity had a Knowledge Panel tied to the old domain, expect the panel to go dark during the transition period; consistent sameAs references across the new site pointing to the same external anchors help re-establish it faster

CMS and Plugin Migrations

Moving from one CMS to another — WordPress to Webflow, Drupal to WordPress, any combination — typically means moving from one schema plugin ecosystem to a different one. Schema plugin settings do not transfer. Document the current plugin configuration in detail before migration: every custom schema type configured, every page-specific override, every field mapping from post metadata to schema properties. This documentation becomes the specification the new implementation is built against.

Migrations are also a forcing function for platform evaluation. Some platforms constrain schema implementation in ways that were not visible before the migration decision was made. If the new platform’s schema options are more limited than the old one, this is the time to invest in custom JSON-LD output via a theme hook or custom plugin rather than accepting the constraints as permanent. The cost of that customization is far smaller than the ongoing cost of suboptimal markup.

Post-Migration Validation Protocol

Run the full validation stack on the new site immediately after launch — not after a week, not after confirming other things look okay, but as part of the launch day checklist:

  1. Spot-check 5-10 representative pages with the Rich Results Test: homepage, a service or category page, a content article, an author page, and a contact page
  2. Run the Schema.org validator on the same pages to catch type-level errors
  3. Submit the sitemap to Search Console and set a calendar reminder to check the Enhancements report at the 2-week and 4-week marks
  4. Compare the post-migration Enhancements report against your pre-migration baseline export
  5. Any error type that appears post-migration but was not in the pre-migration baseline is a migration regression — investigate it as a template issue, not a one-off page problem

Catching a template-level error in week one is a one-line fix. Catching it in month three, after it has compounded into hundreds of suppressed rich results and months of lost CTR, is a recovery project. The full validation process is documented in the schema markup validation guide.

Schema as a Migration Success Criterion

The best migrations treat schema validation as a named go/no-go criterion alongside mobile usability, page speed, and redirect coverage. ‘Schema markup validated on new platform’ belongs on the launch checklist alongside ‘XML sitemap submitted’ and ‘301 redirects verified.’ If your agency’s migration checklist does not include it, add it before the next migration starts.

For sites planning a migration and wanting structured data continuity built into the process from the start — not retrofitted after the fact — my schema markup consulting work includes pre-migration audits and post-launch validation as standard deliverables. The investment is far smaller than the recovery effort when markup breaks at scale.