Schema Parity: Preserve Structured Data in Rebuilds

You launch your new site. Rankings hold. Traffic looks stable for the first two weeks. Then you notice product pages no longer show review stars, your service pages no longer display breadcrumb trails, or your article pages no longer expose clean author and date data. Clicks start dropping even though rankings barely moved, because your appearance and machine-readable context changed during the rebuild.

This is schema loss, and it is one of the most overlooked costs of a CMS migration. Structured data markup (the JSON-LD blocks, Microdata attributes, and RDFa annotations that power rich results) does not migrate automatically when you move from WordPress to Next.js. It lives in your theme, your plugins, your page templates. When those change, the schema changes with them, or disappears entirely.

Rebuilding schema parity is not just about recovering rich results for their own sake. It is about preserving the structured facts that search engines were already using to understand page type, authorship, products, breadcrumbs, reviews, and organization details. Supported rich result loss can reduce click-through rate even when the ranking position stays the same. Over a site with hundreds of pages, that loss compounds quickly.

This guide covers what schema markup does for search visibility, exactly why structured data disappears in CMS rebuilds, and the complete schema parity process (inventory, mapping, and validation) you need to preserve supported structured data through a migration. This post works alongside canonical tag parity and redirect mapping for migrations as part of a complete signal-preservation strategy.

The same signal-preservation work appears in the sample SEO Parity Audit, alongside URL, metadata, canonical, and redirect findings. For client proof, start with the case-study hub.

Quick Checklist

• Crawl your WordPress site and extract all structured data blocks (JSON-LD, Microdata)
• Create a schema inventory: which types exist, on which pages, with which properties
• Map each schema type to a corresponding Next.js template or layout component
• Validate every schema block with Google's Rich Results Test after implementation
• Compare Search Console's enhancement and rich result reports before and after migration
• Keep FAQ sections for users, but do not count FAQPage markup as a Google rich-result growth lever
• Monitor for "Unparsable structured data" errors in Search Console post-launch

What Schema Markup Does for Your Search Visibility

Structured data is machine-readable information embedded in a page's HTML that tells Google what the page is about, beyond what it can infer from crawling the text content. Schema markup uses a standardized vocabulary from Schema.org to describe entities: articles, products, reviews, events, FAQs, breadcrumbs, organizations, people, and many others.

When Google can reliably parse this structured data, it can use it for supported search features that go beyond the standard blue-link, description, and URL presentation. Depending on the page type and current Google support, those features can include breadcrumb trails, review star ratings, product details, article metadata, event date and location information, and other structured search appearances.

The SEO value of supported rich results is primarily a click-through rate effect. A result with eligible rich result features can occupy more visual space in the SERP, communicate more information at a glance, and receive a higher proportion of clicks than a plain result at the same ranking position.

Google's own guidance at Search Central makes clear that structured data does not guarantee rich results. Google decides whether to display them based on eligibility, quality, and feature support, but valid, accurate structured data is still the prerequisite for supported rich result formats.

Why Structured Data Gets Silently Dropped During Rebuilds

The schema on your WordPress site is almost certainly not in the content itself. It lives in one or more of these places:

SEO plugins. Yoast SEO, Rank Math, All in One SEO, and similar plugins generate JSON-LD blocks automatically based on page type, post type, and the SEO settings configured for each page. When you move to Next.js and stop using these plugins, all of the schema they were generating disappears. This includes Organization schema, WebSite schema, BreadcrumbList schema, and any post-type-specific schema the plugin generated.

Theme templates. Some WordPress themes embed Microdata or RDFa attributes directly in the HTML template markup. itemtype, itemprop, itemscope attributes on HTML elements. When the theme is replaced with a new Next.js layout, those attributes do not come with it.

Custom code in functions.php or custom plugins. Developers who customized schema output for specific page types (adding Review or AggregateRating schema to product pages, Event schema to event listings, or custom FAQPage schema to support pages) typically implement this in WordPress-specific custom code. This code does not transfer to Next.js.

The failure mode is always the same: the schema existed in infrastructure that was replaced, and no one explicitly documented what schema was running, on which pages, and with which properties before the rebuild started. Without that inventory, the new site has no specification to implement against.

The Schema Parity Process (Inventory → Map → Validate)

Schema parity requires three sequential phases. Skipping the inventory phase and trying to rebuild schema from memory or best guesses produces an incomplete result. The process is methodical by design.

