Webseiten für KI optimieren (GEO) – Information Gain, Markdown-Negotiation und Agent-Readiness

Warum werden technisch saubere Entwickler-Artikel von Perplexity, ChatGPT Search oder Google AI Overviews ignoriert, während ein einzelner Forenbeitrag mit einem verschwommenen Fehler-Log ganz oben als Quelle landet? Wer heute den zehnten Überblicksartikel zu einem Web-Standard veröffentlicht, liefert großen Sprachmodellen bloß das zurück, was bereits in ihren Trainingsgewichten steckt. Gleichzeitig fressen verschachtelte DOM-Bäume, Inline-SVGs und React-Hydration-Skripte beim Abruf über HTTP bis zu 85 Prozent des verfügbaren Kontextfensters auf, bevor der erste Absatz des eigentlichen Fachtextes überhaupt geparst wird.

Generative Engine Optimization (GEO) kombiniert überprüfbare Primärerfahrung (Information Gain) mit einer maschinenlesbaren Auslieferungsarchitektur. Serverseitige Content-Negotiation über Accept: text/markdown, eindeutige JSON-LD-Entitätsgraphen und tabellarische Messreihen senken den Token-Overhead beim Retrieval drastisch und erhöhen die Zitationsrate in RAG-Antwortsystemen. Technische Endpunkte wie /llms.txt oder .md-Routen garantieren jedoch kein Ranking: Ohne indexierbares HTML, echte Messdaten und dokumentierte Fehlergrenzen verwirft der Reranker jede Quelle als redundant.

Warum verwerfen RAG-Pipelines klassische Zusammenfassungen – und wie funktioniert Information Gain?

Wenn ein Nutzer eine technische Frage in Perplexity, ChatGPT Search oder Google AI Mode stellt, beantwortet das Sprachmodell die Frage nicht allein aus seinem statischen Gedächtnis. Es startet eine mehrstufige RAG-Pipeline (Retrieval-Augmented Generation: Architektur, die vor der Textgenerierung relevante Dokument-Abschnitte aus einem Suchindex abruft und in das Prompt-Kontextfenster einspeist.): Die Suchanfrage wird in Teilfragen (Query Fan-out) zerlegt, relevante Webdokumente werden abgerufen, in Textblöcke (Chunks) geschnitten und über einen Cross-Encoder Reranker (Neuronales Bewertungsmodell, das abgerufene Textpassagen auf Informationsdichte, Belegkraft und Neuigkeitswert prüft, bevor sie in den finalen LLM-Prompt gelangen.) nach Informationsdichte sortiert.

Genau an dieser Schwelle scheitern klassische SEO-Texte. Ein Artikel, der 400 Wörter lang erklärt, „was das Model Context Protocol ist“, liefert null zusätzliche Entropie gegenüber dem Basiswissen des Modells. In der Informationswissenschaft und in Googles Patenten zur Dokumentenbewertung wird dieser Differenzwert als Information Gain (Maß für den zusätzlichen, neuen Informationsgehalt, den ein Dokument im Vergleich zu bereits bekannten Quellen oder dem Vortraining des Modells liefert.) bezeichnet.

Die empirische Studie GEO: Generative Engine Optimization (Aggarwal et al., Princeton University & Georgia Tech, KDD 2024) wies über tausende Suchanfragen nach, dass drei strukturelle Merkmale die Sichtbarkeit in generativen Antworten um 30 bis 40 Prozent steigern:

