The invisible layer: what answer engines actually read

You proofread the text. You never proofread what the machine is going to quote. A gap opens between the two, and it never announces itself.

TL;DR

A published article ships two things. A text, for the reader. And a layer nobody ever reads with their eyes: Schema.org, Open Graph, hreflang, canonical, llms.txt. That second layer decides how an answer engine cites you. When it is produced after the text, by another tool or another person, it ends up describing an article that no longer exists. The rule that fixes this fits on one line: the invisible layer ships in the same motion as the text.

What does an answer engine actually receive when you publish?

Far more than what you think you are sending it.

We measured what a single article page exposes in production on our own site. Nineteen Schema.org objects across three JSON-LD blocks. Five question-answer pairs marked up as FAQPage. Three language declarations, one canonical, fifteen meta tags covering indexation and social sharing. Plus two exposure files, llms.txt and llms-full.txt, the second running past 120,000 characters.

The reader sees a title, a text and a few links.

None of those lines are read by a human. All of them are read by models. That is the distinction we set out in our piece on SEO and GEO: SEO optimises access to the page, GEO optimises what the machine does with it. Access depends on the text. Use depends on this layer.

Why does the layer drift without anyone noticing?

Because producing it is easy, and maintaining it is not.

Marking up a site in Schema.org is bounded work. A day for twenty pages, verifiable, safe to outsource. The trap sits elsewhere. It sits in the fact that this work almost always happens after the text: a next step, another tool, often another person, sometimes three weeks later.

From that moment, two objects exist in parallel. The article, which keeps moving through review. And its machine-readable description, frozen on the state it had before.

The Schema title keeps the wording from v1. The marked-up FAQ asks questions the published version no longer covers. The Open Graph summary sells an angle dropped in the final edit. None of this shows on screen, so nothing raises a flag. The content looks healthy. Its representation has quietly moved.

Same mechanism as fuzzy validation, applied to an object nobody ever thought to review. Except here, the missing review is not an oversight. Nobody ever decided that someone should review this at all.

The four drifts that cost the most

They are not alike, and they do not cost the same.

Hreflang pointing at an index. A translated page exists, but the tag announces the blog listing instead. You are telling engines that the English version of your article is a table of contents. The most expensive of the four, and the quietest, because no mainstream tool flags it as long as both pages return a 200.

The entity declared several times. Three blocks describe your organisation, with three sets of fields and no shared identifier. The engine cannot tell which one is authoritative.

A marked-up title that is not the published title. One space lost when the string is built, and headline becomes « SEO and GEO:how to optimise… » while the page displays « SEO and GEO: how to optimise… ». Tiny. Except the title an AI reuses is that one.

Let us take the fourth, which is a different animal.

Content missing from the exposure file. An llms-full.txt generated once, never regenerated, aggregating the key pages and ignoring the blog. Everything you publish afterwards stays invisible to an agent relying on that file.

Then the most embarrassing case, and the most common: a brand figure that differs depending on the source. The site says eleven, the exposure file says thirteen. Both are published. The engine will pick one, and it will not ask you which.

What actually deserves a human read?

Three things. No more.

The meta description first: it is the only sentence a human writes for the machine that the machine reuses verbatim.

The FAQ questions next, because they are what triggers the citation. A question nobody asks is worth nothing, however well it is marked up.

The exposure file summary last, because it decides what an agent retains about the page without ever opening it.

The rest has no business being on a human checklist. Canonical, hreflang reciprocity, entity uniqueness, Open Graph mirroring, dates: all of it verifies by script, in seconds, with no judgement involved.

Putting those items on a review checklist does not get them checked. It guarantees the opposite. A thirty-line checklist where twenty-seven lines are mechanical gets ticked in one pass, and the three that needed a real decision go through with the rest.

What does a control worth running look like?

It compares two sources instead of inspecting one.

Verifying that a Schema headline exists proves nothing. Verifying that it matches the rendered H1 proves something. Same logic for the FAQ: the presence of a FAQPage block says nothing, its verbatim correspondence with the subheadings actually displayed says everything. A hreflang is checked by opening the target and confirming it points back.

The control runs on the HTML served in production, not on the draft. Between the two sit a theme, a cache, sometimes a plugin, and each one can rewrite what you thought you had published.

One method detail that matters more than it looks: grepping the HTML for a string produces a false positive in exactly the case it was meant to catch, since text injected by JavaScript sits in plain sight inside the <script> tag. Strip scripts and styles before comparing anything, or run a real extractor.

FAQ

Doesn’t a good SEO plugin already handle this?

It generates the layer, which is the easy part. It does not verify that the layer still matches the published text, because it has no idea what the text said before. Drift comes from the gap between two versions, not from missing markup.

How often should an llms.txt file be regenerated?

On every publication and every substantial edit, not on a schedule. A file regenerated quarterly describes a site three months old. If regeneration is not triggered by publication itself, it will eventually stop being triggered at all.

Do answer engines read text hidden with CSS?

Yes, and it is counter-intuitive. The main AI crawlers do not execute JavaScript, so no CSS rule applies from their point of view: a block set to display:none reaches them as ordinary text. The practical consequence is that you need to check what a site hides, not only what it shows.

Does the same apply to LinkedIn posts?

A post has no Schema, but it does have an invisible layer: the card the platform builds from the page you link to. That page’s Open Graph tags are part of the post’s deliverable. A link whose preview shows a stale summary is a post written halfway.

Where do you start when everything needs work?

Hreflang and canonical, in that order. They are the only two elements that can send an engine to a page other than yours. The rest degrades the quality of the citation, those two change its destination.

What this changes in the workflow

One rule, and it is structural.

The invisible layer ships in the same motion as the text. Not a next step, not a second tool, not an end-of-sprint catch-up. The day a piece of content is edited, its layer is regenerated with it, and an automated control compares the two before publication.

What stays human then narrows to three decisions, and those three deserve the time you give them. Everything else becomes an exit condition, the same way a test passes before a deployment.

The question to ask about your last published article is not whether the FAQ was written. It is who reviewed it.