Schema.org markup: what it is, which types you need and how to check it

What structured data and markup are

“Structured data” is Google’s term. Yandex calls the same technology markup or semantic markup. This article uses these terms as synonyms.

Google uses the structured data it finds on sites to understand a page’s content. Yandex states the goal of semantic markup as making it easier for search engines and other programs to extract and process information.

Schema.org is the vocabulary; JSON-LD, Microdata and RDFa are formats

Schema.org is a joint open project that creates and maintains schemas for structured data on the web. The vocabulary is used by Google, Microsoft, Yandex and other companies.

The vocabulary consists of types and properties:

• A type answers the question “what is this”: Organization is an organization, BlogPosting is a blog post, Service is a service.
• A property describes a characteristic of the object: name (name), site address (url), author (author), publication date (datePublished).
• A specific object of a given type with its own properties is called an entity.

Types are arranged in a hierarchy: the most general type is Thing, and all others inherit from it.

The vocabulary can be used with different serialization formats, including these three:

• JSON-LD is a separate block of code inside a <script> tag, placed in the page’s <head> or <body>.
• Microdata uses the itemscope, itemtype and itemprop attributes directly on the HTML tags of visible content.
• RDFa is an HTML5 extension, also based on tag attributes.

Google recommends using JSON-LD where possible. For Yandex, the format depends on the markup type — more on that in the section on the differences.

An example of JSON-LD using placeholder data — an organization and a blog post:

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Example Studio",
      "url": "https://example.com/",
      "logo": "https://example.com/logo.png"
    },
    {
      "@type": "BlogPosting",
      "@id": "https://example.com/blog/primer/#article",
      "headline": "How to choose a markup format",
      "datePublished": "2026-10-01T07:00:00Z",
      "author": { "@type": "Person", "name": "Anna Ivanova" },
      "publisher": { "@id": "https://example.com/#organization" }
    }
  ]
}

Here there are two main entities — the organization and the blog post; the author is described directly inside the post. The blog post’s publisher property doesn’t redescribe the organization — it references it through @id. @id is an entity identifier in JSON-LD; in Microdata its counterpart is the itemid attribute.

What markup helps with, and what it doesn’t

Helps with:

• Describing the page unambiguously. Markup tells a search engine what kind of page it is and what objects are on it, in a machine-readable form.
• Becoming eligible for a rich result. A rich result is a snippet with extra elements: a breadcrumb trail, an organization’s logo, a publication date, a product price. For content to appear in Google’s rich results, you need to fill in all the required properties of the type. Yandex states that semantic markup can improve how a snippet is presented.

Doesn’t guarantee:

• A rich snippet. Google doesn’t guarantee that structured data will appear in search results, even if the page is marked up correctly. Yandex likewise doesn’t guarantee that the data it picks up will appear in search results. How a result looks in the SERP can differ from the preview in a testing tool.
• Higher rankings. In the Google and Yandex documentation this article relies on, markup is described as a way to understand content and become eligible for a rich snippet — there’s no promise of higher rankings there. Google specifically clarifies that manual actions for markup violations strip a page’s eligibility for a rich result but don’t affect its ranking in web search.
• Indexing. A search engine only reads markup once it has crawled the page: Yandex states that a structured snippet can form after the next time its robot recrawls the page. If a page isn’t in the search index, its markup won’t show up in search results at all. How to check whether a page has been indexed is covered in a separate article.

Which markup types a site needs

Markup shouldn’t describe everything indiscriminately: you choose the type based on what’s actually shown on the page. Google recommends using the most specific type and properties from the Schema.org vocabulary that fit the content.

Type	Where it belongs	Key properties	How to check it
Organization	Homepage or an “About” page	name, url, logo, sameAs	Rich Results Test, Schema Markup Validator
WebSite	Homepage only	name, url; alternateName	Schema Markup Validator
BreadcrumbList	Pages with a visible breadcrumb trail	itemListElement → ListItem: position, name, item	Rich Results Test, Schema Markup Validator
Article / BlogPosting	Articles, news items, blog posts	headline, image, author, datePublished, dateModified	Rich Results Test, Schema Markup Validator
Service	A page for a specific service	name, description, provider, serviceType, areaServed	Schema Markup Validator
Product / Offer	Product page, product review	name; offers with price and availability	Rich Results Test, Schema Markup Validator
FAQPage	A page with a visible list of questions and answers	The questions and answers shown on the page	Schema Markup Validator; Google no longer shows FAQ snippets

Rich Results Test only works with data types eligible for Google’s rich results — the list is given in the tool’s help documentation. WebSite and Service appear in neither that list nor Google Search’s feature gallery, so it’s more practical to check their correctness in Schema Markup Validator. Yandex’s validator doesn’t appear in the column: its help documentation doesn’t list JSON-LD among the supported formats, though Microdata and RDFa can also be checked there.

Organization and WebSite

