# Webseiten für KI optimieren (GEO) – Information Gain, Markdown-Negotiation und Agent-Readiness > **Autor:** Lukas Kopischke (Lead Software-Engineer, Düsseldorf) > **Kanonische URL:** https://lukiluki.me/garden/geo > **Markdown-Endpunkt:** https://lukiluki.me/garden/geo.md > **Kategorie:** KI & Agents | **Tags:** GEO, llms.txt, Next.js 16, JSON-LD, RAG, Content Negotiation > **Veröffentlicht:** 2026-10-23 | **Aktualisiert:** 2026-10-23 > **Zusammenfassung:** Praxis-Leitfaden für Generative Engine Optimization (GEO): Information Gain, Accept: text/markdown in Next.js 16, JSON-LD und echte Token-Messdaten. --- 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. > **Merksatz (Information Gain vor Zusammenfassung):** > Sprachmodelle fassen bekanntes Lehrbuchwissen selbst zusammen – sie zitieren externe Webseiten nur dann, wenn dort empirische Messwerte, dokumentierte Fehlschläge oder spezifische Konfigurationsgrenzen stehen, die im Vortraining fehlen. Technische Protokolle wie Accept: text/markdown und JSON-LD stellen sicher, dass dieser Informationsgewinn ohne HTML-Ballast im Kontextfenster des Modells ankommt. ## 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: ### 1. Primäre Evidenz & Post-Mortems (Inhalt) Jeder Fachartikel beantwortet die Kernfrage im ersten Viertel (40–80 Wörter) und belegt Aussagen durch reale Messreihen, Versionsnummern und reproduzierbare Fehlerszenarien statt zweiter Hand zusammengefasster Tutorials. ### 2. HTTP Content-Negotiation (.md) (Transport) Fragt ein KI-Agent oder Entwickler eine URL mit `Accept: text/markdown` oder der Endung `.md` an, liefert der Server über `src/proxy.ts` reines, strukturiertes Markdown ohne Navigations-HTML und Hydration-Skripte aus. ### 3. Dichte JSON-LD-Entitätsgraphen (Semantik) Ein verknüpfter Schema.org-Graph (`TechArticle`, `Person`, `knowsAbout`, `sameAs`, `encoding`) verbindet Autor, Technologie-Tags und die alternative Markdown-Repräsentation maschinenlesbar im Seitenkopf. ### 4. Semantischer Accessibility-Tree (Aktorik) Saubere ARIA-Rollen, benannte Formularfelder und deterministische Browser-Werkzeuge ([Web MCP](/garden/web-mcp)) ermöglichen autonomen Browser-Agenten die fehlerfreie Navigation ohne fragiles DOM-Scraping. --- ## 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: | Garden-Route auf `lukiluki.me` | SSR HTML-Payload | Geschätzte HTML-Tokens | Reiner `.md`-Stream | Geschätzte `.md`-Tokens | Eingespannter Token-Ballast | | :--- | :--- | :--- | :--- | :--- | :--- | | `/garden/geo` | 54,8 KB | ~13.700 Tokens | 9,6 KB | ~2.400 Tokens | **-82,5 %** | | `/garden/web-mcp` | 51,2 KB | ~12.800 Tokens | 7,4 KB | ~1.850 Tokens | **-85,5 %** | | `/garden/brownfield-ai` | 56,4 KB | ~14.100 Tokens | 10,2 KB | ~2.550 Tokens | **-81,9 %** | | `/garden/3d-print-mcp` | 52,0 KB | ~13.000 Tokens | 7,8 KB | ~1.950 Tokens | **-85,0 %** | | `/garden/accessibility` | 49,6 KB | ~12.400 Tokens | 6,8 KB | ~1.700 Tokens | **-86,3 %** | ### 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"`. > **Realer Praxisfehler: Veraltete Trainingsdaten bei Next.js 16 Proxy** > Wenn du heute ein Sprachmodell ohne aktuellen Kontext bittest, Content-Negotiation für Next.js zu schreiben, generiert es fast immer eine `middleware.ts`. Seit Next.js 16 heißt diese Dateikonvention jedoch verbindlich `proxy.ts` mit der exportierten Funktion `proxy(request: NextRequest)`. Genau solche versionsspezifischen Brüche sind perfekter Information Gain für technische Dokumentation. ### 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: ```typescript // src/proxy.ts (Next.js 16 File Convention) import { NextResponse } from "next/server"; import type { NextRequest } from "next/server"; import { prefersMarkdown } from "@/lib/ai-telemetry"; const siteUrl = process.env.NEXT_PUBLIC_SITE_URL || "https://lukiluki.me"; export function proxy(request: NextRequest) { const { pathname } = request.nextUrl; const acceptHeader = request.headers.get("accept") || ""; // 1. Direkte .md-Endung (z. B. /garden/geo.md oder /en/garden/geo.md) const mdMatch = pathname.match(/^(?:\/(en))?\/garden\/([^/]+)\.md$/i); if (mdMatch) { const locale = mdMatch[1] === "en" ? "en" : "de"; const slug = mdMatch[2]; const rewriteUrl = new URL(`/api/markdown/${slug}`, request.url); rewriteUrl.searchParams.set("locale", locale); return NextResponse.rewrite(rewriteUrl); } // 2. HTTP Content-Negotiation (Accept: text/markdown hat Vorrang vor text/html) const gardenMatch = pathname.match(/^(?:\/(en))?\/garden\/([^/.]+)$/); if (gardenMatch && prefersMarkdown(acceptHeader)) { const locale = gardenMatch[1] === "en" ? "en" : "de"; const slug = gardenMatch[2]; const rewriteUrl = new URL(`/api/markdown/${slug}`, request.url); rewriteUrl.searchParams.set("locale", locale); return NextResponse.rewrite(rewriteUrl); } // 3. Standard-HTML-Auslieferung mit HTTP-Discovery-Headern für Agenten const response = NextResponse.next(); if (gardenMatch) { const isEn = gardenMatch[1] === "en"; const slug = gardenMatch[2]; const mdHref = `${siteUrl}${isEn ? "/en" : ""}/garden/${slug}.md`; response.headers.set("Vary", "Accept"); response.headers.set( "Link", `<${mdHref}>; rel="alternate"; type="text/markdown", <${siteUrl}/llms.txt>; rel="llms-txt"` ); } return response; } ``` 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: ```typescript // src/lib/ai-telemetry.ts (Auszug) export function prefersMarkdown(acceptHeader: string | null): boolean { if (!acceptHeader) return false; const lower = acceptHeader.toLowerCase(); const hasMarkdown = lower.includes("text/markdown") || lower.includes("text/x-markdown"); if (!hasMarkdown) return false; const htmlIndex = lower.indexOf("text/html"); const mdIndex = lower.indexOf("text/markdown") !== -1 ? lower.indexOf("text/markdown") : lower.indexOf("text/x-markdown"); // Nur true, wenn text/html fehlt oder nach text/markdown gelistet ist return htmlIndex === -1 || mdIndex < htmlIndex; } ``` #### Empfohlen (Do): Idempotentes Markdown mit Vary: Accept und kanonischem Link-Header Setze bei Content-Negotiation immer `Vary: Accept` und liefere im Markdown-Header die kanonische URL, das Veröffentlichungsdatum und den Autor mit aus. So bleibt der Kontext erhalten, selbst wenn ein Agent nur die `.md`-Datei in seinen Speicher lädt. #### Vermeiden (Don't): User-Agent-Cloaking mit abweichendem Inhalt für Suchmaschinen Liefere niemals inhaltlich andere Aussagen an den `Googlebot` aus als an menschliche Besucher. Google wertet unterschiedliche Inhalte unter derselben URL ohne saubere Content-Negotiation als täuschendes Cloaking und stuft die Seite im Index herab. --- ## 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: | Crawler / User-Agent | Betreiber & Zweck | Beachtet `robots.txt`? | Liest `/llms.txt` automatisch? | Bevorzugtes Format & Optimierungshebel | | :--- | :--- | :--- | :--- | :--- | | **`Googlebot` / `Google-Extended`** | Google Search, AI Overviews & Gemini-Training | **Ja** (`Google-Extended` steuert nur Training/Grounding, nicht die Suche) | **Nein** (Google nutzt ausschließlich den regulären HTML/DOM-Index) | Serverseitiges HTML (SSR), interne Verlinkung, sichtbarer Text und valides JSON-LD (`TechArticle`). | | **`OAI-SearchBot`** | OpenAI Suchindex für ChatGPT Search | **Ja** (Respektiert `Allow`/`Disallow` strikt) | **Selten** (Crawlt primär Sitemap & HTML-Seiten) | Saubere H2/H3-Frageüberschriften, Tabellen, hohe Faktendichte im ersten Viertel der Seite. | | **`ChatGPT-User` / `Perplexity-User`** | Nutzerinitiierter Live-Abruf während einer Chat-Sitzung | **Teilweise** (Wird als direkter Nutzerabruf gewertet) | **Ja, bei explizitem Prompt** oder über Agenten-Skills | Profitiert massiv von `Accept: text/markdown` und kurzen Antwortzeiten (niedrige TTFB). | | **`PerplexityBot`** | Perplexity AI Such- und Zitationsindex (~10 Quellen pro Antwort) | **Ja** | **Selten** | Zitiert überdurchschnittlich oft Erfahrungsberichte, Vergleichstabellen und konkrete Fehlerlösungen. | | **`ClaudeBot` / Claude Code** | Anthropic Web-Index & Coding-Agenten | **Ja** | **Ja** (Insbesondere in Developer-Workflows & Dokumentationen) | Direkte `.md`-URLs (`/garden/geo.md`), `/llms-full.txt` und kopierbare Codeblöcke mit Versionsangabe. | | **`Bytespider`** | ByteDance LLM-Training | **Häufig ignoriert** | **Nein** | Erzeugt hohe Serverlast ohne Zitations-Traffic; sollte bei Bedarf per WAF gedrosselt werden. | > **Warum wir /llms.txt und .md-Routen trotzdem betreiben** > Laut Google Search Central benötigt eine Webseite für *AI Overviews* weder `/llms.txt` noch spezielle KI-Meta-Tags; maßgeblich ist der reguläre Googlebot-Index. Sobald jedoch ein Entwickler in **Cursor, Claude Code oder Antigravity** arbeitet oder deine Dokumentation als Kontextquelle einbindet, sparen `/llms.txt`, `/llms-full.txt` und `.md`-Endpunkte über 80 Prozent der Token-Kosten und verhindern Abschneidefehler (*Truncation*) im Kontextfenster. --- ## 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*). ```json { "@context": "https://schema.org", "@graph": [ { "@type": "TechArticle", "headline": "Webseiten für KI optimieren (GEO) – Information Gain, Markdown-Negotiation und Agent-Readiness", "url": "https://lukiluki.me/garden/geo", "inLanguage": "de-DE", "isAccessibleForFree": true, "about": [ { "@type": "Thing", "name": "Generative Engine Optimization" }, { "@type": "Thing", "name": "Next.js 16" }, { "@type": "Thing", "name": "Model Context Protocol" } ], "encoding": { "@type": "MediaObject", "encodingFormat": "text/markdown", "contentUrl": "https://lukiluki.me/garden/geo.md" }, "author": { "@type": "Person", "@id": "https://lukiluki.me/#person", "name": "Lukas Kopischke", "jobTitle": "Lead Software Engineer", "sameAs": [ "https://github.com/lnk1812", "https://www.linkedin.com/in/lukas-kopischke-7353aa18b/" ], "knowsAbout": [ "Next.js", "Generative Engine Optimization (GEO)", "Model Context Protocol (MCP)", "Web Accessibility (WCAG 2.2 / BITV 2.0 / BFSG)" ] } } ] } ``` ### 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](/garden/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 `
`-Containern ohne `role`, `aria-expanded` oder verknüpftes `