Schema.org Structured Data: How to Teach Search Engines to Understand Your Website

Let’s imagine a product card. For a user, the page is clear. But a search crawler sees only a DOM tree with text inside divs. It doesn’t know that 999.00 is a price, 4.7 is a rating, and 234 is the number of reviews. They are just strings.

Schema.org markup adds a semantic layer on top of HTML. It explicitly tells the search engine: “this is a product, here is its price, here is its rating.” The data becomes structured and machine-readable.

Schema.org is a dictionary of standardized data types created in 2011 jointly by Google, Microsoft, Yahoo, and Yandex. Instead of each search engine inventing its own markup format, they agreed on a common standard. Currently, it is used by more than 45 million domains.

Rich Snippets — enhanced results in search

The main effect of structured markup is changing the appearance of a result in search.

Regular result:

Smartphone Example Pro 256GB — buy at Example Shop
Flagship smartphone with a 108 MP camera. Delivery across Europe.

With Product + Offer + AggregateRatingmarkup:

Smartphone Example Pro 256GB — Example Shop
★★★★★ 4.7 (234 reviews) · $999.00 · In stock
Flagship smartphone with a 108 MP camera. Delivery across Europe.

The second option takes up more space, contains key information (price, availability, rating), and stands out from competitors.

Google provides specific cases in its documentation:

• Rotten Tomatoes: +25% CTR on pages with markup
• Food Network: +35% visits after implementing structured data
• Rakuten: users spend 1.5 times more time on pages with markup

The numbers vary, but the pattern is consistent: rich snippets increase CTR by 20–30% compared to regular results.

Search engines are increasingly using LLMs to generate answers. Structured data helps these models interpret content more accurately.

The better a search engine understands content, the higher the chance of appearing in AI-generated answers and snippets.

Schema.org is a dictionary, but you can “speak” it to search crawlers using different “languages” (syntaxes). Google, Yandex, and Bing support three main formats, but their relevance differs significantly.

The oldest and classic markup method, where Schema.org attributes are embedded directly into HTML tags using itemscope, itemtype, itemprop.

How it looks:

<div itemscope itemtype="https://schema.org/Article">
<h1 itemprop="headline">How microdata works</h1>
<span itemprop="author">Ivan Petrov</span>
</div>

Pros: the search engine is guaranteed to see the connection between the code and the text visible to the user.

Cons: bulky. Any design change requires rewriting the markup. The risk of “breaking” the layout while editing data increases.

In many ways similar to Microdata, but based on W3C Semantic Web standards and uses vocab, typeof, property attributes.

Status: In modern web development, it has practically been displaced. Found in older projects or specific XML documents. It is not recommended for new websites.

A format for transmitting structured data as a regular JSON object. Unlike Microdata and RDFa, it does not mix with HTML markup and is placed inside a <script> tag.

How it looks:

<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "How microdata works",
"author": {
"@type": "Person",
"name": "Ivan Petrov"
}
}
</script>

Pros:

• Code cleanliness: structured data is separated from visual layout.
• Flexibility: markup can be easily generated dynamically — on the server or client.
• Search engine recommendations: Google officially calls JSON-LD the preferred format.

Cons: Requires accuracy when working with nested objects and maintaining correct JSON structure.

In practice, JSON-LD is the standard for Schema.org in the modern web. Microdata and RDFa remain supported but are used less and less — mainly in legacy projects or when data must be tightly bound to HTML.

Any markup, regardless of its complexity, follows a single logic. It is a regular JSON object containing reserved keys understood by search crawlers.

A required field that tells the search engine which dictionary is used to interpret the data. The context is specified once in the root object. Nested objects inherit it.

"@context": "https://schema.org"

"@type": "Organization"

Defines what the markup describes: an organization, product, article, or event. The type determines the available properties and how search engines interpret the data.

Schema.org contains more than 800 types organized in a hierarchy.

For example:

Thing
  └── Organization
        ├── Corporation
        ├── LocalBusiness
        │     ├── Restaurant
        │     ├── Store
        │     └── ...
        └── ...

LocalBusiness inherits all Organization properties but adds specific ones: openingHours, priceRange, geo. The more precise the type selection, the better the search engine understands the content.

Key-value pairs describing the object. The set of fields depends on the type: for a product it is price, for an article — datePublished.

Each type has its own set of properties. They are divided into:

• Required — without them the markup will not pass validation (for example, name for Product)
• Recommended — improve the quality of rich snippets (for example, description, image)
• Optional — additional information. This also includes enums — strict URL constants from the dictionary, for example "availability": "https://schema.org/InStock"

The full list of properties for each type is on schema.org. For example, for Product: schema.org/Product

Properties can contain not only strings and numbers, but also other objects with their own @type:

{
"@context": "https://schema.org",
"@type": "Product",
"name": "Smartphone Example Pro",
"brand": {
"@type": "Brand",
"name": "Example"
},
"offers": {
"@type": "Offer",
"price": "79990",
"priceCurrency": "RUB",
"availability": "https://schema.org/InStock"
}
}

