Structured data: what it tells Google and what it doesn't guarantee

Structured data is often presented as a lever on ranking: add it and the site climbs. That's not how it works. It's a translation: it takes information that's already written on the page for a person and repeats it in a format a machine can read without having to interpret it. This guide explains what structured data actually communicates, which types are worth using, and why "valid" doesn't mean "you'll see it."

What it is, without metaphors

In the page's code, alongside the visible text, you add a block that says: this is an article, the title is this, the author is this person, the publication date is this, the publisher is this organization. The visitor doesn't see it and doesn't notice it. It's there for whatever reads the page automatically, so it doesn't have to infer anything.

The most widely used vocabulary is Schema.org: a shared list of types — organization, local business, product, article, event — and the properties each one can have. Because it's shared, different parties can understand it: search engines, aggregators, systems that collect information about companies.

The rule that decides everything

The markup describes what's on the page. It isn't a place to add information the visitor can't find.

• If the author isn't shown on the page, it shouldn't be declared in the code.
• If the price shown to the visitor differs from the one declared in the markup, the contradiction is visible and doesn't work in your favor.
• Reviews declared that don't exist, or that the company assigned to itself, are the case most likely to trigger a penalty.
• Questions and answers marked as such must be present on the page and readable by whoever opens it.

A sample page

An article from your site, to show the row-by-row match. The entries are illustrative.

If a row in the right-hand column has no match on the left, that row should be removed. It's the only check that really matters, and it's done by eye.

Choosing a few types, the ones that apply to you

• Organization: your exact name, contact details, public profiles. It helps make the information scattered about you across different places line up.
• Local business, if you receive customers at an address: location, hours, service area. If you don't receive anyone, this isn't your type.
• Product, if you sell online: identifier, availability, conditions. It has precise requirements and needs to be kept aligned with the store, not written by hand a single time.
• Article, for content: author, dates, publisher.
• Breadcrumb, to say where the page sits within the site.

Marking up everything you could mark up doesn't help. Every type you add is one more claim that can become false the next time the page changes, and nobody will notice.

Valid, eligible, shown: three different things

1. Valid: the code is written correctly and the required properties are present. A validation tool tells you this, and the answer is yes or no.
2. Eligible: the page meets the requirements set for a certain type of rich result. Here too a check exists, and it's different from the previous one.
3. Shown: the search engine decides, search by search, whether to display that result. There's no check that guarantees it, and the same page can appear one way today and another way a month from now.

These three things get confused constantly, and the confusion always produces the same conversation: "everything is valid, so why doesn't it show?" Because validity depends on you, and display depends on them.

Check at the start, and recheck when the page changes

Markup drifts away from content over time, and it's a silent failure: it isn't visible, so nobody reports it.

• After every change to the page template, check one example of each type again.
• Requirements and required properties change: the official documentation is the only source, and it should be checked at the moment you make changes, not once and for all.
• If the markup is generated by the site, verify that it pulls data from the same fields that make up the page, not from parallel fields filled in by hand.
• Pages rebuilt after a redesign are the ones that lose their data most often, because the content gets reassembled and the code doesn't.

A periodic check on one page per type — an article, a product, a service page — takes a few minutes and catches almost everything.

What this guide doesn't cover

This guide covers the role of structured data and how to keep it true. No rich result, no appearance of questions and answers, and no citation inside a generated answer can be guaranteed by this work. The overall approach to visibility, and the organization of categories, products, and filters for an online store, are covered elsewhere.