--- title: "Warum ChatGPT unsere Websites nicht lesen konnte" description: "ChatGPT scheiterte an 634 von 634 Abrufen unserer Website. Die Ursache: ein HTTP/2-Bug bei OpenAI. Beweiskette, Fix und Selbst-Check für deinen Server." url: https://hechtinsgefecht.de/chatgpt-crawler-bug/ date_published: 2026-06-12 date_modified: 2026-11-06 organization: HECHT INS GEFECHT organization_url: https://hechtinsgefecht.de organization_knowledge_graph_id: /g/1pp2twrtc organization_sameas: - https://www.northdata.de/HECHT+INS+GEFECHT+GmbH,+Bremen/HRB+42926 - https://firmeneintrag.creditreform.de/28309/2051250968/HECHT_INS_GEFECHT_GMBH - https://www.companyhouse.de/HECHT-INS-GEFECHT-GmbH-Bremen - https://implisense.com/de/companies/hecht-ins-gefecht-gmbh-bremen--DETQXQBC7O52 - https://www.linkedin.com/company/hechtinsgefecht - https://www.xing.com/pages/hecht-ins-gefecht/ - https://social.hechtinsgefecht.de/@hig - https://x.com/hechtinsgefecht - https://www.facebook.com/HechtinsGefecht/ - https://www.instagram.com/hechtinsgefecht/ - https://de.pinterest.com/HechtinsGefecht/ - https://www.threads.com/@hechtinsgefecht - https://www.crunchbase.com/organization/hecht-ins-gefecht-digitalagentur-f%C3%BCr-webdesign-seo - https://clutch.co/profile/hecht-ins-gefecht - https://www.designrush.com/agency/profile/hecht-ins-gefecht - https://agencies.semrush.com/hecht-ins-gefecht/ - https://www.sortlist.de/agency/hecht-ins-gefecht - https://www.goodfirms.co/company/hecht-ins-gefecht - https://techbehemoths.com/company/hecht-ins-gefecht - https://themanifest.com/company/hecht-ins-gefecht - https://www.topseos.com/profile/hecht-ins-gefecht-digitalagentur-fur-webdesign-seo - https://www.semfirms.com/profile/hecht-ins-gefecht - https://www.omt.de/agentur-finden/agentur/hecht-ins-gefecht/ - https://onlinemarketing.de/dienstleister/online-marketing-agentur/bremen/hecht-ins-gefecht - https://www.agenturtipp.de/agentur/hecht-ins-gefecht/ - https://www.seo-united.de/seo-agenturen/hecht-ins-gefecht-3461/ - https://omr.com/de/reviews/service/hecht-ins-gefecht - https://www.ibusiness.de/dienstleister/jb/092582windolph.html - https://feedbax.de/anbieter/hecht-ins-gefecht - https://feedbax.ai/profile/hecht-ins-gefecht - https://www.werbeagentur.de/de/a/hecht-ins-gefecht - https://www.campixx.de/agenturen/seo/hecht-ins-gefecht/ - https://agenturfinder.com/agenturen/hecht-ins-gefecht/ - https://agencyvista.com/agency/hecht-ins-gefecht/marketing-agency/summary - https://www.bark.com/de/de/company/hecht-ins-gefecht/NlYy2/ - https://www.provenexpert.com/de-de/hecht-ins-gefecht/ - https://de.trustpilot.com/review/hechtinsgefecht.de - https://www.trustedshops.de/bewertung/hechtinsgefecht-de - https://www.awwwards.com/HECHTINSGEFECHT/ - https://www.bremen.de/visitenkarte/digitalagentur-hecht-ins-gefecht---webdesign--seo-46684197 - https://www.yelp.com/biz/hecht-ins-gefecht-bremen - https://maps.apple.com/place?place-id=IBAEFB4CEAFB63F7B author: Benny Windolph author_url: https://hechtinsgefecht.de/benny-windolph/ author_orcid: https://orcid.org/0009-0009-2458-3099 author_knowledge_graph_id: /g/11v4_sqnsh --- # Warum ChatGPT unsere Websites nicht lesen konnte Anfang Juni sitze ich an einer routinemäßigen [Crawler-Analyse](https://hechtinsgefecht.de/geo-seo-audit/) 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. Laut Log trat der Fehler schon seit Mitte Mai auf. Dabei erlaubte die robots.txt alles, der Server lief stabil, und das Monitoring zeigte grün. Die Suche nach der Ursache führte zu einem Bug, den vor HECHT INS GEFECHT offenbar niemand öffentlich dokumentiert hatte. Der HTTP/2-Client von OpenAI verschickte fehlerhafte Requests, und der Webserver OpenLiteSpeed beantwortete sie mit einer 404-Seite. Wir haben die Ursache byte-genau nachgewiesen, einen Fix gebaut und ihn noch am selben Tag auf fünf Servern eingerichtet. Bevor Inhalte, Struktur oder Schema für ChatGPT zählen, muss der Abruf technisch gelingen. ## Inhalt 1. [Eine Log-Zeile, die es so gar nicht geben dürfte](#eine-log-zeile-die-es-so-gar-nicht-geben-durfte) 2. [Welcher OpenAI-Bot macht eigentlich was?](#welcher-openai-bot-macht-eigentlich-was) 3. [Die Ursache, byte-genau](#die-ursache-byte-genau) 4. [Was am ChatGPT-Ausfall alles unschuldig war](#was-am-chatgpt-ausfall-alles-unschuldig-war) 5. [Wie groß das Problem wirklich ist](#wie-gross-das-problem-wirklich-ist) 6. [Der Fix: eine HTTP/1.1-Gasse nur für OpenAI](#der-fix-eine-http11-gasse-nur-fur-openai) 7. [Der Beweis im Log](#der-beweis-im-log) 8. [So prüfst du deinen eigenen Server](#so-prufst-du-deinen-eigenen-server) 9. [Häufige Fragen zum ChatGPT-Crawler](#haufige-fragen-zum-chatgpt-crawler) 10. [Quellen](#quellen) ## 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 hatte auf hechtinsgefecht.de immer exakt 711 Bytes, das ist die interne 404-Seite von OpenLiteSpeed. WordPress hat die OpenAI-Requests nie erreicht, sie scheiterten schon im Webserver. Die Auswertung über neun Tage, abgeglichen gegen die offiziellen IP-Listen von OpenAI: | Fetcher | Aufgabe | Ergebnis auf hechtinsgefecht.de | | --- | --- | --- | | ChatGPT-User | Live-Abruf, wenn Nutzer ChatGPT eine Frage stellen | 634 von 634 Requests mit 404, Fehlquote 100 % | | OAI-SearchBot | Macht Websites in der ChatGPT-Suche auffindbar | 68x 404, 75x 200, 47x 301, Fehlquote 36 % | | GPTBot | Sammelt Trainingsdaten | 26x 200, 1x 404, praktisch gesund | Fast wäre ich dabei in eine Falle 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-IP-Bereiche. **Pro-Tipp:** Prüfe Bot-Traffic immer gegen die offiziellen IP-Listen, bevor du Schlüsse ziehst. In den Logs von HECHT INS GEFECHT sind gefälschte ChatGPT-User-Agents keine Seltenheit. ## Welcher OpenAI-Bot macht eigentlich was? OpenAI dokumentiert vier Crawler, nämlich GPTBot, OAI-SearchBot, ChatGPT-User und OAI-AdsBot. Der letzte besucht nur Seiten, die als Anzeige eingereicht wurden. Für deine [Sichtbarkeit in LLMs](https://hechtinsgefecht.de/llm-sichtbarkeit/) zählen die ersten drei. GPTBot sammelt Inhalte, die ins Training der Modelle fließen können. OAI-SearchBot sorgt laut OpenAI dafür, dass Websites in den Suchantworten von ChatGPT erscheinen können. ChatGPT-User ist der Live-Fetcher. Er ruft Seiten in dem Moment ab, in dem ein Nutzer eine Frage stellt. Ob Inhalte in der Suche erscheinen, bestimmt er laut OpenAI nicht. Ein erfolgreicher Abruf ist auch noch kein Zitat. Vom 8. Juli bis 7. August 2026 holte ChatGPT-User bei HECHT INS GEFECHT täglich Seiten mit Status 200. In derselben Zeit zitierte ChatGPT in den Rankscale-Messungen zu fünf Suchanfragen keine einzige unserer URLs. Cloudflare hat in der Auswertung „The crawl-to-click gap“ gemessen, wofür die KI-Bots aller Anbieter zusammen crawlen. In den zwölf Monaten bis Juli 2025 dienten rund 80 % des KI-Crawlings dem Training, 18 % der Suche und 2 % Abrufen, die Nutzer auslösen. Live-Abrufe waren damit der kleinste Teil des KI-Crawlings. Sie hängen aber direkt an einer Nutzerfrage. ChatGPT-User stand bei uns auf 100 % Fehlquote, der Trainings-Crawler lief fast fehlerfrei durch. Wer nur pauschal prüft, ob OpenAI die Website crawlt, übersieht einen solchen Ausfall. Requests der drei OpenAI-Bots über neun Tage im Access-Log von hechtinsgefecht.de, abgeglichen gegen die offiziellen IP-Listen von OpenAI, ein Feld je Request. ChatGPT-User: 634 von 634 Requests mit 404, Fehlquote 100 %. OAI-SearchBot: 68x 404, 47x 301 und 75x 200, Fehlquote 36 %. GPTBot: 26x 200 und 1x 404, praktisch gesund. Requests je OpenAI-Bot Neun Tage Access-Log, abgeglichen gegen die offiziellen IP-Listen Ein Feld = ein Request ChatGPT-User (Live-Abruf) Fehlquote 100 % 634 von 634 Requests mit 404 OAI-SearchBot (Suche) Fehlquote 36 % 68x 404 47x 301 75x 200 GPTBot (Trainingsdaten) praktisch gesund 1x 404 26x 200 Abb. 1 · HECHT INS GEFECHT Abb. 1: Ein Feld je Request der drei OpenAI-Bots: ChatGPT-User bekam auf jeden Abruf eine 404, OAI-SearchBot auf gut ein Drittel, GPTBot blieb praktisch gesund. Für ChatGPT-User gilt laut OpenAI nicht einmal zwingend die robots.txt, weil Nutzer die Abrufe auslösen. Zuverlässig aussperren lässt er sich darüber also nicht. ## Die Ursache, byte-genau Warum loggt ein Webserver `HT2` statt `HTTP/2`? Ganz geklärt ist das nicht. Sicher ist, dass der Pfad schon fehlerhaft beim Server ankam. Der Hexdump eines Abrufs der Startseite zeigt die zusätzlichen Leerzeichen: ``` 47 45 54 20 20 20 20 2f 20 48 54 32 G E T ␣ ␣ ␣ ␣ / ␣ H T 2 (0x20 = Leerzeichen) ``` OpenAI sendete im HTTP/2-Header `:path` führende Leerzeichen, also zum Beispiel `:path = " /schema-strukturierte-daten/"`. Laut RFC 9113, dem HTTP/2-Standard, muss `:path` einen gültigen Pfad enthalten, und der beginnt mit einem Schrägstrich. Ein Request mit Leerzeichen davor gilt als fehlerhaft gebaut (malformed). Der Server muss ihn als Protokollfehler behandeln und darf vorher noch eine Antwort schicken. Für Verstöße gegen die Feldregeln empfiehlt der Standard den Status 400. OpenLiteSpeed bis Version 1.9.0 tat nichts davon. Der Server suchte für den Pfad mit den Leerzeichen eine passende Konfiguration, fand keine und lieferte seine eigene 404-Seite aus. Im error.log steht der entscheidende Satz: ``` No context found for URI: [ /schema-strukturierte-daten/] ``` Reproduzieren ließ sich der Fehler einfach. Ich habe mit der Python-Bibliothek h2 zwei Test-Requests gebaut, einen mit abgeschalteter Header-Normalisierung und Prüfung 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. Gängige Clients wie curl verschicken einen Pfad mit Leerzeichen gar nicht erst. In den Logs von HECHT INS GEFECHT luden Bingbot, ClaudeBot und PerplexityBot dieselben Seiten problemlos, Googlebot kam ohnehin über HTTP/1.1. Weg eines fehlerhaften HTTP/2-Requests von OpenAI an OpenLiteSpeed bis 1.9.0, am Beispiel /schema-strukturierte-daten/. OpenAI sendet im Header :path führende Leerzeichen. OpenLiteSpeed findet für den Pfad keine passende Konfiguration, im error.log steht No context found for URI, und liefert seine eigene 404-Seite mit 711 Bytes zurück; im Access-Log steht HT2 statt HTTP/2. WordPress hat die OpenAI-Requests nie erreicht. Weg eines fehlerhaften Requests Abruf über HTTP/2, Webserver OpenLiteSpeed bis 1.9.0 OpenAI sendet den Request HTTP/2-Request 404, 711 Bytes OpenLiteSpeed sucht eine passende Konfiguration findet keine und liefert seine eigene 404-Seite :path = " /schema-strukturierte-daten/" # führende Leerzeichen vor dem Pfad # error.log No context found for URI: [ /schema-strukturierte-daten/] # access.log "GET /schema-strukturierte-daten/ HT2" 404 711 # HT2 statt HTTP/2 WordPress hat die OpenAI-Requests nie erreicht Abb. 2 · HECHT INS GEFECHT Abb. 2: Der Weg eines fehlerhaften HTTP/2-Requests: OpenLiteSpeed bis 1.9.0 findet für den Pfad mit führenden Leerzeichen keine Konfiguration und liefert seine eigene 404-Seite. WordPress hat die OpenAI-Requests nie erreicht. ## Was am ChatGPT-Ausfall alles unschuldig war Vor dem Eingriff hat HECHT INS GEFECHT vier Verdächtige einzeln geprüft, nämlich das eigene WordPress-Setup, die OpenLiteSpeed-Version, den Webserver als solchen und den eigenen Server. Das Vorgehen war jeweils gleich. Wir stellten eine These auf, bauten ein Gegenexperiment und maßen das Ergebnis. Dieser Ausschluss war der aufwendigste Teil der Arbeit. Er zeigte, dass das Problem über den eigenen Server hinausgeht. ### 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. Das war serponado.org, die Domain von HECHT INS GEFECHT für den SEO-Contest 2026 zum Begriff „Serponado“. Dort lief nur statisches HTML ohne WordPress und PHP, die Server-Konfiguration war von Hand angelegt. Trotzdem stand dieselbe HT2-Signatur im Log, und der OAI-SearchBot scheiterte sogar am Abruf der robots.txt. Für eine Contest-Domain, die in ChatGPT sichtbar werden sollte, war das ein ernstes Problem. Auf zwei Servern, mit und ohne WordPress, trat derselbe Bug auf. Am WordPress-Setup lag es also nicht. ### Die OpenLiteSpeed-Version Zweiter Kandidat: eine veraltete Server-Version. HECHT INS GEFECHT hat zwei frische OpenLiteSpeed-Container mit identischer Konfiguration aufgesetzt, Version 1.8.5 und Version 1.9.0, und beiden dieselben fehlerhaften Requests geschickt. Beide Versionen verhielten sich gleich. Der saubere Pfad bekam 200, der Pfad mit Leerzeichen 404. Version 1.9.2 reagiert anders. In einem Test am 7. Oktober 2026 lieferte OpenLiteSpeed 1.9.2 auf einen solchen Request keine 404 mehr, der Server beendete die Verbindung. Ausgeliefert wird die Seite damit trotzdem nicht. Ob der Client von OpenAI danach auf HTTP/1.1 zurückfällt, ist ungetestet. Nicht getestet sind 1.9.0.1, 1.9.1 und 1.9.3. Ein Update auf 1.9.2 behebt den Ausfall damit nicht. Mit curl prüfst du in 30 Sekunden, ob eine eigene Sperre nach User-Agent greift. Ruf dieselbe URL mit `curl --http1.1` und `curl --http2` auf, jeweils mit einem Bot-User-Agent. Kommt in beiden Protokollen ein 403, greift in der Regel eine eigene Sperre (htaccess, Web Application Firewall oder Bot-Schutz). Den Leerzeichen-Fehler selbst stellt curl nicht nach. Ihn zeigen das Access-Log (auf OpenLiteSpeed bis 1.9.0) und ein Live-Abruf über ChatGPT. ### Der Webserver selbst Dritter Kandidat: OpenLiteSpeed als Sonderfall. HECHT INS GEFECHT hat dieselben fehlerhaften Requests im Test auch an nginx und an die Cloudflare-Edge geschickt. Beide antworteten mit Status 400. Das entspricht dem Standard, hilft dem Bot aber nicht, er bekommt genauso keinen Inhalt. Ein Serverwechsel tauschte im Test nur den Statuscode. Der fehlerhafte Request scheiterte damit auf jedem getesteten Server, nur die Spuren im Log unterschieden sich. Derselbe fehlerhafte Request mit führenden Leerzeichen im Pfad an fünf getestete Server. OpenLiteSpeed 1.8.5 und 1.9.0 antworteten mit 404, der saubere Pfad bekam dort 200. OpenLiteSpeed 1.9.2 beendete im Test am 7. Oktober 2026 die Verbindung. nginx und die Cloudflare-Edge antworteten mit 400. Auf keinem getesteten Server kam Inhalt an. Was die Server im Test antworteten Pfad mit führenden Leerzeichen, Test von HECHT INS GEFECHT Request mit führenden Leerzeichen OpenLiteSpeed 1.8.5 sauberer Pfad: 200 404 OpenLiteSpeed 1.9.0 sauberer Pfad: 200 404 OpenLiteSpeed 1.9.2 Test am 7. Oktober 2026 beendete die Verbindung nginx 400 Cloudflare-Edge 400 Abb. 3 · HECHT INS GEFECHT Abb. 3: Ein Request mit führenden Leerzeichen im Pfad, fünf Server im Test: OpenLiteSpeed bis 1.9.0 antwortet mit 404, Version 1.9.2 beendet die Verbindung, nginx und Cloudflare antworten mit 400. ### Der eigene Server Der vierte Verdächtige war der eigene Server, der die Requests theoretisch selbst hätte verändern können. Dagegen spricht ein sauberer Kontrollbefund. Alle HTTP/1.1-Requests echter OpenAI-IPs waren korrekt aufgebaut, sogar die Leerzeichen-URL kam über HTTP/1.1 korrekt kodiert an. Der Bug steckte damit im HTTP/2-Client von OpenAI. Auf serponado.org folgten zwei fehlerhafte Requests direkt auf eine Weiterleitung von http auf https. Daraus entstand der Verdacht, dass OpenAI beim Folgen einer Weiterleitung den neuen Pfad falsch zusammensetzt. Belegt ist das nicht. ## Wie groß das Problem wirklich ist **LiteSpeed** läuft laut W3Techs auf 14,2 % der Websites mit bekanntem Webserver. OpenLiteSpeed weist W3Techs dabei nicht getrennt aus. Auf nginx und bei Cloudflare erzeugte derselbe Bug im Test 400er, die in keinem SEO-Report auftauchen und im Log leicht untergehen. Wie viele Websites der Bug traf, weiß niemand. ### Auswertung bei Botify zu OpenAI-Crawlern Der Verkehr der **OpenAI-Crawler** ist zugleich stark gewachsen. Der SEO-Berater Chris Long hat als Gastautor bei Botify rund sieben Milliarden Log-Einträge von November 2024 bis März 2026 ausgewertet. Seit dem Start von GPT-5 im August 2025 haben GPTBot und OAI-SearchBot ihr Crawling zusammen etwa verdreifacht. Der OAI-SearchBot wuchs auf das 3,5-Fache. ChatGPT-User ging seit Dezember 2025 dagegen um 28 % zurück. Als möglichen Grund nennt Long, dass weniger Menschen ChatGPT nutzen. Das Team von Botify hält es außerdem für möglich, dass OpenAI öfter auf bereits gespeicherte Seiten zurückgreift. ### Cloudflare-Meldung für das Jahr bis Mai 2025 **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 HECHT INS GEFECHT auf 100 % Fehlquote stand, legten im selben Zeitraum um 2.825 % zu. Im Jahr bis Mai 2025 wuchs also gerade der Abruf am stärksten, der bei uns gar nicht ankam. Für [ChatGPT als Suchsystem](https://hechtinsgefecht.de/chatgpt-seo/) zählt laut OpenAI der OAI-SearchBot. Wer ihn aussperrt, erscheint nicht in den Suchantworten, höchstens noch als Navigationslink. Bei uns scheiterte er an gut einem Drittel seiner Abrufe. Wachstum zweier OpenAI-Bots nach Cloudflare im Jahr bis Mai 2025, Balken maßstäblich ab 0: GPTBot +305 %, ChatGPT-User +2.825 %. Bei HECHT INS GEFECHT scheiterten 634 von 634 Requests von ChatGPT-User mit 404. Wachstum zweier OpenAI-Bots Cloudflare, Jahr bis Mai 2025 Balken maßstäblich ab 0 GPTBot (Trainingsdaten) +305 % ChatGPT-User (Live-Abruf) +2.825 % Bei HECHT INS GEFECHT scheiterten 634 von 634 Requests Abb. 4 · HECHT INS GEFECHT Abb. 4: Wachstum nach Cloudflare, Balken maßstäblich: ChatGPT-User legte um 2.825 % zu, GPTBot um 305 %. Gerade der Live-Fetcher scheiterte bei HECHT INS GEFECHT an jedem Request. ### Der Abruf der Bots auf dem Server Die gängigen Ratgeber für [GEO (Generative Engine Optimization)](https://hechtinsgefecht.de/geo-generative-engine-optimization/) drehen sich um robots.txt-Freigaben, Schema-Markup, Content-Struktur und llms.txt. Robots.txt, Schema und Content-Struktur sind legitime Baustellen, wir bearbeiten sie selbst in jedem Kundenprojekt. In den Ratgebern, die ich mir angeschaut habe, fehlte aber die vorgelagerte Frage, ob die **Requests der Bots** überhaupt heil auf deinem Server ankommen. Nach der [Cost-of-Retrieval-Logik](https://hechtinsgefecht.de/cost-of-retrieval/) ist das der Extremfall. Scheitert der Abruf, sind seine Kosten unendlich hoch, und auch der beste Content ändert daran nichts. ### Antwortzeit des ChatGPT-Live-Fetchers Eine zweite Hürde auf dieser Ebene trifft auch Server ohne den HTTP/2-Bug, nämlich die Antwortzeit. Der **Live-Fetcher** wartet nicht beliebig lange. Der Web-Performance-Experte [Max Böhme](https://www.maxboehme.net/performance-strategie/ai-crawler-server-antwortzeit/) hat dazu Beobachtungen gesammelt. Eine Serverlog-Analyse und ein Konferenzvortrag sahen Abbrüche schon ab etwa 500 bis 800 Millisekunden, auf nginx als Status 499 (der Client hat die Verbindung beendet). Ein offizieller Grenzwert ist das nicht, OpenAI veröffentlicht keine Timeouts. In einem Test mit gezielt geöffneten URLs kam ChatGPT mit bis zu etwa fünf Sekunden Antwortzeit zurecht. Böhme vermutet deshalb zwei Timeout-Stufen, eine längere beim gezielten Öffnen einer URL und eine kürzere, wenn ChatGPT selbst viele Quellen abruft. Laut Böhme versucht es Googlebot bei einer langsamen Antwort später erneut, der Live-Abruf von ChatGPT nicht. Die Protokoll-Ebene davor, an der wir hängengeblieben sind, behandelt Böhme nicht. In beiden Fällen geht der Bot ohne deinen Inhalt, und kein Standard-Tool schlägt Alarm. ### Grenzen des Standard-Monitorings bei ChatGPT-Ausfällen Wie merkst du als Betreiber, dass ChatGPT deine Website nicht abrufen kann? In der Regel merkst du den Ausfall gar nicht. Dein Server schlägt keinen Alarm, für ihn ist eine 404-Antwort Alltag. Dein Uptime-Monitoring testet mit sauberen Clients und sieht 200er. Die Search Console zeigt nichts, weil Google an dieser Stelle nicht beteiligt ist. Auf OpenLiteSpeed bis 1.9.0 zeigt ihn das **Access-Log**, aber nur, wenn du gezielt danach suchst. ### Drosselung der KI-Crawler beim Reiseveranstalter Bei einem Reiseveranstalter auf Shared Hosting drosselte der Hoster die KI-Crawler. **OAI-SearchBot** kam 22-mal, las jedes Mal nur die robots.txt und keinen einzigen Inhalt. GPTBot bekam in 21 bis 30 % der Abrufe einen 429, also die Antwort „zu viele Anfragen“. Auch das zeigt kein Standard-Monitoring, nur das Access-Log. ## 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ürde alle echten Besucher Geschwindigkeit kosten. Rewrite-Regeln und die Web Application Firewall ModSecurity greifen nicht, weil der Request schon vorher scheitert. Ein IP-Block wäre das Gegenteil des Ziels. HECHT INS GEFECHT nennt die Lösung intern die OpenAI-h1-Gasse, eine eigene Spur mit HTTP/1.1 nur für die OpenAI-Bots. Die OpenAI-h1-Gasse als Weiche: Ein Request kommt auf Port 443 an, zwei Firewall-Regeln prüfen den Absender. Nur die rund 300 offiziellen OpenAI-IP-Bereiche gehen auf einen lokalen HAProxy, der per ALPN nur http/1.1 anbietet; danach geht die Verbindung verschlüsselt weiter an OpenLiteSpeed, X-Forwarded-For reicht die echte Bot-IP weiter. Alle anderen Besucher gehen ohne Proxy direkt zu OpenLiteSpeed. Ein stündlicher Timer hält IP-Listen und Zertifikate frisch, der Rollback besteht aus dem Entfernen der zwei Firewall-Regeln und dauert Sekunden. Die Weiche vor OpenLiteSpeed Request auf Port 443 zwei Firewall-Regeln prüfen den Absender rund 300 OpenAI-IP-Bereiche offizielle Listen von OpenAI lokaler HAProxy ALPN: nur http/1.1 verschlüsselt weiter X-Forwarded-For: echte Bot-IP alle anderen Besucher direkt, ohne Proxy OpenLiteSpeed Stündlicher Timer: hält IP-Listen und Zertifikate frisch Rollback: die zwei Firewall-Regeln entfernen, dauert Sekunden Abb. 5 · HECHT INS GEFECHT Abb. 5: Die OpenAI-h1-Gasse als Weiche: Nur die offiziellen OpenAI-IP-Bereiche gehen über den lokalen HAProxy mit http/1.1, alle anderen Besucher gehen ohne Proxy direkt zu OpenLiteSpeed. Im Kern sind das vier Bausteine. Zwei Firewall-Regeln leiten 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, die Protokollwahl beim Verbindungsaufbau) ausschließlich http/1.1 an. Damit nutzt der OpenAI-Client HTTP/1.1, und diese Requests kamen fehlerfrei an. Danach geht die Verbindung verschlüsselt weiter an OpenLiteSpeed. Der Header X-Forwarded-For reicht dabei die ursprüngliche Adresse weiter, so loggt der Server weiterhin die echte Bot-IP. Ein stündlicher Timer hält IP-Listen und Zertifikate frisch. Für normale Besucher ändert sich nichts, ihr Traffic läuft nie über den Proxy. Der Rollback besteht aus dem Entfernen dieser zwei Firewall-Regeln und dauert Sekunden. 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. Nur die Bots, die es brauchen, bekommen ein Protokoll-Downgrade. ## Der Beweis im Log Dieselbe URL vor dem Umbau (9. Juni 2026) und danach (10. Juni 2026): ``` vorher: "GET /schema-strukturierte-daten/ HT2" 404 711 ab 12:57 Uhr: "GET /schema-strukturierte-daten/ HTTP/1.1" 200 35929 ``` HECHT INS GEFECHT hat den Live-Abruf gezielt über die OpenAI-Schnittstelle mit aktivierter Websuche ausgelöst, im Access-Log stand er als ChatGPT-User von einer offiziellen OpenAI-IP. Die Antwort gab die Überschrift und den ersten Satz der Seite wörtlich wieder. Noch am selben Tag ging die Gasse auf vier weitere Server, darunter zwei mit zuvor 45 und 76 fehlgeschlagenen OpenAI-Abrufen pro Tag. Jeden dieser fünf Rollouts haben wir mit einem Live-Abruf geprüft. Von der Entdeckung bis zum Fix auf allen fünf Servern verging insgesamt ein Arbeitstag. Inzwischen ist die Gasse auf neun Servern eingerichtet, bei vier fehlte uns der Zugang zur Prüfung. Eine Internatsberatung zeigt das zweite Fehlerbild, eine eigene Sperre. Sie hatte ChatGPT-User bis Juli 2026 per .htaccess gesperrt, den OAI-SearchBot betraf die Regel nicht. Am 8. September 2026 zitierte ChatGPT die Domain in 0 von 36 Elternfragen, Perplexity über seine Schnittstelle in 24. Ob die frühere Sperre dabei eine Rolle spielt, ist nicht belegt. Die Wurzel des Problems lag im HTTP/2-Client von OpenAI, von außen konnten wir sie nicht beheben. OpenAI verschickte über Wochen Requests, die gegen den HTTP/2-Standard verstießen, und offenbar fiel das niemandem auf. Ob OpenAI den Fehler inzwischen behoben hat, ist offen. Auf den Servern von HECHT INS GEFECHT kommen die OpenAI-Bots seit dem Umbau nur noch über HTTP/1.1 an. OpenLiteSpeed trifft aus meiner Sicht eine Mitschuld. Bis Version 1.9.0 behandelte der Server solche Requests nicht als Protokollfehler und lieferte eine irreführende 404-Seite. Bis zum 10. Juni 2026 haben wir keine öffentliche Dokumentation dieses Fehlerbilds gefunden, und auch danach keinen unabhängigen Bericht. ## So prüfst du deinen eigenen Server Auf OpenLiteSpeed 1.9.2 beendete der Server im Test die Verbindung, ohne eine Zeile ins Log zu schreiben, dort hilft nur der Live-Abruf weiter unten. Auf OpenLiteSpeed bis Version 1.9.0 genügt ein Blick ins Access-Log, der Suchanker ist das Token `HT2` im Protokollfeld: ``` grep -F ' HT2"' access.log | grep -E 'ChatGPT-User|OAI-SearchBot|GPTBot' ``` Prüfe jeden Treffer anschließend gegen die offiziellen OpenAI-IP-Listen. OpenAI veröffentlicht sie je Bot als JSON-Datei auf openai.com. Findest du von OpenAI-IPs stattdessen 403er, blockt in der Regel eine Firewall oder ein Bot-Schutz die Crawler. Das ist ein eigenes Problem, denn der HTTP/2-Bug zeigte sich als 404 (OpenLiteSpeed bis 1.9.0) oder im Test als 400 (nginx, Cloudflare). 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 selbst auslösen. Das hilft auch auf Servern mit OpenLiteSpeed 1.9.2, deren Access-Log den Fehler im Test nicht zeigte. Gib ChatGPT mit aktivierter Websuche den Auftrag, eine konkrete URL deiner Website zu öffnen und die H1 zu zitieren. Beobachte parallel dein Access-Log. Steht in der Antwort ein korrektes Zitat und im Log ein 200er der echten OpenAI-IP, kommt der Live-Abruf durch. 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, hat HECHT INS GEFECHT im Beitrag zur [Indexierung für LLM-Sichtbarkeit](https://hechtinsgefecht.de/indexierung-llm-sichtbarkeit/) aufgeschrieben. HECHT INS GEFECHT ist eine SEO-Agentur aus Bremen. In der laufenden [KI-SEO-Betreuung](https://hechtinsgefecht.de/ki-seo-agentur/) prüfen wir die Erreichbarkeit deiner Inhalte für KI-Crawler. Du erreichst uns über die [Kontaktseite](https://hechtinsgefecht.de/kontakt/). ## Häufige Fragen zum ChatGPT-Crawler ### Woran erkenne ich, dass ChatGPT meine Website nicht lesen kann? Auf OpenLiteSpeed bis Version 1.9.0 erkennst du das Problem am zuverlässigsten im Access-Log, am Token HT2 im Protokollfeld bei Requests mit OpenAI-User-Agent. In einem Test von HECHT INS GEFECHT beendete Version 1.9.2 die Verbindung, ohne eine Zeile ins Access-Log zu schreiben. Auf nginx und Cloudflare sind 400er-Antworten an verifizierte OpenAI-IPs das Warnsignal. Unabhängig vom Server hilft der Live-Test. Du lässt ChatGPT mit Websuche eine URL öffnen und beobachtest parallel das Log. ### Was unterscheidet GPTBot, OAI-SearchBot und ChatGPT-User? GPTBot sammelt Inhalte, die ins Training der OpenAI-Modelle fließen können. OAI-SearchBot sorgt laut OpenAI dafür, dass Websites in den Suchantworten von ChatGPT erscheinen können. ChatGPT-User ruft Seiten live ab, wenn Nutzer ChatGPT eine Frage stellen, entscheidet laut OpenAI aber nicht, ob Inhalte in der Suche erscheinen. Bei HECHT INS GEFECHT scheiterten die drei Bots unterschiedlich oft, nämlich zu 4 %, 36 % und 100 %. ### Betrifft der Bug nur OpenLiteSpeed? Nein, der fehlerhafte Request scheiterte auf allen getesteten Servern. OpenLiteSpeed bis Version 1.9.0 antwortete mit 404 und machte den Fehler über das HT2-Token im Log sichtbar. nginx und Cloudflare lehnten denselben Request im Test von HECHT INS GEFECHT mit 400 ab. Auch dort kam im Test kein Inhalt zurück, es fällt nur weniger auf. Sauber kam der Abruf nur über HTTP/1.1 an. ### Reicht es, HTTP/2 komplett abzuschalten? Technisch ja, denn über HTTP/1.1 kamen die Requests der OpenAI-Bots in den Logs von HECHT INS GEFECHT fehlerfrei an. Du bezahlst dafür aber mit Performance für alle menschlichen Besucher, die dann ebenfalls auf HTTP/1.1 zurückfallen. Die sauberere Lösung ist ein selektives Downgrade, das nur die OpenAI-IP-Bereiche betrifft. Dafür eignet sich ein vorgeschalteter Proxy, der per ALPN nur http/1.1 anbietet, oder ein zweiter Listener ohne HTTP/2. ### Hat der Ausfall auch unsere Google-Rankings beschädigt? Nein, einen Rankingverlust bei Google hat HECHT INS GEFECHT nicht festgestellt. Googlebot kam auf hechtinsgefecht.de über HTTP/1.1 und war von dem Fehler nicht betroffen. Auch Bingbot, ClaudeBot und PerplexityBot luden die Seiten ohne solche Fehler. Betroffen waren die Abrufe der OpenAI-Bots. Ob dadurch Zitate in ChatGPT verloren gingen, ließ sich nicht messen. ## Quellen - [OpenAI: Overview of OpenAI Crawlers](https://developers.openai.com/api/docs/bots) (offizielle Bot-Dokumentation) - [OpenAI: IP-Ranges ChatGPT-User](https://openai.com/chatgpt-user.json), [OAI-SearchBot](https://openai.com/searchbot.json), [GPTBot](https://openai.com/gptbot.json) - [RFC 9113: HTTP/2](https://www.rfc-editor.org/rfc/rfc9113.html) (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](https://www.botify.com/blog/openai-tripled-web-crawl) (Chris Long als Gastautor, April 2026) - [Cloudflare: From Googlebot to GPTBot](https://blog.cloudflare.com/from-googlebot-to-gptbot-whos-crawling-your-site-in-2025/) (Juli 2025) - [Cloudflare: The crawl-to-click gap](https://blog.cloudflare.com/crawlers-click-ai-bots-training/) (August 2025) - [W3Techs: Usage Statistics of LiteSpeed](https://w3techs.com/technologies/details/ws-litespeed) (Stand Oktober 2026) - [Max Böhme: Warum ChatGPT deine Seite ignoriert, Server-Antwortzeiten messen](https://www.maxboehme.net/performance-strategie/ai-crawler-server-antwortzeit/) - [OpenLiteSpeed: Release Notes](https://github.com/litespeedtech/openlitespeed/releases) (Version 1.9.2 vom August 2026 mit strengerer HTTP/2-Header-Prüfung)