Schema Markup: What It Is and How It Helps Search Engines

What is Schema markup?

Schema markup is code that labels information on a webpage so search engines and other machines can understand it more precisely.

A visitor can look at a product page and recognise its name, price, availability and customer rating from the design. A machine receives HTML containing text, links and images. Structured data explicitly connects those values with meanings such as:

Type: Product
Name: Trail Running Shoe
Price: 89.00
Currency: GBP
Availability: InStock
Brand: Example Sports

The markup does not replace the visible product page. It describes information that the page already provides.

The terms Schema markup and structured data are often used interchangeably in SEO. More precisely:

• Structured data is information organised in a consistent machine-readable format.
• Schema.org supplies a shared vocabulary for describing things and their properties.
• Schema markup is the common name for adding that vocabulary to a webpage.
• JSON-LD, Microdata and RDFa are formats that can carry the information.

That distinction matters because valid Schema.org markup is not automatically eligible for a Google rich result. Google supports particular types and properties for particular search features.

How Schema.org and structured data fit together

Schema.org is a collaborative vocabulary used to describe entities and the relationships between them. Its hierarchy contains types such as Organization, LocalBusiness, Product, Article, Person and Event.

Each type can have properties. For example, an Article can have a headline, author, image, datePublished and dateModified. The author may itself be a Person or Organization, creating a relationship between two entities.

A structured-data statement therefore answers three questions:

1. What is this thing? The @type, such as Article.
2. Which thing is it? Its name, URL, identifier or @id.
3. What do we know about it? Properties such as author, date or price.

Schema.org defines a much wider vocabulary than any single search engine uses for visible search features. A property can be valid according to Schema.org without being required, recommended or displayed by Google.

When implementing Schema markup for SEO, consult both Schema.org for the vocabulary and relationships, and the search engine's current documentation for supported features, eligibility rules and required properties.

How search engines use Schema markup

To identify the subject of a page

Structured data can make the page's main entity explicit. A string such as “Clearcrawl” might otherwise be a product, company, author or article title. An Organization object identifies the intended meaning and supplies supporting properties.

To understand relationships

Markup can connect an article to its author, a product to its offers or a local business to its address and opening hours. These relationships help machines interpret information that may be scattered across the visible page.

To assess eligibility for search features

Google uses supported structured data to determine whether a page may be eligible for particular rich results and search experiences. A product result, for example, may include price, availability or ratings when the page and markup satisfy the relevant requirements.

Eligibility is an opportunity, not a promise. Google may choose a standard result even when the implementation is valid.

To process information at scale

A consistent template lets a search engine interpret thousands of similar pages. It also lets the website owner audit them as a group. One malformed template can create the same problem on thousands of URLs, which is why sitewide validation matters.

What are the benefits of Schema markup?

Clearer machine-readable meaning

Schema markup removes some ambiguity by declaring the page's entities and properties directly. It supports the visible content with a consistent machine-readable description.

Eligibility for rich results

Supported structured data can make a page eligible for enhanced search presentation. Depending on the content type, this may include product price, event dates, recipe details, article imagery or breadcrumb paths.

The available features and requirements change over time. Choose markup because it accurately describes useful content, then check current search-engine documentation rather than relying on an old list of rich results.

Consistency across templates

Structured data encourages a site to define important information consistently. A product template needs a reliable source for price and availability. An article template needs dependable author and publication data.

This can expose underlying content-model problems. If the website cannot produce an accurate author URL or current stock status, adding markup alone will not solve the data issue.

Easier auditing

Because the information follows a known structure, a crawler can identify where types are present, absent or inconsistent. Teams can find errors across a template instead of checking each page manually.

Schema markup, LLMs and AI visibility

Schema markup is also relevant to AI-powered search and discovery because it expresses entities, attributes and relationships in a predictable machine-readable form.

An AI system trying to understand a business, product or article may need to distinguish between similar names, connect an author with their work, or identify whether a number represents a price, rating or product identifier. Accurate structured data can make those relationships explicit.

For example, Product markup can connect:

Product > Brand
Product > Offer > Price
Product > Offer > Availability
Product > SKU or GTIN

That structured context can help search and discovery systems process the page more reliably. Microsoft has described structured product data as useful for search, shopping experiences and AI-powered assistants. Google also advises sites appearing in its AI search experiences to maintain crawlable, indexable pages and make structured data agree with the visible content.

Schema supports clarity rather than guaranteeing inclusion

There is no dependable rule that adding Schema markup will cause a page to be cited by an LLM, included in an AI answer or recommended by an assistant. Different systems retrieve, index and interpret web content in different ways, and their public documentation does not promise that every Schema.org property will be used.

