RAG-Optimierung für Enterprise-KI: Firmen-KI richtig füttern

Die interne Wissensdatenbank ist gepflegt, die Produktseiten sind aktuell, trotzdem liefert die firmeneigene KI-Anwendung falsche Antworten und ChatGPT kennt das neue Produkt nicht. Oft liegt das nicht am Modell, sondern an der RAG-Optimierung der Quellen, aus denen es schöpft.

Definition: RAG-Optimierung (Retrieval Augmented Generation) für Enterprise-KI-Systeme bezeichnet die technische und strukturelle Vorbereitung von Unternehmensinhalten, damit KI-Systeme sie zuverlässig finden, lesen und zitieren können. Das betrifft sowohl interne KI-Anwendungen, die auf Basis eigener Dokumente antworten, als auch öffentliche KI-Crawler wie GPTBot, ClaudeBot oder PerplexityBot, die dieselben Inhalte für Training oder Live-Antworten abrufen.

RAG-Optimierung und KI-Crawler: zwei Seiten derselben Struktur

Ein internes RAG-System zerlegt Dokumente in Abschnitte, sucht bei einer Anfrage die passenden heraus und gibt sie dem Sprachmodell als Kontext mit. Genau das macht auch ein öffentlicher KI-Crawler wie GPTBot oder ClaudeBot, nur dass die Inhalte danach nicht in einem internen Chatbot landen, sondern in ChatGPT, Perplexity oder Google AI Overviews. Beide Systeme brauchen dieselbe Grundlage: klar abgegrenzte Absätze, eindeutige Überschriften und keine widersprüchlichen Doppelversionen desselben Dokuments.

In diesem Themenfeld tauchen ständig dieselben Begriffe auf: geaio, GEO, SEO und KI-Suche bezeichnen verwandte, aber nicht identische Konzepte. GEO (Generative Engine Optimization) ist dabei der Oberbegriff für die Sichtbarkeit in generativen KI-Systemen, während klassisches SEO weiterhin die Grundlage für Auffindbarkeit über Google bleibt. Wer eine strukturierte Dokumentations-SEO betreibt, verbessert damit fast nebenbei auch die Basis für ein internes RAG-System, weil beide dieselben sauber strukturierten Textblöcke lesen.

Die typischen Baustellen: blockierte KI-Crawler und fehlende llms.txt

Drei Probleme tauchen bei Unternehmen mit eigener KI-Strategie immer wieder auf: KI-Crawler werden versehentlich über eine zu strenge robots.txt ausgesperrt, veraltete oder widersprüchliche Inhalte werden trotzdem weiter indexiert, und eine llms.txt fehlt komplett oder ist nur eine Kopie der Sitemap ohne echten Mehrwert.

