Wie KI Ihre Website wirklich liest

Wenn ein Mensch Ihre Website öffnet, passiert im Hintergrund einiges: Der Browser lädt das Dokument, führt Skripte aus, holt Bilder und Schriften nach und setzt daraus die Seite zusammen, die am Ende auf dem Bildschirm steht. Dieses Ergebnis ist so selbstverständlich, dass man es leicht für die Website hält.

Maschinelle Besucher gehen diesen Weg nicht zwangsläufig mit. Manche holen sich das Dokument und lesen den ausgelieferten Text. Andere führen die Seite in einem echten Browser aus und sehen die fertige Oberfläche. Wieder andere kommen gar nicht in erster Linie zum Lesen, sondern um auf der Seite etwas zu erledigen.

Deshalb lässt sich die Frage „Was sieht KI auf meiner Website?“ in dieser Form nicht beantworten. Beantwortbar wird sie erst mit drei Zusätzen: welches System, zu welchem Zweck, auf welchem Weg. Diese drei Fragen ziehen sich durch den ganzen Beitrag.

• Zweck 1

  Suche und Auffindbarkeit

  Ein System erfasst Inhalte, um sie später in Suchergebnissen oder Antworten zeigen und verlinken zu können. OpenAI nennt dafür OAI-SearchBot: Wer möchte, dass Inhalte in Zusammenfassungen und Ausschnitten in ChatGPT auftauchen, darf diesen Zugriff nicht blockieren. Anthropic beschreibt Claude-SearchBot als Bot, der die Qualität von Suchergebnissen verbessern soll. Perplexity beschreibt PerplexityBot als dafür gedacht, Websites in Suchergebnissen zu zeigen und zu verlinken.

• Zweck 2

  Modellentwicklung — und deren Steuerung

  Beim zweiten Zweck geht es um Inhalte, die in die Entwicklung von Modellen einfließen können, und vor allem darum, wie ein Websitebetreiber das steuert. OpenAI verweist dafür auf GPTBot: Wer Seiten von möglichem Training ausnehmen möchte, soll diesen User-Agent ausschließen. Anthropic schreibt zu ClaudeBot, er sammle Inhalte, die potenziell zu deren Training beitragen könnten. Perplexity grenzt sich an dieser Stelle ausdrücklich ab: PerplexityBot werde nicht eingesetzt, um Inhalte für KI-Basismodelle zu erfassen.

• Zweck 3

  Abruf im Auftrag eines Nutzers

  Beim dritten Fall steht der unmittelbare Nutzerabruf im Vordergrund: Ein Mensch stellt eine Frage, und der Anbieter kann dafür gezielt Webinhalte abrufen. Anthropic beschreibt Claude-User so — wenn Menschen Claude etwas fragen, kann Claude über diesen Agenten Websites aufrufen. Perplexity beschreibt Perplexity-User entsprechend und hält dazu ausdrücklich fest, dass dieser Abrufer robots.txt in der Regel ignoriert, weil ein Nutzer den Abruf ausgelöst hat. Daraus folgt keine allgemeine Aussage darüber, wie Anbieter solche Abrufe anschließend speichern oder weiterverarbeiten.

Für viele automatisierte Crawler ist eine einzige Datei im Wurzelverzeichnis das zentrale Steuerungsmittel: robots.txt. Anthropic schreibt, die eigenen Bots hielten sich an die branchenüblichen Angaben darin. Wie sich nutzerausgelöste Abrufe verhalten, hängt dagegen vom Anbieter und von der Zugriffsart ab: Perplexity hält für Perplexity-User ausdrücklich fest, dass dieser Abrufer robots.txt bei nutzerangeforderten Abrufen in der Regel ignoriert. Robots.txt ist damit eine Steuerung und kein Schloss.

Ein häufiges Missverständnis gehört gleich hierher: Google-Extended ist kein eigener Bot. Googles Crawler-Dokumentation hält fest, dass Google-Extended keine eigene User-Agent-Zeichenkette in HTTP-Anfragen hat; gecrawlt wird mit den vorhandenen Google-User-Agents, und der Eintrag in der robots.txt wirkt allein steuernd. Er regelt, ob von Google erfasste Inhalte für das Training künftiger Gemini-Modelle und für das Grounding in bestimmten Google-Produkten verwendet werden dürfen. Auf die Aufnahme in die Google-Suche und auf das Ranking dort hat er nach derselben Dokumentation keinen Einfluss.

