What is structured data?

What is structured data on a website?

Structured data expresses information through explicit types, properties, and relationships that software can interpret. On a website, it can describe the page and its visible subject matter. Accurate markup gives consumers clearer clues, but it does not replace the explanation readers need or establish facts that the business cannot support in the actual content.

• Google’s structured-data introduction, accessed October 8, 2026, describes its use in understanding pages and supporting eligible search features.

  A labelled property differs from a marketing sentence: it states what the value represents rather than leaving a consumer to infer that relationship from prose alone.

• A page can identify its subject, relevant organization, and other supported information without becoming a different resource.

  The visible explanation remains essential. Hidden markup should not contain invented service details or claim a relationship absent from the page merely because those properties seem useful for search.

• The term is broader than one vocabulary or encoding.

  Schema.org provides common vocabulary, while a serialization describes how the information is written. A consumer also has its own rules about what it supports. Those layers need separate checks before anyone claims that a valid data block enables a specific Google appearance.

• The useful implementation goal is accurate machine-readable representation of real published information.

  A large block with many speculative properties can be worse than a smaller complete description. Select the supported purpose, verify the underlying facts, and maintain consistency with the page rather than filling every available field.

• Rich-result eligibility depends on the consumer’s requirements for the data and page; valid syntax alone cannot establish display.

How do vocabulary, format, and search-feature rules differ?

Vocabulary defines the types and properties available for describing information. Format defines how those statements are encoded. Search-feature rules define what a particular consumer requires for a supported appearance. Passing one layer does not establish the others, so keep syntax validation, semantic accuracy, and Google-specific eligibility separate throughout implementation and review.

• Schema.org’s data-model documentation describes types, properties, and expected values within a flexible model.

  Schema markup uses that vocabulary. A type being available does not mean Google displays a dedicated rich result for every instance or uses every property in the same way.

• JSON-LD is a common encoding that can place the description in a script block.

  Google’s introduction also discusses Microdata and RDFa. The chosen format should fit the implementation and supported feature rather than be selected through an unsupported claim that one syntax always creates better rankings.

• Google says its own feature documentation is definitive for its search behavior.

  Schema.org can contain additional properties useful to other consumers. A schema validator can therefore recognize vocabulary that the Rich Results Test does not identify as a supported feature. That difference is not automatically a defect in either tool.

How should the page’s actual subject determine the markup?

The page’s actual subject should determine the description, rather than a desired appearance deciding which content type to pretend it contains. Read the visible information and identify its real purpose. A service explanation, article, organization page, and collection have different relationships, even when they share a layout or commercial call to action.

• Google’s general structured-data guidelines require representative relevant information and suitable specificity.

  Do not label unrelated instructions as another content type merely because that type has an attractive search feature. The implementation should describe what the page actually provides.

• Separate the page from the thing it describes.

  A page about an organization is not necessarily the organization itself. A guide written by a person can describe a service without becoming that service. Schema.org’s data-model discussion explains relationships such as a page’s main entity and broader subject information.

• A shared template needs enough context to make that distinction.

  Applying the same type everywhere because it is easy can misrepresent mixed page purposes. Review representative page classes and their actual published information before configuring automatic descriptions. A theme’s default output is not proof that its assumptions fit every resource.

• When intent is unclear, resolve the content purpose before adding a more elaborate graph.

  More markup cannot make an incomplete page coherent. A correct concise representation of the verified subject is more useful than multiple speculative entities that imply offerings or relationships the reader cannot find or confirm.

Which visible facts should be verified before markup is generated?

Verify the visible facts that each property will assert, including identity, dates, descriptions, images, and relevant relationships. A template can produce syntactically valid values from outdated or inappropriate fields. Check the source and meaning of the data before publishing it, so a machine-readable statement does not contradict the page or manufacture unsupported commercial information.

• Google’s quality guidelines require current representative information visible to readers.

  A property can be technically accepted while still misleading. Automated validation cannot establish that the business actually offers a service at a claimed location or that a person’s stated role is real.

• Review date semantics.

  A publication date and an edit date describe different events. A scheduled record date may not be the actual publication event. Do not set every date to the deployment day merely because that value is conveniently available; use the field that accurately represents the stated property.

• Check descriptions and titles against the rendered page.

  A CMS summary may be stale after the explanation changes. A plugin may use a generic site description on every item. The resulting output can look complete while losing the specific subject that the page actually presents to its readers.

• Omit unsupported values instead of inventing them.

  Missing information can be a reason to improve the underlying content or choose a different eligible implementation. It is not permission to fabricate ratings, prices, qualifications, offices, or relationships merely to satisfy a tool’s suggested property list.

