Structured data – what it is, how it works, and when it genuinely matters for SEO

Most sites have structured data shipped by default – through a plugin, a theme, or a developer who “read somewhere it’s worth it”. Rarely does anyone sit down and think about what it’s actually for and whether what’s sitting in the code makes any sense at all. What structured data is, which types actually translate into Google visibility, and where implementing it without a plan can hurt your site – read on.

What structured data is – a plain-language definition

Google indexes billions of pages. Just reading the text isn’t enough – the algorithm has to “understand” what that text describes. Is “Arabica 250g, $12” a product, an article or a company name? Of course, that isn’t the only signal Google uses to tell what’s what, and Google is already excellent at recognizing this through entities on its own, but in this article we’re sticking to structured data 🙂 Structured data

answers that question directly. Instead of forcing Google to guess, you tell it: this is a product, it costs this much, it has this rating, it’s in stock.The vocabulary Google uses is

schema.org – an open standard built jointly by Google, Bing and Yahoo. Every type of object (a product, an article, a person, a restaurant, an event) has properties defined there that you can describe in a page’s code. You can implement structured data in three formats:

JSON-LD

– Google’s recommended format, a code block in the <head> section, separate from the page's HTML, easiest to maintain, Microdata

( (Microdata) – tags woven directly into the HTML, an older approach, still supported

RDFa – similar to Microdata, used in more complex projects

If you’ve never worried about structured data before and want to implement it from scratch, my advice is to go with JSON-LD. Easier to edit, easier to debug.

Correctly implemented structured data raises your chances of rich results in Google, helps the algorithms build context for the page, and, more importantly, is one of the main signals for AI systems like Google AI Overviews. It’s one of the more cost-effective parts of technical SEO, and from what I see in audits, it’s often neglected.

What shows up in search results – a rich snippets overview

Structured data is invisible to the user on its own. But its effect can be rich results ( rich results, rich snippets) – extra information shown directly in the SERP. I say “can be”, because Google doesn’t guarantee they’ll show even with perfectly implemented markup. I’ve seen pages with flawless JSON-LD and not a single star in the results, and pages with minor errors that showed a full rich result. It isn’t a 1:1 relationship.

Below are the types worth implementing, though for a few of them the visual effect in the SERP has long since disappeared:

Product + Offer + AggregateRating – price, availability and stars next to products. Priority number one for any store. A direct effect on CTR for shopping queries. If you run e-commerce, you’d better check whether you have this implemented.

Star ratings in organic results can also be implemented on service pages or blog posts. But the snippet won’t work with LocalBusiness or Organization – since 2019 Google has treated reviews of a company shown on that same company’s own site as “self-serving reviews” and doesn’t display them as a rich result. That applies to a company’s own reviews and to third-party review widgets embedded on the site alike. So is it worth marking up a site with LocalBusiness at all? It is 😀 But more on that later.

BreadcrumbList (the breadcrumb trail) – turns a raw URL in the results into a readable path. Google often generates this itself from the URL structure, but the schema gives you control over exactly what displays, instead of leaving it to the algorithm’s interpretation. Worth implementing anywhere you have an extensive category hierarchy.

Article / NewsArticle – publication date and author next to articles. A standard implementation for blogs and content sites. It won’t revolutionize your CTR, but it tidies up signals for Google, freshness among them.

LocalBusiness – business information, opening hours, location. Important for local SEO, but as I said above, don’t count on stars in organic results from this markup. Its value lies elsewhere – it helps Google build a coherent picture of the business entity, especially combined with a Google Business Profile listing. It’s an absolute must-have for local sites.

VideoObject – a thumbnail and duration next to videos. Worth it if you have video content Google indexes and you care about visibility in video results.

HowTo – steps shown directly in the SERP. Google has cut back how often this shows – it appears occasionally on desktop and has practically disappeared on mobile. Implement it if you have content like this, but don’t treat it as a reliable channel for rich results.

Event – the date, place and time of events shown directly in the results. Mandatory for event sites and pages that regularly organize or promote events.

SitelinksSearchbox – a site’s own search box embedded in the SERP. Only for very large sites – Google grants this automatically, independent of markup, so there’s no point implementing it on small sites.

FAQ – it used to show up, but on May 7, 2026, Google completely removed FAQ rich results from the SERP for practically every site. The expandable questions under a result are gone. But it’s still worth keeping and shipping the FAQ schema, not for the visual effect in Google, but for a different reason I cover in the next section.

That’s quite a list (and only a fraction of the full library), so let me suggest where to start. For stores, start by checking Product + Offer + AggregateRating + BreadcrumbList. If you run a local business, LocalBusiness with complete data, ideally matching what’s on your Google Business Profile listing and your NAP citations. If you also run a blog on the site (which you should), Article. That’s the absolute minimum. Choose the rest based on what’s actually on your site, not on whatever your plugin happens to generate.

Structured data has to reflect the content – Google verifies this

This is probably the most common problem I see in audits. Structured data living its own life, disconnected from the page’s content. A price in the schema different from the one on the page. Star ratings in the markup with no reviews anywhere on the page. A product description in JSON-LD with nothing to do with what the user sees.

Google explicitly defines this as a violation. The official guidelines (Structured Data Policies) state that structured data has to be a “true representation of page content” and prohibit marking up content invisible to the user. Violating this rule can result in a manual action called “Spammy Structured Markup” – the page loses its eligibility for rich results. Nobody’s seen manual actions like this in a long while, but that doesn’t mean you can ignore it, especially since it’s checked continuously.Back in 2019, Google filed a patent application (US12073187B2) describing a system for automatically verifying semantic consistency between structured data and text content – technology able to detect mismatches between what’s in the markup and what a page actually describes. So a mismatch between structured data and content isn’t only a policy violation, it’s something the algorithm can detect with no human involved.So the rule here is very simple: whatever you put in schema has to be visible to the user on the page.

Where structured data brings the most benefit

Online stores and Google Shopping

Product

Offer

AggregateRating, – this trio should be on every product page. It has a direct effect on how the results look, and with Google Shopping, structured data carries extra weight. Incomplete markup (missing, price availability or, condition, fields) can exclude a product from showing in product listing ads. Google Shopping is picky - either the data is complete or the product simply doesn't appear in shopping results.Local SEO

LocalBusiness schema complements your Google Business Profile listing – these are two sources Google cross-references while building an entity picture of the business in its knowledge graph. It’s worth adding the

sameAs property pointing to your profile, Facebook, LinkedIn and any other place the business is present online. The more consistent, mutually linked sources there are, the stronger the signal to local algorithms. When auditing local businesses, I often find this missing, which is a shame, because it genuinely works. Author cards and E-E-A-T

Person schema with

sameAs properties linking to LinkedIn and social media profiles signals to Google who's behind the content. In the context of E-E-A-T ( Experience, Expertise, Authoritativeness, Trustworthiness) – the framework for assessing content credibility – author attribution genuinely carries weight, especially in YMYL industries (finance, health, law).The best way to explain this is with an example from my own turf. My name has been associated with SEO in Google’s eyes for years, through articles, industry commentary, my LinkedIn profile. When I publish a piece on technical SEO with correctly implemented Person schema and

sameAs , Google has context: it knows the author, knows their specialization, can assess the content's credibility. If I wrote an equally thorough article about brewing coffee tomorrow (and I love coffee, I'd probably have something to say), that context would vanish. Same name, but the entity in Google's knowledge graph doesn't associate me with coffee. That article would practically start from zero on author signals.FAQ and AI systems