Treat structured data as one part of AI visibility alongside:

• Useful content that answers real questions.
• Clear authorship and organisational identity.
• Crawlable, indexable pages.
• Consistent names, URLs and business details.
• Reliable product identifiers and current availability.
• Strong internal links and canonical signals.
• Accurate modification dates and fresh source data.

Entity consistency matters

The same organisation, person or product should not be described differently across templates. Use stable names and identifiers, connect official profile URLs where appropriate and keep the markup aligned with the visible page.

Do not create speculative AI-only markup

Use established Schema.org types that accurately describe the page. Adding unsupported properties, hidden keyword lists or claims written only for machines can make the implementation misleading without improving AI visibility.

What Schema markup cannot do

• It does not guarantee a rich result. Passing a validation test means the tested code meets that tool's checks. Google still decides which result format is useful for a particular search, person, location and device.
• It is not a general ranking shortcut. Structured data helps search engines understand content and may enable search features. It does not turn a weak, irrelevant or inaccessible page into a strong result.
• It cannot correct inaccurate visible content. Do not use markup to supply a different price, rating, author or event date from the information visitors can see.
• It does not make every Schema.org type visible in Google. Schema.org contains many types that have no special Google search presentation.
• It cannot compensate for blocked or non-indexable pages. A rich-result implementation on a URL blocked by access controls, returning an error or carrying a noindex directive cannot achieve its intended search purpose.

The same caution applies to AI visibility. Markup can provide clearer machine-readable context, but it cannot guarantee a citation, generated answer, recommendation or visit.

JSON-LD, Microdata and RDFa

Google supports three structured-data formats for Search.

JSON-LD

JSON-LD places a JSON object inside a script element, normally in the page's <head> or <body>. The data is separate from the visible HTML structure. Google recommends JSON-LD in most cases because it is usually easier to add, read and maintain at scale.

Microdata

Microdata adds attributes such as itemscope, itemtype and itemprop directly to HTML elements. It can work correctly, but large or nested objects may become difficult to maintain when the page design changes.

RDFa

RDFa also adds attributes to HTML and supports linked-data relationships. It remains a supported format, though it is less common in everyday SEO implementations.

Which format should you choose?

Use the format your platform can generate accurately and maintain consistently. For a new implementation, JSON-LD is generally the practical choice. Do not convert a valid, well-maintained implementation merely to follow fashion; assess the maintenance benefit and test the change first.

A simple JSON-LD example

The following example identifies an Academy page as an article:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Schema Markup: What It Is and How It Helps Search Engines",
  "url": "https://example.com/academy/schema-markup/",
  "image": "https://example.com/images/schema-markup-guide.jpg",
  "datePublished": "2026-09-23",
  "dateModified": "2026-09-23",
  "author": {
    "@type": "Organization",
    "name": "Clearcrawl",
    "url": "https://example.com/"
  }
}
</script>

The main parts are:

• @context identifies the Schema.org vocabulary.
• @type identifies the object as an Article.
• headline, url, image and the date properties describe the article.
• author contains a nested Organization object.

The values must come from the real page and publishing system. Replace the example domain, image and dates with accurate information. Do not copy example values into production.

JSON must also remain valid. Quotation marks, commas, brackets and value types matter. A missing comma can prevent the whole block from parsing.

How to choose the right Schema type

Start with the page's primary purpose. Ask what a visitor would say the page is about.

Use the most specific accurate type supported by the content. Do not choose a type only because its search appearance looks attractive.

Some pages contain several related objects. A product page may describe a Product, an Offer, a Brand and breadcrumb navigation. These objects should form a coherent description rather than several contradictory blocks.

Before selecting a type, confirm that the visible page genuinely contains the required information, check whether Google currently supports a relevant search feature, read the type-specific guidelines, decide where every value will come from, and plan how the data will stay current. Once you understand the markup, use a structured-data validation workflow and compare the page-specific requirements in the Article Schema guide.

Where should Schema markup be added?

Add markup to the page that primarily contains or represents the described information.

• Product on an individual product page.
• Article on an individual article.
• LocalBusiness on a page containing information about that location.
• Organization on the homepage or a single page describing the organisation.
• Event on the specific event page.

Avoid adding every available type to every URL. Repeating an identical organisation block across the site may be technically possible, but Google's guidance recommends placing the information on the homepage or a single organisation page. The useful placement depends on the type and the search feature.

Markup can be placed in the initial HTML or generated with JavaScript. If JavaScript creates it, confirm that the rendered output contains the completed data and that search engines can process it. Fast-changing product information deserves particular care because delayed or unreliable rendering can leave price and availability out of date.

How to implement Schema markup

