Schema markup: what it is, which types matter and how to test it

Updated 24 Sept 20267 min readBy Max Beech

Schema markup is structured data, written in the schema.org vocabulary, that tells search engines and AI systems exactly what a page describes, such as an organisation, an article, a product or a piece of software. Add it as JSON-LD in the page's HTML, use only the types that match what is visibly on the page, and check it with Google's Rich Results Test and the Schema Markup Validator.

Common schema.org types, where to use them and what Google can show
Type	Use it on	What Google can show
Organization	Homepage or About page	Your logo and organisation details in results and knowledge panels
Article / BlogPosting	Blog posts, news and guides	The right headline, image, author and dates for the article
FAQPage	Pages with visible questions and answers	FAQ rich results only for well-known government and health sites since 2023
Product	Individual product pages	Price, availability and review stars in product snippets and merchant listings
BreadcrumbList	Any page within a site hierarchy	A breadcrumb trail in desktop results
SoftwareApplication	App and SaaS product pages	Rating and price in a software app rich result (needs ratings or reviews)
Person	Author pages and article bylines	No rich result on its own; makes authorship clear

What schema markup does

Schema.org is a shared vocabulary for describing things on the web, started in 2011 by Google, Microsoft, Yahoo and Yandex. Schema markup is that vocabulary applied to your pages: a machine-readable statement that this page is a BlogPosting by this Person, published by this Organization, or that this is a Product with this price.

It pays off in two ways.

Rich results. Google uses structured data to decide whether a page can show an enhanced listing: review stars, prices, breadcrumbs, a logo. Markup makes a page eligible, but it never guarantees Google will show the enhancement.

Machine understanding. Markup states facts explicitly instead of leaving a crawler to infer them from layout. That helps search engines connect your pages to entities in their knowledge graph, and gives AI systems unambiguous facts to work with when they summarise or cite you.

What schema markup won't do is push a page up the rankings by itself. Google has said structured data is not a general ranking signal. Its value comes from clearer understanding and better-looking listings, which can lift click-through.

The rule underneath all of it: mark up what is visible on the page, and nothing else. Markup describing content users can't see, or reviews that don't exist, breaks Google's structured data guidelines and can lead to a manual action.

JSON-LD vs Microdata vs RDFa

There are three ways to add schema markup, and Google supports all of them.

JSON-LD is a block of JSON inside a <script type="application/ld+json"> tag, usually in the <head>. It sits apart from your visible HTML, so you can generate it from the same data that renders the page without touching the layout. Google recommends it.

Microdata adds attributes (itemscope, itemtype, itemprop) directly to the HTML elements that show the content:

<div itemscope itemtype="https://schema.org/Product">
  <h1 itemprop="name">Acme Invoicing</h1>
  <span itemprop="description">Invoicing for UK freelancers</span>
</div>

It keeps markup and content together, but it is fiddly to maintain and easy to break when someone edits a template.

RDFa works the same way with different attributes (vocab, typeof, property). You'll mostly meet it in older CMSs and some government and academic sites.

For a new site, use JSON-LD. It is easiest to generate, review and test, and you can describe several connected entities in one block with @graph. Google can read JSON-LD added by JavaScript, but put it in the server-rendered HTML where you can: other crawlers, including many AI crawlers, may not run your scripts.

The types most sites need

Most product and content sites need a handful of types, applied carefully.

Organization on the homepage: name, url, logo, and sameAs links to your official profiles. Give it an @id so other markup can refer to it.
WebSite on the homepage, with your site name.
Article or BlogPosting on every post: headline, image, datePublished, dateModified, and author as a Person with a url to their author page.
BreadcrumbList on pages below the top level, matching the breadcrumb users see.
Product on product pages: name, image, offers with price, priceCurrency and availability, and aggregateRating only if the page shows real reviews.
SoftwareApplication for apps and SaaS: name, applicationCategory, operatingSystem and offers. Google's software app rich result also needs a rating or review.
FAQPage where the page genuinely shows questions and answers.

Connect entities rather than repeating them. An article's publisher can point to your Organization's @id, and its author to a Person with its own @id. Consistent identifiers help search engines and AI systems understand that the same company and people appear across your site.

Keep values in step with the page. A price in markup that differs from the price on screen is the most common way sites end up with invalid or ignored structured data.

FAQ schema after 2023

In August 2023 Google restricted FAQ rich results to well-known, authoritative government and health websites. For everyone else, FAQPage markup stopped producing the expandable questions under a search result. HowTo rich results were dropped entirely around the same time.

