Learning schema and structured data

What does Google do with this code?

Google writes that it uses the structured data it finds on the web to understand the content of a page, and also to gather information about the web and the world: people, books, companies. So this code is first of all a shared language rather than an SEO technique.

Three formats are supported: JSON-LD, Microdata and RDFa. Google writes that all three are equally fine for it as long as the markup is valid and properly implemented, and in most cases recommends JSON-LD, because it sits in its own script block instead of being interleaved through the page HTML. In practice that is the one people write.

And an expectation to cut short: writing this code does not mean getting a rich result. Correct markup makes a page eligible for a rich presentation, and the decision to show it stays with Google. A page with nothing to say still has nothing to say with schema on it.

One step further: the presentations themselves get withdrawn. In its documentation updates Google wrote that the FAQ rich result would no longer appear in Search from 7 May 2026, and later removed that documentation altogether; it had already done the same for the How-to rich result. So markup that was worth writing in 2023 is the same code today, just as valid, and shows nothing in the results. This site prints FAQPage on pages that have questions and answers, and since that date no rich result comes out of it; leaving it in place is fine, because it describes genuinely visible content, but expecting anything from it is not.

Which schema type belongs to your page?

The answer is short: the type the page actually is. A hosting sales page is a Product. A blog post is an Article. A contact page is an Organization or a LocalBusiness. A service page is a Service. Choosing the type by which rich result looks nicest is the mistake that ends in a manual action later.

Every type has required properties and recommended ones, listed in Google's own documentation for that type. The LocalBusiness type, for instance, has two required properties: address and name. Google writes that you must include all the required properties for an object to be eligible for a rich result.

More than one type on a single page is normal: a blog post is an Article, its trail is a BreadcrumbList, and its publisher is an Organization. The clean way to write several of them is a graph: one JSON-LD block holding several nodes that reference each other by identifier. Then "the organization" is defined once and every other node points at it.

A small example holding all three ideas at once: the right type, a required property, and a reference by identifier.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#org",
      "name": "The business name",
      "url": "https://example.com/"
    },
    {
      "@type": "Article",
      "@id": "https://example.com/post/#article",
      "headline": "The same headline printed on the page",
      "datePublished": "2026-09-05",
      "publisher": { "@id": "https://example.com/#org" }
    }
  ]
}

Three things are visible in those few lines. First, every node has an identifier and that identifier is a URL, so anything else can point at it. Second, the article's publisher is not defined again and merely references the organization's identifier; that one move is what stops two different descriptions of the same thing. Third, the article headline is the headline printed on the page rather than an optimised variant of it, which leads straight into the rule in the next section.

Why you must not mark up what is not on the page

Google has written this in two separate places and is blunt in both. In the general guidelines: "Don't mark up content that is not visible to readers of the page." And on the introduction page: do not create blank pages just to hold structured data, and do not add markup about information the user cannot see, even if that information is accurate.

Those last words are where the argument ends. The most common justification we hear is "but the number really is correct, we just did not print it on the page". Under the policy, that changes nothing.

The consequence has a name: "structured data issue" is one of the manual actions reported in Search Console. Its effect is that the page stops being eligible for rich results. What over-marking was supposed to win is exactly what it loses.

The correct order is simple and always one-way: put the information on the page first, then mark it up. Never the other way round.

Why the rating you collected yourself gets no stars

This is where most of the wrong schema in a small market gets written. Google's documentation on review snippets carries one clause that has to be read literally: if the entity being reviewed controls the reviews about itself, its pages using LocalBusiness or any other type of Organization structured data are ineligible for the star review feature.

The example Google gives is exactly our common case: a review about entity A placed on the website of entity A, either directly in its structured data or through an embedded third-party widget. That means your own review box, even when the reviews are genuine.

Note that the restriction is tied to two types and not to all of them. Ratings on types such as Product and Software App are still supported; what Google closed off is self-collected ratings on the business and organization types. For LocalBusiness it says separately that the rating property is only recommended for sites that capture reviews about other businesses.

And one more rule that gets less attention: the review you mark up must be available to a visitor from that same page, and it must be immediately obvious that the page has review content. If you write an aggregate rating into the markup, that same rating has to be visible on the page.

How to test, and how many blocks a page carries

Google names two separate stages and the split matters. During development, the Rich Results Test; after deployment, the rich result status reports in Search Console, because markup usually breaks later, through templating and serving issues, rather than while you write it. The URL Inspection tool is there to see whether Google found your structured data at all. For checking the code itself, without the question of rich-result eligibility, there is schema.org's own validator.

Now the trap the tools do not show you: a page can carry more than one JSON-LD block, and usually does, because the theme prints one and each plugin prints another. On one of our own pages on 5 September 2026 we counted four separate blocks: a five-node graph from the theme, plus three standalone blocks printed by plugins. Count them with one command:

curl -s -A "Mozilla/5.0" "https://example.com/page/" \
| grep -c 'application/ld+json'

Why it matters: when several blocks sit on one page, the same thing can be described twice in two different ways. On that page of ours there are two breadcrumb nodes that disagree, one with two steps and one with three. That is exactly what this check exists to find, and we found it on our own site. The right rule is to keep one source of truth per entity and have everything else reference it. On a site where several plugins print schema at once, that consolidation is usually the first job an SEO project should do.