De chats van ChatGPT worden geïndexeerd door Google

Nog geen 24 uur geleden deelden scherpe SEO’s een slimme vondst: ChatGPT’s openbare /share-gesprekken waren volledig indexeerbaar en sommige verschenen al in Google’s top 20 voor long-tail zoekopdrachten. De ontdekking voelde als digitale alchemie—onmiddellijk, gezaghebbend materiaal dat je zelf niet hoefde te schrijven. Screenshots doken op Twitter op, blogposts schoten uit de grond en een paar opportunisten begonnen de chats zelfs te scrapen voor snelle affiliate-pagina’s.

Toen volgde de mokerslag.

De volgende ochtend was elk /share-resultaat uit Google’s index verdwenen. Typ vandaag site:chatgpt.com/share en je ziet nul resultaten. OpenAI voerde in rap tempo drie stille wijzigingen door—<meta name="robots" content="noindex">, een site-brede canonical naar de homepage en (hoogstwaarschijnlijk) een bulkverzoek via Google’s URL Removal Tool. “ChatGPT-share-URL’s” werden zo een live casestudy in razendsnelle Google-de-indexatie.

Een snelle peiling onder 225 oprichters ving de stemmingswisseling:

De inzet is glashelder:

• Gemiste citaties: Elke AI-assistent of nieuwsbron die jouw /share-chat citeerde, verliest de linkwaarde zodra Google de pagina wist.

• AI-zichtbaarheidskloof: LLM’s trainen op recente websnapshots en zien Google’s index als vertrouwenssignaal. Geen index, geen citatie.

• Organisch-verkeersravijn: Als Google je in één crawlcyclus van de SERP kan vegen, is je contentpipeline maar zo sterk als je compliance-discipline.

Gisteren’s groeihack is vandaag een waarschuwing—bewijs dat wanneer je op mazen in plaats van duurzame SEO-principes vertrouwt, de afstand van ranken naar verdwijnen slechts één Google-refresh is.

Hoe /share-pagina’s in de eerste plaats geïndexeerd werden

1. Robots.txt liet de deur wagenwijd open
   Toen ChatGPT de openbare “Share”-functie lanceerde, stond in het robots.txt-bestand expliciet Allow voor crawlen van /share/ onder User-agent: *. Voor Googlebot is dat groen licht om elke gedeelde conversatie als normale HTML-pagina op te halen en te beoordelen.

2. Googles arsenaal voor verborgen-URL-ontdekking
   Zelfs als geen enkele site naar die pagina’s linkte, kan Google ze toch vinden via passieve datapijpen die de SEO-gemeenschap “Google side-channels” noemt.

   • Chrome URL-hints — wanneer miljoenen gebruikers een /share-link in de omnibox plakken of erop klikken in ChatGPT, levert Chrome-telemetrie geanonimiseerde URL-samples aan Googles crawlplanner.

   • Android Link Resolver — elke tik op een /share-URL in een Android-app triggert een intent die wordt gelogd door Play-services-diagnostiek.

   • Gmail & Workspace-scans — gedeelde chats die per e-mail worden verstuurd, worden gescand op phishing; URL’s die als veilig gelden gaan de crawlqueue in.

   • Public DNS- & QUIC-heuristieken — hoge volumes DNS-look-ups voor dezelfde submap signaleren “dit pad is belangrijk”.

   Het nettoresultaat: Geen interne links ≠ geen ontdekking. Google heeft geen hyperlink-grafiek nodig als gebruikersgedrag zelf naar nieuwe URL’s wijst.

3. AI-gegenereerde content oogt vers & uniek
   Elke /share-pagina bevatte nieuwe tekst die nergens anders voorkomt, dus Google’s freshness-classifier kende meteen waarde toe. De combinatie van Allow crawlen en unieke content versnelde de opname in de live-index—sommige pagina’s binnen uren na het delen.

Googles snelle schoonmaak: de viervoudige oplossing

Waarom Google binnen 24 uur kon reageren

• Big-brand-prioriteit: Domeinen met hoge autoriteit worden vaker gecrawld, waardoor richtlijnwijzigingen sneller uitwerken.

• Manuele duw: OpenAI heeft vrijwel zeker “Fetch as Google” in Search Console gebruikt om cruciale pagina’s na de nieuwe tags direct te verversen.

