ChatGPT-Chats werden von Google indexiert

Vor weniger als 24 Stunden teilten findige SEOs eine pfiffige Entdeckung: Die öffentlichen /share-Unterhaltungen von ChatGPT waren vollständig indexierbar, und einige tauchten bereits in Googles Top 20 für Long-Tail-Suchanfragen auf. Der Fund wirkte wie digitale Alchemie – sofortiger, autoritativer Content, den man nicht selbst schreiben musste. Screenshots landeten auf Twitter, Blogposts schossen aus dem Boden, und einige Opportunisten begannen sogar, die Chats für Schnellschuss-Affiliate-Seiten abzugreifen.

Dann fiel der Hammer.

Am nächsten Morgen war jedes /share-Ergebnis aus Googles Index verschwunden. Geben Sie heute site:chatgpt.com/share ein und Sie sehen null Treffer. OpenAI spielte in schneller Folge drei Änderungen ein – <meta name="robots" content="noindex">, ein siteweites Canonical auf die Homepage und (höchstwahrscheinlich) eine Massenanfrage über Googles URL-Removal-Tool. „ChatGPT-Share-URLs“ wurden damit zum Live-Beispiel für blitzschnelles Deindexieren durch Google.

Eine Schnellumfrage unter 225 Gründern fing die Stimmung ein:

Der Einsatz könnte nicht klarer sein:

• Verlorene Zitationen: Jeder KI-Assistent oder Nachrichtendienst, der Ihren /share-Chat zitiert hat, verliert das Link-Equity, sobald Google die Seite löscht.

• AI-Visibility-Gap: Auf aktuellen Web-Snapshots trainierte LLMs werten Googles Index als Vertrauenssignal. Kein Index, keine Zitation.

• Organic-Traffic-Cliff: Wenn Google Sie in einem einzigen Crawl-Zyklus von der SERP fegen kann, ist Ihre Content-Pipeline nur so robust wie Ihre Compliance-Disziplin.

Der Wachstums-„Hack“ von gestern ist heute zur Warnung geworden – ein Beweis dafür, dass der Weg vom Ranking zum Verschwinden nur einen Google-Refresh entfernt ist, wenn man auf Schlupflöcher statt auf nachhaltige SEO-Grundlagen setzt.

Wie /share-Seiten überhaupt in den Index gelangten

1. Robots.txt ließ die Tür sperrangelweit offen
   Als ChatGPT die öffentliche „Share“-Funktion startete, erlaubte die robots.txt unter User-agent: * explizit das Crawlen von /share/. Für Googlebot war das grünes Licht, jede geteilte Unterhaltung als normale HTML-Seite abzurufen, zu rendern und zu bewerten.

2. Googles Arsenal zur Entdeckung versteckter URLs
   Selbst wenn keine Seite auf diese URLs verlinkte, kann Google sie über passive Datenströme finden, die die SEO-Community „Google Side-Channels“ nennt.

   • Chrome-URL-Hints — wenn Millionen Nutzer einen /share-Link in die Omnibox einfügen oder ihn in ChatGPT anklicken, sendet die Chrome-Telemetrie anonymisierte URL-Samples an Googles Crawl-Scheduler.

   • Android-Link-Resolver — jeder Tap auf eine /share-URL in einer Android-App löst einen Intent aus, der von den Play-Services-Diagnosen protokolliert wird.

   • Gmail- & Workspace-Scans — geteilte Chats, die per E-Mail zwischen Kollegen verschickt werden, werden auf Phishing geprüft; als unbedenklich eingestufte URLs landen in der Crawl-Queue.

   • Public-DNS- & QUIC-Heuristiken — hohe DNS-Look-ups für dasselbe Verzeichnis signalisieren: „Dieser Pfad ist relevant.“

   Ergebnis: Keine internen Links ≠ keine Entdeckung. Google braucht keinen Linkgraphen, wenn das Nutzerverhalten selbst auf neue URLs hinweist.

3. KI-generierter Content wirkt frisch & einzigartig
   Jede /share-Seite enthielt neuartigen Text, der nirgendwo sonst dupliziert war; Googles Freshness-Classifier schrieb ihr sofort Wert zu. Die Kombination aus erlaubt-Crawling und einzigartigem Content brachte die Seiten rasant in den Live-Index – manche binnen weniger Stunden nach dem ersten Teilen.

Googles Blitzaufräumung: Die Vierfach-Lösung

Warum Google innerhalb von 24 Stunden reagieren konnte

• Big-Brand-Priorität: Domains mit hoher Autorität werden häufiger gecrawlt, daher verbreiten sich Direktiven schneller.

• Manueller Schubs: OpenAI hat höchstwahrscheinlich „Abruf wie durch Google“ in der Search Console ausgelöst, um nach Aktivierung der neuen Tags eine Zwangsaktualisierung kritischer Seiten zu erzwingen.

