GEO · Crawler · llms.txt

AI-Crawler-Strategie & llms.txt. Das technische Fundament unter GEO.

Wer KI-Crawler nicht bewusst steuert, ist entweder pauschal unsichtbar (Default-Block in CMS-robots.txt) oder unkontrolliert offen. Diese Seite beschreibt die technische Schicht unter allen GEO-Programmen: robots.txt für AI-Crawler, Snippet-Direktiven, llms.txt und Rendering für LLMs — engine-übergreifend, nicht engine-spezifisch.

Engine-spezifische Optimierungs-Hebel liegen in den Engine-Seiten (Google AI Overviews, ChatGPT, Perplexity, Claude & Copilot). Hier geht es nur um das technische Fundament — was für alle Engines gleichzeitig gilt.

Die relevanten AI-Crawler

Aktuell relevante User-Agents, die in jeder GEO-Diagnose geprüft werden:

  • GPTBot — OpenAI Trainingsdaten-Crawler für künftige Modelle. Steuert Verankerung in der Modell-Basis.
  • OAI-SearchBot — OpenAI Live-Retrieval für ChatGPT Search. Steuert Echtzeit-Sichtbarkeit in ChatGPT.
  • ClaudeBot, claude-web — Anthropic. Zurückhaltender im Volumen, Voraussetzung für Claude-Web-Antworten.
  • PerplexityBot — Perplexitys eigener Retrieval-Crawler. Voraussetzung für die Aufnahme ins Quellen-Karussell.
  • Google-Extended — separat steuerbar für Gemini / Google AI Overviews, getrennt vom klassischen Googlebot.
  • Applebot-Extended — Apple-Intelligence / Siri-Antworten, neuer Crawler mit wachsender Bedeutung im Apple-Ökosystem.
  • Bytespider — ByteDance / Doubao, primär für China-relevante Setups.
  • Bingbot — kein klassischer AI-Crawler, aber gemeinsame Index-Basis für ChatGPT Search und Microsoft Copilot.

robots.txt-Strategie

Default-Empfehlung: pro Crawler bewusst entscheiden, nicht pauschal blocken oder pauschal öffnen. Die Entscheidungsmatrix folgt vier Kriterien:

  1. Strategischer Sichtbarkeits-Wunsch in der jeweiligen Engine.
  2. IP-Schutz und Lizenz-Erwägungen — gibt es Inhalte, die nicht in Trainings-Daten oder Aggregations-Antworten landen sollen?
  3. Trainings- vs. Retrieval-Differenzierung — z. B. GPTBot vs. OAI-SearchBot getrennt entscheiden, Google-Extended vs. Googlebot.
  4. Server-Last — bei großen, frequenzstarken AI-Crawlern ggf. Crawl-Rate begrenzen statt komplett zu blocken.

Implementierung erfolgt in robots.txt und wird gegen die Server-Log-Realität gespiegelt — wer die Anweisungen schreibt, ohne zu prüfen, ob die Crawler sie respektieren, hat keine Strategie, sondern eine Hoffnung.

llms.txt

Ein noch nicht standardisierter Vorschlag, der LLMs strukturierte und leichter verarbeitbare Versionen der wichtigsten Inhalte bereitstellt — analog zu sitemap.xml für klassische Suchmaschinen. Adoption ist aktuell begrenzt, kein Garant für mehr Sichtbarkeit. Aber: bei sauber strukturierter Content-Architektur ist die Bereitstellung mit geringem Aufwand möglich, und das Risiko ist asymmetrisch — wenn der Standard sich durchsetzt, ist man früh dabei; wenn nicht, ist nichts verloren. Wir empfehlen Einsatz dort, wo Content-Tiefe ohnehin gegeben ist, und beobachten die Standardisierungs-Entwicklung aktiv.

Snippet- und Aggregations-Direktiven

  • max-snippet — begrenzt die Länge der Text-Ausschnitte, die in Antworten erscheinen können. Standardmäßig nicht setzen; gezielt nur dort, wo Inhalte nicht aggregiert werden sollen.
  • nosnippet — unterdrückt die Snippet-Anzeige vollständig. Verzichtet damit auf AI-Overview-Zitierbarkeit. Nur für Inhalte mit rechtlichen oder strategischen Sperr-Gründen.
  • data-nosnippet — granular auf einzelne Inhalts-Bereiche anwendbar (z. B. interne Bewertungs-Daten, sensible Tabellen-Inhalte).
  • noai / noimageai — Vorschläge für KI-spezifische Direktiven, noch nicht universell unterstützt; wir prüfen Engine-Reaktionen pro Mandat.

Rendering für LLMs

AI-Crawler verarbeiten überwiegend serverseitig gerendertes HTML. Reine Client-Side-Rendering-Setups (CSR ohne SSR/SSG) sind für AI-Retrieval unzuverlässig: viele AI-Crawler führen kein vollständiges JavaScript aus. SSR oder SSG ist Voraussetzung, nicht Optimierung — Tiefe in technisches SEO und Core Web Vitals.

Server-Logs als Crawl-Diagnose

Die einzige verlässliche Quelle, um zu prüfen, welche AI-Crawler tatsächlich kommen, wie oft sie kommen und welche URLs sie ziehen. Wir richten in jedem GEO-Mandat eine fortlaufende Auswertung der AI-User-Agents pro Tag, Status-Codes und Crawl-Frequenz pro Engine ein. Auffälligkeiten (plötzlicher Wegfall einer Engine, hohe 4xx/5xx-Raten, neue Crawler) werden in das laufende AI Visibility Monitoring eingespiegelt.

Häufige Fragen

Nein. Wer pauschal blockt, ist in den jeweiligen KI-Antworten unsichtbar. Bewusste Entscheidung pro Engine: in der Regel zulassen, gezielt blocken nur, wo IP-Schutz oder strategische Gründe es erfordern.


Die AI-Crawler-Strategie ist die technische Schicht unter allen GEO-Programmen und verzahnt sich eng mit technischem SEO und Core Web Vitals. Die engine-spezifischen Optimierungs-Hebel: Google AI Overviews, ChatGPT, Perplexity, Claude & Copilot. Mess-Schicht: AI Visibility Monitoring.