Schema Markup in Practice: Which Types to Use and How to Ship Them

Dominik Breitbach · Founder and Lead SEO Strategist

Dominik Breitbach founded taismo GmbH, an SEO and GEO agency from Munich. Structured data is the part of the job he does every week: Entity graphs in JSON-LD, rich results, and visibility inside AI answers.

⏱ Reading time: 21 min🔄 Last updated: 9 August 2026

Schema markup is the schema.org vocabulary written into a page as JSON-LD so machines can read what the page is about. It does two jobs: It makes a page eligible for rich results in Google, and it hands AI systems an unambiguous entity to cite. Most implementations fail earlier than that, because the markup describes the wrong thing, contradicts itself across templates, or never gets tested after a relaunch. This guide covers the three decisions that carry the outcome: Which type per page, how to connect the types into one graph, and how to test what you shipped.

👉 Not sure what your current markup reports to Google? A schema audit reads every block on every template and names the contradictions.

What schema markup changes

Schema markup adds a machine readable claim to a page. A visitor sees nothing change. A crawler stops guessing from prose and gets told: This is a product, it costs 49 euros, it is in stock, and the company behind it is this legal entity at this address. That claim buys you three things, and only three:

1. Eligibility for rich snippets: Stars, prices, breadcrumbs, event dates and job listings appear only where valid markup supports them.
2. Entity clarity: Google and AI systems can tie the page to a known company, author and topic instead of inferring them.
3. Consistency across a domain: One definition of your company, referenced everywhere, cannot contradict itself.

It buys you no ranking position. Google has stated repeatedly that structured data is not a ranking factor. What it changes is what happens after the ranking, which is a different lever and often the cheaper one.

If you need the vocabulary explained first, our glossary covers structured data, the JSON-LD format and rich snippets as terms. This guide starts where those definitions end: At the work of building the markup and keeping it correct.

Pick the type before you write code

schema.org publishes more than 800 types. Most websites need between four and eight of them, and the decision that wastes the most time in practice is which type belongs on which template.

The rule that settles it: One primary type per page, chosen from what the page visibly is, plus the global entities referenced by @id. A service page is a Service, a blog post is a BlogPosting, a location page is a LocalBusiness.

Two types are missing from that table on purpose. FAQPage and HowTo once produced reliable rich results and produce none today. That has its own section further down, because the dates decide what is still worth building.

Organization and Person: The layer you build once

Split your markup into two layers and the maintenance problem disappears. The identity layer describes what is true across the whole domain, the page layer describes one URL.

The identity layer holds four entities in most cases: Organization (or LocalBusiness for a business with a service address), WebSite, Brand, and one Person per author. Define each exactly once, give it a stable @id, and never repeat its properties anywhere else.

Two properties here carry more weight than the rest. sameAs lists the official profiles describing the same entity elsewhere: The company register entry, LinkedIn, review platforms, industry directories. Each is a corroborating source a machine can follow. knowsAbout names the topics the entity is competent in, and it gets considerably stronger when you point it at your own DefinedTerm nodes instead of at plain strings.

The Person node is where E-E-A-T becomes machine readable. An author name in a byline is text. A Person node with sameAs to real profiles and worksFor pointing at the organization is a claim a machine can check against other sources.

For scale: The global graph on taismo.de holds 14 nodes and about 17,800 characters of minified JSON-LD. All 300 or so pages on the domain reference those 14 nodes rather than restating them, and that is the entire maintenance surface for the identity layer.

Article, Product and FAQPage

The page layer changes per URL and is where most implementation errors live, because it is the layer people generate automatically.

Article and BlogPosting need six properties to carry weight. Those are headline, datePublished, dateModified, image, author and publisher. The dates must be ISO 8601 with a timezone offset and must match what the page shows. A schema date that predates the visible one is a contradiction Google resolves by trusting neither.

Product carries a nested Offer with price, priceCurrency and availability. Adding aggregateRating is what produces stars, and it is also the fastest route to a manual action. The rating has to come from real reviews a visitor can read on that page. Invented ratings, ratings borrowed from another product, and company ratings placed on a product page are all policy violations. On a local page the honest route is a rating backed by visible Google reviews.

