Warum ChatGPT unsere Websites nicht lesen konnte

Anfang Juni sitze ich an einer routinemäßigen Crawler-Analyse für hechtinsgefecht.de. Im Access-Log steht eine Zahl, die ich erst für einen Fehler in meiner eigenen Auswertung halte: 634 Abrufe durch den Live-Fetcher von ChatGPT, 634 Fehlschläge. Kein einziger Abruf kam durch, und das mindestens seit Mitte Mai. Dabei erlaubte unsere robots.txt alles, der Server lief stabil, jedes Monitoring zeigte grün.

Die Spurensuche hat einen Bug zutage gefördert, den vor uns offenbar niemand öffentlich dokumentiert hat. OpenAIs eigener HTTP/2-Client verschickt kaputte Requests, und der Webserver OpenLiteSpeed quittiert sie mit einer 404-Seite. Wir haben die Ursache byte-genau nachgewiesen, einen Fix gebaut und ihn noch am selben Tag auf fünf Server ausgerollt. Geblieben ist eine unbequeme Erkenntnis: Deine Sichtbarkeit in ChatGPT entscheidet sich eine Ebene tiefer, als die ganze Debatte um KI-Sichtbarkeit hinschaut.

Eine Log-Zeile, die es so gar nicht geben dürfte

Hunderte Zeilen im Access-Log sahen so aus:

"GET    /schema-strukturierte-daten/ HT2" 404 711

An der Log-Zeile stimmen drei Dinge nicht. Zwischen Methode und Pfad stehen vier Leerzeichen statt einem. Das Protokoll-Feld lautet HT2 statt HTTP/2. Und die Antwort hat immer exakt 711 Bytes, das ist die interne 404-Seite von OpenLiteSpeed. WordPress hat die OpenAI-Requests nie zu Gesicht bekommen, sie sind schon in der Routing-Schicht des Webservers gestorben.

Die Auswertung über neun Tage, abgeglichen gegen die offiziellen IP-Listen von OpenAI:

In eine Falle wäre ich dabei fast getappt: Sechs Requests mit ChatGPT-User im User-Agent sahen im Rohlog nach Erfolg aus. Alle sechs kamen von Spoofern, also von gefälschten Absendern außerhalb der offiziellen OpenAI-Ranges. Pro-Tipp: Verifiziere Bot-Traffic grundsätzlich gegen die offiziellen IP-Listen, bevor du Schlüsse ziehst. Gefälschte ChatGPT-User-Agents sind im Log eher die Regel als die Ausnahme.

Welcher OpenAI-Bot macht eigentlich was?

OpenAI dokumentiert inzwischen vier Crawler: GPTBot, OAI-SearchBot, ChatGPT-User und OAI-AdsBot, wobei der letzte ausschließlich Anzeigen-Landingpages prüft. Für deine Sichtbarkeit in LLMs zählen die ersten drei, und einer davon ganz besonders. GPTBot sammelt Trainingsdaten für künftige Modelle. OAI-SearchBot baut den Suchindex auf, aus dem die ChatGPT-Suche ihre Kandidaten zieht. ChatGPT-User ist der Live-Fetcher. Er ruft Seiten in dem Moment ab, in dem ein Nutzer eine Frage stellt. Aus solchen Live-Abrufen entstehen Zitate und Quellen-Links in der Antwort.

Cloudflare hat das Verhältnis in der Auswertung „The crawl-to-click gap“ vermessen: rund 80 % des AI-Crawlings sind Training, 18 % Suche, magere 2 % entfallen auf nutzerinitiierte Live-Abrufe. Das heißt: ChatGPT-User ist der seltenste der drei Bots und gleichzeitig der einzige, der dich direkt in eine Antwort bringt. Ausgerechnet ChatGPT-User stand bei uns auf 100 % Fehlquote, während der Trainings-Crawler fast fehlerfrei durchlief. Wer nur pauschal prüft, ob „OpenAI“ die Website crawlt, bekommt deswegen ein fatal falsches Bild.

