Das AI Visibility Audit: Warum Websites in der Suche, nicht aber in der KI erscheinen können
Ein AI Audit kann die Gründe zeigen, warum eine Website bei Google ganz oben stehen kann und für ChatGPT, Gemini, Claude oder Perplexity trotzdem unsichtbar ist.
Das Wichtigste in Kürze
- Gute Sichtbarkeit in der klassischen Suche garantiert keine Sichtbarkeit in KI-Systemen.
- Eine Webseite muss für relevante Crawler erreichbar sein, um in ChatGPT und Co. zu erscheinen.
- Viele Webseiten sind blockiert, ohne dass die Besitzer der Webseiten das wissen.
- Das kann an einem falsch konfigurierten CDN oder am Hosting-Anbieter liegen.
- Mit einem Audit in 5 Schritten lässt sich die KI-Sichtbarkeit testen.
Eine Seite kann auf Platz eins bei Google ranken und in den Antworten der großen KI-Systeme wie ChatGPT, Claude, Gemini oder Perplexity einfach fehlen. Es gibt Gründe, die außerhalb der klassischen SEO liegen. Bevor es um Onpage-Arbeit, Technik oder Backlinks geht, muss eine Website überhaupt für die relevanten Crawler erreichbar sein, die das Trainingsmaterial der Sprachmodelle zusammentragen. Wird sie dort nicht erfasst, taucht sie im Modell auch nicht auf.
Genau an diesem Punkt setzt ein AI Visibility Audit an. Beschrieben hat es Stephen Burns, Web Intelligence Lead bei der Common Crawl Foundation, in einem Handbuch für SEOs und GEOs. Das Audit umfasst fünf Prüfschritte, die zusammen rund 90 Minuten dauern und ausschließlich kostenlose Werkzeuge verwenden. Die einzelnen Schritte stehen weiter unten. Davor lohnt sich ein Blick auf die Theorie, die das Ganze erklärt.
SEO-Beratung: Wir sind Ihre Experten
Wir bringen gemeinsam Ihre Website nach vorne. Profitieren Sie von jahrelanger SEO-Erfahrung.
Wer entscheidet, was eine KI weiß
Common Crawl ist eine gemeinnützige Organisation, die Gil Elbaz 2007 gegründet hat. Sie betreibt einen Bot namens CCBot, der das offene Web jeden Monat durchsucht und die Ergebnisse als frei herunterladbare Archive auf Amazon S3 ablegt. Diese Archive wurden zu einer der ersten Quellen, aus denen OpenAI und andere ihre Modelle trainiert haben. Ob CCBot eine Website besuchen darf, entscheidet damit indirekt darüber, ob deren Inhalte in die Daten gelangen, aus denen die Modelle lernen.
Seit 2008 sind über 10 Petabyte zusammengekommen. Pro Monat erfasst der Crawler etwa 2 bis 2,5 Milliarden Webseiten, über den gesamten Bestand mehr als 300 Milliarden. Eine einzelner Monatscrawl umfasst rund 350 bis 400 TB unkomprimierter Daten.
Der Zugang hängt oft an zwei Zeilen in der robots.txt. Wer CCBot ausdrücklich mit „User-agent: CCBot / Allow: /“ anspricht, öffnet die Tür. Auch eine Website ohne Disallow-Regeln für KI-Crawler steht standardmäßig offen.
Vom offenen Web bis ins Modell sind es vier Schritte
Zuerst holt CCBot öffentlich erreichbare Seiten ab, folgt Links und hält sich an die robots.txt. Wer nicht gecrawlt wurde, fehlt im Crawl.
Die KI-Anbieter greifen auf das Archiv zu, filtern nach Qualität und trainieren ihre Modelle mit den Daten. Am Ende kann das fertige Modell die gelernten Inhalte wiedergeben, umformulieren und empfehlen.
Die Aufnahme ins Trainingsmaterial wirkt wie ein "Rankingfaktor" - auch wenn man bei KI-Systemen streng genommen nicht von Rankings sprechen kann.
Warum manche Seiten häufiger besucht werden
Common Crawl veröffentlicht einen Web Graph, der die Linkstruktur des Webs auf Host- und Domain-Ebene abbildet. Daraus leitet die Organisation ein Maß namens Harmonic Centrality ab. Die Idee dahinter: Eine Domain nahe am Kern des Linknetzes gilt als zentraler als eine am Rand, und zentrale Domains werden beim Crawlen bevorzugt.

