---
title: AI-Crawler, robots.txt und Content-Signale — isla Studio
url: https://isla-stud.io/en/ai-visibility/ai-crawler-robots-txt-content-signale/
date: 2026-06-18
---

# AI-Crawler, robots.txt und Content-Signale

Stand: Juni 2026. Sobald Websitebetreiber:innen von AI-Crawlern hören, passiert oft eine von zwei Sachen: Entweder wird alles sofort blockiert, weil „die KI ja nicht einfach alles klauen soll“. Oder alles bleibt offen, weil Sichtbarkeit irgendwie gut klingt. Beides ist zu grob.



Der bessere Weg ist weniger dramatisch und deutlich nützlicher: Verstehe zuerst, welcher Bot was tut. Suche, Training, user-getriggerter Abruf, Ads-Prüfung, Testing-Tool und Audit-Crawl sind nicht dasselbe. Wer alles in einen Topf wirft, baut sich entweder unnötig Sichtbarkeit weg oder lässt Dinge offen, die eigentlich kontrolliert gehören.



Inhaltsverzeichnis



Die Kurzfassung




robots.txt steuert Crawling, nicht automatisch Sichtbarkeit. Eine blockierte URL kann trotzdem in Suchergebnissen auftauchen, wenn sie von außen verlinkt wird.
robots.txt ist kein Datenschutzschild. Private Inhalte gehören hinter Login, Passwortschutz oder auf nicht öffentliche Systeme, nicht nur in eine Disallow-Regel.
AI-Crawler haben unterschiedliche Aufgaben. Search-Bots, Training-Bots und user-getriggerte Fetches müssen getrennt bewertet werden.
Google-Extended ist kein eigener sichtbarer Crawler. Es ist ein Steuer-Token in robots.txt und betrifft laut Google Gemini-Training und Grounding, nicht Google Search Ranking.
Wer Search-Bots blockiert, kann AI-Sichtbarkeit verlieren. Wer Training-Bots erlaubt, trifft eine andere Entscheidung. Genau diese Trennung ist wichtig.
Content-Signale bleiben entscheidend. Klare Inhalte, gute Struktur, saubere Schema-Daten, Sitemaps, interne Links und maschinenlesbare Fassungen helfen mehr als panisches Bot-Bingo.




Meine Empfehlung: Behandle robots.txt wie einen Türhinweis, nicht wie einen Tresor. Für Sichtbarkeit brauchst du Zugänglichkeit und gute Signale. Für Schutz brauchst du echte Zugriffskontrolle. Das sind zwei verschiedene Baustellen.



Was robots.txt wirklich macht



Die Datei robots.txt liegt im Root deiner Website, also zum Beispiel unter https://example.com/robots.txt. Seriöse Crawler lesen sie, bevor sie Seiten abrufen. Dort steht, welche Bereiche ein bestimmter User-Agent crawlen darf und welche nicht.



Google beschreibt robots.txt sehr nüchtern: Die Datei sagt Suchmaschinen-Crawlern, welche URLs sie abrufen dürfen. Hauptzweck ist die Steuerung von Crawler-Traffic, damit Server nicht unnötig belastet werden. Sie ist nicht dafür gedacht, Webseiten aus Google herauszuhalten.



Das klingt klein, ist aber die halbe Miete. robots.txt ist eine Crawling-Regel. Sie beantwortet die Frage: „Darf dieser Bot diese URL abrufen?“ Sie beantwortet nicht automatisch: „Darf diese URL in Suchergebnissen erscheinen?“ Und sie beantwortet schon gar nicht: „Ist dieser Inhalt privat?“



Was robots.txt nicht macht



Der häufigste Fehler ist die Verwechslung von nicht crawlen, nicht indexieren, nicht anzeigen und nicht verwenden. Das sind unterschiedliche Ziele.




Nicht crawlen: Ein Bot soll eine URL nicht abrufen. Dafür ist robots.txt gedacht.
Nicht indexieren: Eine URL soll nicht in Suchergebnissen erscheinen. Dafür brauchst du in der Regel noindex oder echte Entfernung.
Nicht öffentlich zugänglich sein: Ein Inhalt soll privat bleiben. Dafür brauchst du Login, Passwortschutz, Rechteprüfung oder eine nicht öffentliche Ablage.
Nicht für Training genutzt werden: Dafür haben manche Anbieter eigene User-Agent-Tokens, zum Beispiel GPTBot, ClaudeBot oder Google-Extended.
Nicht in AI Search erscheinen: Dafür sind bei einigen Anbietern Search-Bots relevant, zum Beispiel OAI-SearchBot, Claude-SearchBot oder PerplexityBot.




