Il tuo link di condivisione finisce su Google? Test noindex su 7 hosting gratuiti

Quel link a un'immagine che hai incollato al volo in una chat di gruppo su WhatsApp o su un forum italiano potrebbe già essere finito nell'indice di Google, pronto a saltare fuori a chiunque digiti un site: mirato. Non è una minaccia teorica: succede davvero, ed è più comune di quanto si pensi.

A fine luglio 2026 è scoppiato un caso che ha fatto parlare tutta la comunità della sicurezza informatica: bastava digitare site:claude.ai/share su Google per trovare un'enorme quantità di conversazioni AI altrui — con chiavi API, chiavi private di criptovalute, consulenze legali, persino curriculum. La causa non era un attacco hacker, ma un conflitto di configurazione: quelle pagine di condivisione erano marcate come "non scansionabili" nel robots.txt, ma allo stesso tempo avevano impostato X-Robots-Tag: none. Il problema è che se Googlebot viene fermato già dal robots.txt, non riesce nemmeno a entrare — e se non entra, non può leggere il tag noindex che in teoria avrebbe dovuto funzionare. Risultato: le pagine venivano scoperte tramite link esterni e indicizzate, senza che nessun meccanismo riuscisse a bloccarle. È il quarto incidente dello stesso tipo in un anno, dopo ChatGPT (stimate 70.000-100.000 conversazioni) e Grok (centinaia di migliaia).

Cosa c'entra tutto questo con un servizio di hosting immagini? Direttamente nulla — quello era condivisione di chat AI, non foto. Ma la logica sottostante è identica: qualsiasi funzione basata sul principio "privato solo perché nessuno conosce il link, ma senza un blocco corretto dei crawler" è vulnerabile alla stessa dinamica. Anche la pagina di visualizzazione di un hosting immagini funziona così: chi conosce l'URL può vederla. E anche qui servono tre livelli — robots.txt, meta robots, X-Robots-Tag — per bloccare l'accesso. Basta sbagliarne uno per far finire la foto nei risultati di ricerca.

Quindi l'ho verificato di persona.

Tre livelli decidono se una foto finisce indicizzata

Prima di guardare la tabella, chiariamo i criteri, altrimenti sembra magia. Se un URL viene indicizzato o meno da Google dipende da tre livelli distinti: il robots.txt decide se il crawler può entrare in quel percorso; il tag <meta name="robots"> nell'HTML della pagina decide se, una volta entrato, deve indicizzarla; l'header HTTP X-Robots-Tag è un'istruzione di indicizzazione indipendente, con lo stesso effetto del meta tag ma senza dover toccare l'HTML. Tre livelli separati, spesso trattati erroneamente come un'unica cosa — ed è esattamente questo l'errore alla base dell'incidente Claude: il robots.txt bloccava, l'X-Robots-Tag era impostato correttamente, ma nessuno riusciva a leggerlo.

Vale la pena ricordarlo: perché il noindex funzioni, il crawler deve prima poter entrare. Se blocchi un percorso nel robots.txt e contemporaneamente ti aspetti che il tag noindex di quello stesso percorso funzioni, è una contraddizione di design — nella maggior parte dei casi finiscono per non funzionare né l'uno né l'altro.

Come ho condotto il test, e cosa non ho potuto verificare

Diciamolo chiaramente: il rischio più grande in questo tipo di test è scrivere "a memoria". Quindi ecco il metodo. A settembre 2026 ho lanciato curl -I con uno User-Agent da browser sulla pagina di visualizzazione di ogni servizio per leggere gli header HTTP (cercando X-Robots-Tag), poi scaricato l'HTML completo per cercare <meta name="robots">, e infine letto direttamente il robots.txt di ciascun servizio. Per i servizi che renderizzano il contenuto via JavaScript e dove curl non riesce a catturare i link reali (è il caso della sezione consigliati sulla homepage di Imgur), ho usato uno strumento di automazione browser per caricare davvero la pagina prima di estrarre i link.