FAQPage follows one rule that overrides everything else: The questions and answers in the markup must appear on the page in the same words. Marking up an FAQ that only exists in the JSON-LD is a guideline breach. Mark up the FAQ you actually show, for the machine readability, and expect no visual result at all. The section on retired features explains why.

BreadcrumbList is the cheapest node here. It replaces the raw URL in the search result with a readable path, takes four lines per page, and maps onto the breadcrumb navigation you already render.

LocalBusiness, Event and JobPosting

Three specialist types repay the effort when the business model fits, and cost nothing but time when it does not.

LocalBusiness adds an address, geo coordinates, opening hours and a service area. A company with several branches gets one node per location, each with its own @id on its own location page, linked upward with parentOrganization. The mistake we see most often in local SEO work is a second LocalBusiness for the head office declared on every page, which turns one business into two competing entities.

Event needs startDate, location and, for paid events, an Offer. JobPosting feeds Google job listings and needs datePosted, validThrough, hiringOrganization and jobLocation. Both share the same weakness: They describe something with an expiry date, and markup that still calls a finished event upcoming or a filled vacancy open is a stale signal nobody notices.

VideoObject, Recipe and Review round out the set. Use each where the page genuinely contains that content, and skip the rest. Coverage is not the goal.

Required fields versus recommended fields

Every supported type splits its properties into two classes, and only one of them decides eligibility. Google’s guidelines are blunt about it: “Items that are missing required properties are not eligible for rich results.” Recommended properties widen what the result can show. Leaving them out costs detail, never eligibility.

The table lists the required set for the eight types most sites touch, plus what is worth adding next.

Article is the outlier, and it explains a lot of bad article markup. Google states it twice on the same page: “There are no required properties; instead, add the properties that apply to your content.” An Article node therefore never fails a validator for a missing field. That is why article markup so often carries an author who left two years ago or a date that contradicts the byline. A validator checks whether a field exists. Nothing checks whether it is true.

Product is two features wearing one type. A product snippet needs name plus at least one of review, aggregateRating or offers. A merchant listing, the richer treatment for a page you can actually buy from, needs the offer detail: Price, currency and availability. Google notes that adding the merchant listing properties also makes the page eligible for product snippets, so on a shop you build the merchant listing set and get the smaller feature for free.

One line in the local business documentation costs more sites their stars than any other rule. There, aggregateRating and review are marked “only recommended for sites that capture reviews about other local businesses”. Your own rating, on your own location page, is not a supported use. On a product page the rating has to come from reviews a visitor can read on that same page. Anything else is the shortcut that ends in a manual action.

JobPosting carries a deadline the other types do not. Google requires closed vacancies to be expired in one of three ways: Set validThrough to a past date, return 404 or 410 for the page, or remove the markup. The wording leaves no room: “Failure to take timely action on expired jobs may result in a manual action.” Put that step in the same checklist as taking the ad offline. It is the piece missing from almost every social recruiting setup we inherit.

FAQ and HowTo: The types that stopped paying out

Two schema types are still valid, still parsed, still worth writing, and neither produces anything a visitor can see. The dates matter, because almost every guide on this topic predates them.

1. 8 August 2023: Google removed HowTo rich results entirely and limited FAQ rich results to “well-known, authoritative government and health websites”. For everyone else the FAQ dropdown vanished that week.
2. 7 May 2026: FAQ rich results stopped appearing in Google Search at all. The changelog entry of 8 May 2026 puts it in one sentence: “This feature will no longer appear in Google Search starting May 7, 2026.”
3. 15 June 2026: Google deleted the feature documentation, logged as “Removing documentation for the FAQ rich result feature”.

What remains is a shorter menu than most content plans assume. Google’s structured data gallery currently documents 25 features that can produce a rich result, among them Article, Product, Local business, Event, Job posting, Recipe, Video, Review snippet, Breadcrumb and Organization. FAQ and HowTo are not on that list.

Two conclusions follow, and they pull in opposite directions.

