Le conversazioni di ChatGPT vengono indicizzate da Google

Meno di 24 ore fa, gli SEO più smaliziati condividevano una scoperta ingegnosa: le conversazioni pubbliche di ChatGPT /share erano completamente indicizzabili e alcune comparivano già nella top 20 di Google per query long-tail. Sembrava alchimia digitale: contenuti autorevoli e immediati che non dovevi nemmeno scrivere. Gli screenshot hanno invaso Twitter, sono spuntati post sui blog e qualche opportunista ha perfino iniziato a fare scraping delle chat per creare pagine affiliate lampo.

Poi è calata la scure.

La mattina successiva ogni risultato /share era sparito dall’indice di Google. Se oggi cerchi site:chatgpt.com/share otterrai zero risultati. OpenAI ha introdotto in silenzio tre cambiamenti in rapida successione—<meta name="robots" content="noindex">, un canonical a livello di sito verso la homepage e (con ogni probabilità) una richiesta massiva tramite lo Strumento di rimozione URL di Google. Gli “URL condivisi di ChatGPT” sono diventati un case study live su quanto velocemente Google possa deindicizzare.

Un sondaggio lampo tra 225 founder ha catturato il cambio di umore:

La posta in gioco non potrebbe essere più chiara:

• Citazioni perse: Qualsiasi assistente AI o testata che citava la tua chat /share perde l’equity del link quando Google cancella la pagina.

• Divario di visibilità AI: Gli LLM addestrati su snapshot recenti del web usano l’indice di Google come segnale di fiducia. Niente indice, niente citazione.

• Caduta libera del traffico organico: Se Google può farti sparire dalla SERP in un solo ciclo di crawl, la tua pipeline di contenuti è forte solo quanto lo è la tua disciplina di compliance.

Il “trucco” di crescita di ieri è diventato la lezione di oggi: quando ti affidi alle scappatoie invece che ai fondamenti SEO solidi, la distanza tra posizionarsi e svanire è un semplice refresh di Google.

Come le pagine /share sono state indicizzate all’inizio

1. Robots.txt ha lasciato la porta spalancata
   Quando ChatGPT ha lanciato la funzione pubblica “Share”, il suo file robots.txt consentiva esplicitamente la scansione di /share/ sotto User-agent: *. Per Googlebot è un semaforo verde per prelevare, renderizzare e trattare ogni conversazione condivisa come una normale pagina HTML.

2. L’arsenale nascosto di Google per scoprire URL
   Anche se nessun sito collegava quelle pagine, Google poteva comunque trovarle tramite canali passivi che la community SEO chiama “side-channel di Google”.

   • Suggerimenti URL di Chrome — quando milioni di utenti incollano un link /share nell’omnibox o lo cliccano dentro ChatGPT, la telemetria di Chrome invia campioni di URL anonimi al pianificatore di crawl di Google.

   • Resolver dei link di Android — qualunque tap su un URL /share all’interno di un’app Android genera un intent registrato dai diagnostici di Play-services.

   • Scansioni di Gmail & Workspace — le chat condivise via mail tra colleghi vengono scansionate per il phishing; gli URL ritenuti sicuri entrano nella coda di crawl.

   • Euristiche DNS pubblici & QUIC — un volume elevato di look-up DNS per la stessa sub-directory segnala “questo percorso è importante”.

   Risultato netto: Nessun link interno ≠ Nessuna scoperta. Google non ha bisogno del grafo dei link quando il comportamento degli utenti indica nuovi URL.

3. I contenuti generati dall’AI sembrano freschi e unici
   Ogni pagina /share conteneva testo inedito non duplicato altrove, quindi il classificatore di freschezza di Google gli ha attribuito valore immediato. La combinazione di crawling Allowed e contenuti unici ha portato le pagine nell’indice live—alcune nel giro di ore dalla prima condivisione.

La pulizia lampo di Google: la soluzione in quattro mosse

Perché Google ha potuto reagire in 24 ore

• Priorità ai grandi brand: i domini ad alta autorità vengono scansionati più spesso, quindi le direttive si propagano più velocemente.

• Intervento manuale: OpenAI con ogni probabilità ha usato “Fetch as Google” in Search Console per forzare il refresh delle pagine critiche dopo l’inserimento dei nuovi tag.