Pikant am Rande: Für ChatGPT-User gilt laut OpenAI-Doku nicht einmal zwingend die robots.txt, weil Nutzer die Abrufe auslösen. Über die robots.txt lässt sich ChatGPT-User also weder zuverlässig einladen noch aussperren. Umso wichtiger ist es, dass der Bot technisch überhaupt durchkommt.

Die Ursache, byte-genau

Warum loggt ein Webserver HT2 statt HTTP/2? Weil die Request-Line schon kaputt beim Server ankommt. Der Hexdump zeigt den Grund schwarz auf weiß:

47 45 54 20 20 20 20 2f 20 48 54 32
G  E  T  ␣  ␣  ␣  ␣  /  ␣  H  T  2      (0x20 = Leerzeichen)

OpenAI sendet im HTTP/2-Header :path führende Leerzeichen, also zum Beispiel :path = " /schema-strukturierte-daten/". RFC 9113, der HTTP/2-Standard, verbietet genau das. Ein solcher Request gilt als malformed, der Server muss ihn als Protokollfehler zurückweisen, und die übliche saubere Antwort dabei ist ein Status 400. OpenLiteSpeed macht nichts davon. Der Server reicht den Pfad ungeprüft in seine Routing-Schicht weiter. Dort findet er keine Route, die mit Leerzeichen beginnt, und liefert die eigene 404-Seite aus. Im error.log steht der entscheidende Satz:

No context found for URI: [   /schema-strukturierte-daten/]

Reproduzieren lässt sich der Fehler erstaunlich einfach. Ich habe mit der Python-Bibliothek h2 zwei Test-Requests gebaut, einen mit abgeschalteter Header-Normalisierung und einen mit dem Standard-Verhalten. Die rohen Leerzeichen-Bytes ergaben 404. Der normalisierte Request bekam 200, weil die Bibliothek den Pfad vor dem Senden selbst trimmt. Übliche Client-Bibliotheken normalisieren auf diese Weise. Googlebot, Bingbot, ClaudeBot und PerplexityBot laden dieselben Seiten in unseren Logs völlig problemlos, nur der HTTP/2-Stack von OpenAI fällt aus der Reihe.

Was am ChatGPT-Ausfall alles unschuldig war

Vor dem Eingriff haben wir vier Verdächtige einzeln widerlegt: das eigene WordPress-Setup, die OpenLiteSpeed-Version, den Webserver als Kategorie und unseren eigenen Server. Das Vorgehen war jeweils gleich: These aufstellen, Gegenexperiment bauen, Ergebnis messen. Die Ausschluss-Arbeit war letztlich der aufwendigste Teil, und sie hat gezeigt, dass das Problem größer ist als gedacht.

WordPress, Plugins, Server-Config

Der erste Verdacht fällt bei so einem Muster in der Regel auf das eigene Setup. Doch ein zweiter, komplett anders aufgesetzter Server zeigte exakt dasselbe Bild: serponado.org, unsere Domain für den SEO-Contest 2026 rund ums Keyword Serponado. Dort läuft pures statisches HTML, kein WordPress, kein PHP, ein manuell konfigurierter vHost. Trotzdem stand dieselbe HT2-Signatur im Log, und der OAI-SearchBot scheiterte sogar am Abruf der robots.txt. Für eine Contest-Domain, die von ChatGPT zitiert werden soll, ist das ein Totalschaden. Zwei Server, zwei komplett verschiedene Setups, ein identisches Fehlerbild: Der Bug hängt allein an der Kombination aus OpenAI-Fetcher und OpenLiteSpeed, nicht an unserem Stack.

Die OpenLiteSpeed-Version

Zweiter Kandidat: eine veraltete Server-Version. Wir haben zwei blanke OpenLiteSpeed-Container aufgesetzt, einmal 1.8.5 und einmal 1.9.0, identische Config, und beide mit denselben kaputten Frames beschossen. Beide Versionen verhielten sich exakt gleich. Der saubere Pfad bekam 200, der Leerzeichen-Pfad 404, in beiden Containern. Die Hoffnung auf ein rettendes Update kannst du dir also sparen.