Stop planning content around the feature. An FAQ block written to win more room in the search result now buys a feature that no longer exists. Any plugin still advertising “FAQ rich snippets” is selling a screenshot from 2022, and any agency pricing an FAQ rollout on that promise is selling the same one.

Keep the markup anyway. A marked up FAQ hands a machine a question and its answer, already paired, already scoped to one topic. That is the exact shape an AI assistant lifts when it answers and names a source. We still mark up every real FAQ block on taismo.de, including the one at the end of this article. The reason changed, the practice did not.

One practical read of your own data: If your Search Console FAQ report dropped to zero valid items in May 2026, that is the deprecation and not a break in your markup. Do not hunt for the bug, and do not strip the type in response. Removing it costs machine readability and buys back nothing.

One graph instead of twelve snippets

Here is where solid markup separates from markup that compounds. A typical site carries schema from three sources at once: The SEO plugin, the theme, and whatever somebody pasted into a page builder two years ago. Each one describes the company again, slightly differently.

The fix is @id. Every entity gets a stable identifier, usually the page URL plus a fragment, and wherever that entity appears again you write the reference instead of the description.

"publisher": { "@id": "https://example.com/#organization" }

Google merges nodes that share an @id into a single entity, even across separate script blocks. That is what makes coexistence possible: Your plugin keeps emitting its own graph, and a hand maintained block extends the same nodes instead of competing with them. We run exactly this setup on taismo.de.

Two rules keep the graph honest. Identifiers must be stable, which means one canonical form of every URL, chosen once. And an entity is described in exactly one place, so changing the company address is one edit rather than a search across templates.

JSON-LD, Microdata and RDFa

schema.org supplies the vocabulary. Three syntaxes carry it into a page, and the choice decides how long your markup survives contact with a design team.

Microdata and RDFa wrap attributes around the visible HTML. A price becomes a span with an itemprop, the product becomes a div with an itemscope. The data lives inside the layout, which reads tidy until somebody replaces the layout. From then on every template change is a markup change, usually an unnoticed one.

JSON-LD keeps the data in its own script block, separate from the HTML. Google names it the recommended format and calls it “the easiest solution for website owners to implement and maintain at scale”. The practical argument is ownership: One block, one owner, no dependency on which element happens to wrap the price this quarter.

Placement is flexible. Google reads JSON-LD in the head and in the body, and it reads blocks that arrive later, “when it is dynamically injected into the page’s contents” by JavaScript. Rendered markup does get picked up. It also disappears silently when rendering fails, which is the whole argument for the server response.

Formats coexist on one page, and that is where contradictions are born. A theme from 2016 with Microdata product markup plus a current plugin with JSON-LD gives a crawler two descriptions of one product. Both get parsed, neither wins.

Vocabularies expire as well. Google announced on 21 January 2020 that data-vocabulary.org markup would lose its eligibility, and from 6 April 2020 it triggered an error instead of a warning. Sites whose breadcrumbs used that vocabulary lost the display without anybody touching a line of code. Markup is not a one time project, and that is the cheapest proof of it.

Where the JSON-LD actually goes

Four delivery routes exist. They differ in how reliably the markup survives the next update.

• SEO plugin: Covers the standard cases automatically and is the right starting point. It rarely covers services, glossary terms or multi location setups, and it cannot express a custom graph.
• Theme or template code: Full control, and it disappears with the next theme update unless it lives in a child theme or a must use plugin. We have watched a parent theme update remove an entire graph.
• A dedicated meta field plus a small plugin: The route we default to. The JSON-LD lives in a field per page, gets written through the API, and gets printed in the head by code no theme update touches.
• Tag manager: Works, but the markup only exists after JavaScript runs. For anything load bearing, put it in the server response.

One warning for page builder sites: Several builders strip <script> tags out of post content when they render. Markup pasted into the editor looks correct in the backend and never reaches the page. Check the rendered HTML, not the editor, whenever you use Elementor, Divi or YooTheme. A foundation that keeps markup where you put it is part of what we mean by SEO web design.

WordPress, Shopify and the plugin problem

Almost nobody starts from an empty page. You start with a system that already emits markup, and the first job is finding out what it emits.

