Most schema markup content tells you the same thing: "Add Article schema, fill in your Organization, you're done." That advice was true in 2019. It is no longer true in 2026.
Between August 2023 and the broader rich result restrictions that followed, Google quietly rewrote the rules of what schema markup actually buys you in search. FAQ rich results were locked down to government and authoritative health sources. HowTo rich results on desktop were deprecated outside of "very narrow circumstances." Plenty of guides still tell you to bolt FAQ schema onto every blog post for "rich snippets" that will never appear.
The schema types that actually move the needle in 2026 are not the ones most WordPress tutorials emphasize. After years of hand-rolling structured data for content sites and ecommerce stores — and watching plugin-emitted graphs collide with custom ones in Search Console — I have a much shorter list of what is worth your time. This post walks through that list, the code to implement it correctly in WordPress, and the mistakes that quietly cost rankings.
Schema basics: a fast recap before we get advanced
If you already know JSON-LD from microdata, skim this section. If you do not, here is the entirety of what you need to know to follow the rest of the article.
JSON-LD vs microdata vs RDFa. Three formats exist for telling Google what your content is about. Use JSON-LD. Always. Google explicitly recommends it, every modern WordPress SEO plugin emits it, and it is the only format that lets you keep structured data cleanly separated from your HTML markup. Microdata and RDFa still work, but they entangle schema with your visual templates and make refactoring miserable.
Where to place it. Inside a <script type="application/ld+json"> tag. Either the <head> or the <body> works — Google parses both. WordPress plugins typically inject in the head. If you are hand-rolling, put it wherever your template renders cleanly.
Validation. Two tools matter. Google's Rich Results Test tells you whether a page is eligible for a specific rich result and shows a visual preview. The Schema.org Validator (separate tool, schema.org/validator) checks syntactic correctness against the broader schema vocabulary. Use Rich Results Test for "will this trigger a rich result," and Schema.org Validator for "is my JSON syntactically valid." They answer different questions.
That is the entire foundation. Now the interesting part: which schema types are actually worth implementing.
The schema types that drive rich results in 2026
Google supports dozens of schema types. Most of them do nothing visible in search results. Of the ones that did matter historically, several have been quietly downgraded. Here is the honest 2026 picture, type by type.
HowTo — downgraded but not dead
HowTo schema was a darling of cooking sites, DIY blogs, and tutorial-heavy publishers from 2017 to 2023. Then in August 2023, Google restricted HowTo rich results on desktop to "very narrow circumstances" — effectively killing the desktop carousel for most queries. Mobile rich results still appear for some queries, but at a fraction of the previous rate.
Should you bother? Yes, but only on genuinely procedural content. The reason is not the rich result anymore — it is semantic understanding. HowTo schema tells Google explicitly: "this is a step-by-step procedure with these tools and these inputs." That helps with topic understanding even when the visual rich result does not appear. Do not paint HowTo onto a listicle that is not actually a procedure. That violates the spec and you risk a manual action.
FAQ — restricted but still parsed
FAQ schema took the same hit. As of August 2023, FAQ rich results are restricted to government and authoritative health sources. If you are a marketing blog or ecommerce site, you will not get the accordion FAQ in search results no matter how clean your markup is.
Keep it anyway, with caveats. Google still parses FAQ schema and uses it to inform the "People Also Ask" box. We have seen pages with proper FAQ markup get pulled into PAA at materially higher rates than equivalent pages without it. Just do not waste effort on FAQ schema for pages that are not actually FAQ pages — the spec requires the questions and answers to be the primary content of the page or section.
Product — the workhorse for ecommerce
If you sell things, Product schema is non-negotiable. It triggers price, availability, and rating in the SERP, and those visual elements measurably increase click-through. Required fields: name, image, description, sku, brand, and an offers object with price, priceCurrency, and availability. Recommended additions: aggregateRating and review.
One subtle thing: Google has gotten strict about Product schema reflecting the actual product page. If your offers.price is $49 and the page shows $59, the schema will be ignored or trigger a manual action. The schema must match the page exactly.
Review and AggregateRating — the policy minefield
Review schema and aggregateRating still drive star-rating snippets in SERPs. They are also where most schema-related manual actions originate. Google's policy is unambiguous: ratings must reflect real reviews from real users. Faking aggregateRating values, marking up content as a review when it is not a review, or applying ratings to your own brand from your own page — all violations. The penalties show up as "Site reputation abuse" or "structured data manual actions" in Search Console.
Course — for genuine educational content
Course schema triggers a carousel of course offerings for queries like "learn Python" or "online marketing course." If you publish actual courses, implement it. If you publish "how to" articles you call "courses" for marketing reasons, do not.
SoftwareApplication — the underused SaaS win
This one is undersold. SoftwareApplication schema surfaces price, rating, and operating system in SERPs for software queries. For SaaS landing pages, it produces visible rich results far more reliably than most marketing blogs realize. Required: name, operatingSystem (use "Web" for web apps), applicationCategory. Recommended: offers and aggregateRating.
VideoObject — mandatory if you embed video
Any page with an embedded video should have VideoObject schema. It tells Google what the video is, when it was uploaded, how long it runs, and where the thumbnail lives. Without it, Google has to infer all of that from oEmbed metadata, and it often gets it wrong. With it, your page is eligible for the video carousel and inline video previews. Effort is low, payoff is real.
BreadcrumbList — trivial and universal
BreadcrumbList replaces the ugly URL string under your title in search results with a clean breadcrumb path. It takes ten lines of JSON-LD per page. It works everywhere. Every site should have it. There is no scenario in which BreadcrumbList is not worth implementing.
Organization with full Knowledge Graph fields
Most sites add bare-bones Organization schema with name and logo and stop there. The full set of fields — sameAs linking to your social profiles, contactPoint, founder, foundingDate, address, logo with proper dimensions — is what Google uses to construct a Knowledge Panel for your brand. The Knowledge Panel does not appear automatically. It appears when Google has enough corroborated structured data to build one. Filling out Organization fully is the single highest-leverage schema addition for brand building.
How to add schema in WordPress: the real options
There are four practical paths, and the right one depends on how much control you want to trade for convenience.
Hand-rolled in functions.php or a custom plugin. Maximum control, zero overhead, but you maintain the code. This is what I recommend for content engineers and anyone running a single high-value site. You write the JSON-LD output, hook it into wp_head, and you know exactly what is being emitted. No surprises.
Yoast SEO. Yoast emits a clean default graph: Article, BreadcrumbList, Organization, Person, and WebPage all linked together with proper @id references. It is solid for the basics. It does not give you advanced types like Product, Course, or SoftwareApplication out of the box.
Rank Math (Free + Pro). The best free option in the WordPress ecosystem. Supports Article, Product, Recipe, Video, Course, FAQ, HowTo, Software, and more, with a UI for filling in fields per post. The Pro version adds template-based schema and conditional logic. If you want a plugin and you do not want to pay much, this is it.
Schema Pro and Saswp. Both are template-driven plugins for sites that want comprehensive schema without writing code. Schema Pro from Brainstorm Force is opinionated and clean; Saswp is exhaustive and slightly cluttered. Either works.
My recommendation: hand-rolled if you have a single site and someone who can maintain the code; Rank Math if you want a plugin. Do not stack plugins.
Code example: FAQ schema done right
Here is a full FAQ JSON-LD block for three questions. Note the mainEntity array, the Question and Answer nesting, and the fact that the text field uses plain text — you can include basic HTML, but keep it simple.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "Does FAQ schema still produce rich results in 2026?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Only for government and authoritative health sources. For everyone else, FAQ schema no longer triggers the accordion rich result, but it still informs the People Also Ask box and Google's semantic understanding of the page."
}
},
{
"@type": "Question",
"name": "Should I add FAQ schema to every blog post?",
"acceptedAnswer": {
"@type": "Answer",
"text": "No. FAQ schema is appropriate when the questions and answers are the primary content of the page or section. Adding it to a generic article with a tacked-on Q&A block violates the spec and risks a manual action."
}
},
{
"@type": "Question",
"name": "Can I include the same questions in FAQ schema and on the visible page?",
"acceptedAnswer": {
"@type": "Answer",
"text": "You must. Google requires that any content marked up in schema be visible on the page. Hidden Q&A blocks — collapsed, off-screen, or otherwise not rendered — are explicitly against policy and a common cause of manual actions."
}
}
]
}
</script> Two things to call out. First, the questions are real questions someone actually asks, not keyword-stuffed phrases. Second, every question and answer in the schema is also visible on the page. That is a hard requirement, not a suggestion.
Code example: Product schema with offers and aggregateRating
This is a full Product schema block for an ecommerce product, with the offers object and an aggregateRating that reflects real reviews. Adapt the URLs and SKUs.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Acme Pro Espresso Grinder",
"image": [
"https://example.com/images/grinder-front.jpg",
"https://example.com/images/grinder-side.jpg"
],
"description": "Direct-drive flat burr grinder with 50mm burrs and stepless adjustment, designed for espresso-focused home users.",
"sku": "ACME-EG-50",
"mpn": "AEG50-2026",
"brand": {
"@type": "Brand",
"name": "Acme"
},
"offers": {
"@type": "Offer",
"url": "https://example.com/products/acme-pro-espresso-grinder",
"priceCurrency": "USD",
"price": "549.00",
"priceValidUntil": "2026-12-31",
"availability": "https://schema.org/InStock",
"itemCondition": "https://schema.org/NewCondition"
},
"aggregateRating": {
"@type": "AggregateRating",
"ratingValue": "4.6",
"reviewCount": "184"
}
}
</script> The price field must match what is on the page, including any current promotional pricing. The availability field must reflect actual stock status — if the product is out of stock, change it to OutOfStock or risk a manual action. The aggregateRating must come from real customer reviews on your site or a verified third-party platform.
Nested schema graphs: the @graph approach
Once you have multiple schema types on a single page — an Article written by a Person published by an Organization, with a BreadcrumbList and a WebPage wrapper — you have two options. You can emit several separate <script> blocks, one per type, or you can use a single @graph block that links them with @id references. The second approach is cleaner, smaller, and what Yoast emits by default.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "Organization",
"@id": "https://example.com/#organization",
"name": "Example Publishing",
"url": "https://example.com/",
"logo": {
"@type": "ImageObject",
"url": "https://example.com/logo.png",
"width": 600,
"height": 60
},
"sameAs": [
"https://twitter.com/examplepub",
"https://www.linkedin.com/company/examplepub"
]
},
{
"@type": "Person",
"@id": "https://example.com/about/#author",
"name": "Jane Smith",
"url": "https://example.com/about/",
"worksFor": { "@id": "https://example.com/#organization" }
},
{
"@type": "Article",
"@id": "https://example.com/post-slug/#article",
"isPartOf": { "@id": "https://example.com/post-slug/#webpage" },
"author": { "@id": "https://example.com/about/#author" },
"publisher": { "@id": "https://example.com/#organization" },
"headline": "Article Headline Here",
"datePublished": "2026-04-15T09:00:00-04:00",
"dateModified": "2026-04-26T14:30:00-04:00",
"image": "https://example.com/featured.jpg"
}
]
}
</script> The @id values are URI-shaped strings that act as internal references. You define an entity once and reference it elsewhere. This is how you tell Google "the author of this article is the same person who has this profile page, who works for this organization, which has these social profiles." Without the graph linkage, Google has to infer those relationships from external signals.
What NOT to do: the policy boundaries
Schema looks like a free SEO buff until it triggers a manual action. Here are the policy lines you do not cross.
Do not mark up content that is not visible on the page. The most common form of this is hidden FAQ — a div with display: none containing questions, marked up in FAQ schema, hoping for the rich result. Google calls this out explicitly in their structured data guidelines. It will trigger a manual action.
Do not put fake reviews or invented aggregateRating values. Treat aggregateRating like a financial disclosure. The number must reflect real reviews from real users. If you have 12 reviews averaging 4.2 stars, that is your aggregateRating. Not 4.9. Not 487 reviews.
Do not mark up the same entity twice with conflicting data. Yoast emitting an Article with one datePublished and a custom plugin emitting a second Article with a different datePublished is a real situation we have debugged. Google sees the conflict and ignores both.
Do not use HowTo for non-procedural content. A listicle is not a procedure. A comparison post is not a procedure. HowTo is for "first do X, then do Y, then do Z" content with discrete steps. Misuse is a violation, and the rich result is so rare on desktop now that the upside is minimal anyway.
Validation and debugging: the actual workflow
When schema breaks — and at scale, it always eventually breaks — here is the workflow that finds the problem fastest.
- Rich Results Test (search.google.com/test/rich-results): Paste the URL. It tells you which rich result types Google considers the page eligible for, with a visual preview. If you expect Product rich results and the test shows zero detected, you have a structural problem.
- Schema.org Validator (validator.schema.org): Same URL or a paste of the JSON-LD. This tool catches syntactic issues that Rich Results Test glosses over — missing required fields, malformed dates, type mismatches.
- Search Console > Enhancements: Once Google has crawled the page, the Enhancements section reports indexed schema by type, with errors and warnings broken out per URL. This is where you catch problems that only show up at scale — "Missing field 'image' on 1,247 pages" is the kind of thing you do not see until you look here.
- The browser source view: Always confirm the schema is actually being emitted. Plugins occasionally fail silently after updates. View source, search for
application/ld+json, and confirm the output matches what you expect.
One specific debugging note. If you see "Missing field 'image'" in Search Console, it almost never means you forgot to include the field. It means the image URL did not resolve when Google tried to crawl it — CDN misconfiguration, broken redirect, robots.txt blocking the image directory. Fix the URL resolution and the warning clears on the next crawl.
Schema types in 2026: what is actually worth implementing
| Schema Type | Rich Result in 2026? | Effort | Worth Implementing? | Best For |
|---|---|---|---|---|
| Article | Yes | Low | Always | All editorial content |
| HowTo | Mobile only, narrow | Medium | Only for genuinely procedural content | Tutorials, recipes, step-by-step guides |
| FAQ | PAA only, no accordion | Low | Only for actual FAQ sections | Q&A pages, support documentation |
| Product | Yes (price, rating, availability) | Medium | Always for ecommerce | Ecommerce product pages |
| Review | Yes (star rating) | Medium | Yes for review content | Review sites, testimonials |
| Course | Yes (carousel) | Medium | Yes if education is core | Online courses, education sites |
| SoftwareApplication | Yes (price, rating, OS) | Low | Yes for SaaS | SaaS landing pages |
| VideoObject | Yes (video carousel) | Low | Always when video present | Any page with embedded video |
| BreadcrumbList | Yes (breadcrumbs in SERP) | Trivial | Always | Every site, every page |
| Organization | Knowledge Panel signal | Low (one time) | Always, with full fields | Site root, brand identity |
Schema is not magic SEO dust. It tells Google what your content is about; Google still has to decide whether to surface it. Implement schema where the rich result actually exists, the policy is clean, and the maintenance burden is sustainable. Skip the rest.
Common mistakes I keep finding in audits
These show up in nearly every WordPress schema audit I run. They are not exotic. They are the same five issues, on different sites.
- Marking up content that is not on the page. Hidden FAQ accordions where the answers are loaded via JavaScript and never appear in the rendered DOM. Schema generators that pull product descriptions from a backend API the page does not actually display. Both are violations.
- Two plugins emitting conflicting schema. Yoast plus a theme that ships its own Article schema is the classic version. Search Console reports "Duplicate field" or "Unparsable structured data," and the fix is usually disabling whichever source is less complete.
- Forgetting
imageURLs — or letting them break silently. Image is a common rich result trigger. If your CDN swaps domains, your old image URLs in old schema entries break, and Search Console quietly fills with "Missing field 'image'" warnings that are actually URL resolution failures. - Treating schema as a one-time setup. Schema needs maintenance. Schema.org adds and deprecates fields. Google adds and restricts rich result types. The HowTo and FAQ changes in 2023 stranded a lot of sites that had set their schema once in 2019 and never revisited it.
- Adding 8 schema types when 3 would do. Diminishing returns are real. Article + BreadcrumbList + Organization, done well, outperforms ten half-implemented types. Adding Course schema to a marketing blog because "it might help" is wasted effort. Pick what fits the content.
The 5 schema types worth the effort in 2026
If you have limited time and want to know where to spend it, here is the prioritized list I actually use when setting up a new WordPress site.
- Article on every editorial page. Always. It is the foundation.
- BreadcrumbList universal, trivial, every page gets it. There is no scenario in which BreadcrumbList is not worth ten lines of JSON-LD.
- Organization with full Knowledge Graph fields —
sameAs,contactPoint,founder,foundingDate,logowith proper dimensions. One-time setup, ongoing brand-building payoff. - Product or SoftwareApplication depending on what you sell. If you have a checkout, Product. If you have a SaaS landing page, SoftwareApplication. Both produce visible rich results reliably.
- VideoObject on every page with embedded video. Low effort, real payoff in video carousel placement.
And what to skip unless the use case actually fits: HowTo (limited rich result, only worth it on genuinely procedural content), FAQ (no accordion rich result outside government and health, only worth it on real FAQ pages), Course (only if education is genuinely core to your business).
The schema landscape will keep shifting. The HowTo and FAQ restrictions in 2023 caught a lot of practitioners off guard, and there is no reason to think future deprecations will not come. Build your schema implementation so that adjusting it is a refactor, not a rewrite. Use a single source of truth — one plugin or one custom module — not three competing ones. Validate after every WordPress core or plugin update. And accept that the goal is not "all the schema types." It is "the right schema types, implemented correctly, maintained over time."
Get those five right and you will outperform sites that have triple the markup and half the discipline.