Der Webserver selbst

Dritter Kandidat: OpenLiteSpeed als Sonderfall. Dieselben malformten Requests gegen nginx und gegen die Cloudflare-Edge gejagt ergibt jeweils Status 400. Das ist RFC-konform, hilft dem Bot aber kein Stück, er bleibt genauso blind. Ein Serverwechsel tauscht nur den Statuscode. Aus der LiteSpeed-Geschichte wird damit ein Web-Problem: Der kaputte Request scheitert auf jedem von uns getesteten Stack und hinterlässt nur unterschiedlich gut sichtbare Spuren.

Wir selbst

Der vierte Verdächtige war unser eigener Server, der die Requests theoretisch selbst hätte verstümmeln können. Dagegen spricht ein sauberer Kontrollbefund: Alle HTTP/1.1-Requests echter OpenAI-IPs sind wohlgeformt, sogar die kaputte Leerzeichen-URL kommt über HTTP/1.1 korrekt encodiert an. Der Defekt sitzt ausschließlich im HTTP/2-Pfad des OpenAI-Stacks. Auffällig oft folgen die Fehler-Requests übrigens direkt auf einen 301-Redirect. Unser Verdacht, und mehr als ein Verdacht ist es Stand heute nicht: Das Redirect-Following von OpenAI baut den neuen Pfad fehlerhaft zusammen.

Wie groß das Problem wirklich ist

Die LiteSpeed-Familie liegt laut W3Techs bei 15,2 % der Websites mit bekanntem Webserver, das sind Millionen potenziell betroffener Hosts mit derselben 404-Signatur wie bei uns. Auf nginx- und Cloudflare-Setups erzeugt derselbe Client-Bug 400er, die in keinem SEO-Report auftauchen und im Log-Rauschen untergehen. Wie viele Websites gerade ChatGPT-Zitate an diesen Bug verlieren, weiß deswegen schlicht niemand, auch OpenAI vermutlich nicht. Ehrlicherweise ist genau diese Unsicherheit der unangenehme Teil des Befunds.

Der Traffic der OpenAI-Crawler wächst unterdessen rasant. Der US-SEO Chris Long hat für Botify mehr als sieben Milliarden Log-Events ausgewertet. Sein Befund: OpenAI hat das Crawling seit dem GPT-5-Launch glatt verdreifacht, allein der OAI-SearchBot legte um Faktor 3,5 zu. Cloudflare meldete schon für das Jahr bis Mai 2025 ein GPTBot-Wachstum von 305 %. Die Abrufe von ChatGPT-User, also genau des Fetchers, der bei uns auf 100 % Fehlquote stand, legten im selben Zeitraum um 2.825 % zu. Der am schnellsten wachsende Abruf-Typ war bei uns der einzige, der gar nicht ankam. Die Zugriffe, um die es hier geht, sind also kein Nischen-Traffic mehr, sondern der Kanal, über den deine Inhalte in ChatGPT-Antworten landen. Bei ChatGPT als Suchsystem ist der Live-Abruf der Moment, in dem über ein Zitat entschieden wird.

Die gängigen Ratgeber für GEO (Generative Engine Optimization) drehen sich derweil um robots.txt-Freigaben, Schema-Markup, Content-Struktur und neuerdings llms.txt. Robots.txt, Schema und Content-Struktur sind legitime Baustellen, wir beackern sie selbst bei jedem Kundenprojekt. Doch kein einziger der Guides, die ich mir angeschaut habe, stellt die Frage davor: ob die Requests der Bots überhaupt heil auf deinem Server ankommen. Die blinde Stelle der Guides folgt der Cost-of-Retrieval-Logik in ihrer härtesten Form. Wenn der Abruf scheitert, sind die Kosten des Abrufs unendlich, und der beste Content der Welt ändert daran nichts.

