Three readings of one page: keeping markup, markdown and what renders in agreement
Published · Updated
Markup, a markdown twin and the rendered page are three readings of the same URL. The GEO failure that matters is not missing schema; it is drift between them.
A page an assistant can cite exists in more than one form at once. There is what a browser renders. There is the structured data describing it. And if you follow the llms.txt proposal, there is a clean markdown version served at the same URL as the original page. Those three readings are meant to describe the same thing. The common failure in GEO work is not missing markup. It is drift between them.
The ceiling is what the reader can see
Google's structured data guidance draws a hard line: don't create blank or empty pages just to hold structured data, and don't add structured data about information that is not visible to the user, even if the information is accurate. That rules out an entire category of tactics. Markup describes the page; it does not extend it. If a claim is worth handing to a machine, it has to be on the page for a person first.
The same guidance prefers fewer but complete and accurate recommended properties over every possible property supplied with badly formed or inaccurate data. The documented payoff sits on real content: Rotten Tomatoes added structured data to 100,000 unique pages and measured a 25% higher click-through rate for pages enhanced with structured data, compared to pages without it. Those pages already carried the content. The markup described what was there.
The markdown twin is a parity problem, not a file
The llms.txt proposal has two parts. The first is the index file, whose only required section is an H1 with the name of the project or site. The second is easier to skip: pages with information agents might need should provide a clean markdown version of those pages at the same URL as the original. That second part is not a file you write once. It is a second rendering of everything you publish.
The proposal also sets a convention for an Optional section, holding secondary information and links an agent can skip when a shorter context is needed. Treat that as a budget rather than a bin. Deciding which pages survive truncation forces an explicit ranking of your own site, and that ranking is useful whether or not any assistant ever reads the file.
None of this substitutes for being indexed
Google states the prerequisite plainly. To be eligible to be shown as a supporting link in AI Overviews or AI Mode, a page must be indexed and eligible to be shown in Google Search with a snippet, fulfilling the Search technical requirements. It also says you don't need to create new machine-readable files, AI text files, or markup to appear in these features. The markdown twin is not an entry ticket.
Both AI Overviews and AI Mode may use a query fan-out technique, issuing multiple related searches across subtopics and data sources to develop a response. Nothing on that path reads a markdown variant. The variant matters for assistants that fetch your URL directly. Keep the two audiences distinct, because only one of them is gated on ordinary indexing, and adding files is not interchangeable with fixing indexing.
Drift scales with cadence
Parity is cheap to hold on a ten-page site and expensive at volume. On a four-market build, the platform publishes 8 SEO articles every day across 7 languages, with country domains indexed separately: 4, and manual intervention required: 0. At that rate nobody is hand-checking that the markup, the rendered text and any markdown variant still agree. They agree because one representation generates all three, or they quietly diverge.
Divergence is usually discovered late, in an audit. On a personal platform publishing articles autonomously every day, the GEO audit score after overhaul moved 66→90+. An overhaul is roughly what you pay when three surfaces have been maintained as three separate chores for long enough. Generating them from a single source is not elegance; it is the thing that keeps the bill from arriving all at once.
A parity check you can run today
Take one published page. Read what renders. Read the structured data. Fetch the markdown version if you serve one. List the factual claims in each, then look for anything present in two and absent from the third, or stated differently across them. Dates, availability, pricing and author attribution tend to drift first, because they change after publication and usually get changed in only one place.
Treat the three surfaces as one artefact with three encodings. Decide the visible page first, derive the markup from it, derive the markdown version from it, and let the Optional section carry whatever an agent can safely skip. That ordering keeps you inside the visibility rule by construction, and it is the only version of this work that survives a daily publishing schedule without someone policing it.
Sources
llmstxt.org — The /llms.txt file, v2 — https://llmstxt.org/
Google Search Central — AI features and your website — https://developers.google.com/search/docs/appearance/ai-features
Google Search Central — Introduction to structured data markup in Google Search — https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data
Neurolinks case study — Four markets, one codebase — https://neurolinks.be/work/tatano-energy
Neurolinks case study — A personal brand that publishes itself — https://neurolinks.be/work/matthieu-pesesse-media
Working on a project where these methods apply?