• Evitare penalità automatiche: i sistemi antispam di Google penalizzano contenuti thin o UGC fuori controllo; OpenAI aveva un forte incentivo a neutralizzare il rischio prima che scattasse una demozione stile black-hat su tutto il sito.

Una volta azionate tutte e quattro le leve, gli URL /share diventano invisibili agli utenti e inutilizzabili come citazioni in SERP. Per gli SEO la lezione è chiara: se un percorso ad alto traffico improvvisamente comporta rischi di brand o compliance, noindex + canonical + rimozione URL è la tripletta più rapida per farlo sparire—prima che gli algoritmi di penalità di Google decidano al posto tuo.

Il mal di testa da un milione di URL di Bing

La strategia di pulizia di OpenAI si è fermata a Google Search Console. Di conseguenza, Bing mostra ancora ~1 milione di pagine /share nei suoi risultati—una città fantasma digitale di conversazioni ChatGPT ormai invisibili su Google. La discrepanza evidenzia tre differenze strutturali tra i motori:

1. Latenza crawl-index – Googlebot rivisita i domini ad alta autorità in poche ore; Bingbot spesso impiega giorni. Quando OpenAI ha inserito noindex e canonical, Google ha ricrawllato rapidamente e li ha rispettati. Bing non ha ancora smaltito il suo backlog.

2. Assenza di intervento BWT – lo strumento di rimozione URL e gli acceleratori di ricrawl di Bing si trovano in Bing Webmaster Tools. Tutto indica che OpenAI abbia saltato questa dashboard, per cui Bingbot sta ancora seguendo la direttiva “Allowed” originale finché il suo ciclo naturale non recepirà le modifiche.

3. Storico di ritardi – Non è una novità. Nel 2021 Bing serviva ancora URL favicon di WordPress settimane dopo la loro rimozione da Google, e l’anno scorso ha indicizzato una directory CSS di font trapelata che Google ha ignorato. La flotta più piccola di bot e la finestra di aggiornamento conservativa rendono la piattaforma incline a hangover di indicizzazione ogni volta che un sito di alto profilo cambia direttive improvvisamente.

Messaggio per gli SEO: se ti affidi al traffico Bing—o alle citazioni ChatGPT che poggiano sull’indice di Bing—gestisci due dashboard. Invia richieste di rimozione o ricrawl sia in Search Console che in Bing Webmaster Tools, oppure preparati a un purgatorio prolungato in cui i due motori mostrano realtà molto diverse.

Perché i risultati /share non inglesi dominano su Bing

Un effetto collaterale curioso del ritardo di Bing è che le pagine /share sopravvissute sono in larga parte risultati non inglesi e non in alfabeto latino—giapponese, russo, arabo, thai. Tre fattori spiegano la bias:

1. Gli shard regionali dell’indice si aggiornano più lentamente – Bing partiziona il suo indice per locale. Gli shard ad alto traffico US-EN si aggiornano più in fretta; i segmenti di lingue periferiche possono attendere una settimana o più prima di epurare le pagine noindex.

2. Prioritizzazione dei cluster duplicati – L’algoritmo di deduplicazione di Bing mantiene un URL per cluster canonico. Quando le versioni inglesi sono sparite da Google e hanno perso equity di link, Bing ha spostato il peso su varianti uniche non inglesi che ancora portavano segnali di engagement.

3. Disparità tra serving e indexing – Bing può segnare internamente un URL come “deindicizzato” ma continuare a servirlo in mercati a bassa concorrenza finché non avviene il prossimo ciclo di deploy completo. Questo spiega perché le query in arabo mostrano ancora pagine /share anche dopo che il conteggio nell’indice di Bing inizia a calare.

Insight di ottimizzazione: monitorare quali lingue spariscono per prime offre una lezione live sul crawl budget e sul modello di fiducia di ciascun motore. Per i siti multilingue, rollout scaglionati delle direttive (es. prima EN, poi JP) possono creare finestre di contenuto duplicato involontario. La tattica SEO più sicura è distribuire in modo globale aggiornamenti noindex e canonical, quindi verificare la rimozione in ogni data center locale tramite controlli SERP basati su VPN.