Il segnale arriva quasi sempre così: il traffico organico scende, alcune URL spariscono, Search Console non mostra un colpevole ovvio e il team pensa subito a un core update o a un problema di contenuti. In diversi casi, però, il guasto non è editoriale. È tecnico. E soprattutto è silenzioso.
Quando un server restituisce un codice HTTP a Googlebot e un altro agli utenti reali, entra in una zona che Google considera spam. Non parlo solo del cloaking classico, quello dei contenuti diversi mostrati a bot e persone. Parlo di una variante più subdola: il cloaking dei codici di stato HTTP, dove il server dice a Google “questa pagina è valida” e al browser dell’utente “questa pagina non esiste” oppure “c’è un errore”.
È un problema che vedo spesso sottovalutato perché non si nota navigando il sito in modo superficiale. Se il controllo si limita a “la pagina si apre dal mio browser”, rischi di perdere il punto. Il comportamento può cambiare in base a user-agent, redirect, cache, WAF, CDN, regole nel file di configurazione o logiche lato applicazione.
Nel mercato italiano il rischio non è marginale. Dati AGCOM 2025 indicano che il 18% delle penalizzazioni SEO su e-commerce locali deriva da manipolazioni HTTP cloaking, con 1.200 siti PMI rimossi dall’indice Google negli ultimi 12 mesi. Dal 2024, gli algoritmi AI di Googlebot hanno aumentato del 25% il rilevamento di queste anomalie su siti IT rispetto alla media UE, come riportato da Octotech sul cloaking e sulla tolleranza zero di Google.
Se stai verificando un calo inspiegabile, conviene anche controllare come Google gestisce l’identificazione del crawler. La documentazione aggiornata aiuta a distinguere i bot legittimi dai falsi positivi, e su questo punto è utile la guida di Seowebsite su Googlebot e la documentazione di verifica aggiornata.
Introduzione L'Avviso di Google sul Cloaking Silenzioso
Quando il sito sembra sano ma Google vede altro
La parte insidiosa di questo problema è che spesso il sito, agli occhi del proprietario, “funziona”. La home risponde. Le categorie si caricano. Alcune schede prodotto sono online. Eppure Google inizia a trattare una parte del progetto come inaffidabile.
Succede perché il primo messaggio che il server manda non è il contenuto HTML. È il codice di stato HTTP. Quello è il cartello sulla porta. Se il cartello dice 404 o 500, Google interpreta l’URL in modo molto diverso rispetto a un 200 OK. Se quel cartello cambia a seconda di chi bussa, il motore di ricerca lo considera un comportamento manipolativo.
Perché Google lo considera spam
Google ha una posizione esplicita: il cloaking rientra tra le pratiche proibite quando mostra contenuti o segnali diversi agli utenti e ai crawler con intento manipolativo. Nel caso dei codici HTTP, la manipolazione non sta solo nel testo della pagina. Sta nella risposta tecnica che decide se l’URL è valido, indicizzabile o da escludere.
Regola pratica: se la stessa URL restituisce uno stato diverso a Googlebot e a un utente normale senza una ragione legittima e coerente, devi trattarla come un problema SEO grave.
In consulenza, il pattern ricorrente è questo: migrazione fatta in fretta, plugin di sicurezza troppo aggressivo, regole server copiate da vecchi ambienti, oppure un dev che tenta di “proteggere” pagine o percorsi in modo selettivo. Il risultato finale è identico. Google riceve un segnale, l’utente ne riceve un altro.
Il punto che molti audit saltano
Molti controlli SEO si fermano a title, canonicals, sitemap e contenuti. Sono elementi importanti, ma qui non bastano. Se non analizzi header, log, rendering e risposta differenziale per user-agent, puoi perdere il difetto principale.
Questo è il motivo per cui google mette in guardia contro il cloaking dei codici di stato http con un tono molto più severo di quanto molti pensino. Non è una finezza tecnica per specialisti. È una questione di affidabilità dell’indice.
Cos'è Esattamente il Cloaking dei Codici di Stato HTTP
Il significato reale dei codici HTTP
Ogni volta che browser o crawler richiedono una pagina, il server risponde con un codice di stato. In termini semplici:
- 200 OK significa che la richiesta è andata a buon fine
- 301 o 302 significano che la risorsa è stata spostata
- 404 significa che la pagina non è stata trovata
- 500 segnala un errore lato server
Questi codici non sono dettagli burocratici. Sono istruzioni operative. Dicono a Google se deve usare quella pagina, ignorarla, riprovarla o considerarla instabile.
Google chiarisce che ignora i contenuti degli URL che restituiscono un codice di stato 4xx. Inoltre, nel 2023 il 35% delle penalizzazioni per spam in Italia derivava da cloaking tramite codici HTTP alterati, causando perdite medie di traffico organico del 62% per gli e-commerce di PMI, come indicato nella documentazione e nel contesto riportato da Google sui codici di stato HTTP e la gestione del crawling.
Dove finisce il cloaking tradizionale e inizia quello tecnico
Il cloaking classico mostra contenuti diversi a utenti e motori di ricerca. Quello dei codici di stato fa un passo prima. Manipola il semaforo, non solo la strada.
L’analogia più semplice è quella del postino. Il server è il portiere del palazzo. A Google dice: “Sì, l’appartamento esiste, il destinatario è in casa, puoi registrarlo come valido”. All’utente, davanti alla stessa porta, dice: “Qui non abita nessuno” oppure “c’è un guasto, torna più tardi”. Il problema non è solo la contraddizione. È che Google prende decisioni di indice basandosi su una realtà falsata.
Se la pagina è un negozio, il codice HTTP è l’insegna aperto o chiuso. Non puoi tenere l’insegna “aperto” per Google e “chiuso” per i clienti.
Forme tipiche del problema
Il cloaking dei codici di stato HTTP si presenta spesso in modi meno evidenti di quanto ci si aspetti:
- Controllo sullo user-agent
Il server rileva Googlebot e gli serve un 200, mentre ai browser reali restituisce 404 o 500. - Risposte diverse per geografia, firewall o challenge
Un sistema di protezione blocca o degrada il traffico umano, ma lascia passare il crawler. - Errori applicativi mascherati
La pagina mostra “contenuto non disponibile” o “prodotto inesistente”, ma l’header continua a restituire 200.
Questo terzo caso è spesso confuso con il cloaking intenzionale, ma anche quando nasce da una cattiva implementazione il danno SEO resta.
Esempi Pratici di Cloaking da Evitare
La teoria conta poco se non la traduci in configurazioni concrete. Qui sotto ci sono tre situazioni che incontro di frequente negli audit tecnici.
Risposta diversa in base allo user-agent
È il caso più pulito da capire e uno dei più pericolosi. Una regola lato server o lato applicazione verifica chi sta facendo la richiesta. Se trova “Googlebot”, risponde con 200. Se trova un browser comune, risponde con 404.
Questa logica può essere scritta in molti modi diversi. A volte è nascosta in un middleware. Altre volte in regole di rewrite, plugin di sicurezza o funzioni custom. Il punto non è la tecnologia usata. Il punto è l’effetto: stessa URL, stato diverso, pubblico diverso.
Redirect selettivi che cambiano il significato dell’URL
Secondo scenario: Googlebot viene reindirizzato verso una pagina ottimizzata e coerente, mentre l’utente resta sull’URL originale e riceve una pagina vuota, una soft 404 o un errore.
Qui molti team si confondono perché vedono il redirect e pensano subito a una pratica normale. Ma un redirect è lecito solo quando è coerente per tutti e ha una motivazione tecnica o di esperienza utente trasparente. Se lo usi come corsia preferenziale per il crawler, stai manipolando l’interpretazione dell’URL.
Un redirect corretto accompagna tutti nella stessa destinazione. Un redirect manipolato separa Google dagli utenti.
Errori mascherati da pagine apparentemente valide
Terzo scenario, spesso accidentale. Una pagina di prodotto esaurito, eliminato o irraggiungibile mostra un messaggio di errore all’utente, ma continua a restituire 200. Non è sempre cloaking in senso stretto, ma può diventarlo se il comportamento cambia per bot e persone o se la pagina è costruita per sembrare viva solo ai crawler.
Quando vedo “Prodotto non disponibile” con 200 su migliaia di URL, tratto il caso come un problema di semantica HTTP prima ancora che di contenuto.
Configurazioni Legittime vs. Cloaking Ingannevole
| Scenario | Implementazione Legittima (White-Hat) | Implementazione Ingannevole (Black-Hat Cloaking) |
|---|---|---|
| Pagina rimossa | Restituisce 404 o 410 a tutti gli utenti e ai crawler | Restituisce 200 a Googlebot e 404 agli utenti |
| Redirect di migrazione | 301 uguale per browser e crawler verso la nuova URL | 301 solo per Googlebot verso una pagina “ottimizzata” |
| Pagina con errore applicativo | 5xx quando il server non riesce davvero a generare la risorsa | 200 a Googlebot, 500 o pagina vuota agli utenti |
| Adattamento mobile | Stesso contenuto e stesso significato della risorsa, servito in modo coerente | Versione utile al bot e versione degradata o inesistente all’utente |
Il falso mito dei setup “furbi”
C’è chi pensa che queste differenze possano aiutare a conservare ranking su URL tecnicamente compromesse. Nella pratica succede il contrario. Il motore prima o poi confronta, rileva l’anomalia e la fiducia si rompe. Quando la fiducia tecnica cala, il recupero non passa da un nuovo testo SEO. Passa da pulizia, coerenza e verifica.
I Rischi Concreti per la Tua Visibilità Online
Il primo rischio è semplice: Google può trattare il sito come spam. Non come “sito con qualche errore tecnico”, ma come progetto che altera intenzionalmente i segnali mostrati al motore.
Google ha esplicitamente inserito il cloaking tra le pratiche di spam proibite. Nel contesto italiano, i dati AGCOM del 2023 indicano che il 65% dei siti italiani penalizzati per spam ha coinvolto cloaking o tattiche simili, con perdite medie del 45% nel traffico organico, come riportato nella documentazione ufficiale di Google sulle norme antispam per la Ricerca.
Cosa succede davvero dopo il rilevamento
Le conseguenze non sono tutte uguali, ma in genere si muovono su tre livelli:
- Esclusione di singole URL
Google smette di fidarsi di parti del sito. Le pagine entrano ed escono dall’indice o spariscono. - Azione manuale o forte svalutazione algoritmica
In Search Console può arrivare una notifica. In altri casi non arriva nulla, ma la visibilità crolla lo stesso. - Danno reputazionale tecnico al dominio
Anche dopo la correzione, il sito deve ricostruire affidabilità. Questo richiede tempo e coerenza.
Il costo di business, non solo SEO
Per un e-commerce, questo significa schede prodotto invisibili, categorie che perdono trazione e campagne brand che non trovano più supporto nel traffico organico. Per una PMI B2B significa meno lead da pagine commerciali e meno domanda intercettata nei momenti giusti.
Osservazione operativa: quando il problema è nel livello HTTP, il marketing vede il calo a valle, ma la causa sta a monte. Finché non sistemi il server, nessuna ottimizzazione on-page compensa davvero.
Il punto più scomodo è questo: il cloaking dei codici HTTP crea un divario tra ciò che il team pensa di aver pubblicato e ciò che Google ritiene affidabile. È un divario che taglia ranking, crawl efficiency e capacità di recupero.
Strumenti e Metodi per Diagnosticare il Problema
Il modo corretto di affrontare questo problema non è indovinare. È confrontare risposte reali. Serve vedere la stessa URL da prospettive diverse e verificare se il server racconta due storie.
Per prima cosa, apri una vista concreta in Search Console.
Per approfondire il comportamento del crawler nei casi dubbi, è utile anche la guida di Seowebsite su come controllare l’interazione di Googlebot con il sito.
Controllo URL in Google Search Console
Lo strumento più rapido è Controllo URL. Inserisci una pagina sospetta e osserva tre elementi:
- Stato di indicizzazione
Ti dice se Google considera l’URL accessibile e utilizzabile. - Pagina scansionata
Confronta HTML e screenshot visti da Google con ciò che vedi nel browser. - Risposta HTTP
Se disponibile nel dettaglio tecnico, verifica il codice restituito al crawler.
Se Google vede un 200 e tu ricevi un 404, hai già un indizio forte. Se Google vede una pagina “viva” ma lo screenshot è incoerente o il rendering è parziale, il problema può stare in regole applicative o blocchi intermedi.
Test da terminale con curl
Il controllo manuale da riga di comando è molto utile perché ti permette di cambiare user-agent e leggere subito gli header. Un comando base è questo:
curl -A "Googlebot/2.1 (+http://www.google.com/bot.html)" -I https://tuosito.com/pagina
Poi confrontalo con una richiesta normale:
curl -I https://tuosito.com/pagina
Cosa devi cercare:
- Codice di stato diverso tra richiesta normale e richiesta con user-agent Googlebot
- Location header differente, se partono redirect non previsti
- Header di cache o protezione che cambiano in modo anomalo
Se la risposta cambia solo perché hai cambiato user-agent, non archiviarla come stranezza. Va investigata subito.
Browser DevTools e test umano reale
Apri la pagina dal browser, poi usa F12 e la scheda Network. Ricarica la risorsa e guarda la prima risposta del documento HTML. Non fermarti al fatto che “la pagina si vede”. Verifica il codice di stato effettivo, eventuali redirect e risorse bloccate.
Questo passaggio è utile perché molti errori non si manifestano come pagina completamente rotta. La pagina può caricarsi con componenti mancanti, fallback aggressivi o messaggi di errore lato front-end che nascondono il vero stato server.
Quando l’interfaccia sembra normale ma il documento principale ha una catena di redirect strana o un codice incoerente, il problema è già SEO, non solo tecnico.
Log server e confronto per richiesta
Se vuoi una diagnosi affidabile, vai nei log. È il livello più utile quando il comportamento cambia in modo intermittente o in base a sistemi intermedi.
Controlla:
- User-agent effettivo della richiesta
- Codice di stato restituito
- Percorso richiesto
- Eventuali redirect o riscritture
- Momento esatto dell’errore, per capire se dipende da cache, deploy o filtri di sicurezza
Il confronto migliore è tra un gruppo di richieste Googlebot e un gruppo di richieste umane sulla stessa URL nello stesso intervallo temporale. Se i pattern divergono, il cloaking o una sua variante tecnica è un’ipotesi concreta.
Errori da evitare in fase di diagnosi
Non affidarti a un solo strumento. Search Console vede il mondo dal lato Google. Il browser vede il mondo dal lato utente. curl ti fa testare gli header. I log ti raccontano cosa è successo davvero. Se usi solo uno di questi livelli, rischi una diagnosi incompleta.
Procedure di Correzione e Best Practice di Monitoraggio
La correzione efficace parte da un principio semplice: la stessa URL deve restituire la stessa verità tecnica a tutti, salvo casi legittimi e coerenti. Se oggi il server racconta due versioni, va ripulito senza compromessi.
Correzione immediata
Controlla file di configurazione, regole di rewrite, middleware, plugin di sicurezza, CDN, cache reverse proxy e logiche applicative. Cerca ogni condizione che modifichi la risposta in base a user-agent, challenge, referer o altri segnali non necessari.
Poi esegui una verifica incrociata:
- richiesta browser normale
- richiesta con user-agent Googlebot
- test in incognito
- controllo in Search Console dopo il deploy
Se hai ricevuto un’azione manuale, dopo la bonifica serve documentare bene l’intervento e inviare richiesta di riconsiderazione. Sul tema del recupero è utile anche la guida di Seowebsite su come affrontare gli URL scoperti e attualmente non indicizzati dopo la correzione.
Prevenzione nelle release future
Le buone pratiche qui sono più importanti di qualunque “trucco” SEO:
- Test in staging: ogni modifica a redirect, gestione errori, plugin security e template server va provata prima del rilascio.
- Parità di comportamento: bot e utenti devono ricevere la stessa logica di stato per la stessa risorsa.
- Gestione corretta delle pagine rimosse: se una pagina non esiste più, rispondi con un codice coerente. Non travestirla da pagina viva.
- Controllo dei sistemi intermedi: CDN, firewall e soluzioni anti-bot possono introdurre differenze che il team SEO non vede subito.
Monitoraggio continuo
Il monitoraggio migliore è quello che intercetta la discrepanza prima del danno visibile. Imposta controlli periodici su URL critiche, analizza i log dopo ogni release e guarda Search Console non solo quando il traffico è già sceso.
La trasparenza tecnica non è un dettaglio. È la base che permette a Google di fidarsi del sito nel tempo.
Se vuoi supporto operativo su audit SEO tecnico, contenuti e crescita organica sostenibile, puoi approfondire le risorse e i servizi di Seowebsite, con focus pratico su SEO, performance e link building trasparente.