• Weg A

  Die Fakten stehen im ausgelieferten Dokument

  Elektro König BerlinWallbox-Installation · BerlinTermin anfragen

  Der Server liefert die Angaben bereits mit. Ein System, das nur das ausgelieferte Dokument liest und keinen Browser ausführt, hat Name, Leistung, Ort und gewünschte Handlung sofort beisammen.

• Weg B

  Der Inhalt entsteht erst im Browser

  <div id="root"></div>— sonst nichts —

  Google nennt diesen Aufbau das App-Shell-Modell: Das erste HTML enthält den eigentlichen Inhalt nicht, er entsteht erst, wenn ein Browser die Skripte ausführt. Wer ohne Browser liest, findet an dieser Stelle ein leeres Gerüst. Wer mit Browser liest, sieht dieselbe Seite wie ein Mensch.

• Weg C

  Die fertig gerenderte Oberfläche

  Wallbox-Installation in Berlin[ Termin anfragen ]

  Ein System, das die Seite tatsächlich in einem Browser ausführt, bekommt die fertige Oberfläche: Überschrift, Text, Schaltflächen. Es liest nicht nur — es sieht auch, was sich bedienen lässt.

Ein verbreiteter Kurzschluss lautet: Was im Quelltext nicht als Fließtext dasteht, existiere für Maschinen nicht. So einfach ist es nicht. Zum ausgelieferten Dokument gehört mehr als der sichtbare Text — strukturierte Daten, eingebettete Datenblöcke und serverseitig vorbereitete Inhalte stehen ebenfalls darin und sind lesbar. Die Trennlinie verläuft nicht zwischen sichtbar und unsichtbar, sondern zwischen dem, was der Server mitliefert, und dem, was erst der Browser erzeugt.

Und eine Einschränkung gehört dazu: Das Beispiel ordnet Wege. Es beschreibt nicht die Architektur eines bestimmten Anbieters — welchen Weg ein konkretes System bei einem konkreten Abruf nimmt, ist damit nicht gesagt.

1. Damals gemessen

   Dezember 2024, echte Zugriffsprotokolle

   Vercel und MERJ veröffentlichten am 17. Dezember 2024 eine Auswertung tatsächlicher Zugriffe. Für die dort untersuchten spezialisierten KI-Crawler — genannt werden OAI-SearchBot, ChatGPT-User und GPTBot von OpenAI, ClaudeBot von Anthropic, Meta-ExternalAgent, Bytespider und PerplexityBot — lautete das Ergebnis: Sie führten kein JavaScript aus. Teilweise luden sie JavaScript-Dateien sogar herunter, ohne sie auszuführen.

2. Was das nicht beweist

   Zwei Gegenbeispiele in derselben Studie

   Dieselbe Auswertung nennt zwei Systeme, die sehr wohl rendern: Gemini nutzte Googles Infrastruktur und konnte damit vollständig rendern, und AppleBot rendert nach derselben Quelle über einen browserbasierten Crawler. „Kein JavaScript“ ist also nicht einmal innerhalb dieser Studie eine Eigenschaft aller KI-nahen Zugriffe. Hinzu kommt die Zeitform: Die Studie beschrieb ausdrücklich einen damaligen Stand. Sie ist eine datierte Messung, keine Zusage über jeden heutigen Abruf.

3. Was das für eine Website bedeutet

   Eine Frage statt einer Regel

   Daraus folgt kein pauschales „alles serverseitig rendern“. Es folgt eine Frage, die jeder Betrieb für sich beantworten kann: Welche Angaben, auf die es geschäftlich ankommt, entstehen erst im Browser? Bei Leistung, Ort, Preisrahmen und Kontaktweg ist eine Abhängigkeit vom Browser ein vermeidbares Risiko. Bei einem Bildwechsler oder einem Chat-Fenster ist sie weniger kritisch, solange über die Komponente keine geschäftlich tragende Angabe und keine notwendige Handlung ausschließlich erreichbar ist.

