Structured data can help machines understand what a page represents. For search, it can also make a page eligible for supported result features. Neither outcome begins with copying a JSON-LD example and hoping it fits.
1. Start with valid JSON
JSON-LD is based on JSON, so it must be parseable first. Check double-quoted names and strings, balanced braces and brackets, correct commas and colons, valid escaping, and supported value types. Strict JSON does not allow trailing commas or comments.
A parser error is not a Schema.org problem. Fix the JSON before reviewing types and properties.
2. Confirm context and type
Confirm that @context identifies the intended vocabulary and @type accurately describes the page's main subject. Use the most specific appropriate type, recognized properties, and suitable types for nested objects.
3. Match markup to visible content
Compare names, descriptions, URLs, images, authors, dates, offers, ratings, and availability against the rendered page. Remove unsupported values instead of using placeholders. Structured data should not describe hidden, irrelevant, or misleading information.
4. Check required and recommended properties
Schema.org defines a broad vocabulary. Search providers can set narrower requirements for a supported feature. Review the current documentation for that exact feature, include every truthful required property, and evaluate recommended properties without inventing data.
5. Review nesting, images, and URLs
Check whether each property expects text, a URL, an object, or an array. Confirm nested authors, organizations, offers, addresses, and images. Use correct absolute URLs and verify that images and destinations are accessible when a feature requires them.
6. Use the right validation tools
A JSON parser checks syntax. A JSON Schema validator checks a supplied data contract. A general Schema.org validator checks vocabulary broadly. Google's Rich Results Test checks supported Google features. URL Inspection helps verify the rendered production page after publication.
SiteTend's Structured Data Checker reviews pasted HTML or JSON-LD for common validity, type, property, nesting, image, and URL issues. It is a pre-publication check, not a promise of search appearance.
7. Test the production URL
Templates, rendering, deployment, and client-side injection can change the final markup. After release, confirm the markup is in rendered output and the page is not blocked by robots controls,noindex, authentication, or another access restriction. Then test the live URL and monitor provider reports after material changes.
Pre-publication checklist
- Confirm that JSON parses.
- Verify appropriate context, type, properties, and nesting.
- Match every material value to visible page content.
- Complete truthful required feature properties.
- Check URLs and images.
- Run the appropriate generic and feature-specific tests.
- Assign production URL testing.
- Avoid promises about indexing, ranking, or rich results.
Check structured data before publishing
JSON-LD validation FAQ
Is JSON-LD Google's only supported structured-data format?
No. Google supports JSON-LD, Microdata, and RDFa and generally recommends JSON-LD when it is practical to implement.
Should every Schema.org property be added?
No. Use properties that accurately describe visible content and meet the needs of the intended consumer or supported feature.
Is a warning the same as an error?
No. Errors commonly identify invalid or missing required information. Warnings often concern recommended information and should never be cleared with invented data.
Why test the live URL if the draft already passed?
Rendering and deployment can change or omit markup. The live URL shows what crawlers can actually access.
Will correct structured data improve rankings?
Correct markup can help systems understand a page and support eligible search features, but it does not guarantee rankings, traffic, or a rich result.