Structured data:what search engines and AI understand from it

What schema.org is and what JSON-LD is

schema.org is a shared vocabulary for describing things on the web. It fixes types such as Organization, Service and Question. Each type comes with a set of properties such as name, url and address. It is not a Google product. The large search engines set the vocabulary up together and it is open. That is why the same markup also works for other parties that read your page.

JSON-LD is the notation in which you write that vocabulary down. A block of JSON in a script element with type="application/ld+json", separate from your visible HTML. That separateness is the practical advantage: you add it, change it or take it away without touching one line of your design. There are two older notations, microdata and RDFa, that weave attributes through your HTML. Both still work. For new work you take JSON-LD, because that is what Google recommends and it is the only form you manage in one place.

One rule always holds. What you mark up has to be visible on the page. Google requires in its guidelines for structured data that the markup matches what the visitor gets to see. An FAQ block with five questions that exist only in the JSON-LD is a violation and not a clever move.

Why it weighs more heavily for GEO than for SEO

For classic search results the gain is limited and easy to bound. Google can show an extra element: a breadcrumb trail instead of a bare URL, a date with an event, price information with a product. Structured data is not a ranking factor. Google says that publicly. A page without one line of schema can sit at position one without any trouble.

With an AI answer engine the sum works out differently. That system has to determine in a short time what your page is about, which organisation it belongs to, who wrote it and whether there is a passage in it that answers the question asked. From running text it has to derive all of that. In JSON-LD it is simply there. That is exactly where the gain sits: you take away the step where it goes wrong.

In our own GEO score formula structured data weighs 0.25. That is the heaviest of six parts. It is our operationalisation and not an industry standard. We give it that weight because it is the only factor that lies entirely within your own walls and that you repair in an afternoon.

Be honest about what we do not know. Nobody publishes how much schema exactly yields in citations. What is certain is that a page without schema forces the system to guess. A guess sometimes turns out wrong.

The types that matter for an SMB

Alongside that there is SpeakableSpecification, a small part with which you point out which piece of the page lends itself to being read aloud or taken over. Put it on your answer block at the top. It costs two lines.

Do you choose Organization or LocalBusiness? Take LocalBusiness if customers come to your address or if you serve a bounded working area. Take Organization in all other cases. LocalBusiness is a subtype of Organization, so everything that fits in the one fits in the other as well. Never put both as separate nodes on the same page, because then there are two companies on your site.

Ready-made examples to copy

Replace uwdomein.be and the example data everywhere. The rest can stay as it is.

Your organisation, set up once and repeated on every page:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://uwdomein.be/#organization",
  "name": "Voorbeeld bv",
  "url": "https://uwdomein.be/",
  "logo": "https://uwdomein.be/assets/logo.png",
  "email": "info@uwdomein.be",
  "telephone": "+32 3 123 45 67",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "Voorbeeldstraat 1",
    "postalCode": "2000",
    "addressLocality": "Antwerpen",
    "addressCountry": "BE"
  },
  "sameAs": [
    "https://www.linkedin.com/company/voorbeeld-bv"
  ]
}

The field sameAs is your machine-readable link to the same company elsewhere. That is the bridge to chapter 10.

A service page:

{
  "@context": "https://schema.org",
  "@type": "Service",
  "name": "Onderhoud van verwarmingsinstallaties",
  "serviceType": "Onderhoud en keuring",
  "url": "https://uwdomein.be/onderhoud.html",
  "provider": { "@id": "https://uwdomein.be/#organization" },
  "areaServed": [
    { "@type": "Country", "name": "Belgium" }
  ],
  "description": "Eén zin die letterlijk zegt wat de dienst is en voor wie."
}

A question with its answer:

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "inLanguage": "nl-BE",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Hoe vaak moet een gasketel onderhouden worden?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Schrijf hier hetzelfde antwoord dat zichtbaar op de pagina staat, in twee tot vier zinnen die los van de rest leesbaar zijn."
      }
    }
  ]
}

Watch out with FAQPage. Google limited the visible FAQ results in 2023 to government and health sites. Your SMB therefore no longer gets an expandable block in the search results out of it. The core update of March 2026 pulled the rich results for FAQPage, Review and HowTo on pages that are not the main content back even further. Even so it remains the clearest way to tie a question to an answer for any system that processes your text and Gemini uses schema in AI Mode precisely to test claims and to gauge the reliability of a source. That is where the whole value for GEO sits.