Step 1. Inventory All Existing JSON-LD, Microdata, and RDFa

The goal of the inventory phase is to produce a complete, structured record of every schema block on the current WordPress site. What type it is, what page it appears on, and what properties it includes. This inventory step is part of the broader SEO-safe migration checklist that covers every signal to preserve.

Start by crawling your WordPress site with Screaming Frog. In the configuration, enable the structured data extraction feature. Screaming Frog can extract and log JSON-LD blocks from crawled pages. Run the full site crawl and export the structured data report. This gives you a page-level view of which pages have structured data and what type.

For JSON-LD specifically, you can also use a script to fetch and parse the raw HTML of every key page type, extracting the contents of each <script type="application/ld+json"> block. This gives you the full property-level detail, not just the type but the specific properties and values in each schema block.

For Microdata and RDFa, the crawler will flag pages that include itemtype, itemprop, or typeof attributes, but you may need to manually inspect the template markup to understand the full property structure.

Your inventory output should be a spreadsheet with at minimum these columns: Page URL, Page Template Type, Schema Type(s), Key Properties Present, and Notes. Group rows by template type (blog post, category page, homepage, product page, author page) because the migration mapping work in Step 2 is done at the template level.

Make sure your XML sitemap is also configured correctly so Google can discover and recrawl all pages with updated schema. Additionally, capture a baseline snapshot of your rich results and enhancement reports in Google Search Console before the migration. Navigate to Search Console's "Search Appearance" section and review the Enhancements reports. These show which supported rich result types are currently generating impressions and any errors in your current implementation. Export this data. It becomes the benchmark you compare against after migration.

Step 2. Map Schema to New Page Templates

With the inventory complete, you can now create a schema implementation plan for the new Next.js site. The unit of work here is the template, not the individual page. Implement schema correctly in each template and it covers every page rendered from that template.

For each template in the new site, identify what schema types were present on the corresponding pages in the WordPress site. Then determine how to implement that schema in Next.js.

In Next.js, the standard approach for JSON-LD is to render a <Script type="application/ld+json"> element in the <head> via the layout or page component. The schema object is constructed in the page or component file and serialized to the script tag. This gives you server-side rendering of the schema in the initial HTML response, which is what Googlebot reads.

Some schema types are straightforward to map to templates:

• Article / BlogPosting. Maps to the blog post template. Properties to include: headline, description, author (with @type: Person, name, and optionally url), datePublished, dateModified, publisher (with @type: Organization, name, and logo), and image.

• BreadcrumbList. Maps to any template that displays a breadcrumb navigation UI. Properties: ordered ListItem objects with position, name, and item (URL).

• FAQPage. Maps only to templates or pages that include a visible structured FAQ section. Properties: mainEntity array of Question objects, each with name and acceptedAnswer. Keep it accurate when the page genuinely has FAQs, but do not treat it as a current Google rich-result lever.

• Organization / WebSite. Typically placed on the homepage layout. Properties for Organization: name, url, logo, sameAs (social profile URLs). WebSite schema enables the sitelinks search box in Google results.

For each schema type in your inventory, document the Next.js component or layout file where it will be implemented, the data source for each property (CMS field, static value, or derived from page metadata), and the team member responsible for implementing it.

Step 3. Validate with Google's Rich Results Test + Search Console

After implementing schema in the new templates, validate every schema block before launching to production. The two primary validation tools are Google's Rich Results Test and Search Console's Enhancements reports.