1. Quantifizierbare Messdaten statt Adjektive: Konkrete Zahlen mit Einheiten (z. B. „INP sank von 280 ms auf 42 ms“ oder „Ab 23 registrierten MCP-Tools fiel die Auswahlgenauigkeit um 64 %“) statt wertloser Aussagen wie „deutlich schneller“.
2. Dokumentierte Fehlerbilder & Systemgrenzen: Reale Beobachtungen aus dem Betrieb („Auf iOS 18 Safari bricht der WebGPU-Worker ab 1,8 GB VRAM mit einem Out-of-Memory-Fehler ab“). Ein Sprachmodell kann keinen realen Hardware-Absturz halluzinieren – es muss die Primärquelle zitieren.
3. Direkte Zitierblöcke & Vergleichstabellen: Selbstständige Absätze von 40 bis 80 Wörtern, die eine konkrete Frage samt Einschränkung beantworten, sowie Markdown-Tabellen mit einheitlichen Vergleichskriterien.

Die vier technischen Schichten einer KI-optimierten Webseite

Damit dieser inhaltliche Mehrwert nicht im DOM-Rauschen untergeht, greifen auf lukiluki.me vier technische Architekturschichten ineinander:

Welche Infrastruktur brauche ich und wie implementiere ich Markdown-Content-Negotiation in Next.js 16?

Wenn ein Live-Fetcher wie ChatGPT-User, Perplexity-User oder ClaudeBot eine typische React-Seite abruft, erhält er zunächst das vollständige Server-HTML inklusive globaler Navigation, Inline-SVGs, Tailwind-Klassen und serialisierter React-Server-Components-Payloads (self.__next_f.push(...)).

Unsere Messung auf lukiluki.me: HTML-DOM vs. Markdown-Stream

Wir haben die tatsächliche Payload-Größe und den geschätzten Token-Verbrauch (~4 Zeichen pro Token) auf fünf bestehenden Routen dieses Digital Gardens gemessen. Die reguläre SSR-HTML-Antwort enthält rund 38,4 KB Layout- und Hydration-Rahmen, noch bevor der eigentliche Artikelinhalt beginnt:

Was brauche ich für die Umsetzung? (Voraussetzungen)

• Next.js App Router (ab v16.0+): Zugriff auf Request-Header über src/proxy.ts (in Next.js 16 wurde middleware.ts durch proxy.ts abgelöst) sowie einen Route-Handler unter src/app/api/markdown/[slug]/route.ts.
• Vorab bereinigter Markdown-Korpus: Ein Build-Skript (z. B. mit gray-matter), das MDX-Dateien beim Build von interaktiven Client-Importen bereinigt und als JSON-Map oder statische .md-Artefakte ablegt.
• HTTP-Discovery-Header: Vary: Accept (damit CDN-Caches Markdown-Antworten nicht versehentlich an normale Browser ausliefern) sowie Link-Header mit rel="alternate"; type="text/markdown".

Schritt-für-Schritt-Implementierung: src/proxy.ts

Der folgende produktionsreife Code läuft live auf lukiluki.me. Er fängt sowohl direkte Aufrufe auf /garden/[slug].md als auch reguläre Artikel-URLs mit dem Header Accept: text/markdown ab und setzt für HTML-Aufrufe die passenden Discovery-Header:

