From SEO to GEO: the technical architecture of an AI-readable website

For decades, discoverability rested on a single model: search engines crawl HTML, evaluate links, and return a list of blue links. The human is the filter, opening the pages one by one.

Generative engines like Google AI Overviews, Perplexity or ChatGPT break this model. They use Retrieval-Augmented Generation (RAG): they search for relevant content in real time, load the matching text segments into the context of a language model, and generate a consolidated answer with source attributions. If you're not cited, you're invisible.

This article is the technical companion to it — for everyone who wants to build a website not only for people, but also for machines. We walk through the mechanics of RAG, the proven GEO levers, the necessary standards (llms.txt, JSON-LD, TDM, MCP), and the mistakes we've seen in practice.

1. How generative engines select

At the core of a RAG system lies a simple geometric idea. The search query and the document chunks are converted into high-dimensional vectors via an embedding model. The relevance of two vectors is usually determined through cosine similarity:

Cosine similarity
sim(q, d) = (q · d) / (‖q‖ ‖d‖)

Here, q is the vector of the query and d is the vector of a document chunk. The system selects the k chunks with the highest similarity and passes them to the language model as context.

The practical consequence: how you split your content into chunks (structure, headings, paragraph logic) decides whether your statements are classified cleanly in semantic terms — or linked incorrectly. Poor chunking is a main cause of the “citation-shaped hallucinations”, where an AI links a source to a statement that doesn't appear there at all.

2. The proven GEO levers

The study “GEO: Generative Engine Optimization” (Aggarwal et al., ACM KDD 2024) systematically measured which text changes increase the likelihood of being cited by an LLM — with a visibility gain of up to 40%. The most effective methods:

• Statistics Addition — concrete figures and data instead of qualitative statements. LLMs prefer precision.
• Cite Sources — back up your own statements with source references. Dramatically increases perceived trustworthiness.
• Quotation Addition — include verbatim expert quotes. Signals qualitative depth.

Notably: the effect is domain-dependent and especially strong for pages that were initially poorly ranked. Keyword stuffing — the old SEO reflex — by contrast does not work.

3. llms.txt: the lean shadow surface

The llms.txtprotocol proposed by Jeremy Howard (Answer.AI, September 2024) provides a Markdown file at the domain root that delivers the core of the site without HTML ballast — as a token-efficient entry point for LLMs.

The specification (see llmstxt.org) is deliberately minimal:

llms.txt
# btlabs Core

> Headless platform for SMEs: one data base, multiple channels —
> multilingual, machine-readable, privacy-friendly.

## Services
- [Corporate Websites](/en/services/websites.md): strategy, design, implementation
- [AI Discoverability](/en/services/geo.md): GEO, structured data, MCP

## Optional
- [About us](/en/about.md): Berger+Team, Bolzano

An honest assessment: no major AI provider has formally committed to weighting llms.txt as a fixed signal. The realistic state in 2026 resembles schema.org around 2014 — not universally honored, but cheap enough to be worth it. A hedge without a premium.

4. JSON-LD: making the entity graph explicit

RAG systems prefer data laid out as a graph of facts. With JSON-LD per schema.org you link entities explicitly, instead of letting the AI guess how brand, offering and people are connected:

JSON-LD · schema.org
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "Organization",
"@id": "https://btlabs.dev/#organization",
"name": "btlabs Core",
"areaServed": { "@type": "AdministrativeArea", "name": "Südtirol" }
},
{
"@type": "WebPage",
"@id": "https://btlabs.dev/leistungen",
"isPartOf": { "@id": "https://btlabs.dev/#website" },
"about": { "@id": "https://btlabs.dev/#organization" }
}
]
}

What such a facts graph means in practice is explained in What is a Knowledge Graph?.

The @graph with @idreferences is the point: it turns loose snippets into a connected network — and reduces exactly the faulty links that lead to hallucinations. An everyday example of exactly these broken links is the NAP error: wrongly recommended by AI instead of not at all — when name, address and phone number aren't recognized as one coherent entity.

5. TDM & ai.txt: visibility yes, training by choice

Via the W3C TDM Reservation Protocol (Final Report 2024, based on Art. 4 of the EU Copyright Directive, referenced by the EU AI Act) you declare in machine-readable form whether your content is released for AI training or commercial mining:

tdmrep.json
// /.well-known/tdmrep.json
[
{
"location": "/",
"tdm-reservation": 1,
"tdm-policy": "https://btlabs.dev/tdm-policy.json"
}
]