Organization describes a company. Google uses this markup to get more information about the organization, including a logo for its search results. It’s recommended to place it on the homepage or on a single page describing the organization, such as “About us”; it isn’t needed on every page. Google has no required properties for this type — you add whichever ones fit the organization.

WebSite describes the site as a whole. Google uses this markup as one of the sources for the site name shown in search results. It’s placed only on the homepage of a domain or subdomain; the required properties are name and url. It doesn’t guarantee that the specified name will be the one used.

The organization is a single entity for the whole site. It’s convenient to describe it once with a permanent @id and reference that identifier from the rest of the markup.

BreadcrumbList

A breadcrumb trail shows a page’s position in the site hierarchy and helps users orient themselves. Google requires the BreadcrumbList container to have at least two ListItem elements. Yandex describes breadcrumb markup in JSON-LD format using the BreadcrumbList type.

The trail in the markup must match the one the user sees: only visible content can be marked up.

Article / BlogPosting

Article, NewsArticle and BlogPosting help Google interpret articles better and display their headlines, images and publication dates more clearly. There are no required properties: you add whichever fit the page’s content. For the author.name property, Google recommends listing only the author’s name — without a job title or company name.

Service — for service pages (when it matches the content)

In Schema.org, Service is a service provided by an organization. The main properties are provider (who provides it), serviceType (the kind of service), areaServed (where it’s provided), and offers (the offer).

Google’s list has no dedicated rich result for Service. The point of this markup is to unambiguously describe what service the page is about and who provides it, not to get a special snippet. Use it only on a page for a specific service. In provider, reference the organization entity by @id. Only include a price if it’s shown on the page.

Product / Offer — for products

Product fits product description pages, reviews, and pages where a product can be bought. The sales offer — price and availability — is described through Offer. Google has several rich-result options for products. Product markup is a large topic in its own right; the main rule is the same: the price and availability in the markup must match what the buyer sees.

FAQPage — when it’s appropriate, and what changed in how it’s shown

In Schema.org, FAQPage is a page with one or more frequently asked questions. Status at Google as of October 3, 2026:

• Since September 2023, Google had shown FAQ snippets only for well-known, authoritative government and health websites.
• In May 2026, Google announced that as of May 7, 2026, FAQ rich results would no longer appear in search, and in June 2026 it removed their documentation. FAQ is no longer in the gallery of supported features.
• Google has not shown a rich result for step-by-step instructions (HowTo) since 2023.

Don’t confuse FAQPage with QAPage — these are different Schema.org types. QAPage describes a page with a single question and user-submitted answers; this markup is described, for example, in Yandex’s help documentation. The “Questions and answers” rich result is still in Google’s gallery.

What follows from this: implementing FAQPage for the sake of a Google snippet makes no sense. If a page has a genuine block of questions and answers, markup can describe it — but only the visible content, and without counting on a special appearance in Google’s search results.

Markup for Yandex and Google: what’s shared and what differs

What’s shared:

• Both systems work with the Schema.org vocabulary.
• Both require marking up only content visible to visitors.
• Neither guarantees that marked-up data will appear in search results.

What differs:

• Format. Google recommends JSON-LD. For Yandex, the requirements depend on the type: its help documentation describes breadcrumb markup in JSON-LD, but for strict catalog markup it warns that processing JSON-LD isn’t guaranteed. Yandex’s help documentation explains the basics of schema.org using Microdata examples.
• Set of types. Google has its own list of features eligible for rich results. Yandex lists its own: products, organizations, recipes, movies, questions and answers, video and others.
• Tools. Yandex’s validator checks markup against the requirements of Yandex’s services; Rich Results Test checks whether it’s eligible for a rich result in Google.

Practical takeaway: before implementing a specific type, check both systems’ help documentation for it. If the formats differ, decide type by type, not “for the whole site at once.”

How to check your markup

The checking sequence:

1. Before release, check the code or a test page in Rich Results Test and Schema Markup Validator; check Microdata or RDFa markup in Yandex’s validator as well. Google recommends using Rich Results Test during development.
2. Check the markup against the page’s visible content — using the checklist in the section on mistakes.
3. After release, look at the page with the URL Inspection tool in Search Console. The Rich result report shows the state of markup across the whole site.
4. Fix issues in the site’s code. Structured data lives on the site, not on Google’s servers, so fixing the code is what actually resolves the problem.

Tool	What it shows
Yandex’s structured data validator	Which data was recognized and whether it meets the requirements of Yandex’s services
Rich Results Test	Which of Google’s rich results are possible for the page
Schema Markup Validator	Syntax errors and all entities found on the page

The structured data validator in Yandex Webmaster

The validator is in the “Tools” section of Yandex Webmaster. It helps confirm that the metadata on pages is recognized correctly. Its help documentation lists the supported formats: microformats, Schema.org, Open Graph, HTML Microdata and RDFa. JSON-LD isn’t on that list, so check JSON-LD markup in Rich Results Test and Schema Markup Validator instead.

