Wissen
Technische GEO-Zugänglichkeit
Technische GEO-Zugänglichkeit beschreibt, ob öffentliche Website-Inhalte von den für generative Suche und Retrieval relevanten Systemen technisch gefunden, abgerufen und verarbeitet werden können. Dazu gehören nicht nur robots.txt-Regeln, sondern auch CDN- und WAF-Konfigurationen, HTTP-Statuscodes, JavaScript-Rendering, Canonicals, Sitemaps, Indexierungssignale, Snippet-Kontrollen und die getrennte Analyse verschiedener Bot- und User-Agent-Typen.
Ein Inhalt kann nur technisch berücksichtigt werden, wenn die benötigte Infrastruktur ihn tatsächlich erreichen und verarbeiten kann.
OAI-SearchBot, GPTBot und ChatGPT-User haben unterschiedliche Zwecke und dürfen in Audit und Logfile-Analyse nicht als ein Bot behandelt werden.
Technische Zugänglichkeit ist Voraussetzung für bestimmte Retrieval-Pfade, aber keine Garantie für Indexierung, Ranking, Auswahl oder Citation.
Dokument-Metadaten
Worum geht es in diesem Wissensbeitrag?
Einordnung des Inhalts
- Entity Class
- Wissen
- Content-Typ
- Technischer Grundlagen- und Auditbeitrag
- Hauptthema
- Technische GEO-Zugänglichkeit
- Audit-Typ
- Technischer GEO-Audit: Crawling, Indexierung und Bot-Steuerung
- Primäre Systeme
- ChatGPT Search, OpenAI-Crawler, Google Search, Gemini-nahe Google-Steuerungen und weitere Webcrawler
- Technische Ebenen
- DNS / Netzwerk → CDN / WAF → robots.txt → HTTP → Rendering → Indexierung → Retrieval / Nutzung
- Kernfrage
- Welche technische Schicht verhindert oder ermöglicht, dass relevante öffentliche Informationen von einem bestimmten Such-, Retrieval- oder AI-System verarbeitet werden?
Definition
Was bedeutet technische GEO-Zugänglichkeit?
Technische GEO-Zugänglichkeit ist die Fähigkeit einer Website, relevante öffentliche Inhalte für definierte Crawler und Retrieval-Systeme erreichbar, abrufbar und maschinell interpretierbar bereitzustellen. Der Begriff beschreibt keine einzelne Ranking-Maßnahme, sondern eine technische Voraussetzungskette aus Zugriff, Verarbeitung und Steuerung.
Definition als Faktenstruktur
- Discoverability
- Kann das System die URL über Links, Sitemaps, Suchindex oder andere Quellen entdecken?
- Network Access
- Erreichen Requests DNS, CDN, WAF und Origin ohne technische Blockade?
- Crawl Permission
- Erlauben robots.txt oder andere crawlerbezogene Regeln den automatischen Zugriff?
- Fetchability
- Liefert die URL einen technisch sinnvollen HTTP-Status und verwertbaren Response?
- Renderability
- Ist der relevante Inhalt im gelieferten beziehungsweise gerenderten Dokument vorhanden?
- Index Eligibility
- Verhindern noindex, Canonical-Signale oder andere Indexierungsregeln die gewünschte Aufnahme?
- Serving / Usage Controls
- Welche Snippet-, Preview-, Training- oder Produktregeln schränken die spätere Nutzung ein?
- Observation
- Kann das tatsächliche Bot-Verhalten über Logs, Search Console und andere Telemetrie verifiziert werden?
Mental Model
Technische Zugänglichkeit ist eine Kette – nicht ein einzelner Schalter
URL wird über Link, Sitemap, Suchindex oder anderen Pfad bekannt.
DNS, TLS, CDN und Netzwerkverbindung funktionieren.
robots.txt und Bot-Policy erlauben den vorgesehenen Zugriff.
Server liefert einen passenden HTTP-Response.
Kritischer Inhalt und Metadaten sind maschinell verfügbar.
Die gewünschte URL-Version ist konsistent signalisiert.
Das System entscheidet über Aufnahme oder andere Verarbeitung.
Inhalt wird für eine konkrete Anfrage als Kandidat ausgewählt.
Eine Antwort kann die Quelle sichtbar verwenden oder verlinken.
Crawlbarkeit ≠ Indexierung ≠ Retrieval ≠ Citation
Abgrenzung
Welche technischen Zustände häufig verwechselt werden
Crawler darf abrufen
Die URL ist für einen automatischen Crawler erreichbar und wird nicht durch dessen robots-Regeln blockiert. Das sagt noch nichts über Indexierung oder Citation aus.
Inhalt ist für einen Index zulässig
Eine Seite kann technisch crawlbar sein und dennoch durch noindex oder andere Signale von einer Suchindex-Aufnahme ausgeschlossen werden.
Inhalt wird für eine Anfrage gefunden
Ein vorhandener Inhalt muss für die konkrete Anfrage als relevant erkannt und in den Retrieval-Pfad aufgenommen werden.
Quelle kann sichtbar verwendet werden
Selbst ein technisch erreichbarer und retrievter Inhalt wird nicht zwingend als sichtbare Quelle oder Citation ausgegeben.
OpenAI User Agents
OAI-SearchBot, GPTBot und ChatGPT-User haben unterschiedliche Aufgaben
OpenAI dokumentiert mehrere getrennte User Agents. Für technische GEO-Analysen ist diese Unterscheidung entscheidend, weil dieselbe URL je nach Agent aus einem anderen Grund angefragt werden kann.
| User Agent | Zweck | Automatischer Crawl? | robots.txt | Was ein Log-Hit signalisiert |
|---|---|---|---|---|
|
Search OAI-SearchBot |
Web-Crawling für ChatGPT Search und das Sichtbarmachen von Websites in Search-Ergebnissen. | Ja | Ja. Die Einstellung ist unabhängig von GPTBot. | OpenAI hat die URL beziehungsweise Ressource im Kontext des automatischen Search-Crawlings angefragt. |
|
Training GPTBot |
Crawl von Inhalten, die für das Training generativer Foundation Models verwendet werden können. | Ja | Ja. Kann unabhängig von OAI-SearchBot erlaubt oder blockiert werden. | Ein möglicher Training-Crawl hat die URL angefragt; daraus folgt keine ChatGPT-Search-Sichtbarkeit. |
|
User Action ChatGPT-User |
Aufruf im Rahmen bestimmter Nutzeraktionen in ChatGPT oder Custom GPTs. | Nein, nicht als automatischer Webcrawl. | OpenAI weist darauf hin, dass robots.txt bei nutzerinitiierten Aktionen möglicherweise nicht anwendbar ist. | Ein Nutzer- oder Toolfluss hat die Ressource konkret angefordert; dies ist kein Search-Crawl-Indikator. |
OAI-SearchBot Requests + GPTBot Requests + ChatGPT-User Requests dürfen nicht zu einer einzigen „ChatGPT Bot Traffic“-Metrik zusammengefasst werden.
OpenAI-Steuerung
Search-Zugriff und Training lassen sich getrennt steuern
OpenAI beschreibt OAI-SearchBot und GPTBot als unabhängige robots.txt-Einstellungen. Eine Website kann deshalb Search-Crawling erlauben und Training-Crawling gleichzeitig ausschließen.
User-agent: OAI-SearchBot
Allow: /
User-agent: GPTBot
Disallow: /Wichtige Konsequenzen
- OAI-SearchBot erlaubt
- Schafft die technische Crawl-Voraussetzung für die Aufnahme von Website-Inhalten in ChatGPT Search.
- GPTBot blockiert
- Signalisiert, dass so gecrawlter Website-Inhalt nicht für das Training generativer OpenAI-Foundation-Models verwendet werden soll.
- OAI-SearchBot blockiert
- OpenAI dokumentiert, dass die Website dann nicht in ChatGPT-Search-Antworten gezeigt wird; navigative Link-/Titelanzeigen können in bestimmten Fällen trotzdem möglich sein.
- noindex
- OpenAI empfiehlt noindex, wenn auch eine reine Link-/Titelanzeige verhindert werden soll. Damit der Crawler noindex lesen kann, muss die Seite jedoch crawlbar sein.
Google & Gemini
Googlebot und Google-Extended sind ebenfalls unterschiedliche Steuerungsebenen
Crawling und Indexierung für Google Search
Googlebot crawlt öffentliche Webinhalte für Google Search. robots.txt beeinflusst den Crawl-Zugriff; noindex steuert die gewünschte Indexaufnahme auf Seitenebene.
Produkt-Token für Gemini-bezogene Nutzung
Google-Extended ist ein robots.txt-Produkt-Token, mit dem Publisher bestimmte Gemini-bezogene Nutzungen bereits gecrawlter Inhalte separat von Google Search steuern können. Dazu gehören laut Google unter anderem zukünftiges Gemini-Training und bestimmte Grounding-Funktionen.
Kein eigener HTTP-User-Agent
Google dokumentiert ausdrücklich, dass Google-Extended keinen separaten HTTP-User-Agent besitzt. In Access Logs kann daher nicht einfach nach „Google-Extended“ gefiltert werden.
Keine Search-Ranking-Steuerung
Google-Extended beeinflusst laut Google weder die Aufnahme einer Website in Google Search noch das Ranking in Google Search.
Googlebot → Crawling für Google Search
Google-Extended → separate Nutzungssteuerung für bestimmte Gemini-bezogene Zwecke
kein eigener HTTP-User-Agent → nicht als eigener „Google-Extended“-Bot im Serverlog sichtbar
robots.txt
robots.txt steuert Crawling – nicht automatisch Indexierung oder Zugriffsschutz
Das Robots Exclusion Protocol definiert Regeln, mit denen Websitebetreiber automatischen Clients mitteilen, welche Pfade gecrawlt werden dürfen. robots.txt ist jedoch keine Authentifizierung und kein Sicherheitsmechanismus.
Regelgruppe dem Bot zuordnen
Der User-Agent-Token bestimmt, für welchen Crawler die nachfolgenden Allow- und Disallow-Regeln gelten.
Pfadzugriff steuern
Regeln definieren, welche URL-Pfade automatisiert gecrawlt werden dürfen oder nicht.
Host, Protokoll und Port beachten
robots.txt-Regeln gelten für den jeweiligen Host, das Protokoll und den Port, auf dem die Datei bereitgestellt wird.
Nicht für vertrauliche Inhalte verwenden
Vertrauliche Inhalte benötigen Authentifizierung oder andere echte Zugriffskontrollen statt robots.txt.
User-agent: OAI-SearchBot
Allow: /
User-agent: GPTBot
Disallow: /
User-agent: Googlebot
Allow: /
Sitemap: https://www.example.com/sitemap.xmlCDN, WAF & Bot Protection
Eine korrekte robots.txt reicht nicht, wenn die Infrastruktur den Bot blockiert
Zwischen Crawler und Inhalt liegen häufig mehrere technische Schichten. CDN, Web Application Firewall, Bot Management, Rate Limiting, Geo-Regeln oder Human-Verification können legitime Crawler blockieren, obwohl robots.txt den Zugriff ausdrücklich erlaubt.
WAF / Bot Rule blockiert
Der Request erreicht die Infrastruktur, wird aber wegen Bot-, Firewall- oder Zugriffspolitik abgewiesen.
Rate Limiting
Der Bot darf grundsätzlich zugreifen, überschreitet jedoch eine Rate-Limit- oder Drosselungsregel.
JavaScript Challenge / CAPTCHA
Eine für menschliche Browser gedachte Challenge kann automatisierten Zugriff technisch verhindern.
Regionale oder Login-basierte Blockade
Geo-Blocking, Sessionpflicht oder Authentifizierung können öffentlich gedachte Inhalte für Bots unerreichbar machen.
robots.txt erlaubt → Edge/WAF erlaubt → Origin antwortet → Response enthält nutzbaren Inhalt
Bot-Verifizierung
User-Agent-Strings allein sind kein belastbarer Herkunftsnachweis
Ein HTTP-User-Agent kann von fremden Clients nachgeahmt werden. Logfile-Analysen und Allowlist-Regeln sollten deshalb nicht ausschließlich auf dem sichtbaren User-Agent-String beruhen.
OpenAI
- OAI-SearchBot
- OpenAI veröffentlicht eigene IP-Ranges unter openai.com/searchbot.json
- GPTBot
- OpenAI veröffentlicht eigene IP-Ranges unter openai.com/gptbot.json
- ChatGPT-User
- OpenAI veröffentlicht eigene IP-Ranges unter openai.com/chatgpt-user.json
- Audit
- User Agent mit den jeweils aktuellen veröffentlichten IP-Bereichen kombinieren
- Googlebot
- Google empfiehlt Reverse-DNS-Verifikation oder den Abgleich gegen veröffentlichte Googlebot-IP-Ranges
- Grund
- Google weist ausdrücklich darauf hin, dass Googlebot-User-Agents von fremden Crawlern gefälscht werden können
HTTP
Statuscodes zeigen, ob der Bot tatsächlich verwertbaren Zugriff erhält
| Status | Bedeutung im Audit | Typische Interpretation |
|---|---|---|
| 200 | Erfolgreicher Response | Notwendige, aber nicht hinreichende Voraussetzung: Inhalt kann trotzdem leer, fehlerhaft oder clientseitig unvollständig sein. |
| 301 / 308 | Permanente Weiterleitung | Prüfen, ob Ziel-URL konsistent, erreichbar und canonical ist. |
| 302 / 307 | Temporäre Weiterleitung | Prüfen, ob unbeabsichtigte Redirect-Ketten oder Bot-spezifische Umleitungen entstehen. |
| 401 / 403 | Zugriff verweigert | Häufig Authentifizierung, WAF, Bot Management, ACL oder Geo-Regel. |
| 404 / 410 | Ressource nicht vorhanden | Für entfernte URLs korrekt; bei eigentlich öffentlichen Inhalten ein Zugänglichkeitsfehler. |
| 429 | Rate Limit | Bot wird gedrosselt; Crawl-Frequenz und Schutzregeln analysieren. |
| 5xx | Server-/Origin-Fehler | Temporäre oder persistente technische Unerreichbarkeit. |
HTTP 200 + Fehlerseite / leerer Hauptinhalt ≠ technisch gesunde öffentliche Seite
JavaScript & Rendering
Kritischer Inhalt sollte nicht von einem nicht dokumentierten Rendering-Verhalten abhängen
Google Search kann JavaScript mit einem Web Rendering Service ausführen, dokumentiert aber weiterhin Rendering-Grenzen. Andere Crawler müssen JavaScript nicht in derselben Weise verarbeiten. Für OpenAI-Crawler ist in den hier verwendeten offiziellen Crawler-Dokumentationen keine allgemeine Browser-Rendering-Garantie beschrieben.
Kritische Fakten früh verfügbar machen
Zentrale Textinhalte, Canonicals und andere wichtige Metadaten sind robuster, wenn sie bereits serverseitig beziehungsweise im initialen HTML vorhanden sind.
API- und Script-Abhängigkeiten prüfen
Wenn Hauptinhalt erst nach zusätzlichen Requests entsteht, können blockierte APIs, JavaScript-Fehler oder Bot-Challenges zu einem leeren oder unvollständigen Dokument führen.
Widersprüchliche JS-Canonicals vermeiden
Google empfiehlt konsistente Canonical-Signale und warnt vor Canonicals, die per JavaScript auf eine andere URL geändert werden als im ursprünglichen HTML.
noindex nicht nachträglich „weg-rendern“
Google kann bei vorhandenem noindex Rendering überspringen; ein per JavaScript später entfernter noindex ist deshalb keine verlässliche Indexierungsstrategie.
Canonicalisierung
Canonical-Signale bestimmen, welche URL-Version als repräsentativ gelten soll
Bei mehreren ähnlichen oder identischen URLs muss ein Suchsystem entscheiden, welche Variante die Hauptversion ist. Für Google ist rel=“canonical“ ein starkes Signal, aber ein Hinweis und keine absolute Regel.
Audit-Fragen
- Self-Canonical
- Verweist die gewünschte öffentliche URL konsistent auf sich selbst?
- Redirect
- Führt eine alternative URL auf dieselbe bevorzugte Ziel-URL?
- Sitemap
- Enthält die Sitemap dieselbe gewünschte kanonische URL?
- Internal Links
- Verlinkt die Website intern überwiegend auf die kanonische Variante?
- Parameter / Filter
- Erzeugen Query-Parameter oder Filter unnötige URL-Duplikate?
- JavaScript
- Widersprechen gerenderte und initiale Canonical-Signale einander?
Googles Canonical-Verhalten ist dokumentiert; die exakte Canonical-Verarbeitung jedes generativen Crawlers sollte nicht ohne Anbieter-Dokumentation gleichgesetzt werden.
Sitemaps
Sitemaps unterstützen URL-Discovery und Canonical-Konsistenz
XML-Sitemaps geben Suchsystemen eine strukturierte Liste bevorzugter URLs. Für Google sind Sitemaps ein Hinweis, keine Garantie für Crawl oder Indexierung. In Sitemaps sollten deshalb primär die URLs stehen, die tatsächlich als öffentliche kanonische Seiten behandelt werden sollen.
Audit-Kriterien
- Status
- Sitemap-URLs sollten nicht auf Fehlerseiten oder unnötige Redirects zeigen
- Canonical
- Bevorzugt die kanonischen URL-Versionen listen
- Index Intent
- Keine absichtlich noindex gesetzten URLs als reguläre Indexziele listen
- Aktualität
- Neue und entfernte URLs zeitnah im Sitemap-Set abbilden
- Discovery
- Sitemap in Search Console beziehungsweise unterstützten Discovery-Pfaden bereitstellen
Indexierungs- & Snippet-Kontrollen
robots.txt, noindex und nosnippet lösen unterschiedliche Aufgaben
| Mechanismus | Ebene | Primäre Wirkung | Wichtige Bedingung / Grenze |
|---|---|---|---|
| robots.txt Disallow | Crawl | Automatischer Crawler soll eine URL oder einen Pfad nicht abrufen. | Blockiert nicht automatisch jede Index- oder Linkdarstellung; robots.txt ist kein Zugriffsschutz. |
| noindex | Indexierung | Seite soll nicht in einem unterstützenden Suchindex erscheinen. | Der Crawler muss die Seite abrufen können, um noindex zu lesen. |
| nosnippet | Serving / Preview | Google soll keinen Textsnippet anzeigen. | Google dokumentiert, dass dies auch direkten Input für AI Overviews und AI Mode verhindert. |
| max-snippet:n | Serving / Preview | Begrenzt die maximale Textmenge für Google-Snippets. | Google wendet die Grenze auch auf direkten Input für AI Overviews und AI Mode an. |
| data-nosnippet | Textabschnitt | Bestimmte HTML-Bereiche sollen nicht in Google-Snippets erscheinen. | Gilt nur für unterstützte HTML-Elemente und sollte nicht unnötig von JS-Rendering abhängen. |
| X-Robots-Tag | HTTP Header | Indexierungs- und Serving-Regeln auch für Nicht-HTML-Dateien steuerbar. | Wie Meta-Robots nur wirksam, wenn der Crawler den Response erhält und die Regel unterstützt. |
Logfile-Analyse
Server-, CDN- und WAF-Logs zeigen tatsächliches Bot-Verhalten
robots.txt beschreibt eine beabsichtigte Policy. Logfiles zeigen dagegen, welche Requests tatsächlich angekommen sind, welche URLs angefragt wurden und wie die Infrastruktur geantwortet hat. Für technische GEO-Analysen sollten die verschiedenen User Agents getrennt ausgewertet und nach Möglichkeit verifiziert werden.
Anzahl Requests getrennt nach OAI-SearchBot, GPTBot, ChatGPT-User, Googlebot und weiteren Bots.
Wie viele unterschiedliche öffentliche URLs erreicht ein Bot tatsächlich?
Anteil erfolgreicher Requests pro Bot und URL-Gruppe.
Wie häufig verhindern WAF-, ACL- oder Bot-Regeln den Zugriff?
Wie häufig greift Rate Limiting auf Bot-Traffic?
Wie häufig scheitern Bot-Requests an Origin- oder Serverfehlern?
Welche Seitentypen werden gecrawlt – Wissen, Leistungen, Produkte, Lösungen, Dokumentation?
Wie häufig werden wichtige URLs über einen definierten Zeitraum erneut angefragt?
Log-Datenmodell
Welche Felder für eine belastbare Analyse benötigt werden
Minimaler Log-Datensatz
- Timestamp
- Zeitpunkt des Requests mit eindeutiger Zeitzone
- Source IP
- Quell-IP zur Bot-Verifizierung
- User Agent
- Vollständiger HTTP-User-Agent-String
- Host + Path + Query
- Exakt angefragte URL-Komponenten
- HTTP Method
- GET, HEAD oder anderer Request-Typ
- Status Code
- Edge- beziehungsweise Origin-Antwortstatus
- Bytes / Response Size
- Hilft ungewöhnlich kleine oder leere Responses zu identifizieren
- Cache Status
- HIT, MISS, BYPASS oder vergleichbarer CDN-Zustand
- WAF Action
- Allow, Block, Challenge oder Rate Limit
- Response Time
- Latenz auf Edge- und möglichst Origin-Ebene
Log-Interpretation
Welche Informationen die User Agents tatsächlich liefern
Search Crawl Coverage
Hilft zu prüfen, ob OpenAI wichtige URL-Gruppen im automatischen Search-Crawl tatsächlich erreicht und ob technische Blockaden auf bestimmten Pfaden auftreten.
Training-Crawl-Verhalten
Zeigt einen anderen Verwendungszweck als Search. GPTBot-Traffic sollte deshalb nicht als Indikator für ChatGPT-Search-Crawling oder Citation interpretiert werden.
User-triggered Fetches
Kann anzeigen, dass eine Ressource im Rahmen einer konkreten Nutzeraktion oder eines GPT-Flows angefordert wurde. Der Traffic ist kein automatischer Crawl-Coverage-Indikator.
Search Crawling
Serverlogs ergänzen Search Console um URL-genaue Requestdaten, Statuscodes und technische Infrastrukturinformationen.
Bot-Crawl ≠ Referral Traffic.
Ein Crawler-Request im Serverlog ist nicht dasselbe wie ein Nutzerklick aus ChatGPT oder Google.
Technischer GEO-Audit
Ein technischer Audit sollte die gesamte Zugriffskette testen
Bot-Policy inventarisieren
Relevante Search-, Training-, User-Action- und Suchmaschinenbots samt gewünschter Policy explizit dokumentieren.
robots.txt prüfen
Gruppen, Pfadmuster, Host-Gültigkeit, Sitemaps und unbeabsichtigte globale Disallow-Regeln prüfen.
CDN / WAF testen
403, Challenges, Geo-Regeln, IP-Regeln, Rate Limits und Bot-Management-Ereignisse untersuchen.
HTTP-Verhalten prüfen
Statuscodes, Redirects, Responsegrößen, Header und Responsezeiten auf repräsentativen URLs testen.
Rendering prüfen
Initiales HTML, gerenderten DOM, API-Abhängigkeiten und kritische Ressourcen vergleichen.
Indexsignale prüfen
noindex, X-Robots-Tag, Canonicals, Redirects und Sitemap-Signale auf Konflikte prüfen.
Snippet Controls prüfen
nosnippet, max-snippet und data-nosnippet gegen die gewünschte Search- und AI-Nutzung abgleichen.
Bot-Herkunft verifizieren
User Agents mit aktuellen IP-Ranges, DNS-Verifikation oder Anbietermechanismen validieren.
Logs segmentieren
OAI-SearchBot, GPTBot, ChatGPT-User und Googlebot getrennt nach URL-Gruppe, Status und Zeitraum auswerten.
Coverage Gap ableiten
Soll-Coverage der wichtigen öffentlichen URLs mit tatsächlich beobachtetem Bot-Zugriff vergleichen.
Measurement
Welche Kennzahlen technische GEO-Zugänglichkeit beschreiben können
Anteil relevanter Requests, die ohne WAF-, Auth- oder Rate-Limit-Blockade erfolgreich sind.
Anteil priorisierter URLs, für die innerhalb des Beobachtungsfensters verifizierter Bot-Zugriff gesehen wurde.
Anteil erfolgreicher Responses innerhalb der Bot-Requests.
Anteil 401-, 403-, Challenge- oder vergleichbarer Blockereignisse.
Anteil der Requests mit 429 oder vergleichbarer Drosselung.
Anteil kritischer Inhalte und Metadaten, die im botzugänglichen Dokument vorhanden sind.
Anteil priorisierter URLs mit konsistentem Redirect-, Canonical-, Sitemap- und Internal-Link-Signal.
Anteil priorisierter Seiten ohne unbeabsichtigtes noindex oder andere Indexausschlüsse.
Verteilung der Requests nach Search-, Training- und User-Action-Agenten.
URL-Gruppen mit überdurchschnittlichen 4xx-, 429- oder 5xx-Raten.
Failure Modes
Typische technische Fehler bei GEO-Zugänglichkeit
Häufige Fehlerklassen
- SearchBot versehentlich blockiert
- Eine globale robots-Regel oder eine falsch sortierte User-Agent-Gruppe verhindert OAI-SearchBot-Zugriff
- Training und Search verwechselt
- GPTBot wird blockiert und daraus fälschlich geschlossen, ChatGPT Search sei ebenfalls blockiert – oder umgekehrt
- ChatGPT-User falsch interpretiert
- Nutzerinitiierte Fetches werden als automatischer Search-Crawl gezählt
- WAF False Positive
- robots.txt erlaubt Crawling, aber CDN oder WAF antwortet mit 403 beziehungsweise Challenge
- Rate Limit
- Legitime Crawler treffen 429-Grenzen und erhalten nur eingeschränkten Zugriff
- Client-only Main Content
- Der Hauptinhalt ist ohne erfolgreiche JavaScript- oder API-Ausführung nicht vorhanden
- Canonical Conflict
- HTML, JavaScript, Redirect, Sitemap und interne Links zeigen auf unterschiedliche URL-Versionen
- noindex + robots Disallow
- Der Crawler soll noindex lesen, wird aber durch robots.txt daran gehindert, die Seite abzurufen
- Snippet Restriction unbeabsichtigt
- nosnippet oder max-snippet begrenzen Nutzung stärker als redaktionell beabsichtigt
- UA Spoofing
- Unverifizierte Bot-Imitationen verfälschen Logfile- und Crawling-Analysen
Grenzen
Was technische GEO-Zugänglichkeit nicht beweist
Crawlbar heißt nicht indexiert
Selbst bei erfolgreichem Zugriff entscheidet das jeweilige System separat, ob und wie ein Inhalt gespeichert oder indexiert wird.
Indexiert heißt nicht relevant
Für eine konkrete Anfrage müssen Inhalt und Quelle weiterhin als relevant ausgewählt werden.
Retrieval heißt nicht sichtbare Citation
Ein System kann Informationen verwenden, ohne dieselbe Quelle sichtbar zu zitieren, oder eine andere Quelle bevorzugen.
Bot-Regeln sind nicht universell
User Agents, Produkt-Tokens und deren Semantik werden von den jeweiligen Plattformanbietern definiert und können sich ändern.
Verwandte Entitäten
Welche Leadterion-Entitäten stehen in direkter Beziehung?
GEO
Technische Zugänglichkeit bildet eine Voraussetzung dafür, dass öffentlich bereitgestellte Informationen in generativen Such- und Antwortsystemen technisch erreichbar sein können.
Leistung öffnenGEO-KPIs
Technische Crawl-Metriken sollten von nachgelagerten Visibility- und Citation-Kennzahlen getrennt gemessen werden.
Wissensbeitrag öffnenContext Coverage
Technische Erreichbarkeit löst keine inhaltlichen Context Gaps. Context Coverage beschreibt, ob relevante Problem-Lösungs-Beziehungen überhaupt öffentlich dokumentiert sind.
Lösungsfall öffnenContext Discovery durch Synthetic User
Context Discovery identifiziert fehlende Website-Kontexte; technische GEO-Zugänglichkeit prüft anschließend, ob veröffentlichte Inhalte für relevante Systeme erreichbar sind.
Lösungsfall öffnenRetrieval-Augmented Generation
RAG erklärt, wie externe Inhalte nach erfolgreichem Retrieval als Kontext in generative Antworten eingehen können.
Wissensbeitrag öffnenGroundedness & Faithfulness
Technische Verfügbarkeit einer Quelle sagt noch nichts darüber aus, ob eine spätere Antwort tatsächlich durch diese Quelle gestützt wird.
Wissensbeitrag öffnenFAQ
Häufige Fragen zur technischen GEO-Zugänglichkeit
Was ist technische GEO-Zugänglichkeit?
Technische GEO-Zugänglichkeit beschreibt, ob relevante öffentliche Website-Inhalte für definierte Crawler und Retrieval-Systeme technisch entdeckt, abgerufen und verarbeitet werden können.
Was ist der Unterschied zwischen OAI-SearchBot und GPTBot?
OAI-SearchBot ist laut OpenAI für Search zuständig. GPTBot crawlt Inhalte, die für das Training generativer Foundation Models genutzt werden können. Beide lassen sich in robots.txt unabhängig voneinander steuern.
Was ist ChatGPT-User?
ChatGPT-User wird bei bestimmten nutzerinitiierten Aktionen in ChatGPT oder Custom GPTs verwendet. OpenAI beschreibt ihn nicht als automatischen Webcrawler und weist darauf hin, dass robots.txt bei solchen Nutzeraktionen möglicherweise nicht anwendbar ist.
Kann ich GPTBot blockieren und OAI-SearchBot erlauben?
Ja. OpenAI dokumentiert diese Einstellungen als unabhängig. Damit lässt sich Search-Crawling erlauben und Training-Crawling separat blockieren.
Ist Google-Extended ein eigener Crawler im Serverlog?
Nein. Google dokumentiert, dass Google-Extended keinen eigenen HTTP-User-Agent-String besitzt. Es ist ein robots.txt-Produkt-Token für bestimmte Gemini-bezogene Nutzungen.
Reicht eine korrekte robots.txt für GEO-Zugänglichkeit aus?
Nein. CDN, WAF, Bot Management, HTTP-Fehler, JavaScript-Abhängigkeiten, Canonicals und Indexierungsregeln können den Zugriff oder die Verarbeitung trotzdem verhindern.
Was ist der Unterschied zwischen robots.txt und noindex?
robots.txt steuert den Crawl-Zugriff eines unterstützenden Crawlers. noindex ist eine Indexierungsanweisung auf Seiten- oder Response-Ebene. Ein Crawler muss die Seite abrufen können, um noindex zu lesen.
Welche Rolle spielen nosnippet und max-snippet?
Bei Google steuern diese Regeln die Textmenge, die für Suchdarstellungen verwendet werden darf. Google dokumentiert, dass die Regeln auch direkten Input für AI Overviews und AI Mode beeinflussen.
Warum sind Serverlogs wichtiger als reine Analytics-Daten?
Bot-Requests müssen keinen Client-Side-Analytics-Code ausführen. Server-, CDN- und WAF-Logs erfassen den tatsächlichen HTTP-Zugriff und können deshalb Statuscodes, Blockierungen und User Agents direkt zeigen.
Bedeutet OAI-SearchBot-Traffic, dass eine Seite in ChatGPT zitiert wird?
Nein. Ein Crawl-Hit zeigt technischen Zugriff. Retrieval, Auswahl und sichtbare Citation sind nachgelagerte und separate Prozesse.
Quellen
Primärquellen und technische Dokumentation
Bei Crawlern und Bot-Steuerung sind aktuelle Anbieter-Dokumentationen besonders wichtig, weil User Agents, Produkt-Tokens und technische Regeln von den Plattformbetreibern geändert werden können.
| Quelle | Herausgeber | Einordnung | Originalquelle |
|---|---|---|---|
| Overview of OpenAI Crawlers | OpenAI | Primärquelle zu OAI-SearchBot, GPTBot und ChatGPT-User, ihren Zwecken, robots.txt-Verhalten und veröffentlichten IP-Ranges. | OpenAI Developers |
| Publishers and Developers – FAQ | OpenAI | Erläutert Auffindbarkeit in ChatGPT Search, OAI-SearchBot, noindex und Referral-Kennzeichnung. | OpenAI Help Center |
| Guidance for allowing OpenAI web crawlers | OpenAI | Technische Hinweise zu robots.txt, CDN/WAF, Bot-Abwehr, JavaScript-Challenges, IP-Ranges und Rate Limiting. | OpenAI Help Center |
| RFC 9309 – Robots Exclusion Protocol | IETF / RFC Editor · 2022 | Standardspezifikation des Robots Exclusion Protocol und Grundlage für robots.txt-Verhalten automatischer Crawler. | RFC 9309 |
| Google Search Technical Requirements | Google Search Central | Definiert technische Mindestanforderungen für Google Search: Googlebot-Zugriff, erfolgreicher HTTP-Response und indexierbarer Inhalt. | Google Search Central |
| JavaScript SEO Basics | Google Search Central | Dokumentiert Googles Crawl-, Render- und Indexierungsprozess für JavaScript sowie Hinweise zu Canonicals und noindex. | Google Search Central |
| Canonicalization | Google Search Central | Erläutert Canonical-Auswahl und Signale wie Redirects, rel=“canonical“ und Sitemaps. | Google Search Central |
| Build and Submit a Sitemap | Google Search Central | Dokumentiert Sitemap-Formate, kanonische URL-Empfehlungen und die Rolle von Sitemaps als Hinweis für Discovery und Crawling. | Google Search Central |
| Robots Meta Tags, data-nosnippet and X-Robots-Tag | Google Search Central | Primärquelle für noindex, nosnippet, max-snippet, data-nosnippet und X-Robots-Tag einschließlich Auswirkungen auf AI Overviews und AI Mode. | Google Search Central |
| What Is Googlebot | Google Search Central | Erläutert Googlebot, Crawl-Steuerung und die Verifikation über Reverse DNS beziehungsweise veröffentlichte IP-Ranges. | Google Search Central |
| Common Google Crawlers – Google-Extended | Google Crawling Infrastructure | Definiert Google-Extended als robots.txt-Produkt-Token für Gemini-bezogene Training- und Grounding-Nutzung und stellt klar, dass kein eigener HTTP-User-Agent existiert. | Google Developers |
| How HTTP Status Codes Affect Google’s Crawlers | Google Crawling Infrastructure | Dokumentiert die Interpretation von 4xx, 429 und 5xx durch Google-Crawler und deren Auswirkungen auf Crawling. | Google Developers |
Wissen
Technische GEO-Zugänglichkeit beginnt mit der richtigen Frage: Welches System soll auf welchen Inhalt zu welchem Zweck zugreifen?
Erst wenn Search-Crawler, Training-Crawler, nutzerinitiierte Fetches, klassische Suchmaschinen und Produkt-Tokens sauber getrennt werden, lassen sich robots.txt, Infrastruktur und Logfiles korrekt interpretieren. Der technische Audit verbindet deshalb Policy, tatsächlichen HTTP-Zugriff, Rendering, Indexsignale und beobachtbares Bot-Verhalten.