Von SEO zu GEO: Die technische Architektur einer KI-lesbaren Website

Jahrzehntelang basierte Auffindbarkeit auf einem Modell: Suchmaschinen crawlen HTML, werten Links aus, liefern eine Liste blauer Links. Der Mensch ist der Filter, der die Seiten einzeln aufruft.

Generative Engines wie Google AI Overviews, Perplexity oder ChatGPT brechen dieses Modell. Sie nutzen Retrieval-Augmented Generation (RAG): Sie suchen relevante Inhalte in Echtzeit, laden die passenden Textsegmente in den Kontext eines Sprachmodells und generieren eine konsolidierte Antwort mit Quellenangaben. Wer nicht zitiert wird, ist unsichtbar.

Dieser Artikel ist die technische Begleitung dazu — für alle, die eine Website nicht nur für Menschen, sondern auch für Maschinen bauen wollen. Wir gehen durch die Mechanik von RAG, die belegten GEO-Hebel, die nötigen Standards (llms.txt, JSON-LD, TDM, MCP) und die Fehler, die wir in der Praxis gesehen haben.

1. Wie Generative Engines auswählen

Im Kern eines RAG-Systems steht eine simple geometrische Idee. Suchanfrage und Dokument-Chunks werden über ein Embedding-Modell in hochdimensionale Vektoren überführt. Die Relevanz zweier Vektoren wird meist über die Kosinus-Ähnlichkeit bestimmt:

Kosinus-Ähnlichkeit
sim(q, d) = (q · d) / (‖q‖ ‖d‖)

Dabei ist q der Vektor der Anfrage und d der Vektor eines Dokument-Chunks. Das System wählt die k Chunks mit der höchsten Ähnlichkeit und übergibt sie dem Sprachmodell als Kontext.

Die praktische Konsequenz: Wie du deinen Inhalt in Chunks zerlegst (Struktur, Überschriften, Absatzlogik), entscheidet darüber, ob deine Aussagen semantisch sauber eingeordnet — oder falsch verknüpft werden. Schlechtes Chunking ist eine Hauptursache für die „zitationsförmigen Halluzinationen", bei denen eine KI eine Quelle für eine Aussage verlinkt, die dort gar nicht steht.

2. Die belegten GEO-Hebel

Die Studie „GEO: Generative Engine Optimization" (Aggarwal et al., ACM KDD 2024) hat systematisch gemessen, welche Textänderungen die Wahrscheinlichkeit erhöhen, von einem LLM zitiert zu werden — mit einem Sichtbarkeits-Plus von bis zu 40 %. Die wirksamsten Methoden:

• Statistics Addition — konkrete Zahlen und Daten statt qualitativer Aussagen. LLMs bevorzugen Präzision.
• Cite Sources — eigene Aussagen mit Quellenverweisen belegen. Erhöht die wahrgenommene Vertrauenswürdigkeit drastisch.
• Quotation Addition — wörtliche Expertenzitate einbinden. Signalisiert qualitative Tiefe.

Bemerkenswert: Der Effekt ist domänenabhängig und besonders stark für ursprünglich schlecht platzierte Seiten. Keyword-Stuffing — der alte SEO-Reflex — wirkt dagegen nicht.

3. llms.txt: die schlanke Schatten-Oberfläche

Das von Jeremy Howard (Answer.AI, September 2024) vorgeschlagene llms.txt-Protokoll liefert eine Markdown-Datei im Root der Domain, die den Kern der Seite ohne HTML-Ballast bereitstellt — als token-effizienter Einstiegspunkt für LLMs.

Die Spezifikation (siehe llmstxt.org) ist bewusst minimal:

llms.txt
# btlabs Core

> Headless Plattform für KMU: eine Datenbasis, mehrere Kanäle —
> mehrsprachig, KI-lesbar, datenschutzfreundlich.

## Leistungen
- [Corporate Websites](/de/leistungen/websites.md): Strategie, Design, Umsetzung
- [KI-Auffindbarkeit](/de/leistungen/geo.md): GEO, strukturierte Daten, MCP

## Optional
- [Über uns](/de/ueber-uns.md): Berger+Team, Bozen

Ehrliche Einordnung: Kein großer KI-Anbieter hat sich formal verpflichtet, llms.txt als festes Signal zu gewichten. Der realistische Stand 2026 ähnelt schema.org um 2014 — nicht universell honoriert, aber günstig genug, dass es sich lohnt. Ein Hedge ohne Prämie.

4. JSON-LD: den Entitäten-Graphen explizit machen

RAG-Systeme bevorzugen Daten, die als Fakten-Graph hinterlegt sind. Über JSON-LD nach schema.org vernetzt du Entitäten explizit, statt die KI raten zu lassen, wie Marke, Angebot und Personen zusammenhängen:

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" }
}
]
}

