Structured Data: A Practical Guide to Machine-Readable Meaning

What structured data is

Structured data expresses information according to a defined vocabulary and syntax. Instead of requiring a system to infer every relationship from visible text, the markup can state those relationships directly.

For example, a business page may visibly contain a company name, telephone number, address, hours, and service area. A person can usually understand how those details relate. Structured data can identify them explicitly as properties of the same business entity.

Depending on the page, structured data may help answer questions such as:

• Is this page primarily about an article, organization, person, product, event, recipe, video, or job opening?
• Who wrote, published, manufactured, organized, or offers the subject?
• What name, date, location, image, price, or identifier belongs to it?
• Is one entity part of, offered by, reviewed by, or associated with another?
• Where does the page sit within the website’s breadcrumb structure?
• Which URL identifies the entity being described?

Structured data therefore works as a machine-readable description of information that the page already communicates to people.

Structured data, Schema.org, and JSON-LD are not the same thing

These terms are closely related, but they describe different parts of the system:

Structured data

The general practice of representing information in a standardized, machine-readable form.

Schema.org

A shared vocabulary of types and properties used to describe entities and their relationships. Examples include Article, Organization, Product, author, and datePublished.

JSON-LD

A syntax for expressing linked data in JSON. It is one of several formats that can be used to place Schema.org vocabulary on a webpage.

Rich result

A search presentation that may include additional visual or informational features. Google supports rich results for selected structured data types under its own eligibility rules.

A page can contain valid Schema.org markup without qualifying for a Google rich result. Likewise, a supported type does not guarantee that Google will display an enhanced result. Vocabulary validity, search-feature eligibility, and actual search presentation are separate questions.

How structured data relates to HTML

HTML provides meaningful document structure. Elements such as headings, paragraphs, lists, links, tables, figures, navigation regions, and forms help browsers, assistive technologies, search systems, and people understand how a page is organized.

Structured data adds a more explicit entity-description layer. It can identify a visible set of information as an organization, associate a person with an article through the author property, or connect an offer to a product.

The two layers overlap, but they are not interchangeable:

• Semantic HTML describes the structure and function of the document.
• Structured data describes named entities, their properties, and their relationships through a formal vocabulary.

Structured data should reinforce the page rather than compensate for an unclear document. A page with weak headings, ambiguous copy, inaccessible controls, or incomplete product information does not become clear merely because a script identifies it as a Product.

For a deeper comparison, see Schema Markup vs. Semantic HTML and Machine-Readable Structure vs. Human-Readable Structure.

Why structured data matters

Webpages often contain details that are easy for a person to recognize but harder for a machine to interpret consistently. A date might be a publication date, an event date, a product release date, or the date a page was last revised. A name might identify an author, organization, location, product, or quoted source.

Structured data can reduce this ambiguity by assigning defined types and properties to the information.

It can clarify entities and relationships

Markup can identify the main subject of a page and describe how related entities connect. This can support clearer entity interpretation, especially when names or relationships would otherwise be ambiguous.

It can support eligible search features

Google uses supported structured data for search features associated with products, recipes, videos, events, job postings, breadcrumbs, articles, and other content. Supported features and requirements can change, so implementations should be checked against the current Google Search Gallery documentation.

It can make information more portable

A standardized vocabulary gives different systems a shared way to describe common entities. Not every crawler, search engine, or retrieval system will use every property, but a well-formed description is easier to process than a collection of unlabeled facts.

It can expose inconsistencies

Preparing structured data often reveals gaps in the underlying page. A missing publication date, unclear author identity, inconsistent organization name, or outdated product availability may become more noticeable when the information must be represented explicitly.

Common Schema.org types

The appropriate type depends on the page’s actual subject and purpose. A type should be chosen because it accurately describes the visible content, not because it appears to offer a desirable search treatment.

• Article, BlogPosting, and NewsArticle: Used for editorial and article content. The most specific accurate type is generally preferable.
• Organization: Describes a company, nonprofit, institution, association, or other organization.
• LocalBusiness: Describes a business with a physical presence or defined local operation. More specific subtypes may be available.
• Person: Identifies a person and relevant public properties, such as a name, role, or authoritative profile URL.
• Product and Offer: Describe a product and commercial details such as price, currency, condition, and availability.
• BreadcrumbList: Represents a page’s position within a navigational hierarchy.
• Event: Describes a real event, including its name, date, location, attendance mode, and organizer where applicable.
• JobPosting: Describes an actual employment opening with details such as title, hiring organization, location, and posting dates.
• VideoObject: Describes a video and properties such as its title, thumbnail, duration, upload date, and content URL.
• Recipe: Describes a recipe with ingredients, instructions, preparation information, and related properties.
• Review and AggregateRating: Represent genuine review information under applicable platform policies. They should not be added merely to create stars in search results.
• FAQPage: Describes a page containing visible questions and answers. Valid markup does not necessarily produce a rich result, and Google limits FAQ rich-result visibility to certain authoritative government and health websites.