Per verificare se le foto fossero effettivamente rintracciabili, ho fatto anche ricerche dirette su Google — ma qui devo ammettere un limite onestamente: lo strumento di ricerca che ho usato è stato bloccato proprio dal dominio imgur.com (non da Google, ma dalla protezione anti-bot di Imgur), quindi per la casella "già indicizzato" di Imgur non ho potuto verificare con lo stesso metodo usato per gli altri — posso solo dire, in base alla sola configurazione tecnica, che è "teoricamente indicizzabile", e lo segnalo onestamente nella tabella. Non è qualcosa che voglio nascondere, è un limite dello strumento, e dirlo chiaramente è meglio che far finta di aver testato tutto allo stesso modo.

I risultati del test

Ogni riga di questa tabella corrisponde a un URL e a una risposta HTTP che ho davvero verificato, non a informazioni prese da documentazione di terze parti.

Servizio	Esempio pagina	Restrizioni robots.txt	meta robots / X-Robots-Tag	Stato indicizzazione (test 09/2026)
Imgur	imgur.com/gallery/xxx	Percorso /gallery/ non bloccato	Nessuna impostazione (indicizzabile di default)	Tecnicamente indicizzabile; verifica diretta impossibile perché lo strumento di ricerca è bloccato da imgur.com
ImgBB	ibb.co/xxx	robots.txt completamente vuoto	Nessuna impostazione	Già indicizzato — cercando parole chiave generiche si trovano subito pagine reali con foto
Postimages	postimg.cc/xxx	robots.txt completamente vuoto	Nessuna impostazione	Già indicizzato — anche qui pagine trovate direttamente, con nome file incluso
Flickr	flickr.com/photos/user/id	Alcuni crawler nominati (incluso Googlebot) autorizzati su /photos/	Solo noarchive, nessun noindex	Già indicizzato — trovata la pagina di una foto specifica di un utente specifico
Catbox	files.catbox.moe/xxx	Alcuni percorsi amministrativi bloccati, ClaudeBot/GPTBot bloccati esplicitamente	Il file è un link binario diretto, nessuna pagina HTML dove inserire un meta tag	Non esiste strutturalmente una "pagina di visualizzazione indicizzabile" — senza pagina, non c'è nemmeno il concetto di meta robots
Link di condivisione Google Foto	photos.app.goo.gl/xxx	Percorso /share/ non escluso esplicitamente dal robots.txt	Pagina renderizzata via JS, curl non riesce a leggere il contenuto	Già indicizzato — trovati link di condivisione altrui tramite ricerca, alcuni ancora accessibili
lpic.cc	lpic.cc/codice-breve	Allow: / (aperto a livello di homepage)	Codice sorgente della pagina imposta esplicitamente index: false, follow: true	Noindex esplicito — la pagina di visualizzazione è progettata per non essere indicizzata

Vedendo la riga di Google Foto, devo ammettere che sono rimasto sorpreso per qualche secondo.

Analisi servizio per servizio: dov'è il problema

ImgBB e Postimages sono i due casi più netti di questo test: il robots.txt restituisce direttamente un contenuto vuoto, quindi nessuna restrizione di percorso; nella pagina non c'è nemmeno un tag meta robots. Nessuna restrizione più nessun tag equivale a "completamente aperto" — è il valore predefinito, non un'opzione che l'utente può disattivare al momento del caricamento. Ho trovato risultati quasi istantaneamente, e molti titoli delle pagine erano nomi file originali generati dalla fotocamera del telefono (del tipo IMG_ seguito da data e ora) — segno evidente di foto caricate direttamente dallo smartphone.

Flickr è un caso più sottile, facile da fraintendere. Il suo robots.txt elenca quasi quaranta crawler nominati (incluso Googlebot), e questo elenco esclude solo alcuni account e pagine funzionali specifiche — il percorso standard /photos/utente/id-foto non rientra nella lista di esclusione; la pagina ha solo noarchive (niente snapshot della cache), assolutamente nessun noindex. Questo è un caso concreto: la pagina foto che ho trovato tramite ricerca era un post tutorial dell'account ufficiale che spiegava "come condividere le foto su Flickr" — persino la pagina che insegna a condividere è finita indicizzata, il che ha un che di ironico.

