Schema.org Structured Data: What It Gives and What Takes It Away

You have seen search results with star ratings, product prices or questions that expand in place. That is structured data — code that tells Google what exactly is on the page.

One clarification up front: markup does not lift rankings. It changes how your result looks once it is already there. But appearance drives click-through, and that affects everything downstream.

Why it matters

Google reads the page text but cannot always tell what is what. Is 4,500 a price, a stock count or a founding year? Markup states it outright.

The practical result looks like this:

The FAQ block deserves a separate mention: it occupies more space in results and physically pushes competitors further down.

Where to start

You do not need to mark up everything. In order of value:

1. Organization on the homepage — basic company information. Only name is required, but without logo, url and sameAs there is little benefit: those tie the site to your social profiles.
2. BreadcrumbList on inner pages — the cheapest way to improve how a result looks.
3. LocalBusiness if you have a physical address. It needs name and address; for local results add telephone, openingHours and coordinates.
4. Article on the blog — author, publication date, image.
5. Product and FAQPage where they genuinely apply.

You can assemble the code with the markup generator and then check it with the validator. The pair works together: build it, then confirm there are no errors.

What gets a rich result removed

This is the important part, because the penalty applies site-wide rather than to one page.

Data that contradicts the page. The markup says 500, the page says 900. That counts as deception. The core rule: every value in the code must be visible to a person on the page.

A rating with no reviews. An AggregateRating block on a page with no reviews at all. The most common trigger for a manual action — and the most tempting mistake, because stars look attractive in results.

FAQ with no answers on the page. The questions exist only in the code and not in the text. Google checks this.

Marking up content that is not yours. Describing a product that is not on the page, or someone else's reviews.

Technical errors

Beyond the content issues there are purely technical ones — and they fail silently: the markup simply does not work, and without a check it is hard to see why.

• A trailing comma before a closing bracket. JavaScript allows it, JSON does not.
• Single quotes instead of double. Often the result of copying from code.
• Comments — JSON has none at all, and one line invalidates the whole block.
• No @context — the block is not tied to the schema.org vocabulary and goes unrecognised.
• A non-standard date: it must be 2026-01-15, not 15/01/2026.

Markup and language models

There is one more reason that has come up recently. Language models read pages and must also work out what is on them. Structured data states it directly, so the model does not have to infer it from the markup.

How much this affects citation nobody can say precisely yet. But markup is needed for search regardless, so treat it as a welcome side effect rather than a reason in itself.

A working order

1. Pick the type for the page — one primary type, do not mix.
2. Fill the required properties, then the recommended ones.
3. Check every value against the page: it must be visible to a reader.
4. Validate the syntax with the validator.
5. Run it through Google's Rich Results Test — only that gives the final answer.

In short

Markup is about how your result looks and how many people click, not about rankings. Start with Organization and BreadcrumbList, add the rest as needed. One rule above all: the code should contain only what a person can see on the page.