Abbildung: Vergleich zwischen PageRank und Harmonic Centrality
Das unterscheidet sich vom klassischen PageRank. Der PageRank fragt, wie viele wichtige Seiten auf eine Webseite verlinken. Harmonic Centrality fragt, wie nah die Webseite Kern des Webs sitzt. Ein einziger Link von einer kernnahen Seite kann die Centrality stärker heben als Dutzende Links von abgelegenen Seiten.
Für die Praxis heißt das: Linkqualität zahlt sich doppelt aus. Höhere Centrality bedeutet häufigere Besuche, mehr erfasste Seiten, mehr Trainingsmaterial und damit eine größere Chance, dass Modelle die Seite kennen und empfehlen.
Zwischen Veröffentlichung und KI-Antwort liegen oft Monate
In der klassischen SEO bringt ein erneuter Crawl eine Änderung binnen Tagen in den Index. Bei der Trainingssichtbarkeit dauert das länger. Eine Seite erscheint, der CCBot entdeckt sie bei einem späteren Durchlauf, ein Monats-Crawl nimmt sie in das Archiv auf und wird veröffentlicht, und erst eine spätere Trainingsrunde verarbeitet sie. Jeder Schritt kostet Zeit. Diese Form der Sichtbarkeit baut sich damit recht langsam auf. Zugang und Anbindung sollte man früh richtig setzen, weil der Effekt nach dem Zeitplan des Modells eintritt und nicht nach dem eigenen.
Ist eine Seite einmal gelistet, lebt sie in zwei Schichten. Die erste ist das parametrische Gedächtnis: Inhalte, die vor dem Trainingsstichtag erfasst wurden und fest in den Modellgewichten stecken. Das ist das Wissen, das ein Modell abruft, ohne nachzuschlagen.
Die zweite Schicht ist die Live-Abfrage (RAG): Inhalte, die das Modell zur Laufzeit frisch holt. Dafür muss die Seite für Such- und Abrufbots zum Zeitpunkt der Abfrage erreichbar sein. Eine Website kann im parametrischen Gedächtnis stehen, aber für die Live-Abfrage gesperrt sein, oder umgekehrt. Ein vollständiges Audit prüft beides: Warst du erreichbar, als das Modell trainiert wurde, und bist du es heute für den Live-Abruf?
Diese Unterscheidung geht auf das Rahmenkonzept von Duane Forrester zurück („When the Training Data Cutoff Becomes a Ranking Factor“, März 2026). Jedes Modell hat einen Trainingsstichtag. Inhalte, die danach erscheinen, leben zunächst nur in der Live-Abfrage, bis die nächste Trainingsrunde sie aufnimmt. Je weiter der Stichtag eines Modells zurückliegt, desto stärker hängt es bei aktuellen Themen am Live-Abruf, und desto mehr entscheidet der heutige Crawler-Zugang darüber, ob eine Seite auftaucht.
ChatGPT, Gemini und Claude mischen trainiertes Wissen mit Live-Suche, Perplexity arbeitet überwiegend mit Live-Abfragen. Die konkreten Stichtage ändern sich mit jeder Modellversion; verlässlich sind nur die Angaben der Anbieter selbst.
Das stille Blockieren
Am häufigsten verschwindet eine Seite aus der KI durch eine Voreinstellung im CDN oder in der Firewall, die niemand geprüft hat. Zwei Mechanismen erklären den Großteil der Fälle. Manche CDNs schreiben automatisch Disallow-Regeln für KI-Crawler in die robots.txt und stellen Bots wie GPTBot, ClaudeBot, Google-Extended und CCBot vor die Tür.
Andere Sperren sitzen in der Web Application Firewall: Ein Schalter „KI-Bots blockieren“ weist Anfragen schon vor dem Server ab, der Seitenbetreiber sieht in seinen eigenen Dateien nichts, und der Bot erhält einen 403. Weil ein einzelnes großes CDN vor einem erheblichen Teil des Webs sitzt und manche Anbieter neue Domains von Haus aus auf Blockieren stellen, ist das eher der Normalfall als die Ausnahme.
Im Nachrichtenbereich trifft es ausgerechnet CCBot am härtesten. Eine Untersuchung von 100 großen US- und UK-Nachrichtenseiten aus dem Januar 2026 sah CCBot mit 75 Prozent als meistgesperrten Trainingsbot, vor Anthropic-ai (72 Prozent), ClaudeBot (69 Prozent) und GPTBot (62 Prozent). Bei einem Verlags- oder Nachrichtenkunden sollte man den CCBot-Zugang also zuerst prüfen.
Wer wie oft gesperrt wird (ausgewählte Werte)
|
Datenquelle |
Bot |
Anteil gesperrt |
|---|---|---|
|
arXiv-Studie, Nachrichtenseiten |
KI-Bots gesamt |
23 % (09/2023) → 60 % (05/2025) |
|
Originality.AI, Top 1.000 |
GPTBot |
35,7 % (08/2024) |
|
Originality.AI, Top 1.000 |
CCBot |
22,1 % |
|
BuzzStream, 100 Nachrichtenseiten |
CCBot |
75 % (01/2026) |
Tabelle: Gesperrte KI-Bots bei US-Nachrichtenwebsites. Quelle: BuzzStream
Die gute Nachricht: Zurück in den Crawl zu kommen ist meist so einfach wie das Sperren selbst war. Weil sich Crawler wie CCBot an die robots.txt halten, genügt es oft, die KI-Agenten am Rand und in der robots.txt wieder freizugeben. Dann nehmen die Crawler ihren normalen Rhythmus wieder auf. Je früher eine Seite offen ist, desto eher beginnt sie, Präsenz in den Monatsarchiven aufzubauen, und die wächst über die Zeit. Den Zugang heute zu öffnen, ist der wirkungsvollste und zugleich einfachste Schritt, den die meisten Websites in Richtung KI-Sichtbarkeit gehen können.
Die ehrliche Gegenseite: Manche wollen draußen bleiben
Nicht jeder Verlag will ins Training. Wer aus Prinzip, aus wirtschaftlichen Gründen oder aus Ablehnung gegen die Verwendung seiner Inhalte ausgeschlossen bleiben möchte, trifft eine legitime Wahl. Nur funktioniert das Opt-out weniger zuverlässig, als viele glauben. Die Mechanismen wirken bei den Crawlern unterschiedlich; eine Regel, die einen Bot stoppt, lässt einen anderen ungehindert. Genau dieselben Zugangsprüfungen aus dem AI Viasibility--Audit helfen auch hier.
KI neigt zum Englischen: ein Hinweis für deutschsprachige Seiten
Für den deutschsprachigen Markt kann eine Seite lokal gut ranken und die AI Citations trotzdem an englische Seiten verlieren. Die Wurzel liegt im Korpus: Englisch macht rund 43 bis 45 Prozent der Seiten im aktuellen Common Crawl aus, nach der Qualitätsfilterung effektiv noch mehr. Darauf basieren zwei Verzerrungen. Die Retriever der KI-Suche stellen englische und autoritäre Seiten oft über vergleichbare lokalisierte Seiten, besonders wenn die Anfrage englisch ist. Und große Modelle rechnen offenbar in einem teils sprachübergreifenden Begriffsraum, der ins Englische kippt.
Der Hebel, den man nutzen kann, ist der Retriever: Eine hochwertige englische Fassung der wichtigsten Seiten erweitert die Reichweite. Dabei helfen sauberes hreflang, eigene crawlbare URLs und ein englischer Text, der wirklich brauchbar ist und keine rein maschinelle Übersetzung. Beide Sprachfassungen sollten die Zugangsprüfungen bestehen.
Wichtig bei der Formulierung gegenüber Kunden: Modelle tendieren zum Englischen, sie übersetzen aber nicht ins Englische. Anthropic beispielsweise nutzt Claude gemeinsame, sprachunabhängige Konzepte.
Das AI Visibility Audit: 5 Prüfschritte
Bei einem AI Visibility Audit arbeitet man die einzelnen Schritte der Reihe nach ab, weil ein frühes Problem oft die späteren erklärt. Alle Schritte verwenden kostenlose Werkzeuge.
Schritt 1: Erreicht der Crawler die Seite?
Hier prüft man, ob irgendetwas bestimmte KI-Crawler aussperrt. Zuerst schaut man in die robots.txt nach Disallow-Zeilen für CCBot, GPTBot, ClaudeBot und Google-Extended. Eine saubere robots.txt sagt aber nichts, wenn die Firewall den Bot trotzdem abweist. Deshalb fragt man den Server mit dem CCBot-User-Agent ab und vergleicht die Antwort mit der eines normalen Browsers. Ein 200 für CCBot ist gut, ein 403 zeigt, dass die Website für den Bot blockiert ist. Bekommt der Browser 200 und CCBot 403, sitzt die Sperre am Rand beziehungsweise in der Firewall. Ansatzpunkte sind die Konfiguration der CDN oder die Einstellungen des Webservers. Manche Hostinganbieter blockieren KI-Bots standardmäßig. Hier hilft dann nur ein Gespräch mit dem Support oder ein Wechsel des Anbieters.
Schritt 2: Steht die Domain wirklich im Archiv?
Über den Common Crawl Index fragt man ab, ob die Domain vorhanden ist, wann sie zuletzt gecrawlt wurde und wie viele Seiten ungefähr erfasst sind. Keine Treffer heißt: nicht enthalten. Wenige Treffer heißt: nur oberflächlich erfasst. Alte Zeitstempel heißen: veraltet. Eine Domain kann offen stehen und trotzdem kaum besucht werden.
Zwischenschritt: Ist es überhaupt der echte CCBot?
Der echte CCBot läuft aus festen IP-Bereichen mit Reverse DNS. Eine geloggte IP prüft man per Forward-confirmed Reverse DNS: Der echte CCBot löst auf einen Hostnamen unter .crawl.commoncrawl.org auf, der wieder auf dieselbe IP zeigt. Ein Betrüger scheitert daran.
Schritt 3: Wird die Domain priorisiert oder zurückgestellt?
Hier prüft man die Harmonic Centrality und den Rang der Domain im Web Graph. Ein niedriger Rang heißt: zurückgestellt im Crawl-Budget. Dann besucht der Crawler die Seite selbst bei offenem Zugang nur oberflächlich und selten.
Eine niedrige Centrality markiert man als strategisches Risiko und als Ziel für Linkaufbau, der auf kernnahe Seiten zielt. Am schnellsten geht das aktuell mit dem CC Rank Checker unter webgraph.metehan.ai, den Metehan Yesilyurt auf Basis der Web-Graph-Daten gebaut hat. Es handelt sich um ein unabhängiges Community-Projekt; Common Crawl arbeitet an einem eigenen Werkzeug.
Schritt 4: Lässt sich der Inhalt sauber abbilden?
Entitäten ohne strukturierte Daten sind im Training schwerer darzustellen und für Modelle schwerer zuzuordnen. Auf den wichtigen Seiten prüft man deshalb das Schema.org-Markup: Organisation, Artikel beziehungsweise Produkt, Autor, Breadcrumb. Prüfen lässt es sich mit dem Google Rich Results Test.
Schritt 5: Existiert der Inhalt auch ohne JavaScript?
Viele KI-Crawler verhalten sich wie der frühe Googlebot: Sie holen das HTML, führen aber kein JavaScript aus. Werden die wichtigen Inhalte erst nach dem JavaScript-Lauf angezeigt, erfasst der Crawler womöglich eine leere Hülle. Man gleicht den rohen Abruf mit der gerenderten Seite ab und sucht im rohen HTML nach einem wichtigen Textstück der Seite. Ein Treffer heißt: serverseitig gerendert und für den Crawler sichtbar. Kein Treffer heißt: per JavaScript nachgeladen, und der Crawler sieht möglicherweise nichts. Möglich ist es auch, eine Webseite mit im Browser deaktivieren JavaScript zu laden und sich die Ergebnisse anzusehen. Auch Tools wie Screaming Frog können bei der Analyse hilfreich sein.
Werkzeuge und Ergebnis
Der Common Crawl Index Server beantwortet die Frage, ob die geprüfte Seite im Archiv steht, und wann sie zuletzt abgerufen wurde. Der CC Rank Checker liest Centrality und Crawl-Priorität.
Dazu kommen vier Helfer
- Screaming Frog für Crawls mit eigenem User-Agent
- curl für schnelle Tests an Firewall und rohem HTML
- der Google Rich Results Test für das Markup und
- das eigene CDN-Dashboard, in dem die meisten versehentlichen Sperren tatsächlich behoben werden.
Die Resultate fasst man pro Domain auf einer einseitigen Scorecard zusammen: bestanden oder durchgefallen bei Zugang und Rendering, vorhanden oder fehlend im Index, eine Centrality-Note und eine Liste der Lücken beim strukturierten Markup, jeweils mit einer konkreten Abhilfe.

