Zur llms.txt gehört allerdings eine Einschränkung, die in der Praxis oft übersehen wird. Laut der Dokumentation von Google Search Central ist eine eigene KI-Textdatei wie llms.txt für die Sichtbarkeit in der Google-Suche einschließlich ihrer generativen KI-Funktionen nicht nötig, weil Google Search sie nicht auswertet (https://developers.google.com/search/docs/fundamentals/ai-optimization-guide, Stand 10.07.2026). Ob und wie stark GPTBot, PerplexityBot oder ClaudeBot llms.txt tatsächlich berücksichtigen, ist öffentlich nicht einheitlich dokumentiert. Eine ausführliche Anleitung zu llms.txt haben wir bereits im Blog beschrieben.

Rechenbeispiel (hypothetisch): Bei 500 Dokumentationsseiten und einem robots.txt-Fehler, der ClaudeBot vollständig aussperrt, blieben in diesem Modell alle 500 Seiten für dieses eine System unsichtbar, unabhängig von der inhaltlichen Qualität dieser Seiten.

Ausgangslage und Beobachtung: robots.txt-Lücken bei KI-Crawlern

Ausgangslage: Interessant ist, ob Unternehmen mit gepflegter Dokumentation ihre robots.txt konsequent für alle relevanten KI-Bots pflegen, oder ob sie meist nur an den bekanntesten Namen denken.

Naheliegende These: robots.txt-Regeln gelten pro User-Agent, nicht pauschal für „KI-Bots” insgesamt. Wer zuerst GPTBot einträgt, weil dieser Name am bekanntesten ist, lässt ClaudeBot, PerplexityBot oder CCBot damit unter Umständen unbeachtet, denn jeder dieser Bots braucht eine eigene Zeile mit seinem eigenen User-Agent-Namen (siehe Tabelle weiter unten). Bei anderen Websites tritt der gegenteilige Fehler auf: Ein pauschales Disallow für alle Bots sperrt versehentlich auch Crawler aus, die eigentlich erwünscht wären.

Einordnung: Wie stark eine lückenhafte robots.txt die tatsächliche Zitierhäufigkeit in einer bestimmten KI-Anwendung beeinflusst, ist öffentlich nicht belegt. Das GEO-Feld ist jung, und belastbare Kausalketten zwischen Crawler-Zugriff und späterer Zitierung fehlen bislang.

robots.txt je Bot: GPTBot, ClaudeBot, PerplexityBot und Common Crawl steuern

Wer Enterprise-KI und öffentliche KI-Sichtbarkeit gleichzeitig im Blick behalten will, kommt an einer bewussten robots.txt-Konfiguration nicht vorbei. Laut dem Claude Help Center von Anthropic betreibt das Unternehmen drei getrennte Bots mit unterschiedlichem Zweck: ClaudeBot sammelt Trainingsdaten, Claude-User ruft Seiten im Auftrag einzelner Nutzeranfragen ab, Claude-SearchBot dient der Suchfunktion, und jeder lässt sich einzeln über einen eigenen User-Agent-Namen in robots.txt sperren (https://support.claude.com/en/articles/8896518-does-anthropic-crawl-data-from-the-web-and-how-can-site-owners-block-the-crawler).

User-Agent	Betreiber	Zweck
GPTBot	OpenAI	Trainingsdaten
ClaudeBot	Anthropic	Trainingsdaten
Claude-User	Anthropic	Abruf für einzelne Nutzeranfragen
Claude-SearchBot	Anthropic	Claude-Suchfunktion
PerplexityBot	Perplexity	Crawling für den Suchindex
CCBot	Common Crawl	Offenes Web-Archiv, Trainingsdatenquelle mehrerer Modelle
Google-Extended	Google	Steuerungstoken für Gemini-Training

Google-Extended ist dabei ein Sonderfall: Laut der Crawling-Dokumentation von Google handelt es sich um ein eigenständiges Steuerungstoken ohne eigenen Crawler, mit dem sich die Nutzung von Inhalten für das Training von Gemini-Modellen unterbinden lässt, ohne dass dies Ranking oder Aufnahme in die reguläre Google-Suche beeinflusst (https://developers.google.com/crawling/docs/crawlers-fetchers/google-common-crawlers). Für die konkrete Syntax lohnt sich unser Beitrag zu robots.txt für KI-Crawler.

Was das für die interne RAG-Fütterung bedeutet

Aus den bisherigen Punkten lässt sich eine Schlussfolgerung ziehen: Eine Website, die für öffentliche KI-Crawler sauber strukturiert ist, liefert damit auch eine bessere Grundlage für ein internes RAG-System, weil beide auf denselben Prinzipien aufbauen, nämlich klar abgegrenzten Absätzen, eindeutigen Überschriften und aktuellen Inhalten ohne widersprüchliche Parallelversionen. Wer testen will, ob die eigene Struktur für beide Systeme taugt, kann genau das prüfen: Ist jeder Absatz in sich abgeschlossen und auch ohne den Kontext des Nachbarabsatzes verständlich? Genau dieses Kriterium ist auch für die Chunking-Logik eines RAG-Systems relevant, bei der ein einzelner Textabschnitt isoliert an das Sprachmodell übergeben wird.

Strukturierte Daten liefern dafür einen zusätzlichen, gut belegten Hinweis. Laut der Dokumentation von Google Search Central erzielte Rotten Tomatoes durch den Einsatz von strukturierten Daten (schema.org via JSON-LD) 25 Prozent höhere Klickraten, Food Network 35 Prozent mehr Besuche (https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data, 2025). Diese Zahlen stammen aus Googles klassischer Suche, zeigen aber, dass Maschinenlesbarkeit messbare Effekte haben kann, wenn sie sauber umgesetzt ist. Wer diesen Weg konsequent geht, sollte parallel prüfen, ob die eigene llms.txt-Anleitung bereits umgesetzt ist, bevor die interne KI-Anwendung auf denselben Quellen aufsetzt.

Häufig gestellte Fragen

Was ist der Unterschied zwischen RAG und klassischer KI-Suche? RAG (Retrieval Augmented Generation) ist eine Architektur, bei der ein Sprachmodell vor der Antwort passende Textabschnitte aus einer eigenen Datenquelle abruft. Klassische KI-Suchsysteme wie Perplexity oder ChatGPT Search kombinieren dasselbe Prinzip mit einem öffentlichen Web-Index statt mit unternehmenseigenen Dokumenten.

Brauchen wir llms.txt, wenn wir schon robots.txt haben? robots.txt steuert, welche Bots crawlen dürfen, llms.txt soll Inhalte für KI-Systeme zusammenfassen. Laut Google Search Central nutzt Google Search llms.txt nicht, für andere Anbieter ist die tatsächliche Nutzung öffentlich nicht einheitlich dokumentiert. Beide Dateien haben unterschiedliche Funktionen und ersetzen sich nicht gegenseitig.

Blockiert ein Disallow für GPTBot auch ChatGPT-Nutzeranfragen? Nein. OpenAI unterscheidet in seiner Dokumentation zwischen GPTBot für Trainingsdaten und separaten Bots für Live-Suche und Nutzeranfragen. Ein Disallow für GPTBot betrifft nur das Training, nicht zwangsläufig andere Bot-Typen desselben Anbieters.

Wie hängt Enterprise-RAG mit unserer öffentlichen KI-Sichtbarkeit zusammen? Beide Systeme lesen häufig dieselben Ausgangsdokumente, etwa Produktseiten oder technische Dokumentation. Eine saubere Struktur, aktuelle Inhalte und funktionierende robots.txt-Regeln verbessern die Grundlage für beide Anwendungsfälle gleichzeitig, auch wenn sich der konkrete Effekt je nach eingesetztem Modell unterscheiden kann.

**Ergebnis:** Beide beanstandeten Stellen entfernt: der Absatz mit der unbelegten „45 Regeln in vier Kategorien"-Behauptung und der Satz „Das beruht auf eigenen Scans …" sind gestrichen. Die zweite, weiter unten wiederholte Nennung derselben „45 Regeln" habe ich ebenfalls entfernt (Folgesatz-Regel), sonst wäre der Artikel im nächsten Prüflauf wieder durchgefallen.

**Wichtig:** Statt der gestrichenen Passagen steht jetzt eine als These gekennzeichnete Schlussfolgerung, die sich ausschließlich auf bereits im Text belegte Fakten stützt (die Anthropic-Quelle zu den getrennten User-Agent-Namen). Keine neue Quelle, keine neue Zahl ergänzt.

**Offen:** `draft: true` steht weiter im Frontmatter — Freigabe für den nächsten Claim-Gate-Lauf liegt bei dir.