Question explained · gr.AI

What structured data actually does for AI

by Cătălin Popa · updated 2026-09-02

Plenty of people still take it for an SEO trick. That is the inheritance from rich results: yellow stars in the listing, recipes with photos, the price shown under the link. In AI search it does something else.

A model that opens your page receives raw HTML. It has to work out on its own what each piece of text is. A title, a price, opening hours, a person's name. Structured data tells it directly, with no guessing.

First, what it does not do

It ranks nothing. It is not a positioning factor, not in classic search and not in AI answers. It does not make up for weak text and it does not replace missing content. If the text is not delivered by the server, a perfectly written block of structured data describes a page the engine still cannot read.

It does one thing and does it well: it removes ambiguity. The difference is not between being found and not being found. It is between being read and being understood.

What coralbaby.ro declares, and why

It is a children's therapy practice, so a field where an approximate description is worse than none. Three types, each chosen because it closes off one route to misreading.

  • MedicalTherapy

    Each therapy is declared as a medical therapy, not as a generic service. A model asked about a particular therapy does not have to infer from context that treatment is involved.

  • MedicalAudience

    Who each therapy suits. Age, situation, type of patient. Without it, a model can correctly recommend the practice to the wrong person.

  • EducationalOccupationalCredential

    The therapists' qualifications, declared as such. Not so they look good somewhere, but so no room is left for interpretation about who delivers the treatment.

Taken together they say something that can no longer be read the wrong way. It is a medical practice, with specific therapies, for specific patients, run by people with verifiable qualifications.

What muzeulcfr.ro declares, and why

A different kind of site, different needs. At a museum the two most sought-after pieces of information are when it is open and how to get there. Both are written in the text as well, but text can be misread.

  • OpeningHoursSpecification

    The opening hours, written once, in a machine-readable format. A model asked when the museum is open no longer digs through prose, and no longer risks picking up old hours from another page.

  • GeoCoordinates

    The exact coordinates, not just the address. It matters for a museum whose entrance is not where you would expect, where the difference between an address and a point on a map is a wasted walk.

The three ways it breaks

The unpleasant part is that a broken block raises an error nowhere. The site works, the page looks fine, nobody finds out until someone goes looking.

  1. 01

    It exists, but it is empty

    The platform generates the block automatically and the fields that matter stay empty. We saw a shop with a product block on all 358 of its pages, with no price and no availability in any of them. The validators passed it.

  2. 02

    It exists, but it is wrong everywhere at once

    Worse than empty. The same wrong address, declared on every page of the site. The engines learned the wrong one perfectly, because it was repeated consistently.

  3. 03

    It exists, but the JSON is broken

    One comma too many, one unclosed quote. The block is ignored silently and nobody tells you. From the engine's point of view, it is as if you never wrote it.

What matters about it, briefly

Three rules, all of them dull. The types should be the right ones, not the fashionable ones. They should describe what is actually on the page, not what you wish were there. And they should be valid, because otherwise they do not exist.

You check it with Google's rich results test or the schema.org validator. But before the validator, simply read what the block says. Most of the problems we find are not syntax errors, they are fields that say something other than the page does.

Further reading