Steuerung der Webcrawler: Robots.txt und Robots-Meta-Tag

Googlebot: Smartphone und Desktop nicht getrennt steuerbar

Google verwendet unterschiedliche HTTP-User-Agents für Smartphone- und Desktop-Crawling. In der robots.txt werden beide jedoch über den Token Googlebot angesprochen.

Du kannst deshalb in der robots.txt nicht festlegen, dass beispielsweise Googlebot Smartphone eine URL crawlen darf, Googlebot Desktop aber nicht.

KI-Crawler gezielt steuern: Training ist nicht Suche

Neben klassischen Suchmaschinen greifen KI-Anbieter mit unterschiedlichen Bots auf öffentliche Webinhalte zu. Entscheidend ist inzwischen nicht mehr nur die Frage, ob ein KI-Anbieter crawlen darf, sondern für welchen Zweck.

Ein Anbieter kann getrennte User-Agents für Modelltraining, Suchindexierung und vom Nutzer ausgelöste Webseitenabrufe einsetzen.

OpenAI: GPTBot und OAI-SearchBot erfüllen unterschiedliche Aufgaben

• GPTBot: crawlt Inhalte, die für das Training generativer Modelle verwendet werden können.
• OAI-SearchBot: dient der Auffindbarkeit von Inhalten in ChatGPT Search.
• ChatGPT-User: kann bei bestimmten direkt vom Nutzer ausgelösten Aktionen auf Webseiten zugreifen. Dieser Zugriff ist nicht mit dem automatischen Crawling für ChatGPT Search gleichzusetzen.

Damit lässt sich beispielsweise das Training ablehnen, ohne die Auffindbarkeit über ChatGPT Search grundsätzlich zu blockieren:

User-agent: GPTBot
Disallow: /

User-agent: OAI-SearchBot
Allow: /

➡️ Das ist für GEO entscheidend: Wer pauschal alle OpenAI-Crawler sperrt, kann damit auch die Chance verringern, dass eigene Inhalte in ChatGPT Search gefunden, zusammengefasst oder als Quelle verlinkt werden.

Anthropic unterscheidet ebenfalls nach Zweck

• ClaudeBot: sammelt öffentliche Webinhalte, die potenziell zur Modellentwicklung und zum Training beitragen können.
• Claude-SearchBot: wird für die Suche und die Verbesserung von Suchergebnissen verwendet.
• Claude-User: dient vom Nutzer ausgelösten Abrufen von Webseiten.

Auch hier kann eine Website Training und Suchzugriff getrennt behandeln:

User-agent: ClaudeBot
Disallow: /

User-agent: Claude-SearchBot
Allow: /

Google-Extended ist ein Sonderfall

Google-Extended ist kein eigenständiger HTTP-Crawler. Es handelt sich um einen robots.txt-Produkt-Token. Damit können Publisher unter anderem steuern, ob bereits von Google gecrawlte Inhalte für das Training zukünftiger Gemini-Modelle sowie für bestimmte Grounding-Anwendungen genutzt werden dürfen.

Ein Disallow für Google-Extended schließt eine Website nicht aus der Google Suche aus und ist kein Ranking-Signal.

Für KI-Funktionen innerhalb der Google Suche – etwa AI Overviews und AI Mode – ist stattdessen der Zugriff des Googlebot maßgeblich. Wie viel Inhalt dort als Vorschau oder direkter Input verwendet werden darf, lässt sich zusätzlich über Preview-Direktiven wie nosnippet, data-nosnippet oder max-snippet steuern.

Merksatz: Training, KI-Suche und klassische Suchindexierung sind technisch nicht dasselbe. Pauschale Bot-Sperren können deshalb unbeabsichtigte Folgen haben.

robots.txt und llms.txt erfüllen unterschiedliche Aufgaben

Mit llms.txt ist ein weiterer Ansatz entstanden, Websites für KI-Agenten leichter verständlich zu machen. Dabei handelt es sich um eine im Root-Verzeichnis abgelegte Markdown-Datei, die wichtige Inhalte und Dokumentationen einer Website strukturiert zusammenfassen kann.

Der entscheidende Unterschied:

• robots.txt = steuert den Zugriff von Crawlern
• XML-Sitemap = hilft beim Auffinden relevanter URLs
• llms.txt = bietet KI-Agenten eine kuratierte Orientierung zu wichtigen Inhalten

Eine einfache Struktur kann beispielsweise so aussehen:

# Beispiel-Website

> Kurze Beschreibung der Website und ihres Schwerpunkts.

## Wichtige Inhalte

- Startseite
- Ratgeber
- Dokumentation
- Häufige Fragen

Wichtig: llms.txt ist weiterhin ein Proposal und keine verbindliche Suchmaschinenrichtlinie. Die Datei ersetzt weder robots.txt noch XML-Sitemaps und garantiert keine bessere Platzierung oder Zitierung in KI-Antworten.

Für GEO kann sie trotzdem interessant sein, weil sie Maschinen eine kompakte und bewusst kuratierte Übersicht über besonders relevante Inhalte anbietet.

IndexNow: Änderungen aktiv an Suchmaschinen melden