That led many people to remove FAQ markup. It is still worth keeping where a page really has a question and answer section, for a few reasons:

It is valid schema.org. Search engines still parse it, and Google's validator tools still check it.
Machines read it. FAQPage turns a question and its answer into an explicit pair. Search engines and AI systems that summarise pages can lift those pairs with less guesswork than parsing headings and paragraphs.
Other consumers exist. Google is not the only search engine or tool that reads structured data.

What to avoid:

Marking up questions that aren't visible on the page.
Using FAQ markup for advertising copy dressed up as questions.
Duplicating the same FAQ block across hundreds of pages.

Keep answers short and self-contained, a sentence or three, so each one makes sense lifted out of context. That habit helps AI answers regardless of whether any rich result appears. Every guide on this site, this one included, carries FAQPage markup for exactly that reason.

A JSON-LD example

Here is one block describing a blog post, its author and the company that publishes it, connected with @id:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://acme.example/#org",
      "name": "Acme",
      "url": "https://acme.example",
      "logo": "https://acme.example/logo.png",
      "sameAs": ["https://www.linkedin.com/company/acme-example"]
    },
    {
      "@type": "BlogPosting",
      "headline": "How to chase a late invoice",
      "image": "https://acme.example/images/late-invoice.png",
      "datePublished": "2026-09-01",
      "dateModified": "2026-09-20",
      "author": {
        "@type": "Person",
        "name": "Sam Taylor",
        "url": "https://acme.example/authors/sam-taylor"
      },
      "publisher": { "@id": "https://acme.example/#org" }
    }
  ]
}
</script>

A few details worth copying:

Use full, absolute URLs for url, logo and image.
Use ISO 8601 dates, and change dateModified only when the content actually changes.
Put the Organization once, with an @id, and reference it everywhere else.
Generate the block from the same data that renders the page, so the two can't drift apart.

In a framework such as Next.js, that usually means building the object in the page component from the post's own metadata and rendering it with JSON.stringify inside the script tag. The headline, dates and author then come from one source, and a content edit updates the markup automatically.

Add a BreadcrumbList beside it if the page sits in a hierarchy, and a FAQPage if the post ends with visible questions. All of them can live in the same @graph array.

Testing and maintaining schema markup

Use two tools, because they answer different questions.

Rich Results Test (search.google.com/test/rich-results) shows which Google rich results a page is eligible for, and lists errors that block eligibility and warnings that don't. It tests a live URL or a pasted code snippet, and renders JavaScript.
Schema Markup Validator (validator.schema.org) checks your markup against the whole schema.org vocabulary, including types Google doesn't use for rich results. Use it for anything the Rich Results Test ignores.

After launch, watch the enhancement reports in Google Search Console, such as Breadcrumbs, Product snippets and Review snippets. They show valid and invalid items across the whole site and flag new errors after a deploy.

Common mistakes:

Markup that doesn't match the visible page, especially prices and ratings.
Self-serving review stars on your own Organization or LocalBusiness, which Google won't show.
Missing required properties after a template change.
Bumping dateModified on every build when nothing changed.

OpenHelm's GEO audit includes a JSON-LD and schema check alongside llms.txt, AI crawler access, citable facts, heading hierarchy and authorship. Its agents make fixes in the product's own repository, so the markup lives with your code. See SEO with OpenHelm.

Questions

Does schema markup improve rankings?

Not directly. Google says structured data is not a general ranking signal, but it can make pages eligible for rich results and helps search engines and AI systems understand them.

Which schema markup format should I use?

JSON-LD. Google supports JSON-LD, Microdata and RDFa, but recommends JSON-LD because it is easier to generate and maintain.

Is FAQ schema still worth adding?

Yes, where the page genuinely has visible questions and answers. Most sites no longer get FAQ rich results in Google, but the markup still gives machines explicit question and answer pairs.

Where do I put JSON-LD?

In a script tag with type application/ld+json, usually in the head, and ideally in the server-rendered HTML so crawlers that don't run JavaScript can read it.

What is the difference between the Rich Results Test and the Schema Markup Validator?

The Rich Results Test checks eligibility for Google's rich results only. The Schema Markup Validator checks your markup against the full schema.org vocabulary.

Can schema markup get my site a penalty?

Yes, if it misleads. Marking up content users can't see, or inventing reviews, breaks Google's structured data guidelines and can lead to a manual action.