Besonders tückisch: Wenn du eine Seite per robots.txt blockierst, kann Google laut eigener Dokumentation die URL trotzdem finden, wenn andere Seiten darauf verlinken. Dann steht die URL unter Umständen ohne Snippet in den Suchergebnissen. Das ist meist nicht das, was Websitebetreiber:innen wollten.



Wenn etwas wirklich nicht öffentlich sein soll, gehört es nicht nur in robots.txt. Dann gehört es hinter eine Zugriffskontrolle. Punkt. robots.txt ist ein Hinweis an höfliche Crawler, kein Sicherheitssystem.



Vier Fälle, die man sauber trennen muss



Für AI Visibility ist die Unterscheidung der Bot-Zwecke inzwischen wichtiger als der einzelne Bot-Name. Praktisch gibt es vier Fälle:



FallWorum es gehtTypische EntscheidungSearch-CrawlerInhalte werden für Such- oder Antwortoberflächen gefunden und verlinkt.Für öffentliche, wichtige Inhalte meistens erlauben.Training-CrawlerInhalte können für Modelltraining oder Modellverbesserung gesammelt werden.Bewusst entscheiden, oft restriktiver als Search.User-getriggerter FetchEin Mensch bittet ein KI-System, eine konkrete URL oder Quelle abzurufen.Nicht reflexhaft blockieren, aber sensible Bereiche schützen.Tool-, Audit- oder Produkt-CrawlerEin Dienst prüft, rendert, testet oder analysiert Seiten im Auftrag.Nur erlauben, wenn Zweck und Quelle plausibel sind.



Genau hier wird es 2026 interessanter als früher. Früher war robots.txt für viele WordPress-Websites vor allem ein SEO-Nebenschauplatz. Heute kann dieselbe Datei beeinflussen, ob Inhalte in ChatGPT Search, Claude-Suche, Perplexity oder Gemini-nahen Funktionen besser auffindbar sind, ob sie für Training freigegeben werden und ob WAFs legitime AI-Bots versehentlich aussperren.



Googlebot, Google-Extended und Google-CloudVertexBot



Bei Google ist die Unterscheidung besonders wichtig, weil viele Debatten hier erstaunlich unscharf laufen.



Googlebot ist der klassische Google-Crawler für Google Search. Regeln für Googlebot betreffen laut Google die Google-Suche einschließlich Search-Features sowie weitere Oberflächen wie Discover, Google Images, Google Video und Google News. Wer Googlebot pauschal blockiert, blockiert also nicht „nur KI“, sondern die normale Google-Sichtbarkeit gleich mit.



Google-Extended ist etwas anderes. Google-Extended hat laut Google keinen eigenen HTTP-User-Agent. Gecrawlt wird mit bestehenden Google-User-Agents; Google-Extended ist ein robots.txt-Token zur Steuerung. Es soll Publishern ermöglichen, zu kontrollieren, ob bereits von Google gecrawlte Inhalte für das Training zukünftiger Gemini-Modelle und für Grounding in Gemini Apps und Vertex AI genutzt werden dürfen. Google schreibt außerdem ausdrücklich, dass Google-Extended weder die Aufnahme in Google Search beeinflusst noch als Ranking-Signal in Google Search verwendet wird.



Google-CloudVertexBot betrifft nach Googles Dokumentation Crawls, die Websitebetreiber:innen für den Aufbau von Vertex-AI-Agents anstoßen. Auch das hat keinen Effekt auf Google Search. Wenn eine Organisation eigene Agenten mit Vertex AI baut, kann dieser Bot relevant sein. Für den normalen WordPress-Blog ist er erst einmal nicht der Schalter, an dem man seine Google-Sichtbarkeit festmacht.



Der praktische Take: Google ist nicht ein einziger KI-Schalter. Googlebot, Google-Extended und Google-CloudVertexBot haben unterschiedliche Bedeutungen. Wer hier aus Ärger pauschal alles dichtmacht, trifft nebenbei Entscheidungen über klassische Suche, Bilder, News, Gemini-Nutzung und Agenten-Workflows. Das sollte man nicht im Vorbeigehen erledigen.



OpenAI: OAI-SearchBot, GPTBot und ChatGPT-User



OpenAI trennt die Zwecke in der eigenen Crawler-Dokumentation vergleichsweise klar.




