September 30, 2026
A schema markup audit checks whether your Schema.org code is syntactically correct and whether it qualifies your pages for specific search features. The first move is simple: run a representative page or code snippet through the Rich Results Test. That single check tells you which pages are eligible for rich results right now and where your biggest errors are hiding.
TL;DR:
- Filling all required properties is crucial, as even a single omission can disqualify a page from rich result eligibility.
- Validating schema markup with both Google’s Rich Results Test and Schema.org’s Validator helps identify errors that impact visibility and structural issues separately.
- Address JavaScript-injected schema by using a crawler that captures rendered markup, since source code may not contain all necessary structured data.
- Prioritize fixing errors that block Google eligibility first, then address data-type issues, followed by JavaScript injection gaps and finally recommended properties.
- Conduct regular audits by inventorying schema types, running both validators, and verifying fixes in Search Console to prevent silent schema breakage over time.
Table of Contents
- What a complete schema audit covers: objects, properties, and validation
- Which tools to use and how to run each test
- Common schema errors and the order to fix them
- A repeatable audit workflow from inventory to verification
- How to confirm fixes worked and keep schema healthy
- Why author experience and reusable checklists matter here
- The part of schema auditing most teams get backward
- Get a schema audit without adding it to your own plate
- Sources
- FAQ
What a complete schema audit covers: objects, properties, and validation
A schema audit works on two levels, and most teams only check one of them. Object-level checks confirm the entity itself is present and correctly typed, a Product, a LocalBusiness, an Article. Property-level checks confirm the fields inside that entity, like price, availability, or datePublished, are filled in and formatted correctly. You can pass one level and still fail the other, which is why a page can look “structured” and still get rejected.
Required properties matter more than everything else on this list. Google’s own technical guidelines specify required properties per structured data type, and a page missing even one of them fails search-feature validation, regardless of how clean the rest of the markup is. Recommended properties, by contrast, improve the appearance or richness of the result but rarely block eligibility on their own.
A thorough audit also checks nested objects and @id consistency. When a Product references a Brand or an Organization, those nested entities need their own valid structure, and the audit documentation from Sitebulb recommends using JSON-LD with consistent @id values so search engines can connect related entities instead of treating them as duplicates or orphans.
A complete audit scope includes:
- Object presence: confirming each expected entity type exists on the page.
- Property completeness: checking required and recommended fields per entity.
- Nested entity structure: verifying linked objects like Brand, Organization, or Person are valid.
- @id consistency: making sure references point to the correct, matching entity.
- Vocabulary compliance: validating against Schema.org syntax rules.
- Search feature eligibility: validating against Google’s specific requirements for rich results.
That last distinction deserves its own callout. Schema.org vocabulary validation and Google Search Features validation are different tests with different pass conditions. A page can be perfectly valid Schema.org markup and still not qualify for a Google rich result, because Google layers its own required-property rules on top of the spec. Fix the Google-specific errors first if your goal is regaining visibility quickly, then circle back to general vocabulary cleanup.
Which tools to use and how to run each test
Three tools cover almost everything you need for a schema audit, and each answers a slightly different question.
- Start with the Google Rich Results Test. Paste in a live URL or a raw code snippet at the Rich Results Test to see whether the page qualifies for specific rich results like FAQs, products, or reviews. This is the fastest way to know if a fix actually worked.
- Cross-check with the Schema.org Markup Validator. The Schema Markup Validator extracts JSON-LD, Microdata, and RDFa from a page and checks it against the Schema.org vocabulary itself, independent of what Google requires. Use it when you need to confirm the underlying markup is well-formed, not just Google-eligible.
- Crawl with a JS-enabled tool for rendered markup. Many modern sites inject JSON-LD through JavaScript after the initial page load, and a standard HTML crawl will miss it entirely. Sitebulb’s structured data report recommends running a Chrome (JS) crawl specifically to capture that injected markup, and you can confirm the gap yourself by viewing page source and searching for “schema.org”: if it is absent there but present in the rendered DOM, your schema is JavaScript-dependent.
Reading the results correctly matters as much as running the test. Errors are hard failures: a missing required property, a malformed date, an invalid URL. Warnings are softer, usually recommended properties that would improve richness but will not block eligibility. Map errors to the object or property level as you go, since that mapping is what turns a raw report into a fix list your team can act on.
Pro Tip: Always test both the rendered page and the raw HTML source. If the two disagree, your schema is being injected by JavaScript, and you need a JS-enabled crawler like Sitebulb to see the full picture.
For a broader sense of which rich result types exist beyond the basics, this catalog of structured data opportunities is worth bookmarking once your core audit is clean.
Common schema errors and the order to fix them
Not every error deserves the same urgency. Triage by visibility impact, not by how many errors a report lists.
Missing required properties are the fastest wins on the board. Google’s structured data guidelines make clear that missing a required field disqualifies the entity from that rich result entirely, so a single field like image on a Product or datePublished on an Article can be the only thing standing between a page and eligibility. Fix these first.
Data-type and format errors come next: a price written as “$49.99” instead of a plain number, a date that does not follow ISO 8601, or a URL missing its protocol. These are cheap to fix once identified but easy to miss without a validator flagging the exact field.
Errors caused by JavaScript injection are a category of their own. If your validator or crawler shows no schema at all on a template that should have it, check whether the markup exists in rendered HTML but not in source, a sign your CMS or tag manager is injecting it client-side and a standard crawler is walking right past it.
- Missing required properties: fix first, since they block eligibility outright.
- Data-type and format errors: fix second, since they are usually quick corrections.
- JavaScript-injection gaps: fix third, since they require a rendering-aware crawl to even diagnose.
- Recommended-property warnings: fix last, since they improve appearance but rarely change eligibility.
A structured data report separates true errors from optimization warnings. Sitebulb’s structured data report flags errors that prevent rich result eligibility separately from warnings that are simply recommended-property gaps, which means your fix list is already sorted by urgency before you open a spreadsheet.
A repeatable audit workflow from inventory to verification
A schema audit only produces value if it is repeatable. Here is the sequence that holds up across a five-page site or a five-thousand-page one.
- Inventory. List every template type on the site, homepage, product, service, blog, location, and note which schema type each one should carry. This becomes your baseline against which “missing schema” is measured.
- Crawl. Run both a standard HTML crawl and a JavaScript-rendering crawl. Comparing the two immediately surfaces any schema that only exists after rendering, which a source-only crawl would miss entirely.
- Validate. Run the Rich Results Test and the Schema Markup Validator in that order, Google eligibility first, general vocabulary compliance second, and save the raw reports rather than just the summary screen.
- Triage. Group every error by type, by the page’s business importance, and by likely visibility impact. A missing
reviewproperty on your top landing page outranks a missingimageon a low-traffic blog post. - Fix and deploy. Assign fixes to the template level where possible rather than patching individual pages, since most CMS platforms render schema from a shared component.
- Verify. Re-run both validators on the fixed pages and confirm the error is gone before marking the ticket closed.
For sampling on large sites, validate your highest-traffic or highest-conversion pages first, confirm the fix works there, then roll the corrected template out site-wide before running a full crawl to catch anything the sample missed.
On the CMS side, most fixes live in a shared template or plugin rather than a one-off page edit. A WordPress structured data plugin can generate the base JSON-LD, but plugin defaults rarely cover every required property for every content type, so plan on manually verifying at least one page per template after activating or updating a schema plugin. If your local business locations need schema synced with your Google Business Profile, this step-by-step guide to local business schema walks through keeping JSON-LD and your CMS templates aligned.
A useful audit report includes:
- The full inventory of templates and their expected schema types.
- Raw validator output for each page tested, not just pass or fail.
- A triage table sorted by priority level, one through three.
- Acceptance criteria: a passing Rich Results Test result plus confirmed appearance in Search Console Enhancements.
Keep the working file simple: a CSV with columns for URL, schema type, object pass or fail, property-level errors, Google-specific errors, priority, assigned owner, fix status, and verification evidence. That single sheet becomes the audit trail anyone on the team can pick up later. For developer-level implementation details on FAQ schema specifically, this FAQ schema implementation guide has working code examples worth referencing during the fix stage.
How to confirm fixes worked and keep schema healthy
A fix is not done until it is verified twice: once in a validator, once in the wild.
Re-run the Rich Results Test and the Schema Markup Validator on every page you touched, and treat a clean pass on both as your acceptance test, not just one or the other. Then watch Google Search Console’s Enhancements reports over the following weeks, since that is where you will see whether Google actually started serving the rich result, not just whether your code is technically valid.
Set a cadence based on how often your content changes. A cadence that works for most sites:
- Monthly spot checks for dynamic sites that publish frequently or rely on JavaScript-rendered templates.
- Quarterly full-site audits for everyone else, covering every template type at once.
- Immediate re-validation any time a CMS update, theme change, or plugin update touches your templates.
- Scheduled automated crawls with alerts set to flag new errors the moment they appear, rather than waiting for the next scheduled audit.
Schema tends to break quietly. A plugin update or a template change can silently drop a required field, and the first sign is often a slow decline in rich result impressions rather than an obvious error message.
Why author experience and reusable checklists matter here
Schema audits reward process over guesswork, which is why a documented checklist beats a one-off manual review every time. This piece draws on Idea Stream Marketing’s ongoing technical SEO and AI SEO work, where schema markup audits are a standing part of client engagements.
- Use a shared inventory CSV so every template’s expected schema type is documented once, not re-discovered each audit.
- Score each error against acceptance criteria, a passing validator result plus visible Search Console enhancement data, before calling a fix complete.
- Bring in outside help when the JavaScript-rendering layer, cross-template rollout, or ongoing monitoring cadence outpaces your in-house bandwidth.
The part of schema auditing most teams get backward
Most schema advice treats the audit as a one-time cleanup: run a validator, fix red errors, move on. That misses the point. Schema breaks continuously, through CMS updates, plugin changes, and template edits nobody flags as SEO work, so a single clean report is a snapshot, not a guarantee.
The bigger miss is prioritization. Teams often chase every warning a validator shows, spending hours on recommended properties while a missing required field, the one thing actually blocking a rich result, sits unfixed on a top page. Visibility impact should decide the order of work, not the order a report lists errors in.
I’d also push back on treating Schema.org compliance and Google eligibility as the same goal. They are related but separate tests, and conflating them wastes time. Fix what blocks Google’s rich results first, because that is where the visibility and click-through gains actually show up. Clean, spec-perfect markup that never earns a rich result is a technical win with no business result attached.
Get a schema audit without adding it to your own plate
Running a full schema audit by hand takes real hours, crawling, validating, triaging, deploying fixes, then checking Search Console weeks later to confirm anything changed. Our team handles that entire cycle as part of our search engine optimization work, including AI SEO and technical SEO for sites of any size.
A schema audit engagement with us typically includes a full template inventory, validator reports for every page type, a prioritized fix list, and a monitoring plan so issues get caught before they cost you rich result visibility. If you want a second set of eyes on your markup, visit our main services page to schedule a consultation.
Sources
- Rich Results Test – Google
- Schema Markup Validator
- Schema validation (Sitebulb documentation)
- Structured data policies – Google
FAQ
What is a schema markup example?
A common example is Article schema, which uses JSON-LD to label a page’s headline, author, and publish date so search engines can display that information in a rich result. FAQ, Product, and LocalBusiness schema are other frequently used types, each with its own required properties defined by Google’s structured data guidelines.
How do I perform an SEO audit that includes schema?
A general SEO audit reviews technical health, content quality, and links, while the schema portion specifically checks object and property completeness against both Schema.org rules and Google’s eligibility requirements. Run the Rich Results Test and Schema Markup Validator as part of the technical review, then fold the findings into your broader audit report.
How do I test my schema markup for errors?
Paste a URL or code snippet into the Rich Results Test to check Google eligibility, then run the same page through the Schema Markup Validator to confirm general Schema.org compliance. If the markup does not appear in either tool but shows up when you inspect the rendered page, it is likely injected by JavaScript and needs a JS-enabled crawler to fully diagnose.
Is schema markup still relevant?
Yes, schema remains a practical way to help search engines and AI systems understand and accurately cite page content, since it acts as a translation layer between your content and the machines reading it. It also directly determines eligibility for specific rich results, which affects how a listing appears in search. For more on how it supports AI-driven search specifically, see our breakdown of schema for AI search.
What is the difference between a schema error and a warning?
An error means a required property is missing or malformed, which will block a page from qualifying for that rich result. A warning flags a recommended, non-required property that would improve the result’s appearance but will not stop the page from being eligible.