Schema Debugger Example: Article, Product, BreadcrumbList

The report identifies the missing aggregateRating and shows you the JSON to add. Stop before you paste it. There is one condition, it is absolute, and getting it wrong is the most expensive mistake available in structured data:

So the correct sequence is the reverse of the one the report implies. Collect the reviews first. Display them on the page. Then mark up the aggregate you are already showing. Schema describes a page; it does not create facts about it.

The same applies to brand and description: fill them with what is true. If this product page has no reviews, the honest state of the markup is one without an aggregateRating — and a Product block scoring 62/100 with no stars is in a far better position than one scoring 100 with a manual action attached.

That badge looks confused, and it is precise. "Rich result" is not one thing. A Product block can qualify for several different SERP features, each gated by different properties, and it can pass one while failing another:

So the page is eligible — for the price-and-availability snippet — and simultaneously ineligible for the stars, because those are a separate feature with a separate requirement. Both statements are true at once.

The under-used opportunity here is the third row. shippingDetails and hasMerchantReturnPolicy surface delivery cost and the returns window in the search result itself — answering the two questions that most often stop someone clicking a product listing. They are the most neglected properties in e-commerce structured data, and unlike a rating, you can add them today because you already know the answers.

A schema report can only speak to the first two. This is the distinction that produces most of the disappointment in structured data work:

1. Valid — the JSON parses, the types are real, the properties exist. All three blocks here pass.
2. Eligible — every property Google requires for a given feature is present. The Product block is eligible for some features and not others.
3. Displayed — Google actually shows the enhancement. This is never guaranteed.

Eligibility is a permission, not a promise. Google decides per query, per device, per user whether a rich result adds anything, and it withholds enhancements from pages it does not trust — regardless of how immaculate the markup is. Perfect schema on a low-quality page earns nothing, and that is working as intended.

Which is why the only report that answers the third question is Search Console → Enhancements. It is the only place that tells you what Google is doing with your markup across the live site — and the only place you find out that the schema which validated beautifully has been silently broken on four hundred pages by a templating change nobody connected to it.

The Article block scores 78 and names three gaps. They are not equally meaningful and one of them is widely misunderstood.

dateModified

Worth adding, with one condition: it must be true. Bumping the date on every deploy, on pages that have not changed, is a signal that stops meaning anything — and once Google concludes your freshness dates are unreliable, it stops using them. A dishonest dateModified is worse than an absent one.

author.sameAs and the "E-E-A-T signal" label

Read this one carefully. There is no schema property that confers E-E-A-T. Experience, Expertise, Authoritativeness and Trust are concepts from Google's Search Quality Rater Guidelines — a description of what raters are asked to assess, not a set of fields with a score attached. No markup grants it.

What author.sameAs genuinely does is entity disambiguation: it points at the author's other established profiles, letting Google connect the byline on your page to a person it already knows about elsewhere. That is real and it is useful — and it only helps if the author is a person Google has reason to have heard of. Adding sameAs to an anonymous staff byline achieves nothing, because there is no entity to resolve to.

Chasing a score of 95+ by filling fields is the wrong instinct. The number rises; nothing else does. Fill the fields whose values are true and meaningful, and leave the rest empty.

The report shows 18%. Be careful with this metric, because it is not what it appears to be.

Density is a ratio — markup as a proportion of the HTML — and a ratio has two ways to rise. You can add more structured data, or you can have less content. A thin page with an elaborate JSON-LD block scores extremely well on density and is precisely the page Google declines to index. The metric cannot tell the two apart, and neither can a target of "above 10%".

Use density as a smoke detector, not a target. A very low figure on a page you have marked up means the markup is missing or broken. A very high figure means either rich markup or a thin page — and you should go and find out which.

Three separate JSON-LD blocks is normal and fine. What is not fine — and what a per-block score cannot detect, because it examines each block in isolation — is three blocks that contradict each other.

The failure is common on any platform where several plugins each emit their own markup: two Organization blocks with different names, a BreadcrumbList from the theme describing a different path from the one the SEO plugin publishes, a Product price that disagrees with the price in the page's own microdata. Google's response to contradictory statements about one entity is to trust the page less, not to average them.

Two checks worth running on this page, neither of which appears in the report:

• Does the marked-up price match the displayed price? A stale £279 in JSON-LD against a £249 on the page is a mismatch Google will notice, and it is the fastest route to losing a merchant listing.
• Does the BreadcrumbList match the visible breadcrumb trail? It should describe the path a user can actually see and click.

The clean pattern, once you have more than two blocks, is a single @graph in which each entity is declared once with a stable @id, and everything else references that @id rather than repeating it. Contradiction then becomes impossible by construction, because each fact is only ever stated once.

What is a rich result?

Rich results are enhanced Google search appearances enabled by schema markup — star ratings, prices, event dates, recipe details, breadcrumb trails. They typically have higher CTR than standard results. To qualify, your JSON-LD must include all required properties for that schema type. Note that the supported types change: FAQ rich results were restricted in 2023 to a small set of authoritative government and health sites, and HowTo rich results were removed entirely, so check Google's current documentation before building markup for a specific feature.

What is structured data density?

Structured data density is the proportion of your page HTML that is structured JSON-LD data. Treat it as a smoke detector rather than a target. It is a ratio, so it rises either when you add markup or when the page has less content — meaning a thin page with an elaborate JSON-LD block scores highly and is exactly the page Google declines to index. No major answer engine has published a citation criterion based on markup density, and claims to that effect rest on inference rather than confirmation. A very low figure on a page you have marked up means the markup is missing or broken; a very high figure means either rich markup or a thin page, and you should find out which.

How do I validate schema markup?

Use the aiwebpageseo Schema Debugger to validate from a URL, or the Rich Snippets Tester to paste JSON-LD. For the official Google test, use the Rich Results Test at search.google.com/test/rich-results. All three tools are complementary — aiwebpageseo adds AEO signal analysis that Google's tool does not provide.

Can I just add an aggregateRating to get star ratings?

No. The rating must come from real reviews that are visible on the page. Marked-up review data with no corresponding reviews a visitor can see violates Google's structured data policies, and the penalty is a manual action for structured data spam — which suppresses rich results across the entire site until it is fixed and appealed. Collect the reviews, display them, then mark up the aggregate you are already showing. Schema describes a page; it does not create facts about it.

Why does the report say "rich result eligible" and "stars missing" at the same time?

Because a rich result is not one thing. A Product block can qualify for several SERP features, each gated by different properties. Price and availability come from name, image and the offers block — which this page has, so it qualifies for a product snippet. Stars require aggregateRating or review, which it lacks. Delivery and returns information requires shippingDetails and hasMerchantReturnPolicy, which are also absent, and those two are the most neglected properties in e-commerce structured data.

Does adding author.sameAs improve my E-E-A-T?

No schema property confers E-E-A-T. Experience, Expertise, Authoritativeness and Trust are concepts from Google's Search Quality Rater Guidelines — a description of what human raters are asked to assess, not a set of fields with a score attached. What author.sameAs actually does is entity disambiguation: it connects the byline to profiles Google already knows, which helps only if the author is someone it has reason to have heard of. Adding it to an anonymous staff byline resolves to nothing.

My schema is valid and eligible. Why is Google not showing the rich result?

Because eligibility is a permission, not a promise. Valid, eligible and displayed are three different things: Google decides per query, per device and per user whether an enhancement adds anything, and it withholds enhancements from pages it does not trust regardless of how good the markup is. Perfect schema on a low-quality page earns nothing. Search Console's Enhancements report is the only place that tells you what Google is actually doing with your markup on live pages.