Schema.org contains a much broader vocabulary than any one search engine uses for enhanced results. Begin with the entity the page genuinely represents, then use the properties necessary to describe it accurately.

How to choose appropriate markup

A useful implementation begins with the page rather than the vocabulary list.

1. Identify the page’s main purpose. Determine whether the page is primarily an article, product listing, event, job opening, business page, profile, or another kind of resource.
2. Identify the main entity. Ask what person, place, organization, item, event, or concept the page principally describes.
3. Choose the most specific accurate type. A specific type can communicate more than a broad parent type, but only when the narrower classification is true.
4. Map visible facts to relevant properties. Use names, dates, URLs, images, prices, locations, authorship, and other details that are actually supported by the page.
5. Check platform requirements. If a Google search feature is relevant, compare the implementation with Google’s current required and recommended properties.
6. Test the completed page. Validate both the syntax and the rendered implementation.
7. Maintain it with the content. Update structured data when the visible information changes.

Do not begin by asking, “Which schema might earn a rich result?” Begin by asking, “What is this page, and what does it truthfully describe?”

Why JSON-LD is commonly used

Schema.org vocabulary can be expressed through JSON-LD, microdata, or RDFa. Google supports all three formats for structured data, but generally recommends JSON-LD when it is practical.

Microdata and RDFa place properties directly within HTML elements. JSON-LD usually places the description in a separate script block. This separation often makes the markup easier to read, generate, update, and debug without weaving attributes throughout a page template.

The following simplified example describes an article:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "A Practical Guide to Structured Data",
  "description": "An introduction to structured data, Schema.org, and JSON-LD.",
  "datePublished": "2026-08-25",
  "dateModified": "2026-08-25",
  "mainEntityOfPage": "https://example.com/structured-data-guide/",
  "author": {
    "@type": "Person",
    "name": "Example Author",
    "url": "https://example.com/about/"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Example Publisher",
    "url": "https://example.com/"
  },
  "image": "https://example.com/images/structured-data-guide.jpg"
}
</script>

This is an illustrative example rather than a universal template. The right properties depend on the page, the entity, and any search feature being considered. Placeholder information should always be replaced, and copied markup should be reviewed rather than published unchanged.

JSON-LD does not need to reproduce every sentence on the page. It should provide a faithful structured description of the relevant entities and facts. Additional guidance is available in Structured Data with JSON-LD.

The continuing role of microdata and RDFa

Microdata and RDFa are not obsolete simply because JSON-LD is often easier to maintain. They may be appropriate when structured properties are closely tied to a template’s visible HTML or when an existing system already implements them reliably.

Format choice matters less than accuracy, consistency, and maintainability. Valid markup that remains synchronized with the page is more useful than a fashionable format that becomes stale.

How to test structured data

Testing should answer more than one question. A document may be valid according to Schema.org while still being incomplete for a particular Google feature. It may also contain correct code that is not present in the rendered page because of a template, caching, or JavaScript problem.

Google Rich Results Test

Use the Google Rich Results Test to determine whether Google can detect markup associated with its supported rich-result features. The tool can identify errors, warnings, and detected items.

A passing result indicates technical eligibility for a supported feature. It does not guarantee that the feature will appear in search results.

Schema Markup Validator

Use the Schema Markup Validator to examine Schema.org vocabulary and syntax more broadly. This is useful for structured data that is valid but not tied to a Google rich-result feature.

Google Search Console

After publication, Google Search Console can help confirm whether Google can access the URL, render the page, and detect supported structured data. Relevant enhancement reports may show site-wide patterns that are difficult to see while testing one page at a time.

Manual review

Validation tools cannot determine whether every statement is truthful or contextually appropriate. A human review should compare the markup with the visible page and confirm that names, dates, authors, prices, availability, addresses, and relationships agree.

Common structured data mistakes

