We translate the page into data that a machine reads without guessing, and we check the result with the engine’s tool.

No. The special display is granted by the engine, not by the markup. Valid data are the entry condition, not the purchase of the result. This is clear even from the type of markup sold everywhere: Google documentation states that FAQ rich results are shown only for well-known and authoritative government and health websites — a restriction that came into force in September 2023. So a provider who sells you “FAQ-rich fragments” today either has not read the documentation or hopes you have not read it.

Because the special display is only one of the consumers of the format. A correctly declared questions block says unambiguously which text is the question and which is the answer — information used by engines to extract fragments, by assistants that read the page at a user’s request, and by any system that takes the content without seeing the layout. And there is another effect, less discussed: the obligation to declare pairs forces you to have real answers to real questions. Websites that cannot complete the format usually have nothing to declare.

With form, not with inventory and not with composition. SEO answers the question “can the engine reach each page and does it know which is the official version”. Visibility in generated answers answers “can it be used as a source”, where the result cannot be promised. Here the question is “can a machine take the exact information from the page without guessing”, and it is the only one of the three with an external verdict: you give the validator tool’s address and get the answer immediately.

No, and it is a mistake we find often. Markup that describes something other than the visible content is treated as a mismatch, and the consequence is loss of display, sometimes a manual penalty. The rule we apply is mechanical, not one of common sense: the block is generated from the same source as the page text, so it cannot contain something that is not visible. When someone asks us to add an answer in the data that they do not want to write on the page, the discussion stops there.

Because we cannot prove a rating. An aggregate rating declared in the data must correspond to real reviews, publicly verifiable. Without that, it is a false claim in a machine-readable format. We are categorical here for a concrete reason: in our own repository we found a component that declared a rating of 4.9 from 87 reviews and six reviews signed with people’s names, and a second one that declared a catalogue of four offers with prices. Neither is rendered anywhere — production serves a single block today, verified — but they were one import away. We flagged them in the team’s decision log, not deleted them in silence.

The ones we run: page, main entity of the page, breadcrumb, organisation and questions block. Our public generator covers five types — local business, organisation, article, product, FAQs — and is available on the site. Any other type is discussed on request, after a compatibility check with what the engine actually displays for your domain. What we do not do: we do not add types because they exist in the specification. A block that no engine uses for your site is weight, not an advantage.

In three places, because one alone lies. The engine’s validation tool gives the external verdict. Our analysis module gives a score with eight checks and points written in code, so you can compare between runs. And a script run after each publication fails if a block has stopped parsing or a type has disappeared. We also add our module’s limitation, so you do not discover it yourself: it does not yet read types from a graph, so it gives a lower score than the reality of correctly built pages — including our own.

The link between the block and the page. Someone changes an answer in the text, the block stays with the old one, and nothing looks broken on screen — that is why it goes unnoticed for months. The second thing that breaks is the blocks left over from an earlier version of the site, which describe an offer that no longer exists. Both have the same remedy: blocks are generated from the text source, and what is not generated is deleted.

The inventory table with each address, each block, types and bytes. The implemented blocks, generated from the content source. The validation tool verdict for each page type. The verification script run after publication. And the list of remaining gaps, written as gaps — on this site, for example, the organisation node without links to profiles, the questions page absent from the site map, and a shared image route declared in metadata that does not exist in the code.