Schema markup is one of those SEO topics that sounds far more technical than it is. Strip away the jargon and it comes down to a single idea: search engines can read the words on your page, but they cannot reliably tell what those words mean. Schema markup is how you tell them, explicitly, in a format they already agreed to understand.
This guide walks through every schema type worth your time, with copy-paste JSON-LD for each one. It also covers the parts most tutorials skip: which rich results Google quietly killed, how to link entities together with @id instead of repeating yourself, and the mistakes that get markup silently ignored.
What schema markup actually is
A page might contain the text "Open 8 to 5." A human knows those are business hours. A crawler sees five characters and a couple of numbers. Schema markup removes the guesswork by attaching an explicit label: this is an openingHoursSpecification, it opens at 08:00, it closes at 17:00, and it applies Monday through Friday.
The vocabulary that defines those labels is schema.org, a collaborative project launched in 2011 by Google, Microsoft, Yahoo, and Yandex. It is not owned by any one search engine, which is exactly why it became the standard. If you only ever bookmark one reference from this article, make it the full schema.org type list.
Two things schema markup is not. It is not a ranking factor. Google has said this repeatedly and consistently, and no amount of markup will push a weak page above a strong one. It is also not a place to stash keywords, because every property has to describe something genuinely present on the page.
What it does do is unlock rich results, clarify the entities on your page, and determine how cleanly AI systems can extract your content. That last point has quietly become the most valuable one. When an AI assistant answers a question about local plumbers, structured data is the cleanest signal available to it.
JSON-LD, Microdata, or RDFa
There are three valid ways to write structured data. You should use one of them.
JSON-LD is a self-contained script block. It sits in your <head> or body and describes the page without touching a single line of your visible HTML. Google explicitly recommends it, and the JSON-LD specification is a W3C standard. This is what every example below uses.
Microdata and RDFa both work by wrapping attributes around your existing markup, so your schema lives inside your layout. They are still parsed and still valid, but they break the moment somebody restructures a template, and debugging them is miserable. There is no upside to choosing them for a new build.
The short version: use JSON-LD. If an existing site already runs Microdata and it validates cleanly, leave it alone rather than running both, because duplicate conflicting markup causes more problems than it solves.
How schema.org is organized
Schema.org is a hierarchy. Everything descends from a single root type called Thing, and each level down gets more specific while inheriting every property from its parents.
This matters practically, because it means you should always use the most specific type that accurately describes you. A plumbing company marked up as Plumber still inherits everything from LocalBusiness, Organization, and Thing, so you lose nothing and gain precision.
- Thing
- └─ Organization
- └─ LocalBusiness
- ├─ HomeAndConstructionBusiness
- ├─ Plumber
- ├─ RoofingContractor
- └─ HVACBusiness
- ├─ MedicalBusiness
- └─ Dentist
- └─ ProfessionalService
- ├─ CreativeWork
- ├─ Article → BlogPosting, NewsArticle
- └─ WebPage, VideoObject, Review
- ├─ Person
- ├─ Product
- ├─ Event
- └─ Place
Every type page on schema.org lists its expected properties, what each one accepts, and which types it inherits from. When you are unsure whether a property exists, check the type page rather than guessing. Invented properties are silently ignored.
The anatomy of a schema block
Every JSON-LD block has the same three moving parts.
<script type="application/ld+json">
{
"@context": "https://schema.org", <-- which vocabulary
"@type": "LocalBusiness", <-- what kind of thing
"name": "Example Plumbing", <-- properties
"telephone": "+1-555-010-1234"
}
</script>@context is always the same string. It tells the parser you are speaking schema.org. @type declares what you are describing. Everything after that is properties.
Properties can hold a plain string, an array, or another nested object with its own @type. That nesting is where the real expressiveness comes from, and it is covered further down.
The schema types that matter
Schema.org defines over 800 types. You will realistically use a dozen. Here they are, in roughly the order you should implement them, each with what it does, when to use it, and a working example you can adapt.
Organization
Who you are as a company. This is the identity block, and it belongs on every site.
When to use it: Sitewide, usually on the homepage. One canonical Organization entity that everything else references.
{
"@context": "https://schema.org",
"@type": "Organization",
"@id": "https://example.com/#organization",
"name": "Example Company",
"url": "https://example.com",
"logo": "https://example.com/logo.png",
"telephone": "+1-555-010-1234",
"email": "hello@example.com",
"address": {
"@type": "PostalAddress",
"streetAddress": "100 Main Street",
"addressLocality": "Orlando",
"addressRegion": "FL",
"postalCode": "32801",
"addressCountry": "US"
},
"sameAs": [
"https://www.linkedin.com/company/example",
"https://www.facebook.com/example"
]
}WebSite
The site itself, as distinct from the company that owns it. Small block, useful for entity clarity.
When to use it: Homepage only. Pair it with Organization via publisher.
{
"@context": "https://schema.org",
"@type": "WebSite",
"@id": "https://example.com/#website",
"url": "https://example.com",
"name": "Example Company",
"publisher": { "@id": "https://example.com/#organization" },
"inLanguage": "en-US"
}LocalBusiness
A business with a physical location or a defined service area. The single highest-value type for local companies.
When to use it: Homepage, contact page, and every location or city page. Use the most specific subtype available.
{
"@context": "https://schema.org",
"@type": "Plumber",
"@id": "https://example.com/orlando#localbusiness",
"name": "Example Plumbing",
"url": "https://example.com/orlando",
"telephone": "+1-555-010-1234",
"priceRange": "$$",
"address": {
"@type": "PostalAddress",
"streetAddress": "100 Main Street",
"addressLocality": "Orlando",
"addressRegion": "FL",
"postalCode": "32801",
"addressCountry": "US"
},
"geo": {
"@type": "GeoCoordinates",
"latitude": 28.5383,
"longitude": -81.3792
},
"openingHoursSpecification": [{
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday"],
"opens": "08:00",
"closes": "17:00"
}],
"areaServed": [
{ "@type": "City", "name": "Orlando" },
{ "@type": "City", "name": "Winter Park" }
]
}Article / BlogPosting / NewsArticle
Editorial content. BlogPosting and NewsArticle are subtypes of Article, so pick the one that fits.
When to use it: Every blog post and guide. Get datePublished and dateModified right, they matter more than the rest.
{
"@context": "https://schema.org",
"@type": "BlogPosting",
"headline": "How to Unclog a Drain Without Wrecking the Pipe",
"description": "A practical walkthrough for homeowners.",
"image": ["https://example.com/images/drain.jpg"],
"datePublished": "2026-08-06",
"dateModified": "2026-08-06",
"author": {
"@type": "Person",
"name": "Jamie Rivera",
"url": "https://example.com/about/jamie-rivera"
},
"publisher": { "@id": "https://example.com/#organization" },
"mainEntityOfPage": {
"@type": "WebPage",
"@id": "https://example.com/blog/unclog-a-drain"
}
}Product
A physical or digital item for sale. Nests Offer for price and availability, and AggregateRating for stars.
When to use it: Every product page on an ecommerce site. This is the type most likely to change how your listing looks.
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Heavy Duty Pipe Wrench",
"image": ["https://example.com/images/wrench.jpg"],
"description": "A 14-inch cast iron pipe wrench.",
"sku": "PW-14",
"brand": { "@type": "Brand", "name": "Example Tools" },
"offers": {
"@type": "Offer",
"url": "https://example.com/products/pipe-wrench",
"price": "39.99",
"priceCurrency": "USD",
"availability": "https://schema.org/InStock",
"itemCondition": "https://schema.org/NewCondition"
},
"aggregateRating": {
"@type": "AggregateRating",
"ratingValue": "4.7",
"reviewCount": "128"
}
}Service
Something you do rather than something you sell. No rich result, but strong for entity understanding.
When to use it: Service pages. Pair with your Organization or LocalBusiness as the provider.
{
"@context": "https://schema.org",
"@type": "Service",
"serviceType": "Emergency Drain Cleaning",
"name": "Emergency Drain Cleaning in Orlando, FL",
"description": "24/7 drain and sewer clearing across the Orlando metro.",
"provider": { "@id": "https://example.com/orlando#localbusiness" },
"areaServed": { "@type": "City", "name": "Orlando" },
"hasOfferCatalog": {
"@type": "OfferCatalog",
"name": "Drain Services",
"itemListElement": [{
"@type": "Offer",
"itemOffered": { "@type": "Service", "name": "Hydro jetting" }
}]
}
}FAQPage
A list of questions and answers. The rich result is deprecated, but the markup still helps machines parse your answers.
When to use it: Pages with a genuine FAQ section. Every Q&A in the markup must be visible on the page.
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [{
"@type": "Question",
"name": "How fast can you get here?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Most Orlando calls are reached within 90 minutes."
}
}]
}Review & AggregateRating
Individual reviews and the rolled-up score. Powerful and heavily policed, so be careful here.
When to use it: Only where real reviews are displayed on the page. Never self-serving reviews of your own business.
{
"@context": "https://schema.org",
"@type": "Review",
"itemReviewed": {
"@type": "Product",
"name": "Heavy Duty Pipe Wrench"
},
"author": { "@type": "Person", "name": "Dana Wu" },
"datePublished": "2026-07-30",
"reviewRating": {
"@type": "Rating",
"ratingValue": "5",
"bestRating": "5"
},
"reviewBody": "Held up to a full day of rough work."
}Person
A human being. Used for authors, team members, and founders, and increasingly important for author credibility.
When to use it: Author bios, team pages, and as the author property inside Article markup.
{
"@context": "https://schema.org",
"@type": "Person",
"@id": "https://example.com/about/jamie-rivera#person",
"name": "Jamie Rivera",
"jobTitle": "Master Plumber",
"worksFor": { "@id": "https://example.com/#organization" },
"url": "https://example.com/about/jamie-rivera",
"sameAs": ["https://www.linkedin.com/in/jamierivera"]
}Event
Something happening at a time and place, in person or online. Still produces a genuine rich result.
When to use it: Event pages, webinars, classes, and open houses.
{
"@context": "https://schema.org",
"@type": "Event",
"name": "Free Home Maintenance Workshop",
"startDate": "2026-09-12T18:00-04:00",
"endDate": "2026-09-12T20:00-04:00",
"eventAttendanceMode":
"https://schema.org/OfflineEventAttendanceMode",
"eventStatus": "https://schema.org/EventScheduled",
"location": {
"@type": "Place",
"name": "Example Plumbing HQ",
"address": {
"@type": "PostalAddress",
"streetAddress": "100 Main Street",
"addressLocality": "Orlando",
"addressRegion": "FL",
"addressCountry": "US"
}
},
"organizer": { "@id": "https://example.com/#organization" }
}VideoObject
A video hosted on or embedded in the page. Feeds video results and the video tab.
When to use it: Any page with a meaningful embedded video. Upload date and duration are the properties people forget.
{
"@context": "https://schema.org",
"@type": "VideoObject",
"name": "How to Shut Off Your Main Water Valve",
"description": "A two-minute walkthrough for homeowners.",
"thumbnailUrl": ["https://example.com/images/valve-thumb.jpg"],
"uploadDate": "2026-06-01T09:00-04:00",
"duration": "PT2M14S",
"contentUrl": "https://example.com/video/main-valve.mp4",
"embedUrl": "https://example.com/embed/main-valve"
}JobPosting
An open role. Feeds Google job listings, which is a genuine traffic source most companies ignore.
When to use it: Careers pages, one block per open role.
{
"@context": "https://schema.org",
"@type": "JobPosting",
"title": "Service Plumber",
"description": "<p>Full description of the role.</p>",
"datePosted": "2026-08-01",
"validThrough": "2026-10-01T23:59",
"employmentType": "FULL_TIME",
"hiringOrganization": { "@id": "https://example.com/#organization" },
"jobLocation": {
"@type": "Place",
"address": {
"@type": "PostalAddress",
"addressLocality": "Orlando",
"addressRegion": "FL",
"addressCountry": "US"
}
},
"baseSalary": {
"@type": "MonetaryAmount",
"currency": "USD",
"value": {
"@type": "QuantitativeValue",
"minValue": 55000, "maxValue": 85000, "unitText": "YEAR"
}
}
}HowTo
Step-by-step instructions. The rich result was deprecated, so treat this as semantic markup only.
When to use it: Optional. Useful for machine parsing of tutorials, but do not expect a visual result.
{
"@context": "https://schema.org",
"@type": "HowTo",
"name": "How to Reset a Garbage Disposal",
"totalTime": "PT5M",
"step": [
{ "@type": "HowToStep", "position": 1,
"name": "Cut the power",
"text": "Switch off the disposal at the breaker." },
{ "@type": "HowToStep", "position": 2,
"name": "Press the reset button",
"text": "Find the red button underneath and press it." }
]
}Running a local business?
Schema is one piece. The map pack is the whole game.
LocalBusiness markup reinforces your Google Business Profile, but rankings come from relevance, distance, and prominence working together. See how we build local campaigns around all three.
Explore local SEO servicesarrow_forwardNesting and @id, the part everyone gets wrong
Most schema tutorials stop at single isolated blocks. That produces markup where your company is redefined from scratch on every page, and nothing connects to anything else.
The fix is @id. You define an entity once, give it a unique identifier, then reference that identifier everywhere else instead of repeating the full definition.
// Defined once, on the homepage
{
"@context": "https://schema.org",
"@type": "Organization",
"@id": "https://example.com/#organization",
"name": "Example Plumbing",
"url": "https://example.com",
"logo": "https://example.com/logo.png"
}
// Referenced everywhere else, no repetition
{
"@context": "https://schema.org",
"@type": "BlogPosting",
"headline": "How to Unclog a Drain",
"publisher": { "@id": "https://example.com/#organization" }
}The convention is a URL plus a fragment, like https://example.com/#organization. The fragment does not need to point at anything real. It just has to be unique and consistent across your whole site.
The other half of entity clarity is sameAs. It holds links to authoritative profiles of the same entity, which lets search engines confirm that your Example Plumbing is the one with that LinkedIn page and that Wikipedia entry, not a different company with the same name. For anything with a common name, this is the difference between being recognized as an entity and being ambiguous text.
What Google shows vs what it just understands
This is the section most schema guides are years out of date on. Not every type produces a visible change in search results, and Google has retired several that used to.
FAQ rich results are deprecated.The expandable question accordion no longer appears in Google Search for the overwhelming majority of sites. Google's own FAQPage documentation now states the feature is shown only for well-known, authoritative government and health websites. HowTo rich results were retired too.
That does not make the markup worthless. It makes it semantic rather than cosmetic. Structured Q&A is still the cleanest possible format for an AI system to extract an answer from, and AI Overviews, ChatGPT, and Perplexity all benefit from it. Keep adding FAQPage markup. Just stop promising clients an accordion.
Types that still produce genuine visible rich results include Product, Review and AggregateRating, BreadcrumbList, Event, VideoObject, JobPosting, and Recipe. The authoritative list is Google's structured data search gallery, which is worth checking before you promise anyone a specific result.
Types like Service, Person, and Organization rarely change how your listing looks. They earn their place by building the entity graph that everything else hangs off.
How to add schema to your site
Custom or framework-built sites. Render the JSON-LD server side, directly in the page template. It ships in the initial HTML, needs no JavaScript execution, and is the most reliable option available.
WordPress. Most established SEO plugins generate a connected Organization, WebSite, and Article graph automatically. Check what is already being output before you add anything, because the most common WordPress problem is two plugins emitting conflicting blocks for the same entity.
Shopify. Themes usually ship with Product markup already in place. Verify what the theme outputs before installing an app on top of it, or you will end up with two Product blocks and mismatched prices.
Google Tag Manager. Workable but the weakest option. Google has to render the page before it sees the markup, so pickup is slower and less predictable. Use it when you have no access to templates, not as a first choice.
Whatever the method:the markup must match what a visitor actually sees. Marking up content that is hidden, absent, or different from the visible page violates Google's structured data guidelines and can trigger a manual action.
How to test and validate
Two tools, and they answer different questions. Run both.
Schema Markup Validator checks your markup against the schema.org vocabulary itself. It tells you whether the syntax is valid and whether your properties actually exist on the type you declared. This is the one that catches typos and invented properties.
Google Rich Results Test checks whether Google specifically considers your page eligible for a rich result, and it flags the required properties Google wants that schema.org treats as optional. A block can be perfectly valid schema and still fail here.
Once pages are live, the Enhancements reports in Google Search Console show errors and warnings across your whole site at scale, which is the only practical way to monitor a site with hundreds of pages. Validators test one URL. Search Console tests all of them.
Common mistakes that break markup
In practice, the same handful of errors account for nearly every broken implementation we find during an SEO audit.
- errorMarking up invisible content. The single fastest way to get a manual action. If a review, price, or FAQ answer is in the markup, it has to be on the page.
- errorSelf-serving reviews. Review markup about your own business, on your own site, is against Google policy. Reviews of products you sell are fine. Reviews of you are not.
- errorConflicting duplicate blocks. Two plugins, or a theme plus an app, each emitting their own Organization or Product. Google picks one, usually not the one you wanted.
- errorBreadcrumbs that disagree with the page. The BreadcrumbList must mirror the visible breadcrumb and the real URL path. A mismatch here is extremely common after a site restructure.
- errorStale dateModified. Bumping dateModified without changing anything is a credibility problem, not a shortcut to freshness.
- errorInvented properties. Anything not defined on the type is silently ignored. No error, no warning, just nothing.
- errorWrong or generic type. Using LocalBusiness when Dentist or Plumber exists throws away specificity you get for free.
- errorBroken JSON. A single trailing comma invalidates the entire block. Not part of it, all of it.
None of these are exotic. They are the boring failures that quietly cost sites their rich result eligibility for months because nobody checked Search Console.
Questions people actually ask
Does schema markup improve your Google rankings?
expand_more
Not directly. Google has consistently said structured data is not a ranking factor on its own. What it does is make your content machine-readable, which unlocks rich results, helps Google understand the entities on your page, and increasingly determines whether AI systems can extract and cite you. The indirect effect on click-through rate is real, and a listing with review stars or prices usually outperforms a plain one at the same position.
What is the difference between schema.org and structured data?
expand_more
Structured data is the general concept of labeling content in a machine-readable way. Schema.org is the specific shared vocabulary almost everyone uses to do it, maintained collaboratively and originally founded by Google, Microsoft, Yahoo, and Yandex. In practice, when someone says "add structured data," they mean "add schema.org markup," usually in JSON-LD format.
Should I use JSON-LD, Microdata, or RDFa?
expand_more
JSON-LD, in almost every case. It sits in a single script block in the head or body, so it never entangles with your HTML or breaks when a designer changes the layout. Google explicitly recommends it. Microdata and RDFa are still valid and still parsed, but they require wrapping attributes around your visible markup, which makes them fragile and painful to maintain.
Is FAQ schema still worth adding in 2026?
expand_more
Yes, but not for the reason most people think. Google deprecated the FAQ rich result, so the expandable question accordion no longer appears in normal search results for the vast majority of sites. It is now limited to well-known authoritative government and health websites. The markup itself still has value because AI Overviews, ChatGPT, Perplexity, and other systems parse structured Q&A cleanly, and it reinforces what your page is about. Just do not add it expecting the accordion back.
How many schema types can one page have?
expand_more
As many as genuinely describe it. A product page might reasonably carry Organization, WebSite, BreadcrumbList, and Product with a nested Offer and AggregateRating. The rule is accuracy, not volume. Every type you declare has to correspond to content actually visible on that page, or you risk a manual action for spammy structured data.
Can schema markup get my site penalized?
expand_more
It can. Google publishes structured data guidelines, and marking up content that is not visible to users, inventing reviews you never received, or declaring types that do not match the page can trigger a manual action. The result is losing rich result eligibility, sometimes across the whole site. Describe what is genuinely on the page and you will never have a problem.
Where should the JSON-LD script go, in the head or the body?
expand_more
Either works. Google parses JSON-LD wherever it appears in the document, and it will also parse markup injected by JavaScript once the page renders. The head is the conventional place and the safest choice for server-rendered pages. If you are injecting via a tag manager, be aware Google has to render the page first, which adds a delay to how quickly the markup is picked up.
Do I need schema markup if I have a small local business site?
expand_more
It is arguably more valuable for a small local site than a large one. LocalBusiness markup with an accurate address, hours, geo coordinates, and areaServed reinforces every signal your Google Business Profile is sending. For a business competing on proximity and prominence in a local map pack, consistency between your site markup, your profile, and your citations is one of the cheapest wins available.
Joshua Rouillard
Founder, RouillardMedia
Joshua has spent over a decade in performance marketing and search. He founded RouillardMedia, where the team ships structured data across local, ecommerce, and lead generation sites, and writes about what actually moves the needle rather than what sounds impressive.