WordPress: Yoast SEO and Rank Math both output a complete @graph by default, typically Organization, WebSite, WebPage, Article, Person and BreadcrumbList, wired together by @id. That covers the identity layer and the standard page types without a line of code. What they do not cover: Your services, your glossary terms, a second location, and every type outside the standard set. What they cannot do: Stop a second plugin from describing the same company again.

You can usually tell the blocks apart in the page source. Yoast writes one graph with fragment identifiers in the pattern #/schema/logo/image/. A review plugin writes a stand alone Product or Review node. A theme writes something with no @id at all, and that last one is the block that cannot be merged into anything and therefore has to go.

Shopify: The Product JSON-LD sits in the theme’s Liquid files, and review, subscription or bundle apps add their own on top. Same duplication, different stack. The fix lives in the theme file rather than in an app setting, and you verify it in the rendered source of a product page, never in the app preview.

Where the custom part belongs on WordPress: Not in functions.php. On taismo.de the JSON-LD of each page lives in its own meta field, written through the REST API and printed into the head by a must use plugin. A must use plugin loads before everything else and survives theme updates. We moved to that setup after a parent theme update wiped a connector out of functions.php and took the schema of every page with it.

The rule that keeps a stack sane: One system owns each entity. The plugin can keep the identity layer, the custom block extends the same nodes through the same @id. Two systems describing one company is not redundancy. It is one contradiction with two authors.

A worked example: One post, four nodes

Here is a complete blog post graph. Four nodes, two references to global entities defined elsewhere, nothing repeated:

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "WebPage",
      "@id": "https://example.com/blog/schema-markup/",
      "url": "https://example.com/blog/schema-markup/",
      "name": "Schema markup in practice",
      "isPartOf": { "@id": "https://example.com/#website" },
      "primaryImageOfPage": { "@id": "https://example.com/blog/schema-markup/#primaryimage" },
      "breadcrumb": { "@id": "https://example.com/blog/schema-markup/#breadcrumb" },
      "mainEntity": { "@id": "https://example.com/blog/schema-markup/#article" },
      "inLanguage": "en-US"
    },
    {
      "@type": "BlogPosting",
      "@id": "https://example.com/blog/schema-markup/#article",
      "headline": "Schema markup in practice",
      "datePublished": "2026-08-09T09:00:00+02:00",
      "dateModified": "2026-08-09T09:00:00+02:00",
      "author": { "@id": "https://example.com/#person-jane-doe" },
      "publisher": { "@id": "https://example.com/#organization" },
      "image": { "@id": "https://example.com/blog/schema-markup/#primaryimage" },
      "mainEntityOfPage": { "@id": "https://example.com/blog/schema-markup/" }
    },
    {
      "@type": "ImageObject",
      "@id": "https://example.com/blog/schema-markup/#primaryimage",
      "contentUrl": "https://example.com/img/schema-markup.webp",
      "width": 1280,
      "height": 720
    },
    {
      "@type": "BreadcrumbList",
      "@id": "https://example.com/blog/schema-markup/#breadcrumb",
      "itemListElement": [
        { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://example.com/" },
        { "@type": "ListItem", "position": 2, "name": "Blog", "item": "https://example.com/blog/" },
        { "@type": "ListItem", "position": 3, "name": "Schema markup in practice" }
      ]
    }
  ]
}

Three details do the heavy lifting. The author and publisher values are references, not objects, so the person and the company stay defined in one place. Every @id is an absolute URL in the same canonical form. And the dates carry a timezone offset, which is what makes them unambiguous to a parser. Nothing here needs a generator, and a generator would work against you, because it produces isolated blocks by design.

Test it before Google does

Schema markup is invisible, so a broken block produces no symptom. One missing comma voids an entire graph while the page looks perfect. Three tools cover the ground, and they answer different questions.

1. Rich Results Test: Reports whether Google considers the page eligible for a specific rich result. It only covers types that produce a visual feature, so a valid Service node showing nothing here is expected, not a fault.
2. Schema Markup Validator: Checks the markup against the schema.org vocabulary, independent of Google. This is the tool that catches a misspelled property.
3. Google Search Console: Shows what Google actually parsed on your live URLs at scale. The other two test one URL you choose. This one reports the templates you forgot.