An article with an author and a breadcrumb trail, together in one block:

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Article",
      "@id": "https://uwdomein.be/blog/artikel.html#article",
      "headline": "De titel van het artikel, kort gehouden",
      "datePublished": "2026-08-03",
      "dateModified": "2026-08-03",
      "inLanguage": "nl-BE",
      "author": {
        "@type": "Person",
        "name": "Voornaam Achternaam",
        "url": "https://uwdomein.be/over-ons.html"
      },
      "publisher": { "@id": "https://uwdomein.be/#organization" },
      "speakable": {
        "@type": "SpeakableSpecification",
        "cssSelector": [".antwoordblok"]
      }
    },
    {
      "@type": "BreadcrumbList",
      "itemListElement": [
        { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://uwdomein.be/" },
        { "@type": "ListItem", "position": 2, "name": "Blog", "item": "https://uwdomein.be/blog/" }
      ]
    }
  ]
}

The @graph trap that scanners run aground on

The last example uses @graph. With it you put several entities in one block under one @context and you give each entity an @id so that they can refer to each other. It is the tidy way and Google reads it without any problem.

Even so a lot goes wrong here, for three reasons.

Your scanner sees nothing. Many SEO checkers read only the key @type at the top of the block. In a @graph that key is not there, because the types sit one level deeper. The report then states that you have no structured data while everything is in place. What happens next is predictable: someone takes fright at the red mark and pastes a second block next to it. Now there are two organisations on your page and Google gets to choose. So always check in the official validators and not in the scanner. If those are green, the scanner is wrong and you change nothing.

Your @id differs per page. The reference { "@id": "..." } works only if the string is exactly the same everywhere. Once with www in front and once without gives two companies instead of one. Pick one spelling such as https://uwdomein.be/#organization and use it on every page in every language.

You refer to something that is not there. A provider that points at #organization works only if that node is present on that same page. So include the organisation node in every @graph, on the service page as well.

Our working rule is simple: per page and per language exactly one JSON-LD block with a @graph in it, in which the organisation node is always present. For a multilingual site that means four blocks of which only the text fields differ. The URLs and the @id values stay identical.

The rule that can save your company

Never invent Review or AggregateRating markup for reviews that do not exist. This is the only subject in this entire guide where Google can actively punish you.

What happens: someone puts 4.8 stars out of 137 reviews in the JSON-LD because it looks good in the search result. There are no 137 reviews. Google calls that spam in structured data and the consequences are a manual action, the loss of all rich results and work to get out from under it again. On top of that you may not show stars that you write about yourself. Reviews placed by the owner are not eligible for display in any case.

There is another misunderstanding that comes up more often than invention itself. Even with real reviews, your own review markup earns you no stars. Since 2019 Google no longer shows a star snippet when the reviewed party controls the reviews, and that holds for LocalBusiness and for every other Organization type. It makes no difference whether you type the texts in yourself or use a widget that pulls them from a review site. For Product it is different: reviews of a product you sell may be marked up.

There is a second reason, apart from Google. Invented reviews fall under the rules on unfair commercial practices. That is no longer an SEO problem.

What is allowed and what does work: collecting real reviews on your Google Business Profile. Those Google shows itself, without you needing one line of schema for it. See chapter 10.

How you check whether it is right

Four free checks, in this order.

The two validators differ and that confuses people. The Rich Results Test shows only what Google can use visually. Your Service or Organization block therefore does not appear there while it is perfectly in order. The Schema Markup Validator shows everything. Use the Schema Markup Validator for the question of whether your markup is right and the Rich Results Test for the question of whether Google does something visible with it.

What you can do yourself and what you cannot

To do yourself, without a developer:

• Take over the organisation block above, fill it in and put it in the <head> of every page. This is half an hour of work for a site of twenty pages.
• Complete sameAs with your profiles elsewhere. Only profiles that you really maintain.
• Make a Service block per service page. The template is the same every time and only the name, the URL and the description change.
• Add FAQPage on pages where the questions are visible as well.
• Run the two validators and read the result.

What you need help with:

• A webshop with hundreds of products, where Product and Offer have to be generated from your stock data.
• A plugin that sends out a @graph of its own that clashes with what you add. Then it is a matter of working out what is there before you add anything.
• The four language variants of the same block, where only the text may differ and the identifiers have to stay the same.
• A site that is built entirely in JavaScript, where the schema block only comes into being after loading. Not every system that fetches your page runs JavaScript.

Our order: first Organization on everything, then Service on the service pages, then FAQPage and Article where it applies. The first point delivers the largest part of the gain and it costs the least time.

Would you rather not do this yourself: SEMANU carries out the full SEO and GEO audit for 1,450 euro, report and working session included. What it covers is on the guide page.