Il link di condivisione di Google Foto è la riga che mi ha preoccupato di più in questo test. Attenzione: un link di condivisione sembra un meccanismo privato — "solo chi lo riceve può vederlo" — ma usando solo parole chiave generiche, senza alcun operatore di ricerca speciale, ho trovato link di condivisione photos.app.goo.gl di altre persone (per motivi di privacy, non riporto qui i link reali). Alcuni, aprendoli, richiedevano il login — segno che il permesso di condivisione è stato modificato o è scaduto nel frattempo; altri invece si aprivano ancora — cioè un link "condiviso privatamente con una persona specifica" è, o è stato, raggiungibile tramite ricerca pubblica. È lo stesso tipo di rischio dell'incidente Claude: il link non aveva un'intenzione pubblica, ma i dettagli delle regole per i crawler determinano se il motore di ricerca finisce per raccoglierlo comunque.

Catbox è un caso a parte. A differenza degli altri servizi, non ha una "pagina di visualizzazione" indipendente — dopo il caricamento ottieni direttamente un link al file, che apre l'immagine stessa, senza alcun involucro HTML dove inserire un meta robots. Questo significa che il tradizionale "controllo del meta robots" qui è semplicemente impossibile da eseguire. Ma non significa che sia più sicuro, solo che il rischio si sposta altrove: la ricerca immagini di Google potrebbe comunque indicizzare l'URL diretto del file, solo che il criterio di verifica è diverso da quello basato su pagine HTML — e su questo punto, onestamente, non ho trovato un metodo di verifica affidabile, quindi non mi invento un numero a caso.

lpic.cc, il mio stesso prodotto, l'ho testato insieme agli altri — non ha senso testare solo la concorrenza. Guardando il codice sorgente si vede che i metadata della pagina di visualizzazione impostano esplicitamente robots: { index: false, follow: true } — cioè, anche se il tuo codice breve viene condiviso da altri e raggiunto da un crawler, la pagina stessa dice attivamente a Google "non indicizzarmi". È un comportamento deciso in fase di progettazione, non una patch aggiunta per questo test. Ma onestamente, il noindex impedisce solo la comparsa nei risultati di ricerca, non impedisce che "chiunque conosca l'URL possa aprirlo" — è proprio per questo che esiste la funzione di protezione con password, e le due cose vanno usate insieme per una protezione completa.

Cosa significa questo per te, in pratica

Tradotto in termini concreti: se carichi foto contenenti dati personali, fatture, screenshot di conversazioni, documenti d'identità su ImgBB o Postimages — servizi con indicizzazione completamente aperta di default — chiunque potrebbe teoricamente trovarle tramite parola chiave o frammenti di testo presenti nell'immagine, senza nemmeno avere bisogno del link che hai condiviso: basta che il motore di ricerca l'abbia già scansionata, ed è lì che aspetta.

C'è uno scenario ancora più insidioso, spesso sottovalutato: quando pubblichi un link a un hosting immagini su un forum o sui social, di solito non pensi "questa foto potrebbe finire indicizzata" — ma se nella foto compaiono nome, indirizzo, parte di un codice fiscale (frequente in screenshot di documenti fiscali, resi, moduli), una volta indicizzata dal motore di ricerca quell'informazione resta esposta permanentemente in rete, finché non te ne accorgi tu stesso e chiedi la rimozione — e la maggior parte delle persone non sa nemmeno dove cercare per farlo. Nell'UE, e quindi anche in Italia, il GDPR impone obblighi stringenti su titolari e responsabili del trattamento: questo tipo di esposizione accidentale rientra comunque nel perimetro della normativa privacy, ma la tutela legale interviene sempre dopo il fatto, mai prima.

Come proteggere i tuoi link di condivisione

Non tutte le foto hanno bisogno dello stesso livello di protezione: il punto è distinguere tra "un meme condiviso al volo" e "uno screenshot con dati personali", e usare strumenti diversi per ciascuno. Tre azioni concrete:

• Cerca tu stesso prima e dopo il caricamento. Prendi il nome del file o un frammento di testo dalla foto e verifica su Google se compaiono segnali di indicizzazione.
• Per contenuti sensibili, evita servizi con indicizzazione aperta di default; scegli servizi che dichiarano esplicitamente il noindex o che offrono protezione con password.
• Imposta tu stesso una scadenza per il link di condivisione, senza affidarti all'idea che "tanto nessuno conosce l'URL" — il caso Claude ha già dimostrato che il crawler non ha bisogno di conoscere l'URL: basta che un qualsiasi link esterno vi punti.

Se cerchi un servizio che integra già "link di condivisione non indicizzato di default" e "protezione con password", la pagina di visualizzazione di lpic.cc è progettata fin dall'inizio con noindex, più la funzione di protezione con password — entrambi i livelli di protezione in un colpo solo. Ma è giusto essere chiari anche sui limiti: nel piano gratuito i contenuti scadono di default 30 giorni dopo il caricamento (nel modulo di upload l'opzione "estendi automaticamente alla visualizzazione" è attiva di default), e alla scadenza vengono eliminati; il servizio si sostiene con la pubblicità. Sono compromessi che è meglio conoscere prima di caricare, non dopo.

Domande frequenti

D1: Se imposto noindex, la foto non finirà mai nei risultati di ricerca? Non è una garanzia assoluta. noindex è una "richiesta" al crawler di non indicizzare, e nella maggior parte dei casi Google la rispetta — ma solo se il crawler riesce effettivamente a leggere quel tag. Se il robots.txt blocca contemporaneamente lo stesso percorso, il crawler non entra nemmeno, quindi non vede il noindex — è esattamente la causa dell'incidente Claude.

D2: Con un hosting a link diretto come Catbox, le foto possono finire indicizzate? Non è verificabile tramite meta robots, perché non esiste una pagina HTML. In teoria la ricerca immagini di Google potrebbe indicizzare direttamente l'URL del file, ma il metodo di verifica è diverso da quello per una pagina web normale — in questo test non ho trovato un modo affidabile per verificarlo, quindi non faccio affermazioni non verificate.

D3: Ho scoperto che una foto caricata su ImgBB è finita indicizzata. Posso rimuoverla dall'indice? Prima elimina la foto originale così l'URL smette di funzionare, poi invia una richiesta di rimozione tramite lo strumento "Rimuovi URL" di Google Search Console — molto più veloce che aspettare che il crawler ripassi naturalmente.

D4: Questo test è di settembre 2026 — se le piattaforme cambiano configurazione dopo? robots.txt e meta tag possono cambiare in qualsiasi momento, non c'è mai una garanzia permanente. Il consiglio non è memorizzare questa tabella, ma verificare da soli con curl -I o gli strumenti sviluppatore del browser — il metodo dura più a lungo della conclusione.

D5: Perché Flickr permette a Googlebot ma blocca la maggior parte degli altri crawler? È una scelta deliberata — permettere ai motori di ricerca principali di indicizzare per mantenere traffico e visibilità, bloccando invece crawler di terze parti non identificati per ridurre il rischio di uso improprio dei contenuti. Sono due compromessi diversi, non la stessa decisione.

D6: In Italia, dove si segnala un'immagine con dati personali indicizzata senza consenso? Oltre a richiedere la rimozione dell'URL tramite Google Search Console, ci si può rivolgere al Garante per la protezione dei dati personali, che gestisce reclami relativi a violazioni del GDPR per esposizione non autorizzata di dati personali online.

Fonti

• Articolo sull'incidente di indicizzazione dei link di condivisione chat Claude (29/07/2026)
• robots.txt di Imgur, ImgBB (ibb.co), Postimages (postimg.cc), Flickr, Google Foto (photos.google.com), Catbox (catbox.moe), ottenuti tramite accesso diretto a settembre 2026
• Header HTTP e codice sorgente HTML delle pagine di visualizzazione dei servizi sopra elencati, testati a settembre 2026 con curl e strumenti di automazione browser
• Codice sorgente dei metadata della pagina di visualizzazione di lpic.cc (app/(public)/[locale]/[code]/page.tsx)