• Automatisch penalty-ontwijking: Google’s spamsystemen bestraffen dunne of ongebreideld schaalbare UGC; OpenAI had sterke prikkel om het risico te neutraliseren vóór een black-hat-achtige sitebrede degradatie zou toeslaan.

Als alle vier de hefbomen zijn overgehaald, worden /share-URL’s onzichtbaar voor zoekers en onbruikbaar als SERP-citatie. De les voor SEO’s is duidelijk: als een drukbezocht pad plots merk- of compliancerisico’s oplevert, is noindex + canonical + URL-verwijdering de snelste triple-play om het te laten verdwijnen—voordat Google’s penalty-algoritmen de beslissing voor je nemen.

Bings kater van één miljoen URL’s

OpenAI’s schoonmaakactie stopte bij Google Search Console. Daardoor toont Bing nog steeds ~1 miljoen /share-pagina’s in de resultaten—een digitaal spookstadje van ChatGPT-conversaties die in Google onzichtbaar zijn. Het verschil legt drie structurele afwijkingen tussen de engines bloot:

1. Crawl-naar-index-latentie – Googlebot bezoekt domeinen met hoge autoriteit in uren; Bingbot doet er vaak dagen over. Toen OpenAI noindex en canonicals toevoegde, recrawlde Google snel en gehoorzaamde. Bing is simpelweg nog niet door zijn backlog.

2. Geen BWT-ingreep – Bing’s URL-verwijder- en recrawl-accelerators zitten in Bing Webmaster Tools. Alles wijst erop dat OpenAI dit dashboard oversloeg, waardoor Bingbot nog steeds de oorspronkelijke “Allow”-richtlijn volgt tot zijn natuurlijke cyclus de wijzigingen oppikt.

3. Historisch achterstandspatroon – Dit is niet nieuw. In 2021 serveerde Bing wekenlang WordPress-favicon-URL’s nadat Google ze had verwijderd, en vorig jaar indexeerde het een gelekte font-CSS-map die Google negeerde. Het kleinere bot-park en de voorzichtige update-vensters maken Bing vatbaar voor indexeringskater telkens wanneer een prominent site plotseling richtlijnen omgooit.

Conclusie voor SEO’s: Vertrouw je op Bing-verkeer—of op ChatGPT-citaten die leunen op Bing’s index—beheer dan beide dashboards. Dien verwijder- of recrawl-verzoeken in zowel Search Console als Bing Webmaster Tools in, of bereid je voor op een langdurig vagevuur waarin twee zoekmachines twee zeer verschillende realiteiten tonen.

Waarom niet-Engelstalige /share-resultaten domineren in Bing

Een merkwaardig bijproduct van Bings traagheid is dat de overgebleven /share-pagina’s overwegend niet-Engelstalig, niet-Latijns schrift zijn—Japans, Russisch, Arabisch, Thais. Drie factoren verklaren die bias:

1. Langzamere updates van regionale indexdelen – Bing splitst zijn index per locale. Drukke US-EN-delen verversen het snelst; periferale taalslices kunnen een week of langer wachten voordat noindex-pagina’s worden opgeschoond.

2. Duplicate-cluster-prioritering – Bing’s deduplicatie-algoritme houdt één URL per canonical-cluster. Toen de Engelse versies uit Google verdwenen en linkwaarde verloren, verschoof Bing het gewicht naar unieke niet-Engelse varianten die nog gebruikerssignalen droegen.

3. Verschil tussen serveren en indexeren – Bing kan een URL intern als “gedeïndexeerd” markeren maar toch tonen in lage-competitielocales tot de volgende volledige deploy. Dat gat verklaart waarom Arabische zoekopdrachten nog /share-pagina’s opleveren zelfs nadat Bings indexaantal daalt.

Optimalisatie-inzicht: Monitoren welke talen als eerste verdwijnen biedt een live-les in het crawlbudget en vertrouwensmodel van elke engine. Voor meertalige sites kunnen gefaseerde richtlijn-roll-outs (bijv. eerst EN, dan JP) ongewenste duplicate-content-vensters creëren. De veiligere SEO-tactiek is om noindex- en canonical-updates wereldwijd tegelijk uit te rollen en vervolgens verwijdering in elk locale-specifiek datacenter te verifiëren via VPN-SERP-checks.