Schema markup for SEO: how to implement structured data

Short answer: schema markup is structured data, written with the schema.org vocabulary, that tells search engines exactly what a page is about: a business, an article, a product, an event. You add it to the page as a JSON-LD script, test it with Google's Rich Results Test and monitor it in Search Console. It can make a page eligible for rich results such as product prices, review stars or breadcrumbs, but it doesn't guarantee them, and the list of supported rich results changes over time.

What is schema markup (and what is semantic HTML)?

Google describes structured data as "a standardized format for providing information about a page and classifying the page content" (Google Search Central). Schema.org is the shared vocabulary most search engines use for it: a long list of types (Organization, Product, Event) and properties (name, price, startDate). When people say "schema markup" or ask about the "schema tag in SEO", they usually mean this vocabulary added to a page's code.

There are three formats: JSON-LD, Microdata and RDFa. Google accepts all three when they're valid, but in general recommends JSON-LD if your setup allows it (Google Search Central). JSON-LD sits in its own script block, so it doesn't get tangled up with your visible HTML and is easier to maintain.

Semantic HTML is the layer underneath

Semantic HTML means using elements for what they mean rather than how they look. MDN puts it as the question "what purpose or role does that HTML element have" (MDN). In practice that comes down to four habits:

• Headings in order: one h1 that names the page, then h2 and h3 without skipping levels. Headings are for structure; use CSS for size (MDN).
• Landmarks: header, nav, main, article, aside and footer tell screen readers and other tools which part of the page is which (MDN).
• Real lists: steps in an ol, options in a ul, not numbers typed into paragraphs.
• Proper tables: header cells in th with scope, and a caption where it helps, so rows and columns can be read as data.

<body>
  <header>…logo and <nav>main menu</nav>…</header>
  <main>
    <article>
      <h1>Boiler installation in Leeds</h1>
      <h2>What does it cost?</h2>
      <p>…</p>
      <h2>How the installation works</h2>
      <ol><li>Survey</li><li>Quote</li><li>Fitting</li></ol>
    </article>
    <aside>Related guides</aside>
  </main>
  <footer>…</footer>
</body>

Semantic markup in SEO and schema markup do different jobs. Semantic HTML describes the structure of the page. Schema describes the things on the page. A well-built page needs both, and semantic HTML also helps visitors who use assistive technology, which is a good reason on its own.

Does schema markup help SEO?

Yes, in two specific ways. Structured data helps Google understand what a page contains, and it can make the page eligible for rich results, the enhanced listings with extra details (Google Search Central). Google's documentation frames the benefit around understanding and rich results, not as a promise of higher rankings.

Three limits are worth knowing before you start a schema markup implementation:

• No guarantee. Google says it does not guarantee that structured data will show up in search results, even when the markup passes its test (Google Search Central).
• Only supported features produce rich results. Google's search gallery lists the types it currently supports, such as Article, Breadcrumb, Event, Job posting, Local business, Organization, Product, Recipe, Review snippet and Video (Google Search Central). Anything else may still help understanding but won't change how your result looks.
• The list shrinks as well as grows. Google stopped showing HowTo rich results in September 2023 and limited FAQ rich results to well-known government and health sites at the same time. In May 2026 it deprecated FAQ rich results entirely, and in 2025 it retired several other types, including course info, estimated salary and vehicle listing (Google Search Central documentation updates).

So treat seo structured data as part of technical SEO: worth doing well for the types that fit, not a shortcut to rankings.

Which schema types should most business websites use?

Most company sites need a handful of types, not dozens. Match the type to the content that's actually on the page.

Event, JobPosting, Recipe, VideoObject and others make sense if you publish that kind of content. Use the most specific type that fits: Google's guidelines ask for the most specific applicable types and properties, for example a LocalBusiness subtype such as Plumber or Dentist rather than the generic type (Google Search Central).

How to add schema markup with JSON-LD (with examples)

Implementing schema markup comes down to adding a script type="application/ld+json" block to the page. Many CMS platforms and SEO plugins generate the basics; for anything custom, a developer adds it to the page template so it fills in automatically from the page data. The examples below use a fictional plumbing firm. Replace every value with your own, and only include facts that are visible on the page.

Organization

Google lists no required properties for Organization, so add every property that applies (Google Search Central). sameAs links your official profiles on other sites.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Northfield Plumbing",
  "url": "https://www.example.com/",
  "logo": "https://www.example.com/images/logo.png",
  "telephone": "+44 113 496 0000",
  "sameAs": [
    "https://www.linkedin.com/company/example",
    "https://www.facebook.com/example"
  ]
}
</script>

LocalBusiness

name and address are required; opening hours, phone number, URL and coordinates are recommended (Google Search Central). Use one block per location, on that location's page.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Plumber",
  "name": "Northfield Plumbing",
  "url": "https://www.example.com/leeds",
  "telephone": "+44 113 496 0000",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "12 Mill Street",
    "addressLocality": "Leeds",
    "postalCode": "LS1 4AB",
    "addressCountry": "GB"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 53.79648,
    "longitude": -1.54785
  },
  "openingHoursSpecification": [{
    "@type": "OpeningHoursSpecification",
    "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
    "opens": "08:00",
    "closes": "17:00"
  }]
}
</script>