OAI-SearchBot: für ChatGPT Search. Wer diesen Bot blockiert, kann laut OpenAI aus ChatGPT-Suchantworten herausfallen, auch wenn Navigationslinks weiter möglich sein können.
GPTBot: für Inhalte, die für Training generativer Foundation Models genutzt werden können. Ein Disallow für GPTBot signalisiert, dass Inhalte nicht fürs Training verwendet werden sollen.
ChatGPT-User: für bestimmte Nutzeraktionen in ChatGPT und Custom GPTs. Diese Abrufe sind user-getriggert, nicht automatisches Web-Crawling. OpenAI weist deshalb darauf hin, dass robots.txt-Regeln hier nicht immer greifen.




Das ist für Websitebetreiber:innen eine ziemlich wichtige Trennung. Du kannst zum Beispiel sagen: Ich möchte in ChatGPT Search auffindbar sein, aber meine Inhalte nicht für Training freigeben. Dann wäre ein mögliches Muster: OAI-SearchBot erlauben, GPTBot blockieren. Ob das strategisch richtig ist, hängt von deiner Website, deinen Inhalten und deiner Risikohaltung ab. Aber wenigstens ist es eine präzise Entscheidung.



Was du vermeiden solltest: alle OpenAI-User-Agents in einem Atemzug blockieren und dich danach wundern, warum deine öffentliche Expertise in ChatGPT Search nicht auftaucht. Man kann nicht gleichzeitig „Bitte finde mich“ und „Bitte ruf mich nie ab“ sagen und erwarten, dass daraus verlässliche Sichtbarkeit entsteht.



Claude, Perplexity und andere AI-Crawler



Anthropic beschreibt für Claude ebenfalls mehrere Bots: ClaudeBot für Modelltraining beziehungsweise Modellverbesserung, Claude-SearchBot für Suchqualität und Claude-User für user-getriggerte Abrufe. Laut Anthropic kann das Blockieren von Claude-SearchBot die Sichtbarkeit und Genauigkeit in Claude-Suchergebnissen verringern. Das Blockieren von ClaudeBot signalisiert dagegen, dass künftige Inhalte nicht in Trainingsdatensätze aufgenommen werden sollen.



Perplexity trennt PerplexityBot für Search und Perplexity-User für Nutzeraktionen. Zusätzlich weist Perplexity darauf hin, dass WAF-Regeln nicht nur stumpf auf User-Agent-Strings prüfen sollten, sondern idealerweise auch offizielle IP-Ranges berücksichtigen. Das ist ein Detail, aber ein wichtiges: User-Agent-Strings kann jeder behaupten. Für seriöse Bot-Steuerung reichen hübsche Namen im Log nicht aus.



Und dann gibt es noch viele weitere Abrufe: SEO-Tools, Monitoring-Dienste, Preview-Bots, Social-Bots, Sicherheitscanner, betrügerische Scraper, interne Crawler, Hosting-Checks. Nicht jeder Bot mit „AI“ im Namen ist strategisch wichtig. Nicht jeder unbekannte Bot ist harmlos. Die Aufgabe ist also nicht, eine gigantische Liste auswendig zu lernen, sondern die eigenen Ziele sauber zu formulieren.



Content-Signale statt Reflex-Blockade



In AI Visibility geht es nicht nur darum, wer crawlen darf. Es geht auch darum, was ein System vorfindet, wenn es crawlt. Eine Website kann technisch offen sein und trotzdem schlecht verständlich. Dann ist sie wie ein Laden mit offener Tür, aber ohne Beschriftung, Preisschilder und Licht. Sehr frei zugänglich, sehr wenig hilfreich.



Google schreibt in der eigenen Anleitung zu generativer AI Search, dass grundlegende SEO-Arbeit weiter zählt: hilfreiche, einzigartige, gut organisierte Inhalte, die nicht nur recyceln, was ohnehin überall steht. Genau dort sitzt der Hebel. AI-Systeme brauchen nicht nur Zugriff, sondern verwertbare Signale.




Klare Seitenstruktur: sprechende Titel, sinnvolle Zwischenüberschriften, nachvollziehbare Absätze.
Saubere Entitäten: Wer ist die Person, Organisation, Marke, Dienstleistung oder das Produkt?
Zitierfähige Aussagen: konkrete Antworten, klare Definitionen, Daten, Beispiele und Grenzen.
Aktualität: sichtbare Veröffentlichungs- und Änderungsdaten, gepflegte Inhalte, keine Zombie-Ratgeber aus 2018.
Schema-Daten: nicht als Ranking-Magie, sondern als maschinenlesbare Verbindung zwischen Inhalt, Autor:in, Organisation und Produkt.
Sitemaps: damit wichtige Inhalte auffindbar bleiben und nicht in Archiv-Gewirr verschwinden.
Interne Links: Cluster, Pillar, FAQ, Produktseiten und Ratgeber sollen sich gegenseitig erklären.
Maschinenlesbare Fassungen: llms.txt, Markdown oder andere reduzierte Ausgaben können Kontext liefern. Sie ersetzen aber keine Zugriffspolitik.