Eine XML-Sitemap stellt URLs bereit und wartet darauf, dass Suchmaschinen sie abrufen. IndexNow verfolgt einen anderen Ansatz: Websites können teilnehmende Suchmaschinen aktiv darüber informieren, wenn eine URL neu erstellt, geändert oder gelöscht wurde.

Das bedeutet jedoch nicht, dass eine URL automatisch oder sofort indexiert wird. IndexNow ist zunächst ein Änderungssignal. Die Suchmaschine entscheidet anschließend selbst, ob und wann die URL gecrawlt und indexiert wird.

Besonders relevant ist das für Bing. Bing nennt IndexNow neben XML-Sitemaps, crawlbaren internen Links und externen Links ausdrücklich als Discovery-Signal. Diese technische Grundlage ist nicht nur für die klassische Bing-Suche wichtig, sondern auch für Inhalte, die in Bing- und Copilot-basierten Grounding-Ergebnissen berücksichtigt werden können.

Bing Crawl Control

In den Bing Webmaster Tools lässt sich zusätzlich steuern, wie intensiv Bingbot während einzelner Stunden des Tages crawlen soll. So kann die Belastung während besonders stark frequentierter Zeiten reduziert werden.

Wichtig: Ist für Bingbot zusätzlich eine Crawl-delay-Anweisung in der robots.txt gesetzt, hat diese gegenüber der Einstellung in Crawl Control Vorrang.

Warum Webcrawler über deine Sichtbarkeit entscheiden?

Die Steuerung von Webcrawlern beeinflusst direkt, wie Suchmaschinen und KI-Systeme deine Website verstehen, priorisieren und darstellen.

• Crawl-Budget: Besonders bei großen Websites entscheidet die robots.txt, welche Inhalte bevorzugt gecrawlt werden.
• Indexierung: Über Meta-Tags steuerst du gezielt, welche Seiten in den Suchergebnissen erscheinen.
• KI-Sichtbarkeit: Suchcrawler von KI-Anbietern benötigen technischen Zugriff auf deine Inhalte, wenn diese zuverlässig gefunden und verarbeitet werden sollen.
• Technische SEO: Tools wie Screaming Frog oder die Google Search Console helfen dir, Crawling- und Indexierungsprobleme frühzeitig zu erkennen.

Warum Crawler-Regeln für Query Fan-Out entscheidend sind

Moderne Suchsysteme zerlegen Anfragen in mehrere Teilfragen, um komplexe Themen besser zu verstehen. Dieser Prozess wird oft als Query Fan-Out bezeichnet.

Damit deine Inhalte in diesen Prozessen berücksichtigt werden können, müssen sie technisch erreichbar, sauber strukturiert und für die jeweiligen Such- oder Retrieval-Systeme zugänglich sein.

• Sauberes Crawling: Suchmaschinen und KI-Systeme können Inhalte vollständig erfassen
• Klare Indexierung: relevante Seiten werden gezielt priorisiert
• Content-Cluster: zusammenhängende Themen lassen sich korrekt miteinander verknüpfen

Eine fehlerhafte robots.txt oder falsch gesetzte noindex-Anweisungen können dazu führen, dass wichtige Inhalte nicht als mögliche Quelle zur Verfügung stehen. Damit schwächst du unter Umständen ganze Themen-Cluster.

JavaScript SEO: Google rendert – viele KI-Crawler nicht

Bei modernen Websites reicht es nicht immer aus, nur zu prüfen, ob eine URL gecrawlt werden darf. Entscheidend ist auch, ob der eigentliche Inhalt bereits im ausgelieferten HTML vorhanden ist oder erst durch JavaScript im Browser erzeugt wird.

So verarbeitet Google JavaScript

Google beschreibt die Verarbeitung von JavaScript-Seiten heute in drei Hauptphasen:

1. Crawling: Googlebot lädt zunächst die URL und wertet die ursprüngliche HTML-Antwort aus.
2. Rendering: Seiten mit HTTP-Status 200 werden in eine Rendering-Warteschlange gestellt. Der Web Rendering Service nutzt eine Headless-Version von Chromium und führt JavaScript aus.
3. Indexierung: Google verarbeitet anschließend auch das gerenderte HTML und die darin erkannten Inhalte und Links.

Die Rendering-Warteschlange kann nur wenige Sekunden benötigen, bei knappen Ressourcen aber auch länger. Deshalb ist die früher häufig verwendete Vorstellung von exakt zwei klar getrennten „Crawling-Wellen“ zu stark vereinfacht.

Warum reines Client-Side Rendering für KI-Sichtbarkeit riskant ist

Google kann JavaScript rendern. Das gilt aber nicht automatisch für jeden KI-Crawler. Viele automatisierte KI-Crawler arbeiten deutlich einfacher und verlassen sich vor allem auf das HTML, das ihnen der Server direkt liefert.

Wird der eigentliche Text einer Seite ausschließlich durch Client-Side JavaScript erzeugt, kann deshalb eine paradoxe Situation entstehen:

• Google kann die Inhalte nach dem Rendering erkennen.
• Ein KI-Crawler sieht möglicherweise nur ein nahezu leeres HTML-Gerüst.