tdm-reservation: 1 is not a “no TDM” signal, but a “rights reserved” signal. Important in practice: under the working group's interpretation, search and discoverability are considered not covered by the opt-out — so you can stay visible in AI search while at the same time objecting to training.

6. MCP: from document to queryable entity

Perhaps the most important step is the Model Context Protocol (MCP). Instead of letting the AI scrape your site, you offer an authenticated, schema-defined endpoint through which authorized agents read in a targeted way — and act in a controlled way:

Policy & Tools · TypeScript
// Policy declaration
export const AI_ALLOW_MODEL_TRAINING = false
export const AI_ALLOW_DATA_MINING = false
export const AI_ATTRIBUTION_REQUIRED = true
export const MCP_ENDPOINT = '/api/mcp'

// Exposed tools — scoped, auditable
const mcpTools = [
'list_services',
'search_content',
'get_opening_hours',
'submit_inquiry', // controlled, not open
] as const

The MCP keys have graduated rights: read everywhere, write only to defined types. Every action is logged. That is how your website becomes a queryable entity — the groundwork for the coming Agent-to-Agent-Web, in which personal AI assistants compare, request and book on behalf of their users. What that agent readiness actually requires, beyond the chatbot misconception, is explained in Agent-ready doesn’t mean "bolt on a chatbot". How these rights are graded in detail is shown by a look at granular MCP keys.

7. Lessons learned from practice

From building the btlabs Core architecture, a few pitfalls that aren't in any specification:

Avoid silent truncation. If a feed like llms-full.txt loads thousands of documents unpaginated, you risk memory overflow and unnoticed truncated responses. Solution: limit hints (Showing first N of M) and cursor-based pagination.

Multilingual linking. AI models work across languages. If the Markdown twins lack the hreflang analogues (links to translations), you weaken your cross-lingual citation power — which is fatal precisely in a region like South Tyrol.

Don't “decorate” bot protocols. Inventing your own keywords in ai.txt is ineffective — parsers rigidly look for the standardized vocabulary. Sticking to the standard beats creativity.

Resolve placeholders before delivery. AI crawlers must not read unfinished templates ({{contactEmail}}), only the final, verified data. Resolution belongs before the Markdown build, not after.

8. How btlabs Core implements this

In btlabs Core, these building blocks are not a plugin stack but part of the platform. The llms.txt is built on the fly from the CMS — with parallel queries to minimize latency:

llms.txt build · TypeScript
const [pages, posts, faqs] = await Promise.all([
cms.find({
collection: 'pages',
locale: core.locale,
where: { and: publishedFilter('pages') },
limit: 25,
select: { slug: true, title: true, meta: true },
}),
// ...weitere Abfragen
])

JSON-LD, hreflang, tdmrep.json, ai.txt and the MCP endpoint are generated from the same data base as the human-facing website — one single source of truth, two output layers. That is exactly the point: the machine-readable layer is not a bolt-on afterthought, but falls out automatically as a by-product.

Conclusion

The traditional web was built for the human eye. The coming web is an Agent-to-Agent-Web in which AI interfaces talk to each other. The KPIs shift accordingly: away from classic ranking, toward LLM-Share-of-Voice and Citation Probability.

The technology for it exists today — RAG-friendly structure, llms.txt, JSON-LD, TDM and MCP. Most SMEs simply aren't using it yet. Those who build now build the lead.

One thing matters here: a good Google ranking alone is no longer enough. First on Google, Invisible in ChatGPT shows why ranking and AI visibility are two games with their own rules.

If you want to check how well your own site is structured for AI systems, or need help with implementation — get in touch.

Sources & standards

• GEO: Generative Engine Optimization — Aggarwal, P. et al., ACM SIGKDD 2024. arxiv.org/abs/2311.09735
• The /llms.txt proposal — Jeremy Howard, Answer.AI, 2024. llmstxt.org · Original proposal
• W3C TDM Reservation Protocol (TDMRep) — W3C CG Final Report, 2024. w3.org/community/reports/tdmrep
• AI Search Has a Citation Problem — Tow Center for Digital Journalism, Columbia, 2025. cjr.org
• schema.org — vocabulary for structured data. schema.org
• Model Context Protocol (MCP) — open standard for AI agent interfaces. modelcontextprotocol.io

Note: GEO, llms.txt and TDMRep are young, evolving standards. Adoption and impact are growing, but are not formally guaranteed by any major AI provider.