How should required and recommended properties be interpreted?

Interpret properties through the documentation for the specific consumer and supported feature. Required fields concern feature eligibility; recommended fields can improve description but still need accurate evidence. Do not fill missing values with guesses or treat a warning as permission to state information absent from the actual page.

• Google’s structured-data introduction distinguishes its feature requirements from the broader vocabulary.

  Its general guidelines also address completeness. Read the relevant feature guide rather than assuming a general schema validator enforces every Google requirement.

• A missing required property can make an item ineligible for a particular rich appearance.

  That does not automatically mean the page disappeared from ordinary web search. Separate feature validation from indexing state. The Page indexing report answers another question and should not be used as a substitute for structured-data diagnosis.

• Recommended properties deserve a factual review.

  If a field is unavailable, document the limitation or improve the source where appropriate. Providing fewer accurate details is preferable to constructing plausible values simply to remove every warning. A clean report obtained through fabricated information is not a valid implementation outcome.

• Recheck requirements when the feature or documentation changes.

  A historically accepted pattern can no longer be the supported one. Keep the observed source date and feature context in the implementation evidence instead of presenting an old tutorial’s property list as a timeless universal schema rule.

How should identifiers and entity relationships remain consistent?

Identifiers and relationships should consistently describe the intended entities rather than create contradictory copies across templates. Distinguish the page address from the identity of its subject. A moved page can still describe the same organization or person, so review what each reference means instead of mechanically rewriting every identifier whenever a resource URL changes.

How can multiple items describe one page accurately?

Several items can describe one page when each corresponds to real information and their relationships are coherent. An article, video, and navigation context are not identical entities. Represent their appropriate connections while avoiding contradictory duplicates or unsupported relationships introduced simply because multiple plugins generate their own data independently.

• Google’s multiple-item guidelines discuss connected and separately described items.

  Breadcrumbs can express navigation context while another item describes the main content. The coexistence of supported descriptions is different from attaching every available type to one generic entity.

• Review the visible components before adding their corresponding items.

  An absent video should not remain described after the component is removed. A breadcrumb trail should match the intended navigational relationship. A related-content card is not automatically the main entity of the page simply because its title appears in the markup.

• Shared template output needs coordination.

  A CMS plugin can create one organization or article description while application code creates another. Removing all but one block indiscriminately can discard useful information; leaving contradictory copies is also wrong. Inspect which statement each producer emits and consolidate or align them deliberately.

• Validate the resulting graph and visible page together.

  A parser can accept several items without establishing that they describe the correct subjects. The review should explain what each item represents and how it connects, rather than treating the total number of recognized entities as a quality score.

What should images and referenced URLs establish?

Images and referenced URLs should identify the correct relevant resources and be accessible to the intended consumer. A valid-looking address is not proof that the image loads or describes the page’s subject. Verify the actual response and content, especially where a template reuses a default image or references an obsolete route after a publishing change.

• Google’s image guidelines for structured data require relevant accessible image URLs.

  Image SEO adds broader discovery and descriptive considerations. The markup should not point every item to a generic brand asset when the feature requires a meaningful representation of the actual content.

• Open representative resources publicly.

  An owner preview can access an image requiring authentication while a consumer cannot. A CDN URL can also return an error or a different resource. Confirm response and identity rather than checking only whether the stored value begins with the expected scheme or file extension.

• A 404 error at a referenced page or image creates a resource-delivery problem separate from syntax.

  A data block can parse while its dependencies fail. Retest relevant references after migrations and record whether they lead to the intended current resource, not merely an arbitrary successful destination.

• Avoid unnecessary changing addresses where they undermine stable reference.

  The right strategy depends on the actual asset and deployment system. Verify that published references remain valid through supported updates, while keeping accurate resource identity and content freshness rather than applying one simplistic URL rule to every item.

How can JavaScript-generated data be checked reliably?

Inspect the rendered output as well as source code when scripts generate data. Configuration alone does not prove public delivery. Dependencies can fail, duplicates can appear, and transitions can retain another page’s description, so verify what the consumer obtains under the relevant direct-entry and navigation conditions.

• Google’s structured-data introduction says it can read dynamically inserted JSON-LD.

  That support does not guarantee successful execution for every application. JavaScript SEO examines initial delivery separately from rendering so the public resource can be checked at each responsible stage.

• Test a direct route entry and relevant client-side transitions.

  An application can update the visible heading while retaining a previous article’s structured description. A fresh request can also lack state available in the owner’s session. These are output-consistency problems, not proof that every script-generated description is inherently invalid.