Das ist auch die Brücke zum vorherigen Artikel über Schema, Entitäten und zitierfähige Inhalte. Wenn eine Maschine crawlen darf, aber nur widersprüchliche Signale findet, ist wenig gewonnen. Wenn sie crawlen darf und saubere Signale findet, wird aus Zugriff wenigstens eine verwertbare Chance.



WordPress-Checkliste



Für WordPress-Websites würde ich pragmatisch so vorgehen:




Öffentliche Ziele klären: Welche Inhalte sollen in Google, ChatGPT Search, Claude, Perplexity und anderen Antwortsystemen auffindbar sein?
Private Inhalte wirklich schützen: Kundendaten, interne Unterlagen, Staging-Bereiche und nicht freigegebene Downloads gehören hinter Login oder Passwortschutz, nicht nur in robots.txt.
Training separat entscheiden: Willst du Training-Crawler erlauben, blockieren oder differenziert behandeln?
Search-Bots nicht versehentlich aussperren: Wenn AI Search ein Ziel ist, prüfe, ob Search-Bots wie OAI-SearchBot, Claude-SearchBot oder PerplexityBot erreichbar sind.
Googlebot nicht beschädigen: Blockiere nicht pauschal Googlebot, wenn normale Google-Sichtbarkeit wichtig ist.
CSS, JavaScript und Bilder nicht unnötig blockieren: Wenn eine Seite ohne Ressourcen schwer verständlich wird, erschwerst du auch die maschinelle Einordnung.
noindex gezielt einsetzen: Tag-Archive, dünne Suchseiten, interne Danke-Seiten und doppelte Inhalte lieber sauber noindexieren als halbherzig per robots.txt verstecken.
Sitemaps prüfen: Sind wichtige Beiträge, Seiten, Produkte, Kategorien und Medien korrekt enthalten? Sind unwichtige Bereiche draußen?
Schema prüfen: Gibt es mehrere SEO-Plugins, Shop-Plugins oder AI-Plugins, die konkurrierende JSON-LD-Graphen ausgeben?
Logs beobachten: Welche Bots kommen wirklich? Welche werden durch Firewall, Cache, Security-Plugin oder Hosting-Regeln blockiert?
llms.txt und Markdown einordnen: Nutze sie als Kontext- und Orientierungsschicht, nicht als Rechteverwaltung.
Änderungen dokumentieren: robots.txt-Regeln können Sichtbarkeit beeinflussen. Deshalb gehören sie in ein Änderungsprotokoll, nicht in einen spontanen Freitagabend-Anfall.




Ein sinnvolles robots.txt-Beispiel



Das hier ist kein Universalskript zum Kopieren, sondern ein Denkbeispiel. Für viele öffentliche Ratgeber-, Dienstleistungs- oder Produkt-Websites kann eine differenzierte Struktur sinnvoller sein als „alles auf“ oder „alles zu“.



User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: OAI-SearchBot
Allow: /

User-agent: Claude-SearchBot
Allow: /

User-agent: PerplexityBot
Allow: /

Sitemap: https://example.com/sitemap_index.xml



Was dieses Beispiel ausdrückt: Klassisches Crawling und Search-Bots dürfen öffentliche Inhalte finden. Training-Tokens werden restriktiver behandelt. Ob das für deine Website richtig ist, hängt davon ab, was du veröffentlichst. Eine Fotografin, ein juristischer Fachverlag, ein SaaS-Anbieter, ein WooCommerce-Shop und ein lokaler Handwerksbetrieb haben nicht automatisch dieselbe Bot-Politik.



Wichtig ist außerdem: Manche Anbieter unterscheiden zwischen automatischem Crawling und user-getriggerten Abrufen. Genau deshalb ist robots.txt nicht die einzige Steuerungsschicht. WAF-Regeln, IP-Verifikation, Login-Schutz, Consent- und Datenschutzfragen, Serverlogs und Content-Strategie gehören mit an den Tisch.



Wie ich das mit citelayer® denke