Es gibt eine zweite Hürde auf dieser Transport-Ebene, und die trifft auch Server ohne den HTTP/2-Bug: die Antwortzeit. Der Live-Fetcher wartet nicht beliebig lange. Serverlog-Analysen zeigen Abbrüche schon ab etwa 500 bis 800 Millisekunden, im Log sichtbar als vorzeitig beendete Verbindung, auf nginx als Status 499. Googlebot kommt bei einer langsamen Antwort später wieder, der Live-Abruf von ChatGPT kennt diesen zweiten Versuch nicht. Max Böhme hat diese Antwortzeit-Schwelle für AI-Crawler im Detail aufbereitet. Die Protokoll-Ebene davor, an der wir hängengeblieben sind, bleibt allerdings auch dort außen vor. Beide Hürden enden gleich: Der Bot geht ohne deinen Inhalt, und kein Standard-Tool schlägt Alarm.

Wie merkst du als Betreiber, dass ChatGPT deine Website nicht abrufen kann? In der Regel merkst du den Ausfall gar nicht. Dein Server meldet nichts, aus seiner Sicht ist eine 404-Antwort Alltag. Dein Uptime-Monitoring testet mit sauberen Clients und sieht fröhlich 200er. Die Search Console schweigt sowieso, Google ist an dieser Stelle gar nicht beteiligt. Bleibt das Access-Log. Dort steht der Schaden schwarz auf weiß, aber nur, wenn du gezielt danach suchst.

Der Befund in einem Satz: OpenAI crawlt so viel wie nie, ausgerechnet der zitatrelevante Fetcher scheitert still auf einem Teil des Webs, und kein Standard-Monitoring zeigt den Ausfall an.

Der Fix: eine HTTP/1.1-Gasse nur für OpenAI

Aus dem Kontrollbefund folgt die Lösung fast von selbst. Wenn der HTTP/1.1-Pfad der OpenAI-Bots nachweislich sauber ist, müssen genau diese Bots auf HTTP/1.1, und zwar nur sie. HTTP/2 global abzuschalten wäre ein Performance-Eigentor für alle echten Besucher. Rewrite-Regeln und ModSecurity greifen nicht, weil der Request schon in der Routing-Schicht davor stirbt. Ein IP-Block wäre das Gegenteil des Ziels.

Die Architektur, wir nennen sie intern die OpenAI-h1-Gasse:

Im Kern sind das vier Bausteine. Eine Firewall-Regel leitet Port 443 nur für die rund 300 offiziellen OpenAI-IP-Bereiche auf einen lokalen HAProxy um. Der Proxy bietet im TLS-Handshake per ALPN (Application-Layer Protocol Negotiation, der Protokollwahl beim Verbindungsaufbau) ausschließlich http/1.1 an, damit fällt der OpenAI-Client von selbst auf seinen fehlerfreien Code-Pfad zurück. Danach geht die Verbindung verschlüsselt weiter an OpenLiteSpeed, der dank X-Forwarded-For weiterhin die echte Bot-IP loggt. Und ein täglicher Timer hält IP-Listen und Zertifikate frisch. Für normale Besucher ändert sich exakt nichts, ihr Traffic berührt den Proxy nie. Der Rollback besteht aus dem Entfernen von zwei Firewall-Regeln und dauert Sekunden, falls doch mal etwas klemmt.

Auf einem nginx-Server haben wir dieselbe Idee ohne HAProxy umgesetzt, über einen zweiten Listener-Socket ohne HTTP/2 und eine nftables-Umleitung. Das Prinzip bleibt gleich: Protokoll-Downgrade nur für die Bots, die es brauchen.

Der Beweis im Log

Dieselbe URL, derselbe Bot, derselbe Tag:

vorher:        "GET    /schema-strukturierte-daten/ HT2" 404 711
ab 12:57 Uhr:  "GET /schema-strukturierte-daten/ HTTP/1.1" 200 35929