Für die klassische Google-Suche ist der Fall dokumentiert und anders gelagert: Google Search führt JavaScript aus, mit einer laufend aktualisierten Chromium-Version. Die Dokumentation beschreibt dafür drei Phasen — Crawling, Rendering, Indexierung — und hält zugleich fest, dass diese Phasen nicht sauber nacheinander ablaufen und von außen nicht erkennbar sind.

Beides gleichzeitig ist damit möglich: Google kann clientseitig erzeugte Inhalte rendern und für die Indexierung verarbeiten, während ein nicht-rendernder Abruf nur das initial ausgelieferte Dokument erhält. Wer nur auf die Google-Sichtbarkeit schaut, sieht diesen Unterschied nicht.

Technische Vertiefung

Wie moderne Websites gebaut und ausgeliefert werden

Wovon es abhängt, was im initialen Dokument steht: HTML, JavaScript, die vier Auslieferungswege und warum derselbe Frameworkname zwei völlig verschiedene Ergebnisse zulässt.

1. 01 · Discoverability

   Kann ein System die Seite überhaupt abrufen?

   Zugänge, Weiterleitungen, Statuscodes, robots.txt. Ohne offene Tür passiert nichts Weiteres.

2. 02 · Extractability

   Lassen sich die Fakten zuverlässig herauslösen?

   Leistung, Ort, Zuständigkeit, Kontaktweg — als Text, den ein System eindeutig zuordnen kann, nicht nur als Eindruck.

3. 03 · Answerability

   Beantwortet die Seite eine konkrete Frage eindeutig?

   Aus lesbaren Angaben wird nicht automatisch eine übernehmbare Antwort. Dafür muss die Frage auf der Seite tatsächlich beantwortet sein.

4. 04 · Observed AI Visibility

   Taucht die Domain in KI-Antworten tatsächlich auf?

   Das zeigt sich nur in einem definierten, wiederholbaren Test — beobachtet, nicht abgeleitet.

Erreichbar ist eine Voraussetzung — kein Sichtbarkeitsnachweis. Stufe 1 belegt Stufe 4 nicht. Dass ein Crawler eine Seite holen darf, sagt nichts darüber, ob sie je in einer Antwort auftaucht.

Die Anbieter selbst formulieren das übrigens zurückhaltender, als es in der Branche oft wiedergegeben wird. OpenAI beschreibt das Zulassen von OAI-SearchBot als Voraussetzung dafür, dass eine Website für die Aufnahme überhaupt infrage kommt, und hält im selben Abschnitt fest: Eine Platzierung ist nicht garantiert.

Ein Abruf liefert ein Dokument. Ein Agent steht vor einer Oberfläche und soll darauf etwas erledigen. Ob ihm das gelingt, hängt daran, ob die Seite ihre Bedienelemente als das ausweist, was sie sind: eine Schaltfläche als Schaltfläche, ein Formularfeld mit einer Beschriftung, ein Menü mit einem erkennbaren Zustand.

OpenAI nennt dafür ein konkretes Beispiel: ChatGPT Atlas nutze ARIA-Auszeichnungen — dieselben Rollen und Beschriftungen, die auch Screenreader auswerten —, um Seitenstruktur und interaktive Elemente zu deuten. Empfohlen wird, den WAI-ARIA-Empfehlungen zu folgen und interaktiven Elementen wie Schaltflächen, Menüs und Formularen aussagekräftige Rollen, Beschriftungen und Zustände zu geben.

Dieser Punkt wird leicht falsch verstanden, deshalb deutlich: Barrierefreiheit ist kein KI-Trick. Sie ist zuerst dafür da, dass Menschen eine Website benutzen können — mit Screenreader, mit der Tastatur, mit eingeschränkter Sicht. Dass semantische Rollen, Beschriftungen und Zustände zusätzlich Browser-Agenten helfen können, dokumentiert OpenAI derzeit ausdrücklich für den Agentenbetrieb in ChatGPT Atlas — die eben genannte Empfehlung. Eine allgemeine Zusage für beliebige Agenten ist damit nicht verbunden.