1// src/proxy.ts (Next.js 16 File Convention)
2import { NextResponse } from "next/server";
3import type { NextRequest } from "next/server";
4import { prefersMarkdown } from "@/lib/ai-telemetry";
5
6const siteUrl = process.env.NEXT_PUBLIC_SITE_URL || "https://lukiluki.me";
7
8export function proxy(request: NextRequest) {
9  const { pathname } = request.nextUrl;
10  const acceptHeader = request.headers.get("accept") || "";
11
12  // 1. Direkte .md-Endung (z. B. /garden/geo.md oder /en/garden/geo.md)
13  const mdMatch = pathname.match(/^(?:\/(en))?\/garden\/([^/]+)\.md$/i);
14  if (mdMatch) {
15    const locale = mdMatch[1] === "en" ? "en" : "de";
16    const slug = mdMatch[2];
17    const rewriteUrl = new URL(`/api/markdown/${slug}`, request.url);
18    rewriteUrl.searchParams.set("locale", locale);
19    return NextResponse.rewrite(rewriteUrl);
20  }
21
22  // 2. HTTP Content-Negotiation (Accept: text/markdown hat Vorrang vor text/html)
23  const gardenMatch = pathname.match(/^(?:\/(en))?\/garden\/([^/.]+)$/);
24  if (gardenMatch && prefersMarkdown(acceptHeader)) {
25    const locale = gardenMatch[1] === "en" ? "en" : "de";
26    const slug = gardenMatch[2];
27    const rewriteUrl = new URL(`/api/markdown/${slug}`, request.url);
28    rewriteUrl.searchParams.set("locale", locale);
29    return NextResponse.rewrite(rewriteUrl);
30  }
31
32  // 3. Standard-HTML-Auslieferung mit HTTP-Discovery-Headern für Agenten
33  const response = NextResponse.next();
34  if (gardenMatch) {
35    const isEn = gardenMatch[1] === "en";
36    const slug = gardenMatch[2];
37    const mdHref = `${siteUrl}${isEn ? "/en" : ""}/garden/${slug}.md`;
38    response.headers.set("Vary", "Accept");
39    response.headers.set(
40      "Link",
41      `<${mdHref}>; rel="alternate"; type="text/markdown", <${siteUrl}/llms.txt>; rel="llms-txt"`
42    );
43  }
44
45  return response;
46}

