Do structured data really need to match the visible content on the page?

Why does Google enforce the alignment between markup and content?

Google aims to eliminate the abuse of structured data that pollutes search results. For years, some sites have exploited loopholes: review markup on pages with no reviews, fake breadcrumbs, nonexistent prices.

Google's position is clear: structured data must reflect what users actually see. If your category page displays an average of aggregated reviews but contains no visible individual reviews, you cannot markup those reviews in schema.org. The engine wants absolute consistency between the code and the interface.

What constitutes a "correct and appropriate" implementation?

A correct implementation adheres to validated schema.org syntax: well-formed JSON-LD, updated vocabulary, relevant entity types. An appropriate implementation goes further: it corresponds to the context of the page.

For example, if you sell running shoes, your product sheet displays the price, availability, and visible customer reviews with ratings and comments. You can markup Product, AggregateRating, Review, Offer without issues. However, your "Running Shoes" category page lists 50 products with images and titles but no detailed reviews. Marking up Review here would be inappropriate, even if the JSON-LD is technically valid.

Does this requirement apply to all types of structured data?

Google makes no exceptions by schema type. Articles, products, recipes, events, FAQs, breadcrumbs: all must correspond to the visible content. FAQ schema has been particularly scrutinized due to massive abuses observed on pages without a real FAQ section.

Some practitioners think that breadcrumbs or Organization schema escape this rule because they represent the site's structure. This is false. A breadcrumb markup must reflect the visible breadcrumb trail at the top of the page. If your HTML breadcrumb displays "Home > Clothing > T-shirts", your JSON-LD must precisely reproduce this hierarchy, not a imagined or optimized version.

• Strict alignment: each schema.org property must have a visible match on the page
• Technical validation is insufficient: markup without syntax errors can still violate the guidelines if the content does not match
• Risk of manual penalty: repeated structured data abuses can trigger a manual action, not just a loss of rich snippets
• Page context is key: the same property can be appropriate on one page and inappropriate on another on the same site
• No tolerance for reviews: this is the type of markup most monitored by Google's Quality Raters teams

Is this statement consistent with practices observed in the field?

Absolutely. For several years, there have been reports of massive losses of rich snippets on technically sound sites practicing opportunistic markup. E-commerce sites with AggregateRating on category pages have seen their stars disappear overnight, without any manual action notified in Search Console.

The pattern is consistent: Google tests the content-markup alignment in an automated way. If the algorithm detects a mismatch—missing reviews on the page but present in JSON-LD, markup price differing from the displayed price—it removes the rich display. Sometimes immediately, sometimes after a few weeks. Tolerance has become almost nonexistent.

What gray areas remain in this rule?

Calculated or aggregated structured data poses problems. Imagine a category page displaying "Average rating 4.5/5 based on 2,847 reviews" with a link to detailed reviews for each product. Can we markup an AggregateRating here? Google says no because individual reviews are not visible. Yet some sites retain their SERP stars with this setup. [To be verified] depending on verticals and how the aggregation is presented.

Another gray area: FAQ schema on pages with closed accordions. The content exists in the DOM, accessible with a click, but not immediately visible. Google has validated this case in some official examples, yet some sites lose their rich FAQs with exactly this structure. The consistency of applying the rule remains opaque.

In what cases does this rule not really apply?

Let's be honest: it always applies, but enforcement varies. Large sites with significant authority sometimes retain borderline markups that less established sites would be denied. There are also differences by language and market: the same markup can work on .com and fail on .fr.

Technical structured data—Organization, WebSite, SiteNavigationElement—enjoy greater tolerance because they structure the site rather than promise visible enriched content. However, even there, a glaring inconsistency (SearchAction markup without a visible search field) will eventually cause issues.

What should be prioritized for auditing an existing site?

Start with a complete crawl including JSON-LD extraction on all your strategic pages. Screaming Frog, OnCrawl, Botify: all allow the extraction of structured data. Export them, and then manually compare a sample of 20-30 representative pages.

Specifically check: category pages with Product or Review markup while they only show listings, blog pages with Article schema but no actual editorial content, JSON-LD breadcrumbs that do not match the HTML breadcrumb trail. Prioritize pages that generate SEO traffic: losing rich snippets on a strategic landing page directly impacts the CTR.

How to correct discrepancies between markup and content?

Two possible approaches. First option: remove inappropriate markup. If your category page does not display detailed reviews, remove AggregateRating and Review. You may lose stars in SERP, but you will avoid the risk of a manual penalty and a future drastic loss.

Second option: adapt the visible content to justify the markup. Add a "Customer Reviews" section on your category pages with 3-5 real detailed reviews. Effectively display the average rating and the number of reviews. Integrate a real HTML breadcrumb if you want to markup breadcrumbs. This approach often improves both UX and conversion in parallel.

What tools can be used to validate content-markup compliance?

The Rich Results Test from Google validates syntax but does not detect content-markup discrepancies. A human or semi-automated check is required. Create a QA process where each template with structured data is manually checked before deployment.

Some tools like Schema App or custom scripts enable cross-checking the extracted HTML content with JSON-LD properties. For example, if your JSON-LD declares a price of €49.99, a script can verify that an HTML tag indeed contains that price using a regex. Automate these checks in your deployment pipeline.

• Crawl the entire site and extract all structured data by page type
• Manually compare a representative sample of each template: does the markup match the visible content?
• Remove or condition inappropriate markups (reviews on categories, nonexistent FAQs, absent prices)
• Add visible content if the markup is strategic: reviews section, HTML breadcrumb, clearly displayed prices
• Validate each modification with Rich Results Test AND manual verification of the rendered page
• Monitor the evolution of rich snippets in SERPs with a compatible rank tracking tool (SEMrush, Ahrefs, Sistrix)