One tool is missing from that list on purpose. The Structured Data Testing Tool, still linked in half the tutorials online, no longer exists in the form people remember. Google stripped the Google specific checks in December 2020 and handed the tool to the schema.org community, where it runs today as the Schema Markup Validator at validator.schema.org, announced in May 2021. Any instruction that starts with “open the Structured Data Testing Tool” was written before that handover.

Search Console sorts everything into two buckets, and the definitions are stricter than they look. A valid item “doesn’t have any critical issues and can appear on Google as a rich result”. An invalid item has “at least one critical issue preventing it from appearing as a rich result”. Everything else is a non critical issue and blocks nothing.

The reports lag your deploy, because they show the last crawl and not your last commit. A template fixed on Monday can sit in the report as broken for a week. Use the Validate Fix button so Google recrawls the affected URLs, and check one live URL through the Rich Results Test in the meantime rather than watching a graph that has not been updated yet.

Read errors and warnings differently. An error takes the feature off the table until you fix it. A warning names a recommended property you left out, and plenty of warnings are worth ignoring. Chasing every warning to zero is how teams end up marking up fields they cannot maintain.

What the error messages actually mean

Both validators answer in short sentences that name a field and never a cause. Six messages cover almost everything you will meet in practice.

Read the last two as a pair, because together they mark the border of what any tool can do for you. A Product without an offer is a structural fault, found instantly. A date in the wrong format is caught just as fast. A date in the right format that contradicts the byline on the page passes every validator you own. Nothing automated catches a well formed lie, which is why the release checklist matters more than the test run.

Seven mistakes that break schema markup

Seven failure patterns account for nearly everything we find in audits.

1. Marking up what the visitor cannot see. Prices, FAQ and reviews that exist only in the JSON-LD. This is the breach that draws a manual action.
2. Two blocks, one entity, different values. The plugin says one company name, the hand written block says another. Google trusts neither.
3. Invented or borrowed ratings. Company reviews attached to a product, or a rating with no visible source.
4. Type stacking. Nine types on a page that visibly contains two. Every extra type is a claim you have to keep true.
5. Unstable identifiers. An @id that switches between http and https, or between trailing slash and none, splits one entity into two.
6. Markup that only exists after JavaScript. It usually gets picked up, and it fails silently when rendering does.
7. Fossils after a relaunch. Old URLs in @id, an author who left, a price from two years ago.

Six of the seven share one cause: Nobody owns the markup after launch. Put schema in the release checklist next to redirects and it stops happening.

What schema markup does for AI answers

The payoff that has grown fastest since 2024 sits outside classic search. AI assistants and AI Overviews have to decide which entity a page belongs to before they can cite it, and a clean graph answers that without inference.

Be precise about the mechanism, because there is a lot of confident nonsense on this topic. No large language model provider publishes that it reads JSON-LD as a ranking input, and you should distrust anyone who claims otherwise. What structured data demonstrably does is remove ambiguity: It states which of the four companies with your name is yours, which topics you claim competence in, and who wrote the piece. Google’s own AI surfaces work on top of that same knowledge graph layer.

That makes markup one of the concrete levers in generative engine optimization. It replaces neither content nor authority. It makes an entity resolvable, which is the condition for being cited correctly instead of being confused with a namesake.

Does schema markup improve rankings?

No. Structured data is not a ranking factor, and Google has said so consistently since rich results launched. Anyone selling schema markup as a ranking lever is selling the wrong benefit.

The effect lands on click through rate at a fixed position. A result carrying review stars, a price, a readable breadcrumb path or an event date takes up more space in the SERP and answers more of the question before the click. Position four with a rich result routinely outperforms position four without one.

So schema markup is not the fix for a page that does not rank. It is what you do to a page that already ranks, so the ranking converts into visits.

Your rollout in five steps

Five steps, in this order, get a site from nothing to a maintained graph:

