Structured data explained simply

What structured data describes

Structured data assigns information to specific properties. Rather than simply mentioning a company name and address in a paragraph, markup can explicitly identify these details as the name and address of an organisation. This makes it clearer which information belongs to which entity. The markup is an additional description of the page, not a place for a different, more attractive offering.

The fundamental distinction is between content and meaning: a page might display a publication date, for example. In structured data, that date can be identified as the publication date of an article. Another date may represent the last substantive update. Confusing the two produces a misleading statement, even if the technical format can be read without errors.

In its introduction to structured data, Google explains how this information can help with processing. It may be a prerequisite for certain supported features. However, this does not mean that every piece of information that can be marked up will receive an enhanced display. Your page first needs a clear purpose, accessible content and accurate information.

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

Schema.org provides a shared vocabulary of types and properties. A type describes something such as an organisation, an article or a product. Properties identify associated details such as a name, author or offer. The Schema.org directory therefore provides guidance on what the terms mean, but makes no promise about their use by a particular search engine.

JSON-LD is a format in which this information can be embedded in a machine-readable form. On a website, this often happens in a dedicated script element. The markup itself does not appear as a normal paragraph of text. This is why consistency with the content accessible to visitors is so important. A hidden claim does not become accurate simply because it appears in formally valid JSON.

Google supports various formats for relevant features and generally recommends JSON-LD where the particular feature allows it. Before implementation, check which syntax, properties and requirements apply to your specific case. A template from an old project should therefore never be reused without review. Copied identifiers, incorrect addresses and details that only applied to the original website are particularly problematic.

Classify organisations and local businesses correctly

Organization describes an organisation. This may include its actual name, website and relevant identity information, for example. Use the data of one clearly identified organisation and do not combine several companies into a single entry. If a brand name differs from the legal name, model their relationship deliberately and keep the information on the website clear and understandable.

LocalBusiness is a more specific type for a local business and has further subtypes. It does not automatically fit every page containing a place name. A region where you provide services is not a separate business location simply for that reason. Do not invent additional branches or addresses to appear relevant to more places.

For a genuine location, contact details, the address and, where applicable, opening hours must be kept up to date. A move or a change in availability often affects several data sources at once. Record where this information is maintained in the content management system. If local details are the main focus, the Google Business Profile service may also be relevant; however, markup on your website does not change that profile.

Which data type suits which page?

The type follows the actual main purpose of a page. An editorial explanation is not a Product simply because it helps attract customers. Conversely, a genuine product detail page should describe the product offered and its accurate properties. Start by asking what the page actually presents, and only then choose the appropriate type.

Service describes a service, but does not automatically mean an enhanced result format supported by Google. BreadcrumbList sets out the steps in a page hierarchy. This list should match your actual navigation, not serve as a hidden collection of desired search terms. Article is suitable for editorial articles; correctly assigning the author, heading and date matters more than including the longest possible list of optional fields.

Product can describe a product. Additional information about offers, availability and prices must match the specific content. Requirements differ depending on the intended Google feature. Before implementation, you should therefore check the current feature scope, the supported kind of product page and all the details required for it. A general Schema.org type alone does not confirm this eligibility.

FAQPage and the limits of enhanced search displays

In Schema.org, FAQPage can describe a page with questions and answers. However, the vocabulary and Google's search features operate on two different levels. The Google documentation update checked for this article states that the enhanced FAQ display has no longer appeared in Google Search since 7 May 2026. You should therefore not sell FAQ markup as a way to obtain these additional search results.

The official documentation updates also note the removal of the previous FAQ documentation. Useful, visible questions and answers nevertheless remain worthwhile when they resolve genuine uncertainties for your visitors. Write this content for people, not as a pretext for a technical enhancement. Whether another application uses the corresponding data must be checked separately.

As a general rule, Google does not support every Schema.org type as an enhanced search result. Even for supported types, correct implementation and meeting the requirements do not guarantee appearance. The search query, processing and other conditions play a role in the actual display. An enhanced preview in a testing tool is therefore not a guaranteed future place in search.

Visible content, accuracy and completeness

Google's general guidelines require accurate markup that represents the page content. Do not mark up services you do not offer or information unavailable to visitors. Content can also appear in accessible expandable sections; what matters is that the markup does not turn the actual content into a different story. A data field that exists only technically is no substitute for transparent information.

