TL;DR: Geteilte ChatGPT-Unterhaltungen tauchten in den Google-Suchergebnissen auf — und wurden dann innerhalb von 24 Stunden wieder deindexiert. Hier ist, was passiert ist, was das für SEO bedeutet und was wir in unseren eigenen Monitoringdaten gesehen haben, als sich das Ganze live abgespielt hat.
Vor weniger als 24 Stunden machten clevere SEOs eine interessante Entdeckung publik: Die öffentlichen /share-Unterhaltungen von ChatGPT konnten problemlos von Google indexiert werden, und einige davon erschienen bereits unter den Top 20 für Long-Tail-Suchanfragen. Die Entdeckung wirkte wie digitale Alchemie — sofort verfügbarer, autoritativ wirkender Inhalt, den man nicht selbst schreiben musste. Screenshots landeten auf Twitter, Blogposts schossen aus dem Boden, und ein paar Opportunisten begannen sogar schon damit, die Chats für schnelle Affiliate-Seiten zu scrapen.
Dann kam der Hammer.
Am nächsten Morgen war jedes einzelne /share-Ergebnis aus dem Google-Index verschwunden. Wenn du heute site:chatgpt.com/share eingibst, bekommst du keine Treffer. OpenAI hat still und schnell drei Änderungen ausgerollt — <meta name="robots" content="noindex">, ein websiteweites Canonical-Tag zur Startseite und (höchstwahrscheinlich) einen Sammelantrag über Googles URL Removal Tool. „ChatGPT-Share-URLs“ wurden damit zum Live-Beispiel dafür, wie schnell Google Seiten aus dem Index entfernen kann.
Wir haben das bei SEOJuice in Echtzeit beobachtet. Als die ersten Berichte auf Twitter auftauchten, habe ich unsere Kundenseiten schnell daraufhin geprüft, ob irgendwelche /share-URLs als konkurrierende Seiten in den SERPs auftauchten. Folgendes haben wir herausgefunden:


/share-Seiten, die für Long-Tail-Keywords in denselben SERPs erschienen. In einem Fall rankte eine geteilte ChatGPT-Unterhaltung zum Thema best CRM for real estate agents auf Platz #14 für eine Suchanfrage, bei der der Blogartikel unseres Kunden auf #11 stand. Das ist nah genug, um bedenklich zu sein./share-Seiten verschwanden, aber die Positionen unserer Kunden verbesserten sich nicht sofort. Die SERP wurde in den folgenden 48 Stunden neu durchgemischt, und andere Seiten füllten die freien Plätze. Das ist eine gute Erinnerung daran, dass die Deindexierung eines Konkurrenten in der SERP dich nicht automatisch nach oben schiebt — Google bewertet alle Kandidaten neu.Die Episode war kurz genug, dass niemand nachhaltigen Schaden erlitten hat. Aber sie wirft eine Frage auf, zu der ich immer wieder zurückkomme: Was passiert, wenn das nächste KI-Unternehmen nicht so schnell reagiert wie OpenAI?
Eine Blitzumfrage unter 225 Gründern hat diesen Stimmungsumschwung ziemlich gut eingefangen:
| Umfrageoption | Stimmen | Erkenntnis |
|---|---|---|
| Ja — das Risiko lohnt sich | 28.9 % | Fast ein Drittel würde bei Black-Hat-Abkürzungen weiter zocken — selbst nachdem sie gesehen haben, wie Seiten über Nacht deindexiert wurden. |
| Nein — ich brauche SEO-Traffic | 40.4 % | Die Pragmatiker, die wissen, dass organischer Traffic ihre Lebensader ist. |
| Moment… mein SEO verschwindet einfach? | 24.9 % | Geschockte Einsteiger, die gerade erst lernen, was Deindexierung in der Praxis wirklich bedeutet. |
| Was sind Backlinks? | 5.8 % | Die selig Ahnungslosen — bis sie selbst dran sind. |
Deutlicher kann das Signal kaum sein:
Zitate gehen verloren: Jeder KI-Assistent oder jedes News-Medium, das deinen /share-Chat zitiert hat, verliert den Linkwert, sobald Google die Seite deindexiert.
KI-Sichtbarkeitslücke: LLMs, die auf frischen Web-Snapshots trainiert werden, nutzen Googles Index als Vertrauenssignal. Kein Index, kein Zitat.
Absturz beim organischen Traffic: Wenn Google dich in einem einzigen Crawl-Zyklus aus der SERP werfen kann, ist deine Content-Pipeline nur so robust wie deine Disziplin bei Richtlinien-Compliance und technischen Vorgaben.
Der Growth-Hack von gestern ist heute ein warnendes Beispiel — ein ziemlich gutes dafür, dass der Weg vom Ranking zur Deindexierung nur einen Google-Refresh entfernt ist, wenn du auf Schlupflöcher statt auf belastbare SEO-Grundlagen setzt.
Das ist aus technischer SEO-Sicht der spannendste Teil, weil er zeigt, wie Google Inhalte entdeckt und indexiert — selbst ohne klassische Linksignale:
Robots.txt ließ die Tür sperrangelweit offen
Als ChatGPT die öffentliche „Share“-Funktion eingeführt hat, hat die robots.txt-Datei das Crawling von /share/ unter User-agent: * ausdrücklich erlaubt. Für Googlebot ist das grünes Licht, jede geteilte Unterhaltung abzurufen, zu rendern und als normale HTML-Seite zu bewerten. Das war wahrscheinlich eher ein Versehen als eine bewusste Entscheidung — OpenAI war auf die Sharing-Funktion fokussiert, nicht auf die SEO-Folgen. (Ist mir auch schon passiert. Unsere Staging-Umgebung war drei Wochen lang indexierbar, bevor es jemand gemerkt hat. Passiert.)
Googles Arsenal zur Entdeckung versteckter URLs
Selbst wenn keine andere Website auf diese Seiten verlinkt hätte, kann Google sie trotzdem über passive Datenkanäle finden — das, was die SEO-Community gern „Google side-channels“ nennt.
Chrome-URL-Hinweise — wenn Millionen Nutzer einen /share-Link in die Omnibox einfügen oder ihn innerhalb von ChatGPT anklicken, speist die Chrome-Telemetrie anonymisierte URL-Samples in Googles Crawl-Scheduler ein.
Android Link Resolver — jeder Tap auf eine /share-URL innerhalb einer Android-App löst einen Intent aus, der in Diagnosedaten der Play Services protokolliert wird.
Gmail- & Workspace-Scans — geteilte Chats, die zwischen Kollegen per E-Mail verschickt werden, werden auf Phishing geprüft; URLs, die als unbedenklich gelten, landen in der Crawl-Queue.
Öffentliche DNS- & QUIC-Heuristiken — DNS-Lookups in hohem Volumen für dasselbe Unterverzeichnis signalisieren: „Dieser Pfad ist relevant.“
Das Ergebnis in einem Satz: Keine internen Links heißt nicht keine Entdeckung. Google braucht keinen klassischen Hyperlink-Graphen, wenn das Nutzerverhalten selbst auf neue URLs zeigt. Das hat Auswirkungen weit über ChatGPT hinaus — wenn du irgendeine Form von öffentlich zugänglichem User-generated Content auf deiner Website hast, findet Google ihn wahrscheinlich über Kanäle, an die du bisher gar nicht gedacht hast.
KI-generierter Inhalt wirkt frisch & einzigartig
Jede /share-Seite enthielt neuen Text, der nicht an anderer Stelle dupliziert war, also hat Googles Freshness-Klassifizierung den Seiten sofort Wert zugeschrieben. Die Kombination aus erlaubtem Crawling und einzigartigem Inhalt hat diese Seiten direkt in den Live-Index beschleunigt — manche innerhalb von Stunden nach dem ersten Teilen.
Was diese Episode für jeden lehrreich macht, der eine große Website verwaltet, ist die Geschwindigkeit und Präzision der Reaktion. Das ist das technische Playbook, das OpenAI verwendet hat:
| # | Maßnahme | Was sie bewirkt | Warum sie schnell wirkt |
|---|---|---|---|
| 1 | <meta name="robots" content="noindex"> hinzufügen |
Sagt Googlebot, dass er weiter crawlen darf, die Seite aber deindexieren soll. | Das Tag wird beim nächsten Crawl respektiert — oft in < 12 h. |
| 2 | <link rel="canonical" href="https://chatgpt.com"> setzen |
Bündelt verbleibende Rankingsignale auf die Homepage. | Verhindert, dass kanonisierte Duplikate später wieder auftauchen. |
| 3 | Sammelantrag über Googles URL Removal Tool | Blendet URLs sofort für etwa 6 Monate aus den Suchergebnissen aus, während die dauerhafte Deindexierung läuft. | Umgeht Crawl-Latenz; wirkt innerhalb von Minuten. |
| 4 (erwartet) | robots.txt aktualisieren und /share/ auf Disallow setzen |
Stoppt Crawl-Anfragen vollständig und reduziert Bandbreite sowie Log-Müll. | Der letzte Feinschliff; stellt sicher, dass neue Share-Links gar nicht erst wieder in die Queue kommen. |
Dieses Vier-Schritte-Playbook — noindex + canonical + URL removal + robots.txt — solltest du dir abspeichern. Wenn du jemals einen großen Bereich deiner Website schnell deindexieren musst (nach einem Leak der Staging-Umgebung, einer versehentlichen Veröffentlichung oder einer Explosion von User-generated Content), ist das der schnellste verfügbare Ansatz. Wir haben im letzten Jahr bei drei Kunden-Notfällen ein sehr ähnliches Playbook genutzt, und es räumt indexierte URLs zuverlässig innerhalb von 24-48 Stunden ab.
Big-Brand-Priorität: Domains mit hoher Autorität werden häufiger gecrawlt, daher verbreiten sich Änderungen an Direktiven schneller. Wenn chatgpt.com Google etwas mitteilt, hört Google ziemlich schnell zu.
Manueller Schubs: OpenAI hat mit ziemlicher Sicherheit „Fetch as Google“ in der Search Console ausgelöst, um kritische Seiten nach dem Livegang der neuen Tags sofort neu abrufen zu lassen.
Vermeidung automatischer Abstrafungen: Googles Spam-Systeme bestrafen dünnen oder unkontrolliert skalierenden User-generated Content; OpenAI hatte also einen starken Anreiz, das Risiko zu neutralisieren, bevor eine websiteweite Abstufung greift.
OpenAIs Aufräum-Playbook endete offenbar bei der Google Search Console. Das Ergebnis: Bing zeigt weiterhin ~1 million /share pages in seinen Ergebnissen — eine digitale Geisterstadt aus ChatGPT-Unterhaltungen, die bei Google inzwischen unsichtbar sind.
Hier wird die Geschichte aus Multi-Engine-SEO-Sicht interessant. Wir haben dieselben drei Kunden-Queries geprüft, bei denen in Google konkurrierende /share-Seiten auftauchten, und festgestellt, dass diese Seiten in Bing eine volle Woche später immer noch rankten. Dieser Unterschied macht drei strukturelle Differenzen zwischen den Suchmaschinen sichtbar:
Crawl-to-Index-Latenz — Googlebot besucht Domains mit hoher Autorität innerhalb von Stunden erneut; Bingbot braucht oft Tage. Als OpenAI noindex und Canonicals eingebaut hat, hat Google schnell neu gecrawlt und die Signale befolgt. Bing war mit seinem Backlog schlicht noch nicht durch.
Keine BWT-Intervention — Alles deutet darauf hin, dass OpenAI Bing Webmaster Tools ausgelassen hat. Das bedeutete, dass Bingbot weiterhin der ursprünglichen „Allowed“-Anweisung folgte, bis sein natürlicher Rhythmus die Änderungen irgendwann einsammelte.
Historisches Lag-Muster — Das ist nichts Neues. 2021 hat Bing noch wochenlang WordPress-Favicon-URLs ausgeliefert, nachdem sie bei Google längst deindexiert waren, und letztes Jahr indexierte es ein geleaktes Font-CSS-Verzeichnis, das Google ignorierte. Bings kleinere Bot-Flotte und konservativeres Update-Fenster machen die Suchmaschine anfällig für Indexing-Hangover, wenn eine prominente Website ihre Direktiven abrupt ändert.
Praktische Erkenntnis: Wenn du auf Bing-Traffic angewiesen bist — oder auf ChatGPT-Zitate, die sich auf Bings Index stützen — dann brauchst du doppelte Dashboards. Reiche Removal- oder Recrawl-Anfragen sowohl in der Search Console als auch in Bing Webmaster Tools ein. Wir haben das nach diesem Vorfall als Standardschritt in unser Notfall-Playbook für Deindexierung aufgenommen, weil wir auf die harte Tour gelernt haben, dass „in Google behoben“ nicht dasselbe ist wie „überall behoben“.
/share-Ergebnisse in Bing dominierenEin merkwürdiger Nebeneffekt von Bings Verzögerung: Die übrig gebliebenen /share-Seiten sind überwiegend nicht-englische Ergebnisse in nicht-lateinischen Alphabeten — Japanisch, Russisch, Arabisch, Thai. Uns ist das aufgefallen, weil einer unserer Kunden eine japanischsprachige Subdomain hat und in Bing JP mehr konkurrierende /share-Seiten sah als in Bing US. Drei Faktoren erklären diese Schieflage:
Regionale Indexsegmente werden langsamer aktualisiert — Bing partitioniert seinen Index nach Sprach- und Ländervarianten. Stark frequentierte US-EN-Segmente werden am schnellsten aktualisiert; kleinere Sprachsegmente warten möglicherweise eine Woche oder länger, bevor noindex-Seiten deindexiert werden.
Priorisierung von Duplicate-Clustern — Bings De-Duplizierungsalgorithmus behält eine URL pro Canonical-Cluster. Als die englischen Versionen aus Google verschwanden und Interlink-Equity verloren, verlagerte Bing das Gewicht auf einzigartige nicht-englische Varianten, die weiterhin Nutzersignale hatten.
Unterschied zwischen Ausspielung und Indexierung — Bing kann eine URL intern bereits als deindexiert markieren, sie aber in Märkten mit geringer Konkurrenz bis zum nächsten vollständigen Deployment-Zyklus weiterhin ausspielen.
Optimierungshinweis: Bei mehrsprachigen Websites können gestaffelte Rollouts von Direktiven (z. B. erst EN, dann JP) unbeabsichtigte Duplicate-Content-Fenster erzeugen. Der sicherere Weg ist, noindex- und Canonical-Updates global auszurollen und die Entfernung anschließend in jedem sprach- oder länderspezifischen Data Center per VPN-basierten SERP-Checks zu verifizieren. Wir haben das inzwischen in unsere Post-Deployment-Checkliste aufgenommen.
Weiterführende Artikel:

no credit card required