Geschäftlich interessant wird das dort, wo am Ende eine Handlung steht: eine Kontaktmöglichkeit finden, eine Leistung auswählen, eine Anfrage absenden, eine Buchung anbahnen. Was ein bestimmter Agent davon heute tatsächlich zu Ende bringt, ist damit ausdrücklich nicht gesagt — die Bandbreite ist groß und verändert sich laufend. Die haltbare Aussage ist bescheidener: Eine Seite, deren Bedienelemente nicht benannt sind, macht es einem Agenten schwerer als nötig, der sich an dieser Auszeichnung orientiert — und einem Teil Ihrer menschlichen Besucher ebenfalls.

1. 01

   Tragende Angaben gehören ins ausgelieferte Dokument.

   Geschäftlich tragende Informationen sollten nicht unnötig von einem bestimmten Rendering-Pfad abhängen. Name, Leistung, Ort, Preisrahmen und Kontaktweg sind typische Beispiele. Welche Informationen geschäftlich tragend sind, hängt von der jeweiligen Website ab.

2. 02

   Entscheiden Sie Zugänge bewusst statt versehentlich.

   In der robots.txt lassen sich Suche und Modellentwicklung getrennt regeln; bei nutzerausgelösten Abrufen hängt die Wirkung vom Anbieter und von der Zugriffsart ab. Ein pauschales Blockieren kann dabei auch Systeme ausschließen, über die Inhalte auffindbar sein sollen.

3. 03

   Beantworten Sie Fragen dort, wo sie gestellt werden.

   Zentrale Angaben, die ausschließlich in PDFs oder Bildern stehen, sind nicht über jeden Abruf- und Antwortpfad gleich zuverlässig zugänglich; was nur auf telefonische Nachfrage existiert, steht auf der Seite gar nicht. Preise, Einzugsgebiete, Fristen und Zuständigkeiten sollten deshalb zusätzlich als klarer HTML-Text auf der Seite stehen.

4. 04

   Benennen Sie Ihre Bedienelemente.

   Beschriftete Schaltflächen und Formularfelder, korrekte Rollen, eine nachvollziehbare Struktur. Das nützt zuerst Menschen — und kann Agenten, die sich an dieser Auszeichnung orientieren, die Bedienung erleichtern.

5. 05

   Behandeln Sie Sichtbarkeit als Messgröße, nicht als Zusage.

   Ob eine Domain in KI-Antworten auftaucht, lässt sich prüfen — mit definierten, wiederholbaren Tests. Wer es ohne solche Tests behauptet, behauptet es lediglich.

OpenAI

OpenAI nennt die Angaben zu OAI-SearchBot und GPTBot, die ARIA-Empfehlung für ChatGPT Atlas und den Satz, dass eine Platzierung nicht garantiert ist.

Publishers and Developers — FAQ · Searching the web with ChatGPT Abgerufen am 31. August 2026

Anthropic

Anthropic beschreibt ClaudeBot, Claude-SearchBot und Claude-User sowie den Umgang mit robots.txt.

Does Anthropic crawl data from the web, and how can site owners block the crawler? Seitenstand 7. April 2026, abgerufen am 31. August 2026

Perplexity

Perplexity beschreibt PerplexityBot und Perplexity-User samt der Angabe, dass der nutzerausgelöste Abruf robots.txt in der Regel ignoriert.

Perplexity Crawlers Ohne Datumsangabe auf der Seite, abgerufen am 31. August 2026

Google — Crawler

Google nennt zu Google-Extended: keine eigene User-Agent-Zeichenkette, steuernde Wirkung in der robots.txt, kein Einfluss auf Aufnahme und Ranking in der Google-Suche.

Google crawlers and fetchers Seitenstand 14. Juli 2026, abgerufen am 31. August 2026

Google — JavaScript

Google erklärt die Chromium-Ausführung in der Google-Suche, die drei Phasen und das App-Shell-Modell.

Understand the JavaScript SEO basics Abgerufen am 31. August 2026

Vercel und MERJ

Vercel und MERJ dokumentieren die datierte Messung zum Rendering-Verhalten der untersuchten Crawler — einschließlich der beiden Gegenbeispiele Gemini und AppleBot.

The rise of the AI crawler Veröffentlicht am 17. Dezember 2024

Stand dieses Beitrags: 31. August 2026. Anbieterangaben können sich ohne Ankündigung ändern; eine Messung bleibt an ihr Datum gebunden. Wo dieser Beitrag ein Datum nennt, ist das keine Formalie, sondern Teil der Aussage.