What is schema markup in SEO, and what it actually changes
The plain definition, the three syntaxes, a copyable JSON-LD block, the types worth adding first, and how to test what you have shipped.
Published by AI Knows Us · Updated 12 October 2026
Schema markup is a block of code added to a page that states, in a vocabulary search engines agree on, exactly what the page is about: that this is a product with a price and a stock status, that this is a local business with an address and opening hours, that this is an article with an author and a publication date. The vocabulary comes from schema.org, and the recommended format is JSON-LD, a small script in the page source that visitors never see. Its job is to remove guesswork. Instead of an engine inferring your opening hours from a line of text, you declare them.
What it changes is eligibility. Correct markup on the right type of page makes that page eligible for rich results in Google: review stars, FAQ panels, product prices, recipe cards, event listings, breadcrumbs. It also makes your facts unambiguous for any system reading the page, which matters more every year.
This page covers what schema markup is and how to add it. For the specific blocks by type, see LocalBusiness, Organization, Product and SoftwareApplication.
Structured data, schema.org and rich results
Three terms get used for each other, and keeping them apart makes every later decision easier.
- Structured data is the general idea: data on a page in a machine readable form.
- Schema.org is the shared vocabulary, maintained collaboratively and used by Google, Microsoft, Yandex and others. It defines types such as Product, Recipe, Event and FAQPage, and the properties each type accepts.
- Rich results are the enhanced listings Google can show when the markup is correct and the page qualifies. Google documents which types it supports in its structured data gallery, and that gallery is the list to work from.
Markup that is not in Google's supported list is still worth adding where it describes your entity accurately, because other systems read schema.org too. It simply will not produce a visual change in Google's results.
The three syntaxes, and which to use
| Syntax | How it sits in the page | Use it when |
|---|---|---|
| JSON-LD | A separate script block, usually in the head | Almost always. Google recommends it, and it is edited and tested without touching the layout |
| Microdata | Attributes added to existing HTML tags | You are maintaining a template that already uses it |
| RDFa | Attributes in HTML, from a different specification | You are working inside a system built on it |
Pick one per page type. Two syntaxes describing the same thing on one page is how contradictions get shipped.
A copyable JSON-LD block
This is a local business page, with the properties that do the most work. Replace the values, keep the structure, and put it in the head of that one page.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "LocalBusiness",
"@id": "https://example.com/#business",
"name": "Example Dental Care",
"url": "https://example.com/",
"telephone": "+44 20 7000 0000",
"email": "hello@example.com",
"image": "https://example.com/images/clinic.jpg",
"priceRange": "Mid",
"address": {
"@type": "PostalAddress",
"streetAddress": "14 High Street",
"addressLocality": "Leeds",
"addressRegion": "West Yorkshire",
"postalCode": "LS1 1AA",
"addressCountry": "GB"
},
"geo": {
"@type": "GeoCoordinates",
"latitude": 53.7975,
"longitude": -1.5436
},
"openingHoursSpecification": [
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
"opens": "09:00",
"closes": "17:30"
}
],
"areaServed": "Leeds and West Yorkshire",
"sameAs": [
"https://www.linkedin.com/company/example",
"https://www.facebook.com/example"
]
}
</script>
Every value in that block should also be visible to a human somewhere on the page. That is the rule the whole system rests on.
The types worth adding first
| Type | Goes on | Properties that carry it |
|---|---|---|
| Organization | The home page or an about page, once per site | name, url, logo, sameAs, contactPoint, address |
| LocalBusiness | Each location page | address, geo, telephone, openingHoursSpecification, areaServed |
| Product | Each product page | name, image, description, sku, brand, offers with price and availability |
| Article or BlogPosting | Editorial pages | headline, author, datePublished, dateModified, image |
| BreadcrumbList | Any page with a hierarchy above it | itemListElement with position, name and item |
| FAQPage | Pages whose questions and answers are both visible on the page | mainEntity with Question and acceptedAnswer |
| Service | Service pages | serviceType, provider, areaServed, hasOfferCatalog |
Start with Organization and the type that matches your money pages. Google's introduction to structured data lists the required and recommended properties per type, and required means the rich result depends on it.
How to add it
- Decide the type per template, not per page. Product on product templates, Article on the blog template, LocalBusiness on location pages.
- Populate from the database, not by hand. Markup typed manually goes stale the first time a price changes.
- Use a plugin if you are on a managed platform. On WordPress this is covered in schema plugins for WordPress.
- Give each entity a stable @id so the Organization on your home page and the publisher of your articles are understood as the same thing.
- Test before release with the Rich Results Test for Google eligibility and the schema.org validator for vocabulary correctness.
- Watch the Enhancements reports in Search Console after release, because that is Google reporting on your live pages rather than on a single URL.
The five mistakes that cause almost all the problems
- Markup that does not match the visible page. Declaring a price, a rating or opening hours a visitor cannot see is the one thing to avoid completely.
- Review stars added site wide. Review markup belongs on the thing being reviewed, with reviews visible on that page.
- Missing required properties. A Product without offers, or an Event without a start date, validates as schema and still earns no rich result.
- Two blocks contradicting each other. A plugin writing one Organization block and the theme writing another leaves the engine choosing between them.
- Markup injected only by JavaScript that runs late. Render it server side where you can, so it is present in the first response.
Fold the check into your release routine alongside the rest of a technical SEO checklist.
Is schema markup a ranking factor?
Google treats it as a way to understand a page rather than as a score to add. What it earns you is eligibility for rich results and a clearer listing, which lifts click through on the same position. That is a real gain, and it is a different mechanism from ranking.
Does schema markup help with AI search?
It helps for the reason it has always helped: it states your facts in a form that does not need interpreting. Assistants assemble answers from pages they can read, and a page that declares its address, service area, products and author plainly gives them less to get wrong.
Which schema type should I use?
Match the type to what the page is. One primary type per page, with supporting types such as BreadcrumbList alongside it. If two types seem to fit, the page probably wants splitting into two pages.
How do I check my schema markup is working?
Run the URL through the Rich Results Test for eligibility and the schema.org validator for vocabulary, then watch the Enhancements reports in Search Console over the following weeks for site wide errors.
How long until rich results appear?
Google has to recrawl the page first, so allow days to a few weeks and request indexing for important pages. Eligibility is the outcome of correct markup, and which listings Google chooses to show stays its decision.
Do I need schema markup on every page?
No. Put it where it describes something specific: products, locations, services, articles, events, courses, job postings. Thin pages gain nothing from markup and the time is better spent on the templates that carry your revenue.
A reader that takes your markup literally
Schema is a set of statements you make about a page: what it is, who wrote it, what it costs. Search engines read it, and so do the systems that feed assistants, and they take it at face value. If the markup says one price and the page says another, the reply may repeat the wrong one.
After you test your markup, ask an assistant for the facts you marked up and compare. AI Knows Us runs those checks for a set of questions, so a mismatch between markup and answer is found by you and not by a buyer.