• Inspect the actual script block and parsed values after rendering.

  A broken serialization can produce incomplete JSON; another plugin can emit contradictory data. Compare the result with visible content and supported feature requirements. A source-code object or plugin configuration screen is implementation evidence rather than delivered-output verification.

• Where initial generation is practical, it can reduce dependence on client execution for that description.

  Choose according to the resource and implementation needs rather than a claim that one framework guarantees rich appearances. After changing delivery, confirm complete accurate data and the visible page together under the relevant public conditions.

How should syntax validation differ from feature validation?

Syntax checks whether the chosen format parses; vocabulary checks concern the types and properties; feature validation checks a consumer’s supported requirements. These layers can produce different results legitimately. Read each tool’s scope instead of treating one green report as proof of factual accuracy or eligibility for every search appearance.

Why can valid data fail to produce a rich result?

Technical validity is only one requirement for rich-result display. The supported feature and its eligibility rules matter alongside quality and selection for the search context. Diagnose the available evidence without assuming that absent display proves a syntax defect or that adding more properties will necessarily change how the page appears in search.

• Google’s general guidelines explain that passing technical checks does not ensure display.

  A page can be representative and eligible yet receive an ordinary text result. Keep that distinction separate from a genuine error that makes the item ineligible under the documented feature rules.

• Access also matters.

  A noindex instruction or other restriction can prevent the intended public processing. Structured-data validation on submitted code does not prove the live page is available and eligible. Inspect the actual public response and Google’s available page evidence where that distinction is relevant.

• Review the feature’s scope before expecting a specific appearance.

  Some vocabulary has no dedicated supported result, and feature support can change. Do not assume a service item earns review stars, a generic question block earns an FAQ display, or an organization statement creates a particular panel without checking the current applicable documentation.

• Avoid speculative troubleshooting that changes accurate facts merely to provoke display.

  Correct real technical or quality issues, then assess later observations within their limits. Search features are not a publication promise, and the glossary should not attach an invented click-through increase to a technically valid implementation.

How should content changes and duplicated pages keep data accurate?

Update statements when their visible information changes, and review the actual relationship between duplicated pages. Do not assume descriptions belong only on the preferred address. Test relevant template states and references after edits, because a correct implementation can become misleading when records or components change independently of their markup.

• Google’s general guidelines recommend consistent appropriate data on duplicated content, not only one canonical copy.

  Canonicalization concerns equivalent representation. It does not relieve other delivered copies of accurate description when they remain accessible and contain the same relevant information.

• A visible author or service description can change while a plugin retains an old value.

  A removed video can remain in a cached data block. A publication system should connect each statement to its appropriate source rather than maintain several manual copies whose meaning diverges over time.

• Review the output after route moves.

  Referenced page and image URLs can remain obsolete even when the visible explanation is correct. Update justified references and test their current delivery. Do not mechanically rewrite a stable entity identifier without considering whether it represents the page or its underlying subject.

• Keep changes scoped to the real information.

  A routine deployment is not evidence that every item received a substantive update. The description should remain honest about the resource’s history and relationships, rather than assign a new publication date merely because the template was rebuilt.

What would a useful structured-data repair demonstrate?

A useful repair verifies technically readable and factually accurate live output aligned with the supported purpose. Check relevant relationships and references, then validate applicable feature requirements. The immediate outcome is corrected representation; later appearances and customer results need separate observations rather than an assumed benefit from a clean validator.

• Illustrative diagnosis, not client data.

  An article template retains a previous record’s author information during a client-side route transition. The visible article changes, but the rendered description does not. The developer corrects the state boundary and verifies direct entry and transition output against the actual published records.

• The test checks the related image and page references, confirms the correct subject and author relationship, and runs suitable technical and feature validation.

  It does not invent credentials or supply missing ratings to remove warnings. The verified change is consistency between the visible article and its delivered description.

• Google’s introduction discusses evaluating later performance with suitable comparisons.

  Such outcomes can vary for other reasons, so a deployment and valid test are not causal proof of increased visits. Describe any collected observations honestly and leave unmeasured results unclaimed.

• Report the corrected statements, tested public states, supported purpose, and remaining limits.

  That makes the implementation reviewable without overstating what software validation can establish. Structured data remains a maintained representation of real information, not a shortcut for replacing content quality or promising a particular search feature.

Continue the public-page review

Use our website SEO checker for preliminary public-page observations. Verify delivered data and visible information through the procedures above. Our technical SEO services connect confirmed representation and delivery problems with appropriate repairs.