Dispatch
What Is Schema Markup? A Practical Guide to Structured Data
Structured data is markup added to a web page's code that labels specific pieces of content so search engines can understand exactly what they mean, not just what they say....
On this page
Structured data is markup added to a web page’s code that labels specific pieces of content so search engines can understand exactly what they mean, not just what they say. Google’s own documentation describes it as “a standardized format for providing information about a page and classifying the page content,” using the example of a recipe page where the markup explicitly identifies the ingredients, cook time, temperature, and calorie count rather than leaving Google to infer those details from surrounding text. (Google Search Central, Intro to structured data)
The vocabulary most commonly used for this markup comes from schema.org, a shared set of types and properties (Product, Article, Recipe, LocalBusiness, and hundreds more) that search engines agree to recognize. Schema.org was launched jointly by Google, Microsoft, and Yahoo in 2011, with Yandex joining shortly after, specifically to give site owners one common vocabulary instead of several competing ones. Since 2015 it has been maintained through a public W3C Community Group, with contributions from the wider web community as well as the founding companies. (Schema.org, About)
JSON-LD vs. microdata vs. RDFa
Schema.org vocabulary can be expressed in three different syntaxes, and Google treats all three as equally valid as long as the markup is implemented correctly:
| Format | How it works | Google's guidance |
|---|---|---|
| JSON-LD | A self-contained block of JavaScript object notation, usually placed in a <!–INLINECODE0–> tag in the page head | Recommended by Google as the easiest format to implement and maintain at scale |
| Microdata | Attributes (<!–INLINECODE1–>, <!–INLINECODE2–>, <!–INLINECODE3–>) added directly to existing HTML tags | Supported, but markup is mixed into the visible HTML, which makes it more error-prone to edit |
| RDFa | Similar to microdata but using HTML5/RDFa attributes such as <!–INLINECODE4–> and <!–INLINECODE5–> | Supported, same trade-off as microdata |
Google recommends JSON-LD specifically because it sits apart from the page’s visible HTML, so updating or removing it doesn’t risk breaking the content itself, and it’s easier to generate dynamically through a content management system or tag manager. Microdata and RDFa both require editing the HTML elements that make up the visible page, which is harder to maintain consistently across a large site. (Google Search Central, Intro to structured data)
One rule applies regardless of format: the structured data has to describe content that actually appears on the page. Marking up a price, rating, or availability status that isn’t visible to a human visitor is a policy violation, not just a best-practice issue.
Does schema markup improve rankings?
No, not directly, and Google has been explicit about this. Google’s general structured data guidelines state plainly that while violating structured data policies can result in a manual action that removes a page’s eligibility for rich results, that action “doesn’t affect how the page ranks in Google web search.” Structured data’s job is to make eligible content qualify for an enhanced search appearance; it is not itself a ranking signal. (Google Search Central, General structured data guidelines)
That distinction matters because the value of schema markup is indirect. By making a page’s content unambiguous (this is a recipe, this is the price, this is the review score, this is the publish date) it gives Google what it needs to potentially display that page as a rich result, and rich results tend to earn a larger share of clicks than a plain blue link. Google’s own documentation cites two named examples of this effect: Rotten Tomatoes added structured data to 100,000 pages and measured a 25% higher click-through rate on those pages compared to ones without it, and Nestlé measured an 82% higher click-through rate on pages that appeared as rich results versus non-rich-result pages. (Google Search Central, Intro to structured data)
So the honest framing is: schema markup doesn’t move a page up the rankings, but it can change how that page looks once it’s ranked, and a more visually prominent listing tends to get clicked more often.
What rich results actually are, and which schema types still qualify
A rich result is a search listing enhanced beyond the standard title, URL, and meta description, things like star ratings, product prices and availability, event dates, recipe cook times and images, or job posting details shown directly in the results. Structured data is the mechanism that makes a page eligible for these enhanced listings, though eligibility doesn’t guarantee Google will actually display the enhancement for any given search.
It’s worth being precise about which schema types currently produce rich results, because this list has changed. Google’s current structured data search gallery lists roughly two dozen eligible feature types, including Article, Breadcrumb, Course, Dataset, Event, Job Posting, Local Business, Movie, Organization, Product, Profile Page, Q&A, Recipe, Review Snippet, Software App, Video, and several others. (Google Search Central, Search Gallery)
Notably absent from that current list are FAQPage and HowTo schema, and the gap is bigger than most sites realize. Google first scaled both back in 2023: HowTo rich results stopped appearing on both desktop and mobile, not just desktop, and FAQ rich results were restricted to a narrow set of well-known, authoritative government and health sites. (Google Search Central Blog, Changes to HowTo and FAQ rich results) Then, in May 2026, Google went further and discontinued FAQ rich results entirely, even for the government and health sites that had been the last ones still eligible; Search Console’s FAQ report and Rich Results Test support for the feature followed shortly after. (Google Search Central, FAQPage structured data) If your site still relies on FAQPage or HowTo markup expecting a rich-result boost, that expectation is outdated. FAQPage remains a valid schema.org type and Google has said it still parses the markup to understand page content, so leaving it in place isn’t harmful, but it should not be a primary strategy for any site going forward.
Schema, entity understanding, and E-E-A-T
Beyond rich results, schema markup plays a quieter role in helping Google’s systems build a clearer picture of entities: the organization behind a site, the author of an article, the business behind a local listing, the specific product being described. Organization and Person markup, for instance, can help connect a piece of content to a verifiable entity rather than leaving authorship and ownership ambiguous. This doesn’t function as a separate “E-E-A-T score” that schema markup raises, Google has not published any such mechanism, but it is consistent with the general principle in Google’s documentation that anything making content easier to parse and disambiguate supports Google’s underlying understanding of the page. Schema should be treated as a clarity aid that supports the content’s existing trustworthiness signals, not a way to manufacture them.
Common implementation errors
In practice, most structured data problems fall into a handful of recurring categories:
- Markup that doesn’t match visible content. A price, availability status, or rating in the JSON-LD that isn’t actually shown to users on the page. This is a direct policy violation.
- Missing required properties. Each schema type has required and recommended fields; omitting a required one (such as
imageon Recipe orpriceon Product/Offer) disqualifies the page from that rich result even if the markup is otherwise valid. - Outdated markup left in place after a redesign. Templates change, but the structured data block doesn’t get updated to match, so it silently goes stale or starts contradicting the page.
- Using deprecated or de-scoped types expecting rich results that no longer exist, such as treating FAQPage or HowTo as a reliable rich-result strategy after the changes described above.
- Duplicate or conflicting markup blocks, often from a CMS plugin and a manually added script both outputting JSON-LD for the same entity, which can confuse parsers.
None of these require guesswork to catch. They show up as specific, itemized warnings or errors in the validation tools described below.
Testing and validating your markup
There are two distinct tools worth using, and they serve different purposes:
- Rich Results Test (search.google.com/test/rich-results), Google’s own tool, checks a URL or code snippet against the specific schema types that are currently eligible for rich results in Google Search, and previews how the result may appear.
- Schema Markup Validator (validator.schema.org), maintained as a Schema.org community tool (it succeeded Google’s old Structured Data Testing Tool), validates JSON-LD, microdata, and RDFa against the full schema.org vocabulary, not just the subset that’s currently eligible for Google rich results. It’s the better choice when you want to confirm the markup itself is technically correct, independent of whether Google currently rewards that particular type with a rich result.
After deployment, Search Console’s structured data reports continue to surface errors and warnings Google’s crawler actually encounters on indexed pages, which is useful for catching issues that only appear at scale or after a template change, not just in a one-off test of a single URL.
A reasonable workflow is to validate new markup in both tools before launch, spot-check a sample of templated pages (not just one), and then monitor Search Console’s relevant structured data reports periodically rather than assuming markup that validated once will stay correct forever.
The bottom line
Schema markup is a way of making a page’s content machine-readable, not a ranking lever. Use JSON-LD where possible because it’s easiest to maintain, make sure whatever you mark up actually matches what’s visible on the page, keep your expectations about FAQ and HowTo rich results current, and validate before and after deployment rather than assuming a single test result holds forever. Treat the payoff as better-looking, more clickable search listings for content that’s already earning its ranking on its own merits, not as a shortcut around the work that actually produces rankings.