Ausgelöst haben wir den Live-Abruf gezielt über die OpenAI-API mit aktivierter Websuche, im Access-Log stand er als ChatGPT-User von einer offiziellen OpenAI-IP. Die Antwort zitierte die Überschrift und den ersten Satz der Seite, wörtlich korrekt. Ich gebe zu, das war ein zufriedenstellender Moment. Noch am selben Tag ging die Gasse auf vier weitere Server, darunter zwei mit zuvor 45 und 76 fehlgeschlagenen OpenAI-Abrufen pro Tag. Jeden einzelnen Rollout haben wir mit einem Live-Abruf einer zuvor gescheiterten URL verifiziert. Von der Entdeckung bis zum Fix auf allen fünf Servern verging insgesamt ein Arbeitstag.

Die Wurzel des Problems können wir von außen nicht beheben, die sitzt im HTTP/2-Client von OpenAI. Dass der größte KI-Anbieter der Welt seit Wochen RFC-widrige Requests verschickt und es offenbar niemandem auffällt, ist für mich die eigentliche Pointe der Geschichte. OpenLiteSpeed trifft eine Mitschuld. Malformte Requests gehören RFC-konform als Protokollfehler abgewiesen, und mit einer sauberen 400 statt der irreführenden 404-Seite wäre das HT2-Muster vermutlich schon vor Monaten jemandem aufgefallen. Wir haben bis zum 10. Juni 2026 keine öffentliche Dokumentation dieses Fehlerbilds gefunden.

So prüfst du deinen eigenen Server

Auf OpenLiteSpeed und LiteSpeed genügt ein Blick ins Access-Log, das Token HT2 ist der Suchanker:

grep -F ' HT2"' access.log | grep -E 'ChatGPT-User|OAI-SearchBot|GPTBot'

Jeden Treffer anschließend gegen die offiziellen OpenAI-IP-Listen prüfen, die Adressen stehen in drei JSON-Dateien auf openai.com. Findest du von OpenAI-IPs stattdessen 403er, blockt eine Firewall oder ein Bot-Schutz die Crawler. Das ist ein eigenes Problem, denn der HTTP/2-Bug zeigt sich als 404 oder 400. Auf nginx, Cloudflare und vergleichbaren Stacks fehlt der HT2-Marker, dort suchst du nach 400er-Antworten an verifizierte OpenAI-IPs. Pro-Tipp: Den Live-Abruf kannst du jederzeit selbst auslösen. Gib ChatGPT mit aktivierter Websuche den Auftrag, eine konkrete URL deiner Website zu öffnen und die H1 zu zitieren. Beobachte parallel dein Access-Log. Kommt in der Antwort ein korrektes Zitat und im Log ein 200er der echten OpenAI-IP an, bist du sauber.

Vielleicht kommt der OAI-SearchBot bei dir sauber durch und deine Seiten tauchen trotzdem in keiner ChatGPT-Antwort auf. Dann liegt ein anderes Problem vor, nämlich ein Indexierungs- oder Relevanz-Thema. Wie du gezielt in die Suchindexe der LLM-Systeme kommst, haben wir im Beitrag zur Indexierung für LLM-Sichtbarkeit aufgeschrieben.

Häufige Fragen zum ChatGPT-Crawler

Quellen

• OpenAI: Overview of OpenAI Crawlers (offizielle Bot-Dokumentation)
• OpenAI: IP-Ranges ChatGPT-User, OAI-SearchBot, GPTBot
• RFC 9113: HTTP/2 (IETF-Standard, Abschnitte 8.2.1 zu Feld-Werten und 8.3.1 zu Pseudo-Headern)
• Botify: OpenAI Has Tripled Their Crawl of the Web (Chris Long, April 2026)
• Cloudflare: From Googlebot to GPTBot (Juli 2025)
• Cloudflare: The crawl-to-click gap (August 2025)
• W3Techs: Usage Statistics of LiteSpeed (Stand Juni 2026)