• Automatisches Penalty-Umgehen: Googles Spam-Systeme bestrafen dünnen oder unkontrolliert skalierten User-Generated-Content; OpenAI hatte starken Anreiz, das Risiko zu neutralisieren, bevor eine Black-Hat-ähnliche site-weite Abstrafung greift.

Sind alle vier Hebel umgelegt, werden /share-URLs für Suchende unsichtbar und taugen nicht mehr als SERP-Zitate. Für SEOs ist die Lehre klar: Wenn ein stark frequentierter Pfad plötzlich Marken- oder Compliance-Risiken birgt, ist noindex + Canonical + URL-Removal das schnellste Triple-Play, um ihn verschwinden zu lassen – bevor Googles Penalty-Algorithmen die Entscheidung treffen.

Bings Ein-Million-URL-Kater

OpenAIs Aufräumplan endete bei der Google Search Console. Bing zeigt daher noch rund 1 Million /share-Seiten in den Ergebnissen – eine digitale Geisterstadt von ChatGPT-Unterhaltungen, die bei Google bereits unsichtbar sind. Die Lücke verdeutlicht drei strukturelle Unterschiede zwischen den Engines:

1. Crawl-to-Index-Latenz – Googlebot besucht Domains mit hoher Autorität im Stundentakt; Bingbot braucht oft Tage. Als OpenAI noindex und Canonicals einfügte, crawlte Google schnell erneut und gehorchte. Bing hat seinen Rückstau einfach noch nicht abgebaut.

2. Keine BWT-Intervention – Bings Werkzeuge für URL-Entfernung und Recrawl-Beschleunigung befinden sich in den Bing Webmaster Tools. Alles deutet darauf hin, dass OpenAI dieses Dashboard übersprungen hat, sodass Bingbot weiterhin der ursprünglichen „Allowed“-Direktive folgt, bis sein normaler Rhythmus die Änderungen aufnimmt.

3. Historisches Verzögerungsmuster – Das ist nicht neu. 2021 lieferte Bing WordPress-Favicon-URLs noch Wochen nach ihrer Löschung bei Google, und vergangenes Jahr indexierte es ein geleaktes Font-CSS-Verzeichnis, das Google ignorierte. Die kleinere Bot-Flotte und das konservative Update-Fenster machen die Plattform anfällig für Indexing-Hangovers, wenn eine prominente Site Direktiven abrupt ändert.

Fazit für SEOs: Wenn Sie auf Bing-Traffic oder auf ChatGPT-Zitate bauen, die auf Bings Index beruhen, führen Sie zwei Dashboards. Stellen Sie Lösch- oder Recrawl-Anträge sowohl in der Search Console als auch in den Bing Webmaster Tools – andernfalls droht eine längere Phase, in der zwei Suchmaschinen zwei völlig unterschiedliche Realitäten zeigen.

Warum nicht-englische /share-Ergebnisse in Bing dominieren

Eine kuriose Nebenwirkung von Bings Verzögerung ist, dass die verbliebenen /share-Seiten überwiegend nicht-englisch und nicht-lateinisch sind – Japanisch, Russisch, Arabisch, Thailändisch. Drei Faktoren erklären diese Schieflage:

1. Regionale Index-Slices aktualisieren langsamer – Bing partitioniert seinen Index nach Regionen. Stark frequentierte US-EN-Slices werden zuerst aktualisiert; periphere Sprach-Shards warten eine Woche oder länger, bevor noindex-Seiten entfernt werden.

2. Duplicate-Cluster-Priorisierung – Bings Deduplizierungs-Algorithmus behält pro Canonical-Cluster nur eine URL. Als die englischen Versionen bei Google verschwanden und ihr Link-Equity verloren, verlagerte Bing den Schwerpunkt auf einzigartige nicht-englische Varianten, die weiterhin Nutzersignale lieferten.

3. Serving- vs. Indexing-Diskrepanz – Bing kann eine URL intern als „deindexiert“ markieren, sie aber in Regionen mit geringer Konkurrenz weiter ausliefern, bis der nächste vollständige Deployment-Zyklus läuft. Diese Lücke erklärt, warum arabische Suchanfragen weiterhin /share-Seiten liefern, selbst wenn Bings Indexzähler bereits sinkt.

Optimierungs-Insight: Zu beobachten, welche Sprachen zuerst verschwinden, liefert eine Live-Lektion über Crawl-Budget und Vertrauensmodell der jeweiligen Engine. Bei mehrsprachigen Sites können gestaffelte Direktiven (z. B. zuerst EN, dann JP) unbeabsichtigte Duplicate-Content-Fenster öffnen. Die sicherere SEO-Taktik besteht darin, noindex- und Canonical-Updates global auszurollen und anschließend in jedem lokalen Datencenter per VPN-gestütztem SERP-Check die Entfernung zu verifizieren.