Here brand is not a string but a Brand, offers is an Offer object with price and availability. Such nesting allows passing more structured information to the search engine.

A unique identifier (usually a URL with a hashtag) that allows linking objects together.

Why this is needed: Imagine you have a product and a selling organization on the page. Instead of describing all company data (address, logo, social networks) inside each product, you can:

• Describe the organization once and assign an @id:

{
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "Example Shop",
  "logo": "https://example.com/logo.png"
}

• Reference this @id in the product schema:

{
"@type": "Product",
"name": "Smartphone Example Pro",
"offers": {
"@type": "Offer",
"price": "79990",
"seller": {
"@id": "https://example.com/#organization"
}
}
}

Often, several schemas need to be placed on one page: company information, breadcrumbs, product data.

Multiple <script> tags are a valid option, but @graph allows explicitly showing relationships between entities and avoiding duplication:

{
"@context": "https://schema.org",
"@graph": [
{
"@type": "Organization",
"@id": "https://example.com/#organization",
"name": "Example Shop"
},
{
"@type": "Product",
"name": "Smartphone",
"offers": {
"@type": "Offer",
"seller": { "@id": "https://example.com/#organization" }
}
},
{
"@type": "BreadcrumbList",
"itemListElement": [...]
}
]
}

When working with microdata, there are two main sources.

Google Search Central — schemas that are guaranteed to support rich results in Google, with strict requirements for mandatory fields. For most business tasks, this gallery is sufficient.

Schema.org — the full dictionary of the standard (800+ types). Useful when you need to find a specific type not officially supported by Google or to study all available properties of an entity.

When implementing Schema.org structured data on a website, the question arises: how to organize the code so that it is reusable, maintainable, and scalable?

The approach is based on separating responsibilities into four levels:

1. Base rendering component — responsible only for outputting JSON-LD
2.  Schema Generators — functions that build the structure for specific schema types
3. Page schema components — combine multiple schemas for specific pages
4. Usage in pages — declarative placement of schemas

The only component that directly works with the DOM and is responsible for correctly outputting JSON-LD markup into HTML.

import React from 'react';
import { JsonLdSchema } from '../types';

type Props = {
data: JsonLdSchema | JsonLdSchema[] | null;
};

export default function JsonLd({ data }: Props) {
if (!data) return null;

const schema = Array.isArray(data)
? { '@context': 'https://schema.org', '@graph': data.filter(Boolean) }
: { '@context': 'https://schema.org', ...data };

return (
<script
type="application/ld+json"
dangerouslySetInnerHTML={{ __html: JSON.stringify(schema) }}
/>
);
}

The component accepts either a single schema object or an array of schemas (in which case it automatically wraps them in @graph), allowing multiple related schemas on one page.

Functions encapsulate the logic of building specific Schema.org markup types.

import { CreateBreadcrumbListSchemaParams } from '../types';

export function createBreadcrumbListSchema({
items,
baseUrl = '',
}: CreateBreadcrumbListSchemaParams): JsonLdSchema {
const itemListElement = items.map((item, index) => ({
'@type': 'ListItem',
position: index + 1,
name: item.name,
item: {
'@type': 'Thing',
'@id': `${baseUrl}${item.link}`,
},
}));

return {
'@type': 'BreadcrumbList',
itemListElement,
};
}

Components combine several schema types for specific pages.

import { createOrganizationSchema } from '../creators/createOrganizationSchema';
import { createWebSiteSchema } from '../creators/createWebSiteSchema';
import { JsonLdSchema } from '../types';
import JsonLd from './JsonLd';

export function HomePageSchema() {
  const schemas: JsonLdSchema[] = [];
  
  const organization = createOrganizationSchema({
    name: 'Company Name',
    url: 'https://example.com',
    logo: 'https://example.com/logo.png',
    description: 'Company description',
    ...//other properties applicable to your project
  });
  schemas.push(organization);
  
  const website = createWebSiteSchema({
    name: 'Site Name',
    url: 'https://example.com',
    ...//other properties applicable to your project
  });
  schemas.push(website);
  
  return <JsonLd data={schemas} />;
}

Placing schema components on web application pages.

// app/page.tsx
import { HomeSchema } from '@/components/schema-org';

const Home = async () => {
  return (
    <>
      <HomeSchema />
      {/* Page content */}
    </>
  );
};

export default Home;

Schema.org markup can live in both Server and Client components (depending on the data source).

Suitable for:

• Websites with many pages and content types (e-commerce, media, catalogs)
• Projects where markup is needed on 10+ pages
• Teams of several developers
• Cases where type safety and long-term maintainability matter

Excessive for:

• A simple landing page with 2–3 pages
• Microdata needed on only one page
• MVP or one-time project

An alternative approach for simple cases — direct JSON insertion:

export default function Home() {
  return (
    <>
      <script type="application/ld+json">
        {JSON.stringify({
          '@context': 'https://schema.org',
          '@type': 'Organization',
          name: 'Company Name',
        })}
      </script>
      {/* Page content */}
    </>
  );
}