To check a page, enter its address in the “Document URL” field or paste the code and click “Check.” Under the “Check results” heading, the validator shows the recognized data or an error message. If the check succeeds, a structured snippet can form after Yandex’s robot next recrawls the page.

Rich Results Test and Schema Markup Validator

Rich Results Test is Google’s tool for checking rich-result eligibility. It accepts a page URL or a code snippet and recognizes JSON-LD, RDFa and Microdata. You can run the check as the smartphone or the desktop crawler. Google warns that a page can look different in search than it does in the preview.

Schema Markup Validator (validator.schema.org) checks markup against the Schema.org vocabulary without being tied to a single search engine. It finds syntax errors, extracts JSON-LD, RDFa and Microdata — including markup added by JavaScript — and shows a summary of the data graph it found. The tool is based on Google’s former Structured Data Testing Tool and is provided by Google for the Schema.org community.

If markup on a site is output by the theme, an SEO plugin and third-party modules, and errors keep coming back after updates, you need to check the whole site, not individual pages. This is part of markup review within technical SEO.

Common mistakes

Marking up content that isn’t on the page

Google explicitly prohibits marking up content hidden from users: if a description appears in JSON-LD, that same text must be in the page’s HTML code. Markup must accurately reflect the page’s content. Yandex likewise requires marking up only content visible to visitors, not the content of hidden tags.

Typical examples: a rating and reviews that aren’t on the page; a price or availability status that doesn’t match the product card; an FAQ the user never sees. Google can apply manual actions for such violations: the page loses its eligibility for a rich result.

Duplicate entities and disconnected @id values

The same organization can end up described several times: in the homepage template, in an article’s markup, in a contact block. If these descriptions have different names, different logos, or no shared identifier, the markup gives no indication that they’re all the same object.

@id exists exactly for this: in Schema.org it’s the built-in way to specify an entity’s identifier. Recommendations:

• Every key entity — the organization, the site, the author — has one permanent @id.
• The rest of the markup references that @id instead of redescribing the entity.
• An @id that’s referenced must actually be described somewhere in the site’s markup; a link to nowhere doesn’t create a connection.

Several plugins output markup in parallel

On WordPress and other CMSs, markup is often output by several components at once: the theme, an SEO plugin, a store or reviews plugin. The result can be two breadcrumb trails on one page, or two descriptions of the same article with different dates.

Check the page in Schema Markup Validator and see which entities it finds, and how many times. Keep one source for each markup type and disable the others in settings. If you can’t work out which component outputs what, an SEO audit that checks structured data can help.

Checklist for consistency between markup and visible content:

1. Every value in the markup — name, price, date, author — appears in the page’s visible text.
2. The markup type matches the page’s purpose: an article uses Article / BlogPosting, a service uses Service, a product uses Product.
3. The breadcrumb trail in the markup matches the visible one.
4. The organization, the site and the author are each described once and linked through @id.
5. The page doesn’t have two parallel descriptions of the same entity from different plugins.
6. Schema Markup Validator shows no errors, and Rich Results Test shows none for the types Google supports; Microdata or RDFa markup also passes Yandex’s validator.
7. After release, the markup has been checked against its state before the changes.

Markup and generative search

Generative search produces answers that AI generates from the material it finds. Here’s what Google’s official documentation says about structured data as of October 3, 2026:

• Fact. For a page to be used in Google Search’s AI features, there are no additional requirements to meet, no special files to create and no special markup to implement; dedicated Schema.org structured data isn’t needed for this.
• Fact. Among its general recommendations, Google lists keeping structured data consistent with the page’s visible text.
• Recommendation. Markup helps unambiguously describe a page’s entities — who the author is, which organization, which service or product is being discussed. So the same rules matter for generative search as for regular search: the markup is truthful, matches the visible content, and entities aren’t duplicated.

Markup doesn’t guarantee inclusion in, or citation by, AI-generated answers. It’s part of the SEO foundation that GEO — optimization for generative search — relies on. For more on how GEO differs from SEO, see a separate article.

Frequently asked questions

Which format should you choose: JSON-LD or Microdata?

Google recommends JSON-LD. For Yandex, the requirements depend on the markup type: its help documentation describes JSON-LD for some types, while for others processing JSON-LD isn’t guaranteed. Check both systems’ documentation for the specific type you need.

Does markup guarantee a rich snippet?

No. Neither Google nor Yandex guarantees that marked-up data will appear in search results, even when the markup is correct.

Does markup affect rankings?

Google describes markup as a way to understand a page’s content and as a path to rich-result eligibility. Per Google’s documentation, manual actions for markup violations strip rich-result eligibility but don’t affect ranking in web search.

Is markup needed for generative search?

Google states that special markup isn’t needed for its search’s AI features; what matters is that structured data matches the visible text.