• Marking up information that users cannot verify on the page. Important structured claims should be supported by the visible content.
• Choosing a type for its appearance rather than its meaning. A service page should not be labeled as a product merely to pursue product features.
• Publishing copied placeholders. Example names, URLs, dates, images, prices, and identifiers are easily overlooked.
• Confusing validity with eligibility. Schema.org-valid markup may not correspond to a supported Google feature.
• Using unsupported or outdated guidance. Search feature requirements change, even when the underlying Schema.org type remains available.
• Inventing reviews or ratings. Review markup must describe genuine review content and follow the relevant platform policies.
• Creating duplicate or conflicting entities. Plugins, themes, and custom code may each generate their own markup with inconsistent names or types.
• Failing to maintain dynamic properties. Prices, availability, event dates, job expiration dates, and page modification dates can become inaccurate.
• Using JavaScript without checking rendered output. Dynamically inserted markup should be tested as search systems actually receive it.
• Treating warnings as identical to errors. An error may prevent eligibility, while a warning often identifies a recommended property. Each message should be interpreted in context.

If the structured layer contradicts the visible page, it creates uncertainty instead of reducing it.

Structured data and accessibility

Structured data and web accessibility address different needs. JSON-LD is generally intended for machine interpretation by parsers and search systems; it does not repair missing labels, poor keyboard support, unclear headings, weak contrast, or inaccessible forms.

Accessibility depends primarily on the page people actually encounter: its content, HTML, interaction design, visual presentation, and compatibility with assistive technologies.

The two practices still share a useful foundation. Both benefit from information that is:

• accurate and consistently named;
• organized into understandable relationships;
• supported by meaningful HTML;
• available in the visible page experience;
• maintained as the underlying facts change.

A clear heading hierarchy helps people navigate the document. An accurate Article description helps a parser identify its authorship and publication details. Neither replaces the other.

Structured data in modern retrieval systems

Web information is interpreted through several layers. Browsers parse and render the document. Assistive technologies use HTML and accessibility information. Search engines crawl, render, index, and evaluate pages. Other retrieval systems may extract passages, entities, links, metadata, or structured markup.

Structured data can contribute an explicit description of the page, but its role should not be overstated. There is no single rule stating that every AI-assisted retrieval system uses Schema.org markup in the same way. Some systems may use it directly, some may combine it with visible content and other signals, and others may rely mainly on text extraction.

This makes the visible page the more durable foundation. Clear definitions, descriptive headings, explicit relationships, stable URLs, and useful internal links remain important whether or not a particular system reads the JSON-LD.

The most resilient approach is layered:

• Write complete and understandable visible content.
• Use semantic HTML to organize the document.
• Use descriptive metadata where appropriate.
• Connect related pages through meaningful internal links.
• Add structured data when it can describe real entities and relationships accurately.

Structured data is one part of a broader information architecture for retrieval. It can strengthen clarity, but it should not carry meaning that the page itself fails to communicate.

What structured data cannot do

Structured data cannot:

• guarantee indexing, ranking, inclusion, citation, or a rich result;
• make inaccurate information trustworthy;
• replace useful visible content;
• repair inaccessible HTML or interaction design;
• resolve a confusing site structure by itself;
• create genuine reviews, expertise, products, events, or job openings;
• force a search engine or retrieval system to interpret a page in a particular way;
• remain accurate without maintenance.

It works best when the page already provides something coherent and worth understanding.

A practical structured data checklist

Before publishing or revising structured data, check the following:

• Does the selected type accurately describe the page?
• Is the main entity clearly identifiable?
• Does the markup agree with the visible content?
• Are names, URLs, dates, images, prices, and locations correct?
• Are dynamic details likely to remain synchronized?
• Are multiple plugins or templates generating conflicting markup?
• Does the code pass the Schema Markup Validator?
• If a Google search feature is relevant, does it pass the Rich Results Test?
• Have current feature guidelines been reviewed?
• Has a person checked the meaning, not only the syntax?

The final question is the most important: Does this markup clarify what the page truly is?

Structured data should clarify, not decorate

The formats and testing tools have changed since structured data began appearing more widely across the web. JSON-LD is now commonly preferred, search features are more formally documented, and machine interpretation extends beyond conventional search result pages.

The central principle has remained stable. Structured data provides a shared language for describing entities and relationships. Used carefully, it can make a page less ambiguous to systems that process web information.

That value depends on the foundation beneath it: accurate content, meaningful HTML, accessible presentation, coherent site structure, and ongoing human review.

Do not use structured data to make a page appear to be something it is not. Use it to describe more clearly what is already there.