GPTBot & Co.: Ist Ihre Website für KI-Crawler lesbar?

Die erste Hürde auf dem Weg in eine KI-Antwort ist unspektakulär: Der Crawler des KI-Anbieters muss Ihre Seite abrufen und den Text darin finden. An dieser Hürde scheitern Websites, die für Besucher und für Google einwandfrei funktionieren. Dieser Artikel erklärt, woran das liegt und wie Sie es prüfen.

Warum ist JavaScript für KI-Crawler ein Problem?

Viele moderne Websites liefern zunächst ein Gerüst aus und laden die eigentlichen Inhalte anschließend per JavaScript nach. Für den Besucher im Browser ist das unsichtbar, die Seite erscheint vollständig. Ein Crawler, der kein JavaScript ausführt, sieht nur das Gerüst: Menü, Fußzeile, Platzhalter. Der Text, um den es geht, fehlt.

Googlebot führt JavaScript aus und kann solche Seiten mit Verzögerung verarbeiten. KI-Crawler wie GPTBot oder PerplexityBot tun das nach allem, was bekannt ist, nicht oder nur eingeschränkt. Eine Website, die in der Google-Suche gut abschneidet, kann für KI-Systeme deshalb praktisch leer sein. Der Betreiber merkt davon nichts, weil kein Werkzeug ihn darauf hinweist.

Welche KI-Crawler gibt es?

Die großen Anbieter betreiben eigene Crawler mit eigenen Kennungen. Über diese Kennungen lassen sie sich in der robots.txt gezielt zulassen oder ausschließen. Die Unterscheidung nach Zweck ist dabei wichtig, weil nicht jeder Crawler dieselbe Aufgabe hat.

Google-Extended und Applebot-Extended sind keine eigenständigen Crawler, sondern Steuerkennungen. Der Abruf erfolgt weiter über Googlebot beziehungsweise Applebot; die Kennung regelt nur, wofür die Inhalte verwendet werden dürfen. Nach Googles eigener Angabe wirkt Google-Extended nicht auf die Darstellung in der Google-Suche.

Sperrt Ihre robots.txt KI-Crawler aus?

Die robots.txt ist eine Textdatei im Hauptverzeichnis der Website, erreichbar unter der Adresse Ihrer Domain mit angehängtem /robots.txt. Sie enthält Anweisungen, welche Crawler welche Bereiche abrufen dürfen. Manche Hosting-Anbieter, Sicherheits-Plugins und Agenturen haben in den vergangenen Jahren Einträge ergänzt, die KI-Crawler pauschal ausschließen, teils ohne Rücksprache mit dem Betreiber.

Prüfen Sie die Datei auf folgende Muster.

• Eine Zeile User-agent: GPTBot oder mit einer anderen Kennung aus der Tabelle, gefolgt von Disallow: /. Das sperrt den genannten Crawler vollständig aus.
• Eine Zeile User-agent: * gefolgt von Disallow: /. Das sperrt alle Crawler, auch Google, und deutet auf eine vergessene Einstellung aus der Entwicklungsphase hin.
• Sperren einzelner Verzeichnisse, in denen Ihre Inhalte liegen, etwa ein Blog- oder Ratgeberpfad.

Ob Sie KI-Crawler zulassen, ist eine Entscheidung, die Sie bewusst treffen sollten. Wer Sichtbarkeit in KI-Antworten anstrebt, muss zumindest die Crawler zulassen, die für die Suche zuständig sind, etwa OAI-SearchBot und PerplexityBot. Eine Sperre für Trainingszwecke bei gleichzeitiger Freigabe für die Suche ist über die getrennten Kennungen möglich.

Wie prüfen Sie, ob Ihr Text im Quelltext steht?

Ein einfacher Test kommt ohne Werkzeuge aus. Öffnen Sie eine Ihrer Inhaltsseiten im Browser und lassen Sie sich den Quelltext anzeigen, meist über einen Rechtsklick und den Punkt Seitenquelltext anzeigen. Suchen Sie darin nach einem Satz aus dem Fließtext Ihrer Seite. Steht der Satz im Quelltext, ist er serverseitig gerendert und für Crawler lesbar. Fehlt er, wird er per JavaScript nachgeladen.

Ein zweiter Test: Schalten Sie JavaScript im Browser ab und laden Sie die Seite neu. Was dann noch sichtbar ist, entspricht ungefähr dem, was ein KI-Crawler sieht. Bleibt die Seite leer oder zeigt nur Ladeanimationen, besteht Handlungsbedarf. Wie Inhalte gestaltet sein sollten, damit sie nach dem Crawling auch verwendet werden, beschreibt der Artikel Zitierfähige Inhalte schreiben.

Was bedeutet serverseitiges Rendering?

Serverseitiges Rendering heißt, dass der Server die fertige HTML-Seite mit allen Texten ausliefert, statt dem Browser nur ein Programm zu schicken, das die Seite erst aufbaut. Klassische Systeme wie WordPress oder statische Website-Generatoren arbeiten so. Moderne JavaScript-Frameworks bieten ebenfalls einen serverseitigen Modus, der aber aktiv eingerichtet werden muss.

Für die Zugänglichkeit ist es unerheblich, welches System eingesetzt wird, solange der Text im ausgelieferten HTML steht. Eine Umstellung betrifft in der Regel die Konfiguration oder den Bauprozess der Website, nicht deren Gestaltung. Wo das nicht möglich ist, kann eine vorgerenderte Version der Inhaltsseiten eine Zwischenlösung sein.

Ist llms.txt sinnvoll?

Die Datei llms.txt ist ein Vorschlag, KI-Systemen im Hauptverzeichnis der Website eine kompakte Übersicht der wichtigsten Inhalte in Textform anzubieten. Sie ist optional und kein Standard, den die großen Anbieter verbindlich unterstützen. Google gibt an, llms.txt nicht zu verwenden. Ob andere Systeme sie auswerten, ist nach unserem Stand nicht belastbar dokumentiert.

Eine llms.txt schadet nicht und ist schnell angelegt. Sie ersetzt aber keine der oben genannten Maßnahmen. Wer serverseitig gerenderten Text und eine offene robots.txt hat, hat die eigentliche Arbeit getan; llms.txt ist ein Zusatz, dessen Wirkung ungewiss bleibt.

Was das für Vorarlberger Betriebe heißt

Manche Websites von Vorarlberger Betrieben sind in den vergangenen Jahren mit modernen Frameworks neu gebaut worden, andere setzen Sicherheits-Plugins ein, die KI-Crawler standardmäßig sperren können. Beides ist für Besucher unsichtbar und für KI-Systeme entscheidend. Die Prüfung dauert wenige Minuten und gehört an den Anfang jeder Überlegung zu GEO, weil ohne sie alle weiteren Schritte ins Leere laufen. Die Gegenüberstellung mit der klassischen Suche findet sich im Artikel GEO vs. SEO.

Ein KI-Sichtbarkeits-Audit beginnt mit genau dieser Prüfung und dokumentiert, welche Crawler Ihre Seite lesen können und welche Inhalte dabei ankommen. Die Umsetzung technischer Änderungen ist Teil der GEO-Optimierung.