1. Step 1: Inventory. Pull the JSON-LD from one URL per template, duplicates included.
2. Step 2: Identity layer. Define Organization, WebSite and one Person per author, once, with a complete sameAs list.
3. Step 3: Page layer. One primary type per template, referencing the identity layer instead of repeating it.
4. Step 4: Test. One URL per template through both validators, then watch Search Console for two weeks.
5. Step 5: Own it. Put a schema check in the release checklist, next to redirects.

Steps 1 and 2 take a few days and produce most of the value. Steps 3 to 5 stop it decaying.

Schema markup FAQ

What is schema markup?

Schema markup is code that describes the content of a page using the schema.org vocabulary, written in JSON-LD and placed in the page source. It tells search engines and AI systems what the page is rather than letting them infer it from prose.

Does schema markup help SEO?

Yes, indirectly. Structured data is not a ranking factor, but rich results raise the click through rate at an unchanged position, and a clean entity graph improves how correctly search engines and AI systems attribute your content.

How do you add schema markup to a website?

Write the JSON-LD, then deliver it through an SEO plugin, a template, or a dedicated field printed into the head by a small plugin. Put it in the server response rather than in a tag manager, so the markup exists before JavaScript runs.

How do you test schema markup?

Run one URL per template through Google’s Rich Results Test for eligibility and through the Schema Markup Validator for vocabulary errors, then check Search Console to see what Google parsed on your live pages.

How many schema types should one page have?

One primary type that matches what the page visibly is, plus the global entities referenced by @id. Additional types are only worth adding when the page genuinely contains that content, because every type is a claim you have to keep true.

Does FAQ schema still work?

Not as a search feature. Google switched FAQ rich results off on 7 May 2026, after limiting them to government and health sites in August 2023. FAQPage remains valid schema.org and still gives machines and AI systems a clean question and answer pair, so mark up the FAQ blocks you really show and expect no visual result.

Should you use JSON-LD or Microdata?

JSON-LD. Google names it the recommended format because it lives in its own script block, independent of the HTML around it, so a redesign cannot quietly break it. Microdata and RDFa carry the same vocabulary inside the visible markup, which ties your data to your layout.

Which schema types produce a rich result?

Google’s structured data gallery currently documents 25 features, among them Article, Product, Local business, Event, Job posting, Recipe, Video, Review snippet, Breadcrumb and Organization. FAQ and HowTo were removed and no longer appear there.

Sources

• Google Search Central: “Intro to how structured data markup works”, Google, 2026.
• Google Search Central: “General structured data guidelines”, Google, 2026.
• Google Search Central: “Structured data markup that Google Search supports”, Google, 2026.
• Google Search Central: “Changes to HowTo and FAQ rich results”, Google, August 2023.
• Google Search Central: “FAQPage (FAQ) structured data”, Google, 2026.
• Google Search Central: “Local business (LocalBusiness) structured data”, Google, 2026.
• schema.org: “Organization of Schemas”, Schema.org Community Group, 2026.
• Schema Markup Validator: “Schema Markup Validator”, Schema.org Community Group, 2026.
• Google Search Central: “What’s new in Search Central” (changelog entries “Deprecating the FAQ rich result feature”, 8 May 2026, and “Removing documentation for the FAQ rich result feature”, 15 June 2026), Google, 2026.
• Google Search Central: “Article (Article, NewsArticle, BlogPosting) structured data”, Google, 2026.
• Google Search Central: “Product snippet (Product, Review, Offer) structured data”, Google, 2026.
• Google Search Central: “Event (Event, EventSeries) structured data”, Google, 2026.
• Google Search Central: “Job posting (JobPosting) structured data”, Google, 2026.
• Google Search Central: “Recipe (Recipe, HowTo) structured data”, Google, 2026.
• Google Search Central: “Video (VideoObject, Clip, BroadcastEvent) structured data”, Google, 2026.
• Google Search Central: “Sunsetting support for data-vocabulary”, Google, 21 January 2020.
• Google Search Central: “An update on the Structured Data Testing Tool”, Google, December 2020.
• Schema.org: “Announcing Schema Markup Validator”, Schema.org Community Group, 21 May 2021.
• Google Search Console Help: “Rich result status reports”, Google, 2026.