What the schema completeness scorer does
Validators tell you whether your schema is broken. This tool tells you whether it is finished. You give it a page, it fetches the HTML, extracts every JSON-LD block it finds, identifies the @type of each, and then scores how many of that type's required and recommended properties you have actually filled in. Instead of a pass or fail, you get a completeness percentage per schema object, so you can see at a glance which markup is thin and which is fully fleshed out.
The gap this fills is real. A schema can be perfectly valid and still be doing the bare minimum, carrying only the handful of properties Google strictly requires while omitting the recommended ones that actually improve how rich the result looks and how well machines understand the entity. Required fields keep you eligible; recommended fields make the result better and the data more useful. The scorer measures both, because eligibility and quality are not the same thing.
How extraction and type detection work
The tool reads the page's HTML and pulls out every JSON-LD script it contains, then parses each one. Pages often hold more than one schema object, such as an Organization, a WebSite, a BreadcrumbList, and an Article all at once, and the scorer handles them individually rather than lumping them together. For each parsed object it reads the @type to decide which property checklist applies, because a Product is scored against Product's expectations and a Recipe against Recipe's.
Nested objects count too. An Article with an author Person and a publisher Organization carries sub-entities that have their own properties, and the scorer looks into them rather than stopping at the top level. If a block cannot be parsed as JSON or carries an @type the scorer does not have a checklist for, it tells you that instead of pretending to score it, so you always know which objects were actually evaluated and which were skipped.
Required versus recommended, and how the score is built
For each schema type, the scorer keeps two buckets of properties. Required properties are the ones a type must have to be valid and eligible, like headline for Article or name and offers for Product. Recommended properties are the ones Google and schema.org suggest to enrich the result and the entity, like author, datePublished, and image for Article, or brand, sku, aggregateRating, and review for Product. The scorer reports how many of each bucket you filled.
The completeness percentage reflects both buckets, weighted so that missing a required property hurts far more than missing a recommended one. A block with every required field but few recommended fields scores as valid but incomplete; a block missing a required field scores low and is flagged as not just thin but actually at risk of ineligibility. This weighting keeps the number honest: a high score really does mean the markup is both valid and rich, not merely present.
How to read the score
Read the per-object scores first, not just a page-wide average, because one strong block can mask a weak one. For each object you see its type, its completeness percentage, and an itemized view of which required and recommended properties are present and which are missing. A near-complete score with only minor recommended fields absent is fine to ship. A mid-range score usually means you have the required fields but are leaving rich-result quality on the table.
Pay closest attention to anything marked as a missing required property, because that is the line between eligible and ineligible. Treat missing recommended properties as a prioritized to-do list rather than emergencies: add the ones that materially improve your result, like image and ratings, and do not stress over obscure ones that do not apply to your page. Empty strings, placeholder values, and null fields should be read as missing even when they technically exist, because they add nothing.
Why completeness is not the same as validity
It is worth dwelling on the difference between a validator and this scorer, because they answer different questions and teams routinely confuse them. A validator asks: is this schema broken, and is it eligible at all. It returns pass or fail. The completeness scorer assumes you already pass and asks the next question: how good is the schema you passed with. Two pages can both clear a validator with flying colors while one is rich and the other is skeletal, and only a completeness view distinguishes them.
This matters because valid is a floor, not a ceiling. Google's required fields are deliberately minimal so that the barrier to eligibility stays low, but the recommended fields are where the actual richness of a result is decided. A team that treats the validator's green check as the finish line ships valid but thin markup forever and wonders why their results look plainer than competitors'. The scorer reframes the goal from did it pass to how complete is it, which is the question that actually correlates with how your result looks and how well machines understand it.
Scoring multiple objects and nested entities together
Real pages rarely carry a single tidy schema object, and the scorer is built for that messiness. A typical article page might hold an Organization for the publisher, a WebSite for the site, a BreadcrumbList for navigation, and an Article for the content, all in separate JSON-LD blocks or bundled in a graph. The scorer evaluates each one against its own checklist and reports them individually, so a strong Article does not hide a barely-filled Organization. The page's overall structured-data health is only as good as its weakest meaningful object.
Nested entities get the same scrutiny. An Article's author should be a Person with at least a name, and ideally a url or sameAs that links the author to a stable identity; an offer inside a Product should carry price, priceCurrency, and availability, not just a bare price. The scorer looks inside these sub-objects rather than rewarding you for merely declaring them empty. A common surprise is discovering that the top-level type scores well while a nested author or publisher is almost hollow, which is exactly the kind of gap that limits both rich results and AI comprehension and exactly what a completeness view is meant to expose.
Common mistakes the scorer reveals
The most common finding is the valid-but-minimal block: schema that passes validators because it has the required fields, yet omits the recommended fields that make rich results compelling. Teams often stop at valid and never go back to enrich, leaving a plain result where a fuller one was within reach. The scorer makes that gap visible by showing how far below complete the block sits.
Other patterns it surfaces include placeholder or empty values that look filled but are not, nested entities like author or publisher that are present in name only, and inconsistent completeness across a templated site where one page type is rich and another is bare. It also catches the case where a page has several schema objects but one of them, often a secondary type added as an afterthought, is far less complete than the rest and is dragging down the page's overall structured-data quality.
Why completeness matters for SEO and AI search in 2026
Richer schema produces richer results. The recommended properties are exactly the ones that feed images, ratings, prices, dates, and other enhancements into the search listing, so completeness translates fairly directly into how much visual real estate and information your result can claim. Two pages can both be valid, but the more complete one tends to present better and clearer in the SERP.
For AI search the stakes are higher still. Large language models and AI Overviews read structured data to extract facts they can cite, and a complete schema hands them clean, labeled values for things like author, publish date, price, and rating instead of forcing them to scrape and guess from prose. The more complete your markup, the more confidently an AI engine can represent your page, which is increasingly where completeness pays off even on pages where the classic rich result never changes.
What to do after you run the scorer
Start with any missing required properties and fill those first, since they protect your eligibility. Then work down the recommended list in order of impact, adding the fields that unlock visible enhancements, like image, author, datePublished, brand, or aggregateRating, before bothering with marginal ones. Use the matching generator for the type to produce correct property syntax rather than hand-editing, and pull real values from the page so the markup stays truthful.
After enriching, re-fetch and re-score to confirm the completeness number climbed and that no new errors crept in, then run the page through Google's Rich Results Test to verify the richer markup is still valid and eligible. Deploy, request indexing, and watch Search Console's enhancement reports. On a templated site, fix the template once and the gain propagates across every page that uses it, so re-score one representative page per template to confirm the improvement landed everywhere.