Aus meiner citelayer® AI Visibility Audit-Perspektive ist robots.txt nur ein Teil der Diagnose. Ich möchte nicht nur wissen, ob ein Bot theoretisch darf. Ich möchte wissen, was praktisch passiert: Kommen relevante Bots an? Werden sie durch Firewall-Regeln blockiert? Sehen sie die richtigen Inhalte? Stimmen Sitemap, Schema, Canonicals, interne Links, llms.txt und sichtbarer Inhalt zusammen?



Gerade bei WordPress sehe ich oft kein einzelnes großes Problem, sondern viele kleine Widersprüche: SEO-Plugin sagt A, Shop-Plugin sagt B, Security-Plugin blockiert C, Cache liefert D, und in der robots.txt steht noch ein alter Eintrag aus einer längst vergessenen Migration. Das ist nicht spektakulär. Es ist nur leider genau die Sorte Durcheinander, an der maschinelle Einordnung scheitert.



citelayer® für WordPress schließt genau diese Lücke zwischen klassischem SEO-Plugin und AI Visibility: maschinenlesbare Kontextschichten, llms.txt, Schema-Kontext, Bot-Signale und eine bessere Grundlage für Audits. Aber auch hier gilt: Ein Plugin kann Struktur liefern. Die strategische Entscheidung, welche Inhalte sichtbar, zitierfähig, geschützt oder vom Training ausgenommen sein sollen, bleibt redaktionell und geschäftlich.



FAQ



Soll ich alle AI-Crawler blockieren?



Nicht pauschal. Wenn du in AI Search sichtbar sein willst, solltest du Search-Crawler nicht reflexhaft aussperren. Training-Crawler kannst du separat bewerten. Private Inhalte gehören unabhängig davon hinter echte Zugriffskontrolle.



Ist robots.txt rechtlich bindend?



robots.txt ist ein technischer Standard beziehungsweise eine Konvention für Crawler-Verhalten, kein Tresor und keine Rechtsberatung. Seriöse Crawler respektieren die Regeln. Andere können sie ignorieren. Wenn rechtliche Fragen wichtig sind, brauchst du zusätzlich juristische Prüfung und echte technische Schutzmaßnahmen.



Was ist der Unterschied zwischen GPTBot und OAI-SearchBot?



OpenAI beschreibt GPTBot als Crawler für Inhalte, die für Training generativer Foundation Models genutzt werden können. OAI-SearchBot ist dagegen für ChatGPT Search gedacht. Du kannst also theoretisch Search erlauben und Training blockieren.



Beeinflusst Google-Extended mein Google-Ranking?



Laut Google nein. Google-Extended beeinflusst nach Googles Dokumentation weder die Aufnahme in Google Search noch das Ranking in Google Search. Es steuert, ob von Google gecrawlte Inhalte für bestimmte Gemini- und Vertex-AI-Nutzungen verwendet werden dürfen.



Ersetzt llms.txt meine robots.txt?



Nein. robots.txt steuert Crawling-Regeln. llms.txt ist eine Orientierungsschicht für KI-Systeme und Agenten: wichtige Seiten, Kontext, Zusammenfassungen, maschinenlesbare Einstiegspunkte. Das eine sagt eher „wo darfst du hin?“, das andere eher „das ist hier wichtig“.



Warum sollte ich Bot-Logs prüfen?



Weil robots.txt nur deine Absicht zeigt. Logs zeigen, was wirklich passiert: Welche Bots kommen, welche URLs rufen sie ab, welche Statuscodes bekommen sie, welche Firewall-Regeln greifen und welche wichtigen Inhalte nie erreicht werden.



Quellen und Verifikation




Google Search Central: Introduction to robots.txt und Grenzen von robots.txt.
Google Crawling Infrastructure: Google’s common crawlers, insbesondere Googlebot, Google-CloudVertexBot und Google-Extended.
Google Search Central: Optimizing for generative AI features on Google Search.
OpenAI: Overview of OpenAI Crawlers mit OAI-SearchBot, GPTBot und ChatGPT-User.
Anthropic Help Center: Does Anthropic crawl data from the web? mit ClaudeBot, Claude-SearchBot und Claude-User.
Perplexity Docs: Perplexity Crawlers mit PerplexityBot und Perplexity-User.
Eigene citelayer®-Audit- und Plugin-Praxis: wiederkehrende Muster aus WordPress-Audits, Bot-Log-Sichtung, Schema-/llms.txt-Kompatibilität und AI-Visibility-Tests. Diese Beobachtungen sind im Artikel als Praxis-Einordnung genutzt, nicht als externe Primärquelle.