Ratings require particular care. Do not invent stars, numbers of satisfied people or supposed reviews. Positive verbal feedback does not automatically produce a rating metric you are free to use. Individual Google review features may also have their own restrictions. Before implementation, you should therefore check the source, permissibility and current requirements of the chosen use case.

Prices must not be added simply because a generator provides a field for them. An individual quotation is not the same as a fixed offer available at a particular price. Use only details you can genuinely substantiate and explain on the page. The same applies to availability, delivery terms and additional locations. Missing information is a reason to clarify matters, not to invent details.

The additional graphic shows three related layers: the visible website content, its structured description and possible processing by search engines. There is explicitly no guarantee of success between the second and third layers. This arrangement makes clear that good markup explains existing content and does not make up for a lack of substance in the offering.

Demo : select suitable fields without actually publishing

The local markup builder lets you select a page type and view a simplified structure with suitable fields. Try switching between a company profile, a service and an article, for example. Consider which information would need to be visible on each page for the markup to be factually justified. The simplified structure is a learning aid, not a complete implementation template.

{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "name": "…",
  "address": "…",
  "telephone": "…",
  "openingHours": "…",
  "url": "…"
}

The demo does not insert code into your website or connect to an external interface. It does not save or send anything. Reset returns you to the initial state; all controls should also be accessible with the keyboard. A selected list of fields is neither a technical certification nor confirmation that Google offers an enhanced result format for it.

Check required fields and recommended details

Distinguish between a valid Schema.org term and the requirements of a specific Google Search feature. A vocabulary can describe a property without making it mandatory for every use. Google, by contrast, specifies required and recommended details for supported features. The required properties must be present for the particular feature; recommended information can usefully supplement the description.

Do not fill in optional fields blindly. A smaller set of accurate markup is better than an extensive structure full of assumptions. If a required detail is missing, first check whether it can be obtained factually and displayed on the page. If this is not possible, the intended feature may be unsuitable for that page. This is not an invitation to invent a substitute value.

If several extensions already output data, first establish an overview. Multiple entries are not inherently wrong, but they may describe the same organisation with different names or addresses. A website analysis should therefore examine the actual output, not just the settings of a single tool.

Identify errors through tests, Search Console and maintenance

The Rich Results Test checks the enhanced result types supported by Google. It can provide errors and notices about detected items. A Schema.org type without a corresponding Google feature does not necessarily appear there as a supported result. This does not mean that the term is invalid within the vocabulary. Check general syntax and Google eligibility as separate tasks.

Search Console can provide relevant reports and notices for detected, supported features. Before implementation, check which reports your property actually shows. The absence of a notice proves neither correct markup across all pages nor guaranteed processing. If problems arise, examine the affected page, its accessibility and the actual rendered output together.

Typical sources of errors include missing required details, incorrect date formats, outdated prices and contradictory automatically generated entries. The general guidelines also emphasise content quality. A green technical test result therefore cannot confirm that every statement is true and every guideline has been met. Keep a clear record of test results and the reason for each change.

Plan maintenance alongside content work. When an article is revised, a product removed or an address changed, the associated data must also be reviewed. You will find accessibility fundamentals in the draft Technical SEO. The article SEO titles and meta descriptions, which should also be marked as a draft, addresses a different layer of search presentation. If you need a specific review, you can request a website analysis.

Summary

• Structured data describes existing information in a machine-readable format.
• Schema.org provides the vocabulary; JSON-LD is one possible technical representation.
• Choose types according to the actual page content, not the search results you hope to achieve.
• Do not invent prices, ratings or additional locations.
• Google does not support every type as an enhanced search display.
• Technical tests and ongoing content reviews belong together.

Frequently asked questions

Sources

1. Intro to How Structured Data Markup Works | Google Search Central | Documentation | Google for DevelopersGoogle · checked on 2026 - 11 - 05
2. General Structured Data Guidelines | Google Search Central | Documentation | Google for DevelopersGoogle · checked on 2026 - 11 - 05
3. Schemas - Schema.org Schema.org · checked on 2026 - 11 - 05
4. Latest Google Search Documentation Updates | Google Search Central | What's new | Google for DevelopersGoogle · checked on 2026 - 11 - 05

Related articles

• Technical SEO: the essential basics
• How to write effective SEO titles and meta descriptions
• GEO and SEO: what is the difference?