Für SEO und GEO ergibt sich daraus eine klare Empfehlung: Zentrale Inhalte, Hauptüberschriften, wichtige interne Links und entscheidende Informationen sollten möglichst bereits serverseitig im HTML verfügbar sein. Server-Side Rendering, Static Site Generation oder geeignetes Prerendering sind für unterschiedliche Crawler robuster als reines Client-Side Rendering.

Googlebot: 2-MB-Grenze pro Ressource

Auch Google rendert nicht unbegrenzt. Googlebot ruft bei unterstützten Dateitypen derzeit maximal die ersten 2 MB unkomprimierter Daten pro Ressource ab. Das gilt nicht nur für eine HTML-Datei: Auch jede separat referenzierte CSS- oder JavaScript-Ressource unterliegt diesem Grenzwert.

Wird die Grenze erreicht, beendet Googlebot den Abruf und verarbeitet nur den bereits heruntergeladenen Teil.

Achtung: Daraus folgt nicht, dass eine Website insgesamt nur 2 MB JavaScript verwenden darf. Das Limit gilt für den jeweiligen einzelnen Ressourcenabruf.

Mehr als index und noindex: Snippets und KI-Vorschauen steuern

Robots-Meta-Tags können nicht nur bestimmen, ob eine Seite indexiert wird. Sie erlauben auch eine deutlich feinere Steuerung darüber, wie Inhalte in Suchergebnissen und bestimmten KI-Funktionen von Google verwendet oder dargestellt werden dürfen.

Beispiel für eine Kombination:

<meta name="robots" content="max-snippet:160, max-image-preview:large" />

Ein bestimmter Abschnitt lässt sich außerdem gezielt von Snippets ausschließen:

<div data-nosnippet>
Dieser Text soll nicht als Google-Snippet verwendet werden.
</div>

Für GEO besonders relevant: Mit diesen Direktiven steuerst du nicht nur die klassische Darstellung in Google. Einige davon beeinflussen ausdrücklich auch, wie viel Inhalt als direkter Input in Googles KI-Funktionen verwendet werden darf.

Praxis-Tipp aus dem SEO-Alltag

In der Praxis sehe ich häufig, dass wichtige Seiten versehentlich durch robots.txt oder noindex blockiert werden – besonders nach Relaunches oder bei Testumgebungen.

Ein typischer Fehler: Eine Seite wird zunächst auf noindex gesetzt und anschließend zusätzlich per robots.txt gesperrt. Dadurch kann Google das noindex-Signal nicht mehr auslesen – die Seite bleibt im Index.

Ich empfehle daher, jede Änderung zusätzlich mit der Google Search Console zu prüfen und regelmäßig mit SEO-Crawlern wie Screaming Frog zu analysieren.

Profi-Workflow zur Kontrolle deiner Einstellungen

• Google Search Console: Indexierungsstatus prüfen und Fehler erkennen
• Screaming Frog: Crawling simulieren und blockierte Inhalte identifizieren
• robots.txt-Test: Regeln gezielt validieren
• Logfile-Analyse: tatsächliches Bot-Verhalten auswerten
• HTML-Prüfung: kontrollieren, ob zentrale Inhalte bereits im Server-HTML vorhanden sind
• User-Agent-Prüfung: unterscheiden, ob Training-, Such- oder User-Fetch-Bots zugreifen

In der Praxis zeigt sich: Erst die Kombination aus Tools liefert ein vollständiges Bild deiner Crawler-Steuerung.

Häufige Fragen zu robots.txt, Robots-Meta-Tag und noindex

Checkliste: Webcrawler richtig steuern

• robots.txt korrekt im Root-Verzeichnis hinterlegt
• robots.txt als UTF-8-Textdatei ausgeliefert
• robots.txt deutlich unter dem 500-KiB-Limit gehalten
• keine wichtigen Seiten blockiert
• noindex nur gezielt eingesetzt
• Seiten für noindex weiterhin crawlbar
• XML-Sitemap hinterlegt
• KI-Crawler nicht pauschal behandelt, sondern nach Zweck geprüft
• Trainingscrawler und KI-Suchcrawler bewusst erlaubt oder ausgeschlossen
• Google-Extended nicht mit Google Search oder AI Overviews verwechselt
• zentrale Inhalte bereits im HTML verfügbar
• keine wichtigen CSS- oder JS-Dateien blockiert
• große HTML-, CSS- und JavaScript-Ressourcen auf Crawling-Grenzen geprüft
• Preview-Direktiven wie max-snippet oder data-nosnippet bewusst eingesetzt
• IndexNow bei häufig aktualisierten Inhalten geprüft
• Crawl-Budget auf relevante Inhalte fokussiert
• regelmäßige Prüfung mit Search Console und SEO-Tools
• Logfiles auf tatsächliche Google-, Bing- und KI-Bot-Zugriffe geprüft

Diese Checkliste hilft dir dabei, technische SEO-Fehler zu vermeiden und deine Inhalte sowohl für klassische Suchmaschinen als auch für KI-Suchsysteme gezielt zugänglich zu machen.

Fazit: So stimmt die Konfiguration