Nel contesto SEO, il cloaking è la pratica di mostrare contenuti o URL diversi ai motori di ricerca rispetto a quelli che vedono gli utenti. La tecnica punta a manipolare i segnali di ranking servendo una versione “ottimizzata” ai crawler e un’esperienza differente ai visitatori reali. I sistemi di Google e degli altri motori lo considerano spam e possono intervenire con declassamenti o rimozioni dall’indice.
Il meccanismo nasce dal riconoscere il user-agent del bot o il suo intervallo IP. Se il server rileva un crawler, restituisce un markup ricco di keyword, link e testo; se rileva un utente, restituisce un layout normale, spesso con copy più breve o con contenuti commerciali. Questa asimmetria altera il giudizio dell’algoritmo e viola le linee guida sulla ricerca.
Le Norme antispam per la Ricerca indicano il cloaking tra le pratiche non consentite. Il principio è semplice: i contenuti visti dai crawler devono corrispondere a quelli serviti agli utenti, salvo differenze minime dovute al rendering. In caso contrario, la pagina può perdere visibilità o essere esclusa dall’indice. La stessa logica si applica anche ad altri motori che adottano policy simili.
Va distinto il cloaking dalle personalizzazioni lecite. Ad esempio la traduzione tramite hreflang non è cloaking perché ogni utente riceve la versione più adatta. Anche una pagina che adatta valuta e unità di misura può essere legittima se la sostanza informativa rimane uguale per bot e persone.
Molti siti moderni offrono esperienze dinamiche. Mostrare un blocco locale, un banner di consenso, o un prezzo in una valuta non viola le regole se il contenuto chiave resta coerente. Il confine si supera quando si nascondono porzioni sostanziali, quando le query portano a una “pagina fantasma” che il bot vede ma l’utente no, oppure quando i link di cui il crawler tiene conto non sono accessibili ai visitatori.
In pratica, è utile chiedersi: un utente e un crawler possono accedere alla stessa informazione, nello stesso URL, senza passaggi extra? Se la risposta è sì, rientri nella gestione lecita. Se la risposta è no, entra in gioco il rischio cloaking.
Nel gergo tecnico, il cloaking compare in molte forme. Le più note riguardano la discriminazione per user-agent e per IP, l’uso aggressivo di riscritture lato JavaScript e la sostituzione di risorse in base al contesto. Conoscere le varianti aiuta a prevenirle.
Il server legge lo user-agent della richiesta. Se trova stringhe come “Googlebot” o “Bingbot”, serve una pagina ottimizzata ai motori. Se trova un browser comune, serve una pagina diversa. Il comportamento si riconosce facilmente simulando lo user-agent con strumenti da riga di comando o con i DevTools del browser.
Il server mantiene elenchi di subnet dei motori di ricerca e, quando rileva un indirizzo IP in quelle gamme, consegna una versione alternativa del contenuto. La tattica è meno diffusa rispetto allo user-agent cloaking ma continua a emergere in siti che tentano manipolazioni più sofisticate.
Alcuni script montano nel DOM elementi testuali solo quando lo user-agent è un crawler o quando il navigator.webdriver indica un contesto “automatico”. Oppure nascondono blocchi a specifici browser e li mostrano solo a Googlebot. Anche differenze nella catena di rendering CSR/SSR possono generare contenuti che il bot vede interi, mentre l’utente deve compiere interazioni per accedervi.
Manipolare l’header Accept-Language, il fuso orario o la posizione per cambiare sostanzialmente il testo principale può sfociare nel cloaking se la variante servita al crawler non coincide con quella degli utenti nelle stesse condizioni. Le varianti legittime devono mantenere parità di contenuti e messaggi.
Di seguito alcune casistiche emblematiche. Leggendole puoi riconoscere pattern rischiosi nel tuo progetto e disinnescarli in tempo.
Se ti riconosci in almeno uno di questi punti, hai bisogno di un controllo di parità dei contenuti. Lo scopo è allineare la versione “vista da Google” con quella “vista dalle persone” su dispositivo reale.
Lo scopo è semplice: capire se Google e le persone vedono la stessa pagina. Se quello che mostra il motore è diverso da ciò che vede l’utente, c’è un rischio di cloaking. Ecco come controllare senza comandi tecnici.
Apri Search Console, incolla l’URL nella barra di “Ispeziona URL” e avvia l’analisi. Guarda l’anteprima o l’HTML che Google ha rilevato e confrontalo con la pagina vista nel tuo browser. Se Google “vede” testo o link che l’utente non trova, indaga subito.
Apri la pagina in una finestra in incognito. Poi usa un’estensione che simula lo user-agent di Googlebot e ricarica la stessa pagina. Il contenuto principale (titolo, testo, link) deve restare uguale. Se cambia in modo evidente, potresti avere una regola che altera la pagina in base a chi la visita.
Carica l’URL normalmente, poi ricaricalo con JavaScript disattivato (si può fare dalle impostazioni del browser o con un’estensione). Il testo informativo principale deve essere accessibile in entrambi i casi. Se sparisce solo per l’utente, ma a Google risulta presente, è un campanello d’allarme.
Apri due volte la stessa pagina: una volta in navigazione normale e una volta in anonimo. Se vieni spostato su un altro indirizzo o vedi un overlay che copre il contenuto, mentre in Search Console la pagina risulta “pulita”, c’è una discrepanza da correggere.
Chiedi al tuo hosting o allo sviluppatore un breve report per quell’URL: verifica che Googlebot e gli utenti ricevano lo stesso codice di stato (di solito 200) e file di dimensioni simili. Se Google riceve una versione molto più “pesante” o diversa, serve una verifica delle regole su server o CDN.
Allinea le versioni rimuovendo regole che cambiano la pagina in base a user-agent o IP, rendi visibile a tutti il contenuto informativo e ripeti i controlli. Se hai ricevuto una segnalazione, dopo le correzioni invia la richiesta di revisione spiegando cosa è stato sistemato.
Le conseguenze variano. In alcuni casi, un sistema automatico riduce la visibilità delle pagine interessate; in altri, può arrivare un provvedimento manuale con notifica. La rimozione dall’indice è l’esito più severo. Oltre all’impatto in SERP, considera l’effetto su utenti e partner: chi arriva da ricerca e trova qualcosa di diverso ha minore propensione a fidarsi del tuo brand.
Il ripristino richiede un intervento tecnico e un ciclo di verifiche. Le pagine devono tornare in parità, i redirect devono essere coerenti, i contenuti nascosti vanno rimossi o resi accessibili in modo pulito. In presenza di provvedimento manuale serve anche una richiesta di revisione con spiegazione dei cambi applicati.
Molte esperienze moderne si basano su rendering ibrido, componenti condizionali e contenuti che si attivano in differita. Questo non è un problema se imposti correttamente il percorso che porta bot e persone alla stessa informazione.
Se usi Server-Side Rendering genera una base di contenuto completa già all’HTML iniziale. Se usi Client-Side Rendering verifica che il contenuto primario si monti nel DOM anche senza interazioni. Evita che blocchi chiave dipendano da eventi che i crawler non eseguono.
Gestisci le varianti con logiche robuste. Se cambi lingua o valuta, assicurati che il testo informativo resti equivalente per bot e utenti. Evita di sostituire la sezione principale con versioni più “SEO-driven” solo per i crawler. Per i mercati, abbina segnali tecnici come hreflang e un routing chiaro per area linguistica.
Banner, widget social, blocchi di affiliazione cambiano il layout e possono generare differenze tra DOM server-side e client-side. Mantieni stabile il contenuto principale. Evita overlay che coprono il testo per gli utenti e non si attivano davanti ai bot. Quando necessario, sposta elementi non essenziali dopo il contenuto informativo.
Quando emerge un sospetto, definisci un processo in tre fasi: audit, correzione, verifica. L’obiettivo è eliminare ogni differenza ingiustificata, documentare i cambi e stabilire controlli periodici per evitare ricadute.
Raccogli esempi, URL, copie del codice sorgente, screenshot del DOM e campioni di log. Crea una tabella con percorso, differenze osservate, possibile causa, priorità. Identifica le regole lato web server, CDN o app che influenzano IP e user-agent.
Rimuovi le condizioni che discriminano bot e persone. Uniforma i template. Sposta contenuti condizionali in punti prevedibili. Se una pagina richiede gating, usa tecniche che non alterino la sostanza per i crawler. Rivedi i redirect e assicurati che portino gli utenti verso la stessa destinazione valutata dall’algoritmo.
Ripeti i test in riga di comando e visuali. Confronta il DOM finale tra user-agent differenti. Monitora per qualche giorno la stabilità delle risposte. Se c’era un provvedimento manuale, prepara una richiesta di revisione chiara, spiegando cosa è stato risolto e come prevenire il ripetersi del problema.
Per una diagnosi rapida basta una riga di comando. Per un controllo più ampio usa strumenti di crawl che consentono di variare user-agent e IP, oltre a visualizzare il rendering. Incrocia il tutto con i log server o con i report della piattaforma cloud, in modo da rilevare pattern per Paese e dispositivo. Integra nella pipeline di test automatizzati uno step che verifica la parità dell’HTML servito.
Se lavori in team, mantieni una checklist per rilasci e migrazioni. Ogni modifica che tocca routing, caching o CDN va testata anche con user-agent dei crawler. Conserva un registro degli esperimenti e dei roll-back per attribuire in modo corretto eventuali variazioni in SERP.
Il cloaking nasce spesso da buone intenzioni eseguite male. Qui sotto trovi i comportamenti a rischio e cosa fare invece. Se mantieni coerenza tra ciò che valutano i bot e ciò che vive l’utente, proteggi sia l’esperienza sia la visibilità.
Con i framework moderni la tentazione è utilizzare condizioni sul client per personalizzare troppo. Se una sezione compare solo con segnali che i bot non generano, rischi discrepanze. Preferisci SSG o SSR per i contenuti core e lascia al client micro-interazioni e componenti non essenziali. Nei progetti multiregione adotta un router che esponga la stessa struttura per bot e utenti, con segnali internazionali coerenti.
Ricorda che molti crawler eseguono JavaScript, ma non come un utente. Se il contenuto arriva tardi o dipende da eventi complessi, il motore potrebbe non valutarlo. Parità non significa identità pixel-perfect, significa stessa informazione, stesso messaggio, stesso percorso di accesso.
Prima di pubblicare, effettua tre passaggi: test con user-agent del crawler, confronto DOM tra desktop e mobile, verifica dei principali percorsi di navigazione senza script opzionali. Se i risultati sono sovrapponibili, la tua pagina è pronta. Se emergono differenze, correggile subito e ripeti il giro.
Integra la checklist nel flusso CI. Un test automatico che richiama l’URL con due user-agent diversi e confronta gli elementi chiave con un diff semantico previene incidenti in produzione.
Nel contesto dei motori di ricerca è una pratica non consentita. Eccezioni legittime sono personalizzazioni che non alterano il contenuto principale, come lingua, valuta o piccoli blocchi contestuali. La regola è mantenere parità sostanziale tra ciò che vede il crawler e ciò che vede l’utente.
Esegui la pagina con user-agent del bot e di un browser comune. Se il testo informativo, i link principali e i blocchi di valore coincidono, sei al sicuro. Se cambiano in modo significativo, riduci le condizioni e stabilizza il markup iniziale.
Sì. Anche nascondere una singola sezione informativa al pubblico mentre la si mostra al crawler rientra nel cloaking. Valuta ogni blocco che incide sulla comprensione dell’argomento, non solo l’header e il corpo principale.
No se la variante per l’utente è equivalente a quella che il bot vede nelle stesse condizioni. La localizzazione lecita mantiene lo stesso messaggio. In caso di versioni differenziate, usa routing chiaro e segnali come hreflang.
Di per sé no. Diventa un rischio se coprono stabilmente il contenuto per gli utenti ma non per i bot. Imposta gli overlay in modo che non impediscano l’accesso al testo principale.
Puoi subire declassamenti o un provvedimento manuale. Devi riportare le pagine in parità, correggere le regole che discriminano bot e persone e, in caso di provvedimento, inviare una richiesta di revisione con dettagli su cosa è stato risolto.
Sì se i contenuti della lista non sono raggiungibili senza interazioni complesse o se il bot riceve tutte le voci mentre l’utente ne vede poche. Prevedi paginazione accessibile o rendering ibrido che esponga elementi sufficienti già in HTML.
Le varianti devono offrire pari contenuto informativo. Evita di fornire al bot una versione estesa e agli utenti una versione minimale. La parità vale anche tra mobile e desktop, non solo tra bot e persone.
Sì. Chi atterra da una query e trova qualcosa di diverso rispetto all’aspettativa abbandona prima e condivide feedback negativi. Il danno di fiducia pesa quanto la perdita di ranking.
Inserisci un test di parità nel flusso di rilascio. Per ogni URL critico, confronta l’HTML per due user-agent e controlla che elementi, link principali e heading combacino. Documenta le eccezioni accettate e rivedile periodicamente.
Consulta le policy e le guide tecniche: Norme antispam per la Ricerca, Guida all’indicizzazione dei contenuti JavaScript, Aiuto ufficiale sul cloaking. Per test e verifiche: guida alla Search Console.
Riassumendo: il cloaking non è una scorciatoia, è un rischio. Allinea i contenuti tra bot e persone, stabilizza i template, verifica le risposte del server e monitora i cambi in modo trasparente. Con una pipeline di test e una checklist di parità, difendi la tua reputazione e costruisci un traffico che dura nel tempo.
Impostazioni privacy
Questo sito utilizza i cookie per migliorare la tua esperienza di navigazione su questo sito.