After adding Schema.org, it is important to verify that the markup is actually read by search engines. Even a small typo — an extra comma or incorrect date format — can cause the search engine to completely ignore the markup. To avoid this, use three validation stages.

1.  “Here and Now” Validation Tools»

For a one-time check of a specific page or code snippet, use two complementary services:

• Schema Markup Validator (quality standard). This is the official tool from Schema.org. It checks general logic and semantic correctness: validity of types, relationships between nested elements, and syntax errors in JSON-LD.

Important: This tool does not guarantee the appearance of “stars” in search — it only confirms that JSON-LD is written without errors.

You can validate page markup in Schema Markup Validator in the following ways:

• by code snippet

• by your page URL

• Google Rich Results Test  (ticket to search results). A specialized tool for evaluating whether markup is eligible for enhanced results in Google.

Important: If there is a “Critical error” (red icon), Google will definitely not show an enhanced snippet.

You can validate page markup in Google Rich Results Test in the following ways: 

• by code snippet.

• by your page URL.

•  Monitoring After Publication: Google Search Console

If validators check a single page, Google Search Console monitors the entire site over time.

• Enhancements section: Reports for all markup types (Product, FAQ, Breadcrumbs, etc.) will appear automatically.
• Error control: If a template breaks and markup “shifts” across many pages, Search Console will immediately send an email notification.
• Analytics: In the “Performance” report, you can filter by “Search appearance” to see how many clicks came specifically from enhanced results.

If markup is implemented via JSON-LD, you can inspect it directly in the browser without copying code to external services.

1. Open the required page
2. Press F12 → Console tab

Insert the code:

document.querySelectorAll('script[type="application/ld+json"]').forEach(script => { console.log(JSON.parse(script.innerText)); });

All page schemas will be displayed as expandable objects. If there is an error in the code, the console will highlight it.

Data correctness:

• The markup type matches the meaning of the page (for a blog article, BlogPosting is better than the generic Article).
• Price, rating, and dates in JSON-LD match what the user sees on the page.

Data format:

• Dates in ISO 8601 format (2026-02-12 or 2026-02-12T14:30:00+03:00).
• Price specified without currency symbols: "price": "1500" or "price": 1500. Currency — in a separate field priceCurrency.

Technical accessibility:

• robots.txt does not block access to pages with markup
• JSON-LD is delivered via SSR. Although Google handles JavaScript, other systems (Yandex, Pinterest, messengers) may ignore markup if it loads only in the browser

Tool validation:

• Schema Markup Validator — use during development to ensure clean code and proper object nesting.
• Google Rich Results Test — use right before deployment to confirm Google approves your data for enhanced snippets.
• Google Search Console — use after indexing to monitor markup across the entire site and detect issues in time.

Markup does not match content: you cannot specify prices, ratings, or breadcrumbs that users do not see. Mismatch can lead to manual action and complete disappearance of rich snippets for the entire site.

Nonexistent properties: Schema.org is a strict dictionary. Properties are written in camelCase. Common mistakes:

• Invented fields (productColor instead of color)
• Typos (avalability instead of availability)
• Incorrect case (PriceCurrency instead of priceCurrency)

The validator may show a warning, but the search engine will simply ignore incorrect fields.

Duplicate markup: do not use Microdata and JSON-LD for the same object on the same page. This confuses crawlers.

Broken connectivity (@id): if @id identifiers are used to link objects (for example, author and article) but the objects themselves are not fully described, Google will return a data connectivity error.

Overuse: do not try to fill all 40 fields offered by Schema. Better 5–7 key and accurate properties than a canvas of unnecessary information.

Useless pages: there is no point marking up cart pages, personal accounts, registration pages, or pages blocked in robots.txt (noindex). Crawlers either won’t access them or won’t show them in search.

Microdata is a powerful tool, but not a “magic pill.” It is important to understand its limitations:

• It is not a ranking factor. Schema.org will not push a site to the top. It affects clickability (CTR), not position.
• It does not guarantee rich snippets. Even perfectly valid markup is only a request to the search engine. Google decides when and for which user to show an enhanced snippet and when to leave a regular link.
• It does not replace quality content. If the page text itself is weak or useless, no markup will make users click it.

Structured markup is not just “additional tags”; it is a direct communication channel with search engine algorithms and neural networks. In a world where millions of links compete for user attention, structured data becomes your main invisible advantage.

Key points:

• JSON-LD is the de facto standard. Forget bloated HTML. Use clean, readable scripts that are easy to scale in any modern framework.
• CTR instead of positions. Markup alone will not bring you to top-1, but it will make your snippet “starred.” In search, the winner is not the one with more text, but the one people want to click.
• Connections are more important than keys. Help crawlers connect entities: author with article, product with brand. The clearer your “data graph,” the higher the search engine’s trust.
• Validation is mandatory. One extra comma can “turn off” your stars in search. Check code before release and monitor Search Console after.

And remember: in the era of AI search, the winner is the one whose content is better structured for machines and more useful for people. Make your website understandable for AI today, and tomorrow it will treat you as a primary source.

Examples of specific schemas with ready-to-use code — in the next article.