A schema check has three layers: valid JSON-LD syntax, valid Schema.org vocabulary, and truthful alignment with visible content. Passing syntax alone does not guarantee a search feature.
Inspect a public URL with ToolTrace's free Schema Markup Checker, then verify feature requirements with the consuming search engine.
Inventory structured data entities
Inspect JSON-LD, microdata, and RDFa. List every top-level entity and its @type, @id, and relationship to the page.
Duplicate entities with different identifiers often create conflicting facts. Prefer maintainable JSON-LD for new implementations.
Validate JSON-LD syntax
Check quotes, commas, brackets, arrays, escaping, and value types. Confirm @context is https://schema.org.
The W3C JSON-LD specification defines the format.
Check Schema.org types and properties
Verify that properties are supported for each entity and values use expected types. Dates should follow ISO 8601 and URLs should resolve.
Use Schema.org's hierarchy instead of copying an unrelated snippet.
Match markup to visible content
Do not add ratings, prices, availability, FAQs, authors, or dates that are absent or contradictory on the page. Structured data must describe what users can see.
Review Google's structured data policies.
Use stable identifiers and relationships
Assign stable absolute @id values and reuse them. Connect articles to authors and publishers, products to brands and offers, and webpages to primary entities.
Consistent identifiers reduce duplicate definitions and make the graph maintainable.
Test eligibility and monitor releases
Use Google's Rich Results Test for supported features and Search Console after indexing. No validator can guarantee display.
Re-test the rendered production URL after CMS or frontend changes and include schema in the broader SEO audit.
Debug schema errors in dependency order
Begin with the first invalid JSON-LD block because one missing comma can hide every entity inside it. Then resolve unsupported types, misspelled properties, incorrect value types, broken URLs, duplicate identifiers, and contradictions with visible content.
- Parse error: repair JSON syntax and escaping.
- Vocabulary error: verify the property on Schema.org.
- Eligibility warning: check the search feature documentation.
- Accuracy problem: correct the page content or remove the unsupported claim.
Do not add placeholder ratings, authors, prices, or FAQ answers merely to satisfy a validator.
Add structured data to release quality assurance
Generate schema from the same source of truth as the visible page whenever possible. Re-test after CMS, template, pricing, author, localization, and frontend changes. Save representative product, article, organization, and FAQ pages as fixtures.
Monitor valid item counts, invalid blocks, missing required properties, identifier duplication, and differences between source and rendered markup. Use ToolTrace for extraction evidence, the Schema.org validator for vocabulary, and Google Rich Results Test for Google-supported features. These tools answer different questions and should not be collapsed into one score.
Common failure patterns and how to diagnose them
Start with the earliest failing layer. If a request does not return the expected page, inspect DNS, redirects, HTTP status, content type, firewall behavior, and access controls before changing extraction or metadata rules. If the correct document arrives but the result is empty, compare initial HTML with the rendered page and determine whether JavaScript supplies the missing information.
When only some fields are wrong, inspect the page source and identify which signal produced each value. A stale canonical, duplicated title, malformed JSON-LD block, relative URL, or CMS fallback should be corrected at its source. Avoid adding a special case for one URL when the same template defect affects a wider section of the site.
Finally, distinguish a deterministic failure from a recommendation. Invalid JSON, an unreachable URL, or a conflicting index directive can be proven. Content usefulness, ideal wording, and business priority still require human judgment. A professional report should show the evidence, explain the consequence, and avoid presenting a heuristic as a universal rule.
Production quality checklist
Validate the exact production URL, not only a CMS preview, local fixture, or isolated code sample. Confirm the requested URL, final URL, HTTP status, content type, and visible result agree with the page you intended to process. Test at least one normal case, one sparse page, one redirected URL, and one expected failure so the interface communicates limitations clearly.
- Keep source URLs and observation times with exported results.
- Use descriptive labels, headings, and error messages.
- Specify image dimensions and keep media files lightweight.
- Test keyboard access and narrow mobile layouts.
- Separate automatic checks from recommendations requiring judgment.
- Respect access controls, publisher policies, privacy, and applicable law.
After deployment, rerun the workflow against representative URLs and monitor for changes in output size, missing fields, status codes, response time, and template behavior. Keep a known-good result for comparison. When a check fails, fix the source template or data pipeline rather than hiding the warning in the interface.
Frequently asked questions
Does valid schema guarantee rich results?
No. Valid markup is one eligibility condition, and search engines decide when a feature is useful.
Can one page use several schema types?
Yes, when they represent visible entities and relationships without contradictory duplication.
Can JavaScript generate schema?
Yes, but server-rendered JSON-LD is simpler to verify. Always test the rendered production page.