Schema Markup for WordPress: How to Get Rich Results (2026)

Schema markup for WordPress is one of those topics that gets buried under jargon fast: JSON-LD, microdata, rich results, structured data, entity graphs. Strip the jargon away and the idea is simple. A search engine reading your page in plain HTML has to guess what it's looking at: is this a recipe, a review, a how-to, a blog post? Schema markup removes the guessing. It's a small, separate block of code that states outright: this is an Article, published on this date, by this author, containing these FAQ entries. No ambiguity, no parsing effort, no room for the search engine to get it wrong.

That precision used to matter mainly for rich results: the star ratings and readable breadcrumb paths you still see in Google, plus the expandable FAQ dropdowns and step lists it retired in 2023. It matters for a second, newer reason now too: AI-driven search and answer engines pull from your content to generate direct answers, and structured data is the cleanest signal they have for extracting the right facts. This article covers what schema actually is, which types are worth your time on a WordPress site, the honest ways to add it, the mistake that turns schema into a liability, and how to check your work before you publish.

What structured data actually is

Structured data is content described in a standard vocabulary (schema.org) that both search engines and AI systems have agreed to read the same way. Instead of a machine inferring "this looks like a blog post" from your headline and byline, you tell it directly, in a format built for machines rather than humans.

JSON-LD over microdata

There are technically three ways to write schema: microdata (attributes scattered through your existing HTML tags, like itemprop and itemscope), RDFa (similar idea, different attribute syntax), and JSON-LD (a single, self-contained script block). Google has recommended JSON-LD for years, and for good reason. Microdata forces you to weave machine-readable attributes into the same tags that control your visible layout, so a template change can silently break your schema without anyone noticing. JSON-LD sits apart from your markup entirely, in its own <script type="application/ld+json"> tag, which means your visible HTML and your structured data can be edited independently without either one breaking the other. If you're setting up schema markup for WordPress today, there's no real reason to reach for anything else.

Here's what a minimal Article schema in JSON-LD looks like in practice:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Your Article Title",
  "datePublished": "2026-07-18",
  "author": { "@type": "Person", "name": "Your Name" }
}
</script>

That's the whole idea: a plain object, in a format any parser can read without touching your page's visible structure at all.

Which schema types matter on WordPress

Schema.org defines hundreds of types, but a typical WordPress site only needs a handful of them done well. Here's what earns its place.

Article (or BlogPosting)

The baseline type for any post: headline, author, publish date, and usually a publisher. It's what lets Google show a date next to your result and helps establish the piece as a distinct, attributable work rather than an anonymous page. If you write blog content at all, this is the one schema type you shouldn't skip.

FAQPage

Wrapping a genuine question-and-answer section in FAQPage schema states outright which sentence is the question and which is the answer. What it no longer buys you is a search result: since August 2023 Google has shown expandable FAQ snippets only for a small group of government and health sites and switched them off for everyone else. The type still earns its place, because it is one of the formats AI answer engines lift most readily, a question paired with a clean answer being close to the exact shape they need. It only counts when those questions and answers are genuinely visible on the page, which is the subject of the mistake section further down.

HowTo

HowTo schema describes a set of instructions as an ordered sequence, with an optional total duration in ISO 8601 form such as PT45M for 45 minutes. Numbered steps in the search result are gone: Google retired the HowTo rich result in 2023. As a machine-readable outline for tutorials, setup guides and recipes the type is still useful, but you can no longer plan for an effect in search. And it only makes sense when your content actually is a sequence of discrete steps, not a general explainer dressed up as one.

BreadcrumbList

Breadcrumb schema describes your page's position in the site hierarchy (Home > Blog > This Post, for instance) and typically shows up as a clean path under your result's title instead of the raw URL. It's low-effort and close to zero-risk, since it just restates navigation you already have.

Product

For anything you sell, Product schema can surface price, availability and review ratings directly in search results. It's the type with the most visible payoff for ecommerce, and also the one Google audits most aggressively for accuracy, since it's directly tied to a purchase decision.

Which types still show something in 2026

The list is shorter than most tutorials on the web admit. Google cleared house in 2023 and pulled two of the most popular markups out of the results. That did not make them worthless, it moved where they work: in answer engines, in your own llms.txt, and anywhere a program has to read your text instead of look at it.

Why AI search engines lean on structured data

Traditional SEO optimized for a ranking algorithm. Increasingly, you're also optimizing for a language model that has to read your page, decide whether it's trustworthy, and extract a specific fact to hand back to a user in ChatGPT, Perplexity or a Google AI Overview. That's a harder job than ranking a link, and structured data makes it dramatically easier.

An AI system inferring your publish date from scattered text is doing fundamentally different work than one reading "datePublished": "2026-07-18" straight from JSON-LD. The second is faster, cheaper and less error-prone to process, which makes your content a more attractive source to cite. Think of schema as writing an answer engine's cheat sheet directly into your page, rather than hoping it parses your prose correctly. That's the answer-engine angle: structured data was always good for search, and it's arguably even more valuable for AI visibility now.

Next to the schema: llms.txt and answer blocks

JSON-LD answers the question of what a given section means. Two neighbouring pieces answer the question of which page matters at all, and that is the one an answer engine asks first.

llms.txt is a plain Markdown file at the root of your domain, reachable at your-domain.com/llms.txt. It lists the content you want AI systems to prioritise, each with a title, a link and half a sentence on what it is for. Instead of digging through navigation, cookie banners and a footer, an assistant reads a curated map; the longer variant is called llms-full.txt. The honest caveat: this is a proposal, not a ratified standard, and no search engine guarantees it reads the file. The effort is small in return, because there is no more to it than this:

# Example Site

> WordPress care from Hamburg, specialised in fast block themes.

## Core
- [Services](/services/): what we build and what we do not
- [Pricing](/pricing/): fixed-price packages

## Optional
- [llms-full.txt](/llms-full.txt)

Answer blocks are the second piece: a TL;DR up top, a one-sentence definition, question-and-answer pairs, numbered steps. They are there for readers, and they happen to produce exactly the shape of text an AI system can take over without rebuilding a paragraph first. Write them in the editor and let the matching markup be written alongside automatically, and the duplicate maintenance that sinks hand-built schema in practice disappears. We split that work the way the WordPress directory requires: the Hafen theme handles presentation, and the companion plugin Hafen Core emits the JSON-LD for articles, authors, breadcrumbs and the organization, plus llms.txt and the answer blocks. The reason is a directory rule: features have to survive a theme switch, so a theme may only be responsible for presentation.

Honest ways to add schema to WordPress

There's no single correct way to add schema markup to WordPress. There are three reasonably good ones, each with a real trade-off worth knowing before you pick.

An SEO plugin

Yoast SEO, Rank Math and similar plugins generate Article and Breadcrumb schema automatically, plus a block or module for FAQ and HowTo that stays in sync with your visible content. Path of least resistance for most site owners, and a reasonable choice, though it means one more plugin's settings screens and update cycles for a feature that's fundamentally a few lines of JSON.

A manual code block

For a one-off page, or a type your plugin doesn't cover, paste a JSON-LD script into a Custom HTML block in the editor, or into your theme via a code-snippets plugin. Full control, no plugin dependency, but every value has to be kept in sync by hand. Change the FAQ text and you have to remember to update the matching JSON too.

A theme plus its companion plugin

The third path generates the JSON-LD for you, straight from the content blocks you already write, with no SEO plugin and no copy-paste step to forget. It comes in two parts, and the order gets reversed a lot: the theme handles presentation, and a small companion plugin emits the structured data. That is the approach we took with our own theme and its plugin Hafen Core, described below (full disclosure, since we build both), but it's an honest third option, not just the first two.

The mistake that turns schema into a liability

The most common schema mistake isn't a syntax error, it's a mismatch: marking up content that isn't actually visible on the page. Add FAQPage schema for questions a visitor can't see anywhere in your rendered HTML, and you're not gaming the system, you're describing a page that doesn't exist. Google's guidelines are explicit about this, and Search Console will eventually flag it as a manual action or a spam issue once it's caught, at which point you lose the rich result entirely, on every page using that schema, not just the one that triggered it.

The rule is simple to state and easy to forget under deadline pressure: schema should describe what's genuinely on the page, not what you wish were there. If you mark up a HowTo with five steps, five steps need to be visibly readable in your content. If you mark up FAQ questions, a visitor scrolling the page needs to be able to read the same questions and answers your JSON-LD claims exist. Structured data is a mirror of your visible content, not a wishlist layered on top of it.

Testing your schema with Google's Rich Results Test

Before you trust any schema you've added, whether from a plugin, a hand-written code block or a theme, run the live page through Google's Rich Results Test. Paste in your URL, and it tells you exactly which schema types it detected, which fields are valid, and which are missing or malformed. It's free, takes seconds, and it's the same validation logic Google actually uses, so a clean result there is a genuine, not a hopeful, signal.

A few checks worth making a habit: verify the tool actually detects the type you meant to add, not a different one it guessed at from ambiguous markup. Check for warnings, not just errors. Warnings won't block a rich result outright, but they usually point at optional fields worth filling in for a stronger result. And re-test after any theme or plugin update that touches how your pages render, since a template change is the single most common way working schema quietly breaks.

One limitation belongs in the picture: the test no longer shows a preview for FAQPage or HowTo, because Google switched those results off. Whether the markup is valid is still visible there, and the Schema Markup Validator answers that question without any regard for Google's display policy, checking straight against schema.org. A plain JSON validator is the faster route for a simple typo.

The Hafen approach: schema that's just there

At hafenstudios we build Hafen, our AI-native WordPress block theme, and one early decision was that schema shouldn't be a separate task you remember to do. The theme itself only handles presentation. The Article, FAQ, Breadcrumb and Organization JSON-LD comes from the free companion plugin Hafen Core, generated straight from the content blocks you already write: no SEO plugin bolted on for it, no manual code block to keep in sync. Write your FAQ block, and the matching FAQPage schema exists the moment you publish, always in sync with what's visible, sidestepping the mismatch problem above by construction. The split is not a quirk, it is a directory rule: features have to survive a theme switch, so they may not live in the theme. Install the theme on its own and you get no JSON-LD.

To be upfront about where Hafen stands: it is free in the official WordPress theme directory, version 1.0.0 was released on 4 September 2026, and it ships with 38 looks you can switch between without rebuilding anything. Hafen Core is free too, in the official WordPress plugin directory, at version 1.0.1 since 4 September 2026. What it does not have is a decade of hours on other people's servers, which a long-established theme does. If you need proven schema tooling today, a mature SEO plugin is the safer near-term choice. If you'd rather start with a theme that treats structured data as first-class instead of bolted-on, Hafen is worth a look, and Hafen 1.0: one theme, 38 looks, zero font files covers how it is built.

Whichever route you take to add schema, plugin, manual code, or a theme that handles it natively, the underlying discipline is the same: keep it accurate, keep it in sync with what's visible, and test it before you trust it. If you're also weighing whether your page builder is adding more overhead than it's worth, our comparison of WordPress Elementor alternatives covers the same lean-foundation question from a different angle.

Frequently asked questions