JSON-LD and structured data: a practical guide to accurate search information

JSON-LD is a format for expressing structured information about a page and the entities it describes. On a business website, it can describe an organization, article, product or other appropriate subject using a shared vocabulary such as Schema.org. Google supports JSON-LD and recommends it for structured data implementations where the format fits the project. The goal is to provide an accurate, machine readable description of real content.

This article was originally published on October 28, 2015 and has been reviewed for the search landscape of October 12, 2026. The durable principle remains accuracy; supported search displays and platform guidance change. Structured data can contribute to eligibility for particular rich results, but it does not guarantee that those results appear or that a page ranks higher. Treat implementation as information quality work with specific checks.

Start by describing what a visitor sees and why the page exists. A service description is different from a product detail page with a purchasable item and current offer. An editorial article is different from a directory or landing page. The markup should follow the content model rather than a desire to collect as many schema types as possible.

Create a simple mapping of templates to subjects and their factual data sources. For an article, the source might be the CMS fields for headline, author and publication date. For a product, it might be the catalog and inventory system. Ask who maintains each value and whether it is visible or accurately represented on the page. This mapping helps prevent a template from making claims that are not supported by the actual business content.

Schema.org provides a broad vocabulary, while a search engine documents a narrower set of supported features and requirements. A type can be valid in the vocabulary without creating a special Google display. Conversely, a supported feature can require fields and conditions beyond a generic schema validator's checks. Read the specific search documentation for the intended feature before implementation.

This distinction matters when an agency or plugin recommends markup based on old advice. Google's 2026 documentation updates state that FAQ rich results stopped appearing from May 7, 2026. Useful FAQ content can stay on a page, but the former display should not be promised. Evaluate existing markup against current support and the page's purpose. Removing an obsolete expectation from the project brief is as valuable as adding a new technical field.

A page may describe several related entities: an article, its author and the publishing organization, for example. Keep their names and identifiers consistent rather than creating disconnected descriptions in each script. Stable identifiers can help associate references within the implementation, provided the relationships actually match the website. Avoid treating an entity graph as permission to invent expertise or affiliation.

Consider a hypothetical agency article. The publisher is the agency, the author is the person or team responsible for the material, and the main page contains the article. These are different roles even when some information overlaps. Document the intended relationships before generating the JSON-LD. That makes review easier for developers and editors and reduces contradictory output when a theme, SEO plugin and custom code all add their own structured descriptions.

Structured data should remain consistent with the information available to readers. Product prices, availability and review claims deserve particular care because they can change or require additional conditions. A technical syntax check cannot establish whether the business has the evidence to publish a rating. Use real, appropriately sourced data and follow the applicable feature policies.

For editorial pages, preserve the original publication date and update the modification date when substantive content is reviewed or changed. Do not repeatedly reset dates to create an impression of novelty. For company details, align names and contact information with the relevant public pages. Define a single source for each factual value where possible. When the catalog or CMS changes, both the visible page and its structured description should update through the same dependable process.

WordPress themes and plugins frequently emit structured data automatically. Inspect the final page before adding custom output. Determine which component owns the organization, breadcrumbs, article or product description, then disable or replace overlap deliberately. Multiple scripts are not inherently wrong, but contradictory descriptions of the same entity make maintenance harder and may create misleading information.

A custom implementation should read established CMS fields rather than hardcoded text that editors cannot update. Serialize data through the framework's appropriate utilities and review how script content is safely included in the page. Test article pages with missing optional fields, product variations and translated content. The purpose of integration is to keep accurate output during ordinary editorial work, not merely to produce one successful demonstration page before the website launches.

Use different checks for different questions. A JSON parser catches malformed syntax. A schema validator checks vocabulary usage. Google's Rich Results Test evaluates supported search features and can identify required fields for those features. Search Console and URL Inspection help investigate what Google receives and reports after deployment. Passing one tool does not imply that all these questions have been answered.

Test the live output as well as a code sample. A CMS setting, cache layer or plugin conflict can change the deployed page. Start with representative templates and include realistic edge cases, such as an article without a hero image or a product temporarily unavailable. Save the findings with the affected URLs and expected corrections. When a field is absent, decide whether the content needs completion or the markup should omit an unsupported claim.

A structured data implementation is a maintained feature. Product updates, staff changes, revised company details and template releases can all affect its accuracy. Assign ownership to the team that controls the underlying information, with a developer responsible for the generation logic. Add a lightweight check to relevant release workflows so output does not drift silently over time.

A practical maintenance record describes the templates covered, the fields used, the tests performed and the feature documentation reviewed. Review platform updates periodically and when a search report changes unexpectedly. Do not assume an old warning requires immediate code changes without checking current guidance. Similarly, do not leave a false value in place because a validator accepts it. Operational accuracy is the real standard; tool feedback is evidence used to reach that standard.

JSON-LD works within the website's broader technical and editorial context. A well described page can still be inaccessible, excluded from indexing or unhelpful to a customer. Fix those barriers alongside the markup and keep service descriptions, navigation and performance in the same implementation plan. Google also states that no special schema is required for its generative AI search experiences.

8web can audit existing structured output, define a suitable content model and implement it through WordPress or custom development. The scope should specify which templates and supported features are involved, what data must be supplied and how changes will be checked. The result is a maintainable description of real business information. Evaluate success through accurate deployment, reduced inconsistencies and relevant search reporting, with clear limits around rankings and the displays selected by external systems.