Der @graph mit @id-Referenzen ist der Punkt: Er macht aus losen Snippets ein verbundenes Netz — und reduziert genau die fehlerhaften Verknüpfungen, die zu Halluzinationen führen.

5. TDM & ai.txt: Sichtbarkeit ja, Training nach Wahl

Über das W3C TDM Reservation Protocol (Final Report 2024, basierend auf Art. 4 der EU-Urheberrechtsrichtlinie, referenziert vom EU AI Act) deklarierst du maschinenlesbar, ob deine Inhalte für KI-Training bzw. kommerzielles Mining freigegeben sind:

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

tdm-reservation: 1 ist dabei kein „Kein-TDM"-Signal, sondern ein „Rechte-vorbehalten"-Signal. Wichtig für die Praxis: Suche und Auffindbarkeit gelten nach Auslegung der Arbeitsgruppe als nicht vom Opt-out erfasst — du kannst also in der KI-Suche sichtbar bleiben und gleichzeitig dem Training widersprechen.

6. MCP: vom Dokument zur abfragbaren Entität

Der vielleicht wichtigste Schritt ist das Model Context Protocol (MCP). Statt die KI deine Seite scrapen zu lassen, bietest du einen authentifizierten, schema-definierten Endpunkt, über den autorisierte Agenten gezielt lesen — und kontrolliert handeln:

Policy & Tools · TypeScript
// Policy-Deklaration
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'

// Exponierte Tools — scoped, auditierbar
const mcpTools = [
'list_services',
'search_content',
'get_opening_hours',
'submit_inquiry', // kontrolliert, nicht offen
] as const

Die MCP-Schlüssel haben abgestufte Rechte: lesen überall, schreiben nur auf definierte Typen. Jede Aktion wird protokolliert. So wird aus deiner Website eine abfragbare Entität — der Vorbau für das kommende Agent-to-Agent-Web, in dem persönliche KI-Assistenten im Namen ihrer Nutzer vergleichen, anfragen und buchen.

7. Lessons Learned aus der Praxis

Aus dem Aufbau der btlabs-Core-Architektur ein paar Fallen, die in keiner Spezifikation stehen:

Silent Truncation vermeiden. Lädt ein Feed wie llms-full.txt tausende Dokumente unpaginiert, drohen Speicherüberlauf und unbemerkt abgeschnittene Antworten. Lösung: Limit-Hinweise (Showing first N of M) und Cursor-basierte Paginierung.

Mehrsprachige Vernetzung. KI-Modelle arbeiten sprachübergreifend. Fehlen in den Markdown-Twins die hreflang-Analoga (Links zu Übersetzungen), schwächst du deine cross-linguale Zitationskraft — gerade in einer Region wie Südtirol fatal.

Bot-Protokolle nicht „dekorieren". Eigene Schlüsselwörter in ai.txt zu erfinden ist wirkungslos — Parser suchen starr nach dem standardisierten Vokabular. Standard-Härtung schlägt Kreativität.

Platzhalter vor Auslieferung auflösen. KI-Crawler dürfen keine unfertigen Templates ({{contactEmail}}) lesen, sondern nur die finalen, verifizierten Daten. Auflösung gehört vor den Markdown-Build, nicht danach.

8. Wie btlabs Core das umsetzt

In btlabs Core sind diese Bausteine kein Plugin-Stack, sondern Teil der Plattform. Die llms.txt wird on-the-fly aus dem CMS gebaut — mit parallelen Abfragen zur Latenzminimierung:

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 und der MCP-Endpunkt werden aus derselben Datenbasis generiert wie die menschliche Website — eine Single Source of Truth, zwei Ausgabe-Ebenen. Genau das ist der Punkt: Die maschinenlesbare Schicht ist kein nachträglicher Anbau, sondern fällt automatisch mit ab.

Fazit

Das traditionelle Web wurde fürs menschliche Auge gebaut. Das kommende Web ist ein Agent-to-Agent-Web, in dem KI-Schnittstellen miteinander reden. Die KPIs verschieben sich entsprechend: weg vom klassischen Ranking, hin zu LLM-Share-of-Voice und Citation Probability.

Die Technik dafür existiert heute — RAG-gerechte Struktur, llms.txt, JSON-LD, TDM und MCP. Die meisten KMU haben sie nur noch nicht. Wer jetzt baut, baut den Vorsprung.

Wichtig dabei: Ein gutes Google-Ranking allein reicht nicht mehr aus. Platz 1 bei Google, unsichtbar in ChatGPT zeigt, warum Ranking und KI-Sichtbarkeit zwei Spiele mit eigenen Regeln sind.

Quellen & 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 — Vokabular für strukturierte Daten. schema.org
• Model Context Protocol (MCP) — offener Standard für KI-Agenten-Schnittstellen. modelcontextprotocol.io

Hinweis: GEO, llms.txt und TDMRep sind junge, sich entwickelnde Standards. Adoption und Wirkung wachsen, sind aber von keinem großen KI-Anbieter formal garantiert.