1. 01
   Choose one page type

   Begin with a page template that has clear value, such as products, articles or locations. Avoid launching several unfamiliar types at once.

2. 02
   Read the current documentation

   Review the Schema.org definition and the relevant Google Search guide. Separate required properties from recommended ones and note any content-specific eligibility rules.

3. 03
   Map properties to real data

   For each property, identify the source in the CMS, catalogue or business database. Do not use placeholder text or infer facts the site does not hold reliably.

4. 04
   Generate the markup from the template

   Use the same source of truth as the visible page. When a product price changes, the displayed price and structured price should update together.

5. 05
   Test representative examples

   Test a normal page and edge cases: missing images, multiple authors, sale prices, unavailable products, optional addresses and other variations the template allows.

6. 06
   Release a small set

   Publish to a controlled sample before changing every page. Check the live rendered output, page status, canonical and indexability.

7. 07
   Roll out and recrawl

   Once the sample works, deploy the template more widely. Crawl again to confirm the type appears where expected and that errors have not spread across the site.

8. 08
   Monitor after release

   Use Search Console's relevant enhancement reports and URL Inspection where available. Allow time for recrawling and remember that eligibility does not guarantee a visible rich result.

How to test structured data

Use the Rich Results Test for Google features

Google's Rich Results Test checks whether a page or code sample is eligible for the Google rich-result types the tool supports. Use it when the goal is a Google search feature and follow the documentation for that specific type.

Use the Schema Markup Validator for the wider vocabulary

The Schema Markup Validator checks Schema.org structured data without limiting its feedback to Google rich-result features. It is useful for types and properties outside Google's supported search gallery.

They answer related but different questions:

• Schema Markup Validator: is this valid Schema.org markup?
• Rich Results Test: does Google recognise an eligible supported search feature here?

Test the live URL and the rendered page

A pasted code sample may be valid while the live template fails to publish it. Test representative live URLs after release, particularly when JavaScript generates the markup.

Treat errors and warnings differently

An error normally means a required element is missing or invalid for the tested feature. A warning usually identifies a recommended property whose absence does not necessarily block eligibility. Do not fabricate a value merely to remove a warning.

How to audit Schema markup across a website

Build an inventory by type

Group crawled pages by detected structured-data type. Compare the result with the templates that should contain each type. This reveals whether all product pages contain Product, whether Article has appeared on category pages accidentally, and whether old and new implementations are live at the same time.

Find missing coverage

Absence is often a template or data problem. Segment pages expected to contain a type, then find those with no corresponding object. Check whether the exceptions are legitimate rather than forcing a category page into Product.

Group errors by template

Prioritise patterns rather than raw URL counts. Five thousand pages missing offers.priceCurrency may share one template defect. Repairing the source is safer than editing pages individually.

Check crawlability and indexability

Structured data intended for Search belongs on accessible, successful and indexable pages. Review response codes, robots directives, canonicals and redirect behaviour alongside Schema reports.

Look for conflicting objects

Plugins, themes and tag-management systems can publish overlapping markup. Inventory every detected object and establish which system owns each one. Removing obsolete output is often as important as adding missing markup.

Compare the markup with visible content

Automated checks can catch missing properties and invalid values. Human review is still needed to confirm that the markup represents what the visitor sees. Sample pages from every important template and edge case.

Audit Schema markup with Clearcrawl

Clearcrawl gives the team a sitewide view of the pages and templates carrying the implementation. A testing tool can explain one URL in detail; a crawl reveals whether the same pattern is complete and consistent across the whole site.

Use both views together. Validate individual examples against the type-specific rules, then use the crawl to find every page affected by the same template.

How to fix and verify Schema problems

1. 01
   Confirm the intended type

   Make sure the selected type describes the page's primary content and remains supported for the intended search feature.

2. 02
   Identify the source of the output

   Find whether the markup comes from the theme, CMS, plugin, tag manager or custom application code. Check for another system producing a competing object.

3. 03
   Correct the underlying data

   Repair inaccurate prices, author records, addresses or dates at their source. Do not patch the JSON-LD while leaving the visible content or database wrong.

4. 04
   Repair the shared template

   Fix the generator that affects the page group. Handle optional properties and empty values deliberately so one incomplete record does not break the whole object.

5. 05
   Validate normal and edge-case pages

   Test a small but representative set in the appropriate validation tools. Include examples with optional fields, variants or unusual content.

6. 06
   Publish and recrawl

   Confirm that the live rendered page contains the revised markup. Recrawl the affected section and compare the new issue count with the original baseline.

7. 07
   Monitor processing

   Review Search Console reports and inspect important URLs after Google has had time to recrawl them. Investigate new errors at the template level.

Common mistakes

Frequently asked questions