The Rich Results Test accepts either a URL (for live or staged URLs accessible to Google's servers) or raw HTML. Paste the full HTML of a representative page from each template type and confirm: supported schema types are detected, required properties are present, and there are no errors or warnings. Use Schema.org validation as a second check for schema types that Google no longer tests as rich result features.

Pay attention to the distinction between errors and warnings. Errors are properties that are required by Google's rich result schema spec but missing from your implementation, these will prevent the rich result from appearing. Warnings indicate recommended properties that are absent, these will not block the rich result but may reduce its completeness or prominence.

For staging validation, configure your crawler to fetch pages from your staging environment and extract structured data, then compare the output against your inventory from Step 1. Every schema type in the inventory should appear in the staging crawl output, with the same or equivalent properties.

After launch, monitor Search Console's Enhancements reports for four to six weeks. Look for: stable valid counts on supported enhancement types, decreases in errors compared to the pre-migration baseline, and any new "Unparsable structured data" warnings that indicate malformed JSON-LD in the new templates.

Schema Types Most at Risk During WordPress Migrations

Not all schema types are equally likely to survive a migration intact. These are the types most commonly lost when moving from WordPress to a headless or custom Next.js implementation.

Organization and WebSite schema. These are almost always generated by Yoast or Rank Math based on the site's global SEO settings. Business name, logo, social profiles. They are set once and forgotten. When the plugin is removed, they disappear with it. Since these appear on the homepage and potentially across the entire site in the sitewide schema graph, losing them affects sitewide rich result eligibility.

BreadcrumbList schema. Breadcrumb schema is typically generated by WordPress themes or plugins based on the site's navigation hierarchy. Next.js layouts do not generate this automatically. It must be explicitly implemented in the layout component for templates that display breadcrumb navigation.

FAQPage schema. FAQ sections are still useful for users, support teams, and internal links, but FAQPage markup is no longer a current Google rich-result growth lever. Google announced that FAQ rich results were limited in 2023 and then stopped appearing in Search as of May 7, 2026. Preserve FAQ content when it clarifies the page and keep the schema accurate if you use it, but do not forecast FAQ snippet traffic as a migration win.

Review and AggregateRating schema. For sites with user reviews or product ratings, this schema drives star ratings in search results. It is almost never automatically carried over in a migration. It requires integration with the review data source and explicit schema generation in the product or service page template.

Article / BlogPosting schema. While this is perhaps the most commonly implemented schema type, it is also commonly implemented incorrectly after migration. Missing the dateModified property, using a placeholder author value, or omitting the publisher organization block that Google requires for this schema type to be fully valid.

FAQ

Does structured data directly affect rankings?

Structured data does not directly boost ranking positions in Google's algorithm. It is not a traditional ranking signal in the way that links or content relevance are. Its primary effect is on machine-readable clarity and, for supported schema types, search appearance. Supported rich result formats can affect click-through rate, and CTR affects the volume of traffic a ranked page receives.

How do I extract structured data from my WordPress site?

The most comprehensive method is to crawl the site with Screaming Frog with the structured data extraction setting enabled, which captures JSON-LD blocks from every crawled page. For a complete property-level inventory, supplement the crawl with a script that fetches the HTML of representative pages for each template type and parses the JSON-LD script tags. For Microdata and RDFa, inspect the raw HTML of your theme templates directly in the WordPress file editor or via FTP/SSH access to the server.

Which schema types are most important to preserve during migration?

Prioritize schema types that are currently generating active supported rich results in Search Console. These are the types producing a measurable CTR benefit that you can lose if they disappear. After that, prioritize Organization and WebSite schema for sitewide entity clarity, Article/BlogPosting schema for content sites, BreadcrumbList for navigation context, and Review or AggregateRating schema where the review source is compliant and visible. Keep FAQPage only where the visible page has real FAQ content; treat it as clarity and parity, not as a Google rich-result growth lever.

Can WordPress plugins like Yoast export schema for use in Next.js?

Yoast and Rank Math do not have export utilities that produce portable schema configurations for use in other platforms. However, you can use Yoast's schema graph output as documentation. Visit any page on your WordPress site, view the source, and copy the JSON-LD script block. This gives you the exact schema structure Yoast was generating, which you can then use as a template to reimplement in Next.js. The schema structure itself is platform-agnostic; only the generation mechanism needs to change.

What happens if my structured data has errors after migration?

Errors in structured data (missing required properties, malformed JSON, incorrect data types) prevent Google from generating the corresponding rich results. Google does not penalize pages for having invalid structured data (it simply ignores it), but it will not generate rich results for invalid schema. Errors are reported in Search Console's Enhancements reports with specific descriptions of what is missing or malformed, which allows you to diagnose and fix them systematically. The key is monitoring Search Console consistently in the weeks after launch rather than assuming the schema implementation is correct.

Next Steps

Schema parity is the last line of signal preservation in a CMS migration. After redirects carry authority from old URLs to new ones, and after canonical tags consolidate the correct URLs for indexing, structured data is what determines whether your pages appear in search with the same visual presence and click appeal they had before the rebuild. Losing it is invisible until click rates start declining.

Related posts:

• Redirect mapping for migrations
• Canonical tag parity

Services:

• SEO-safe WordPress → Next.js migration
• SEO Parity Audit