Article or BlogPosting

No properties are strictly required, but Google recommends headline, image, dates and author. Give each author a separate entry with a link to a page about them (Google Search Central).

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "How to choose a boiler for a small flat",
  "image": ["https://www.example.com/images/boiler-guide.jpg"],
  "datePublished": "2026-10-01T09:00:00+01:00",
  "dateModified": "2026-10-20T14:30:00+01:00",
  "author": [{
    "@type": "Person",
    "name": "Sam Carter",
    "url": "https://www.example.com/team/sam-carter"
  }]
}
</script>

BreadcrumbList

The list needs at least two items. The last item can leave out item, in which case Google uses the current page URL (Google Search Central).

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [{
    "@type": "ListItem",
    "position": 1,
    "name": "Services",
    "item": "https://www.example.com/services"
  }, {
    "@type": "ListItem",
    "position": 2,
    "name": "Boiler installation"
  }]
}
</script>

Product

A product snippet needs name plus review, aggregateRating or offers. Google recommends always including priceCurrency (Google Search Central). Keep the price in sync with the page; an out-of-date price in the markup is a common error.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Thermostatic radiator valve, 15 mm",
  "image": "https://www.example.com/images/trv-15.jpg",
  "description": "Thermostatic valve for 15 mm radiator pipes.",
  "offers": {
    "@type": "Offer",
    "price": "24.00",
    "priceCurrency": "GBP",
    "availability": "https://schema.org/InStock"
  }
}
</script>

FAQPage

FAQPage is still valid schema.org vocabulary and this blog uses it for its question sections. Just be clear about what it does: Google no longer shows FAQ rich results (Google Search Central), so add it only where the questions and answers are visible on the page, and don't expect a change in how the result looks.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [{
    "@type": "Question",
    "name": "Do you charge a call-out fee?",
    "acceptedAnswer": {
      "@type": "Answer",
      "text": "No. You pay for the work and parts only."
    }
  }]
}
</script>

How to test and validate your structured data

Use two different checkers, because they answer two different questions:

1. Rich Results Test checks whether a page or code snippet is eligible for Google's rich results and shows errors and warnings for Google's required and recommended properties. Google calls it "an easy and useful tool for validating your structured data" (Google Search Central).
2. Schema Markup Validator on schema.org checks markup against the whole schema.org vocabulary, including types Google doesn't use for rich results.
3. URL Inspection in Search Console shows the version Google actually crawled. Use it after publishing to confirm the page isn't blocked by robots.txt, noindex or a login (Google Search Central).
4. Rich result reports in Search Console monitor valid and invalid items across the whole site over time. Check them after each template change.

Test the live URL, not only pasted code. Markup injected by a tag manager or a JavaScript framework can look fine in the editor and still be missing from what Googlebot renders.

Common schema mistakes that block rich results

• Marking up content visitors can't see. Google's guidelines are direct: don't mark up content that isn't visible to readers (Google Search Central).
• Missing required properties. Items without them are not eligible for rich results (Google Search Central).
• Self-serving review stars. If a business controls the reviews about itself, its LocalBusiness or Organization markup is ineligible for the star review feature (Google Search Central). Putting your own testimonials in aggregateRating on the home page won't produce stars.
• Markup that doesn't match the page. Old prices, a different business name or opening hours that differ from the visible text. Structured data must be a true representation of the page content (Google Search Central).
• Blocked images. Image URLs in the markup must be crawlable and indexable (Google Search Central).
• Deprecated types. Spending time on HowTo or FAQ markup for rich results that Google no longer shows.
• Broken JSON. A missing comma or quote invalidates the whole block. The validators catch this in seconds.

Repeated violations can also lead to a manual action. Google says that means a page loses eligibility for rich results; it doesn't affect ranking in web search (Google Search Central). Technical SEO schema work is mostly about keeping the markup correct as the site changes. If you want a second pair of eyes on it, our technical SEO work covers structured data alongside crawling, indexing and page speed. Speed is its own topic, explained in our guide to Core Web Vitals, and multilingual sites should also get hreflang right.

Schema markup and AI search

What Google says: there is no special schema.org structured data you need to add to appear in AI Overviews or AI Mode, and no new machine-readable files are required. Its best practices for AI features include making sure structured data matches the visible text on the page (Google Search Central).

Our view, which is reasoning rather than a documented ranking rule: clean structured data can't hurt in AI search, because it states facts such as your name, address, prices and authors in an unambiguous form, and consistent facts across your site and profiles make it easier for any system to describe you correctly. But don't treat schema as a lever for AI visibility. Clear, well-structured visible content does the heavy lifting, and the markup should simply agree with it.