Damit Browser, die Accept: text/html,application/xhtml+xml,*/*;q=0.8 senden, niemals versehentlich Markdown erhalten, prüft prefersMarkdown() explizit die Priorität im Header:

1// src/lib/ai-telemetry.ts (Auszug)
2export function prefersMarkdown(acceptHeader: string | null): boolean {
3  if (!acceptHeader) return false;
4  const lower = acceptHeader.toLowerCase();
5  const hasMarkdown =
6    lower.includes("text/markdown") || lower.includes("text/x-markdown");
7  if (!hasMarkdown) return false;
8
9  const htmlIndex = lower.indexOf("text/html");
10  const mdIndex =
11    lower.indexOf("text/markdown") !== -1
12      ? lower.indexOf("text/markdown")
13      : lower.indexOf("text/x-markdown");
14
15  // Nur true, wenn text/html fehlt oder nach text/markdown gelistet ist
16  return htmlIndex === -1 || mdIndex < htmlIndex;
17}

Wie prüfe ich Information Gain und Markdown-Streaming im eigenen Projekt?

Mit dem folgenden Werkzeug kannst du zwei Dinge unmittelbar überprüfen:

1. Im oberen Teil (Information-Gain-Auditor): Wähle eines der drei Presets oder füge einen eigenen Textabschnitt ein. Der Auditor berechnet heuristisch den Token-Verbrauch (SSR-HTML vs. .md) und prüft deterministisch auf quantitative Messwerte, dokumentierte Grenzsignale, Tabellenstrukturen und verbotene Marketing-Floskeln.
2. Im unteren Terminal (Live-Endpunkt-Test): Führe einen echten fetch-Aufruf mit Accept: text/markdown gegen die Live-Routen dieser Webseite (/garden/geo.md, /garden/web-mcp.md etc.) aus und inspiziere die realen HTTP-Header von src/proxy.ts.

Was zeigt dieser Auditor – und wo endet seine Aussagekraft?

Der Vergleich zwischen Preset 1 (Praxis-Messreihe) und Preset 2 (Generische Zusammenfassung) macht deutlich, warum Sprachmodelle beim Retrieval wählerisch sind: Während Preset 2 trotz flüssiger Sprache keinerlei extrahierbare Fakten enthält und durch Buzzwords wie „blazing fast“ auffällt, liefert Preset 1 konkrete Schwellenwerte (23 Tools, 64 %, 1,8 GB) und eine direkt parsbare Markdown-Tabelle.

Wichtige Grenze des Werkzeugs: Der lokale Score im Browser ist eine strukturbasierte Heuristik. Er prüft, ob die formalen Bausteine für Information Gain vorhanden sind, kann aber nicht verifizieren, ob deine gemessenen Zahlen fachlich stimmen oder ob deine Domain bereits genügend externe Verweise (Off-Page-Kookkurrenz) besitzt, um bei hart umkämpften Suchbegriffen in die Top-10-Retrieval-Auswahl zu gelangen.

Welcher KI-Crawler liest was – und warum wird /llms.txt von Google ignoriert?

Ein verbreiteter Irrtum in der Entwickler-Community lautet: „Ich lege eine /llms.txt ins Root-Verzeichnis und werde automatisch in Google AI Overviews und ChatGPT zitiert.“ Ein Blick in reale Server-Logs und die Spezifikationen der Suchmaschinenbetreiber zeigt ein deutlich differenzierteres Bild.

Wir müssen strikt zwischen drei Kategorien von KI-Zugriffen unterscheiden:

Wie verknüpfe ich Entitäten im JSON-LD-Wissensgraphen und über den Accessibility-Tree?

Sprachmodelle und Suchmaschinen-Graphen ordnen Fachinhalte über Entitäten zu: Wer hat den Artikel verfasst, welche konkreten Technologien werden behandelt und wo ist die kanonische Quelle verankert?

1. Entitäten-Disambiguierung mit Schema.org @graph

Anstelle eines isolierten Meta-Tags betten wir auf jeder Garden-Seite einen zusammenhängenden JSON-LD-Graphen ein. Entscheidend sind drei Verknüpfungen, die in einfachen Standard-Blogs fast immer fehlen:

• about als typisierte Entitäten-Liste: Alle Technologie-Tags der Kachel werden als Thing übergeben, damit Extraktions-Pipelines das Kernthema ohne Mehrdeutigkeit erfassen.
• encoding mit Verweis auf text/markdown: Weist Crawler im strukturierten Header direkt auf die schlanke .md-URL hin.
• author mit knowsAbout und sameAs: Verknüpft die Personen-Entität konsistent mit GitHub und LinkedIn (Off-Page-Kookkurrenz).

1{
2  "@context": "https://schema.org",
3  "@graph": [
4    {
5      "@type": "TechArticle",
6      "headline": "Webseiten für KI optimieren (GEO) – Information Gain, Markdown-Negotiation und Agent-Readiness",
7      "url": "https://lukiluki.me/garden/geo",
8      "inLanguage": "de-DE",
9      "isAccessibleForFree": true,
10      "about": [
11        { "@type": "Thing", "name": "Generative Engine Optimization" },
12        { "@type": "Thing", "name": "Next.js 16" },
13        { "@type": "Thing", "name": "Model Context Protocol" }
14      ],
15      "encoding": {
16        "@type": "MediaObject",
17        "encodingFormat": "text/markdown",
18        "contentUrl": "https://lukiluki.me/garden/geo.md"
19      },
20      "author": {
21        "@type": "Person",
22        "@id": "https://lukiluki.me/#person",
23        "name": "Lukas Kopischke",
24        "jobTitle": "Lead Software Engineer",
25        "sameAs": [
26          "https://github.com/lnk1812",
27          "https://www.linkedin.com/in/lukas-kopischke-7353aa18b/"
28        ],
29        "knowsAbout": [
30          "Next.js",
31          "Generative Engine Optimization (GEO)",
32          "Model Context Protocol (MCP)",
33          "Web Accessibility (WCAG 2.2 / BITV 2.0 / BFSG)"
34        ]
35      }
36    }
37  ]
38}

2. Der Accessibility-Tree als API für autonome Browser-Agenten

Wenn ein autonomer Browser-Agent (wie Claude Computer Use, OpenAI Operator oder ein lokaler Agent über Web MCP) eine Webseite bedient, parst er bevorzugt den Accessibility-Tree (Vom Browser aus dem DOM erzeugter semantischer Baum (AXTree), der Rollen, Namen, Zustände und Fokuspunkte für Screenreader und KI-Agenten bereitstellt.) des Browsers.

Ein interaktives Filter-Element, das nur aus verschachtelten <div onClick={...}>-Containern ohne role, aria-expanded oder verknüpftes <label> besteht, ist für einen KI-Agenten genauso blind wie für einen Screenreader. Wer strikte Barrierefreiheit nach WCAG 2.2 / BFSG umsetzt (siehe Accessibility & BITV 2.0), baut damit automatisch die zuverlässigste Steuerungsschnittstelle für das agentische Web.

Handlungsprüfung: Ist deine Webseite bereit für KI-Suchmaschinen und Agenten?

Arbeite diese fünf Prüfungen vor dem nächsten Deployment ab, um sicherzustellen, dass sowohl klassische Suchmaschinen als auch RAG-Pipelines und Coding-Agenten deine Inhalte fehlerfrei extrahieren:

• Information-Gain-Test bestanden: Enthält der Artikel mindestens eine eigene Messreihe, ein reales Fehlerszenario (Post-Mortem) oder eine Vergleichstabelle, die so in keiner offiziellen Standard-Dokumentation steht?
• Direkte Antwort im ersten Viertel: Steht unmittelbar nach dem Einstiegs-Hook ein eigenständiger Absatz von 40 bis 80 Wörtern, der Mechanismus, Nutzen und die zentrale Grenze ohne Klick-Abhängigkeit benennt?
• Content-Negotiation aktiv: Liefert curl -I -H "Accept: text/markdown" https://deine-domain.de/pfad den Status 200 OK mit Content-Type: text/markdown; charset=utf-8 und dem Header Vary: Accept?
• Crawler-Freigabe in robots.txt: Sind Retrieval-Bots (OAI-SearchBot, ChatGPT-User, PerplexityBot, ClaudeBot, Googlebot) für Artikel-Routen, /llms.txt und /api/markdown/ explizit freigegeben?
• Entitäten-Graph & Barrierefreiheit: Validiert das eingebettete TechArticle-JSON-LD fehlerfrei und besitzen alle interaktiven Playground-Steuerelemente im Accessibility-Tree eindeutige Labels und mindestens 44×44 Pixel Touch-Fläche?

Quellen und nächste Schritte

Primärquellen & Forschung

• Aggarwal, P. et al. (2024): GEO: Generative Engine Optimization – Proceedings of the 30th ACM SIGKDD Conference on Knowledge Discovery and Data Mining (KDD '24), Princeton University, Georgia Tech & Allen Institute for AI.
• Google Search Central: AI features and your website (AI Overviews & AI Mode) – Offizielle technische Anforderungen für Indexierung, strukturierte Daten und Snippet-Steuerung in Google AI Overviews.
• Next.js 16.3 Dokumentation: How to set up your Next.js project for AI coding agents – Spezifikation für AGENTS.md, .md-Routen und Accept: text/markdown Content-Negotiation.
• Howard, J. / Answer.AI (2024): The /llms.txt Standard Proposal – Spezifikation für kuratierte Markdown-Inhaltsverzeichnisse zur Kontext-Injektion in große Sprachmodelle.

Weiterführende Kacheln im Digital Garden

• Web MCP – Lokale KI-Agenten im Browser: Beantwortet die Anschlussfrage, wie du über reine Text-Extraktion hinausgehst und KI-Agenten über navigator.modelContext deterministische JavaScript-Werkzeuge direkt im Browser bereitstellst.
• Context Engineering mit Obsidian & Graphify: Zeigt, wie du das Prinzip von llms.txt und strukturierten Wissensgraphen auf komplexe Software-Repositories überträgst, um Coding-Agenten mit belastbarem Architekturwissen zu versorgen.
• Accessibility & BITV 2.0: Erklärt im Detail, wie du einen semantisch lückenlosen Accessibility-Tree aufbaust, von dem menschliche Nutzer mit Screenreadern und autonome Web-Agenten gleichermaßen profitieren.