FAQ schema has practically vanished from the SERP for most business sites. But there’s one context where it still pays off heavily: AI Overviews and other LLMs. Well-structured questions and answers in schema are an ideal format for language models: clearly defined semantically, easy to read and interpret. If you care about visibility in AI Overviews, FAQ schema is one of the better signals you can give these systems. More broadly,

schema.org is effectively the language AI systems use to talk to websites. The more correct structured data you have, the better the algorithm understands the context, and the more readily it cites you. How to check whether your structured data is implemented correctly

Three tools I use:

Rich Results Test

– paste in a URL or a raw JSON-LD code snippet and get an answer: whether the page qualifies for a rich result, which fields are required, what’s missing. There’s one catch, though: the tool only checks the types Google Search actually supports – if you’ve implemented Person schema, JobPosting or Course, you won’t be able to verify them here. Schema.org

Validator ( (validator.schema.org) – validates every schema type, regardless of whether Google supports it in the SERP. Useful anywhere you’re implementing markup for AI systems, Google’s Knowledge Graph or other search engines. If you’re implementing Person schema with sameAs for E-E-A-T, check it here.

Google Search Console – the “Enhancements” tab. Here you see the scale: how many pages have correctly implemented markup, how many have errors, and how that changes over time.

While we’re on Google Search Console, I can’t skip a question I get regularly from clients: the difference between an error and a warning.

An error is a missing required field. The page doesn’t qualify for a rich result, full stop. A missing price on a Product schema, for instance.

Non-critical issues ( (warnings) are missing optional fields. The rich result can still appear; the markup is simply incomplete. A missing priceValidUntil or brand – Google will flag it but won’t block the display.

A few dozen warnings in GSC isn’t a fire, it’s just a to-do list for when you get to it. Critical errors are the reason to act.

Structured data is the language you use to tell Google, and increasingly AI systems, what your page’s content actually is. It’s worth speaking that language correctly, completely and consistently with what the user sees, and only where it genuinely makes sense.