TL;DR — Google non penalizza tutti i contenuti nascosti via CSS o JavaScript. Le Spam Policies di Google Search colpiscono solo l’hidden text with intent to manipulate ranking. Un accordion mobile, un tab dinamico o un blocco reso con display:none per motivi di UX non generano azione manuale né demotion algoritmica, ma i contenuti nascosti non sono trattati con peso pieno in ogni scenario: dipende da come Googlebot li renderizza e dalla chiarezza dell’intento.
Questo articolo non è una panoramica generica su “come nascondere testo”: è un’analisi tecnica di tutte le tecniche CSS/HTML/JS disponibili nel 2026, classificate per rischio SEO, con riferimenti alla documentazione ufficiale Google Search Central, al comportamento del Web Rendering Service (WRS) basato su headless Chromium e ai pattern UX conformi alle Google Search Essentials.
Google penalizza i testi nascosti? Risposta diretta
La risposta breve è no, non in modo automatico. Il testo nascosto è una tecnica: viene valutata dall’intento. Le Spam Policies di Google pubblicate su Search Central definiscono esplicitamente due condizioni cumulative perché scatti una violazione:
- Il contenuto è nascosto all’utente ma visibile ai motori di ricerca.
- L’intento è manipolare il ranking, non migliorare la UX.
Se una delle due condizioni manca, non c’è violazione. Un accordion che mostra 4 FAQ dietro click è nascosto al primo paint, ma visibile sia al DOM di Googlebot sia all’utente che vi interagisce: non è spam. Un display:none applicato a un contenitore con 2000 parole di keyword stuffing irrilevanti rispetto al topic è spam, indipendentemente dalla tecnica CSS scelta.
Dal 2016 Gary Illyes ha dichiarato pubblicamente (vedi il tweet più avanti) che nell’indice mobile-first “content hidden for UX should have full weight”: la vecchia regola “il testo dietro tab pesa di meno” era valida nell’era del desktop-first indexing, oggi non lo è più.
Le Spam Policies di Google Search sui contenuti nascosti
La documentazione di riferimento non è più in “Webmaster Guidelines / Quality Guidelines”: dal lancio delle Google Search Essentials le linee guida sullo spam si trovano nella sezione Spam policies for Google web search. La policy specifica sui testi nascosti è hidden-text-and-links.
Google elenca come esempi espliciti di hidden text abuse:
- Testo bianco su sfondo bianco (o colori identici).
- Testo posizionato fuori dallo schermo tramite CSS.
- Font-size impostato a 0 o 1 pixel.
- Testo nascosto dietro immagini.
- Link che consistono di un singolo carattere piccolo (un punto, una virgola, un carattere invisibile).
La stessa policy chiarisce che non costituiscono violazione i contenuti visibili tramite interazione: accordion, tab, carousel, immagini descrittive che aprono dettagli al click. La discriminante rimane l’accessibilità effettiva del contenuto all’utente.
Dal 2022 le violazioni delle Spam Policies vengono gestite in parallelo da due sistemi: le azioni manuali notificate in Google Search Console dal team Search Quality, e SpamBrain, il sistema ML di classificazione spam introdotto nel 2018 e potenziato con i Spam Update 2022, 2023, 2024 e 2025. Per approfondire: Spam secondo Google: le 20 policy ufficiali, SpamBrain e gli aggiornamenti 2024-2026.
Quando nascondere contenuti è legittimo
Nascondere contenuti è una pratica di design standard e spesso imprescindibile. I casi d’uso legittimi sono molti:
- Progressive disclosure su mobile: schede prodotto con descrizione estesa, specifiche tecniche, FAQ, recensioni. Su viewport da 360px un blocco di 3000 parole è inutilizzabile.
- Tab di categorizzazione: split di contenuti omogenei (descrizione / specifiche / recensioni) per ridurre lo scroll cognitivo.
- Modal, popover e drawer: interazioni temporanee invocate da CTA specifiche (checkout, login, filtri).
- Classi screen-reader only (
.sr-only,.visually-hidden): testo descrittivo per utenti di ausili, invisibile ai sighted user ma essenziale per WCAG 2.2. - Skeleton e loading state: placeholder visibili in attesa del contenuto reale, spesso sostituiti via JS dopo fetch.
- Navigazione responsive: menu hamburger che nasconde link secondari fuori dal viewport principale.
- Cookie banner, avvisi GDPR, preferenze: componenti che appaiono/scompaiono a seguito di scelte utente.
In tutti questi casi il contenuto è nel DOM, accessibile a Googlebot dopo rendering, e l’interazione richiesta è minima. Non c’è intento manipolativo: non c’è spam.
Tecniche di hidden text considerate SPAM
Queste tecniche sono esplicitamente indicate da Google come spam. L’identificazione è automatica per molte di esse (SpamBrain riconosce pattern visivi e computati) o manuale in caso di report. Da evitare integralmente.
Cloaking: servire contenuti diversi a bot e utenti
Il cloaking consiste nel servire a Googlebot una versione diversa della pagina rispetto a quella mostrata all’utente. Implementato tipicamente via discriminazione su User-Agent o su range di indirizzi IP noti di Google. È la violazione più grave in tema di hidden content perché rompe completamente il patto informativo con l’indice.
Google dispone di uno strumento specifico per il debug: l’URL Inspection Tool in Search Console mostra lo screenshot e l’HTML renderizzato dal WRS, confrontabile con ciò che vede l’utente. Nel 2024 Google ha anche iniziato a fare fetch da IP non dichiarati per smascherare cloaking basato su IP whitelist.
La penalizzazione può essere parziale (una sezione del sito) o totale (sitewide). Il recupero richiede la rimozione completa della logica di cloaking e una reconsideration request.
Nota: dynamic serving (servire HTML diverso a mobile/desktop sullo stesso URL) e geolocation-based content non sono cloaking se applicati uniformemente a bot e utenti con stesso segnale.
Testo e sfondo dello stesso colore
Il classico white-on-white degli anni ’90. Include varianti più sottili: color: #fefefe su background: #ffffff, colori a basso contrasto (sotto la soglia WCAG 4.5:1), gradient inversi. SpamBrain computa il contrasto e identifica pattern di mismatch evidenti.
Font-size 0 e 1 pixel
.hidden-spam { font-size: 0; }
.tiny-text { font-size: 1px; line-height: 1px; }Esplicitamente citati come spam nella documentazione. Il rendering pipeline di Chromium li identifica come testo non leggibile e Google li classifica negativamente.
Testo fuori dal viewport via text-indent negativo
.offscreen-spam {
text-indent: -9999em;
position: absolute;
left: -9999px;
}Pattern storico per image replacement di loghi. Oggi è obsoleto: si usa <img alt="..."> o role="img" aria-label="...". Google tratta il text-indent negativo come sospetto, ma l’uso tecnico legittimo per il replacement di loghi con font non licenziati per @font-face è tollerato. La ricetta sicura oggi è il pattern visually-hidden a livello di utility accessibility, non di testo SEO aggiuntivo.
Testo nascosto dietro immagini
Sovrapporre un’immagine a un blocco di testo tramite z-index è spam. Stesso trattamento per color: transparent su testo in overlay a immagini.
Keyword stuffing nascosto via display:none
Il caso borderline più frequente: un blocco con display:none contenente liste di keyword non correlate al topic della pagina. La tecnica è CSS-valida, ma l’intento manipolativo fa scattare la violazione. Molti CMS e plugin “SEO miracolosi” inseriscono blocchi di questo tipo: audit puntuale obbligatorio in presenza di penalizzazioni senza causa evidente.
Tecniche CSS/HTML neutre per nascondere contenuti
Queste tecniche non sono spam per definizione: il trattamento SEO dipende dal contesto d’uso. Il WRS esegue il rendering con Chromium headless, quindi applica tutti gli stili CSS e il JavaScript della pagina. Il contenuto nascosto è quindi visto da Googlebot, ma può essere pesato diversamente.
display:none
.collapsed { display: none; }L’elemento è rimosso dal flusso di render: non occupa spazio, non viene dipinto, non è interagibile. Googlebot lo parsa ma lo identifica come non visibile al primo paint. Nel mobile-first indexing, John Mueller ha chiarito che il peso è pieno se il contenuto è reso visibile da interazione utente (tap, click, swipe).
Uso legittimo: accordion, tab, modal, dropdown, carousel. Uso problematico: contenuto nascosto che non diventa mai accessibile nell’interazione utente standard.
visibility:hidden
.invisible { visibility: hidden; }L’elemento occupa il suo spazio nel layout ma non è dipinto. Differenza rispetto a display:none: mantiene il reflow. Lettura dagli screen reader dipende dall’implementazione, ma generalmente viene ignorato. Uso legittimo: placeholder di skeleton layout, transizioni di stato.
opacity:0
Rende trasparente l’elemento mantenendolo interagibile (click-through se non combinato con pointer-events:none). Trattato da Google come visualmente nascosto ma presente. Pattern frequente: animazioni di entrata con opacity 0 → 1, tooltip.
Attributo hidden HTML5
<div hidden>Contenuto nascosto</div>
<div hidden="until-found">Trovabile via CTRL+F</div>L’attributo HTML5 hidden è semanticamente equivalente a display:none ma con valenza semantica dichiarata. Chromium supporta dal 2022 il valore hidden="until-found": il contenuto resta nascosto ma è trovabile via find-in-page del browser, scrolling automatico e espansione al match. Utile per accordion SEO-friendly nativi.
content-visibility: auto e hidden
.section { content-visibility: auto; contain-intrinsic-size: 500px; }
.lazy-block { content-visibility: hidden; }Introdotta nel 2020-2022, content-visibility è un’ottimizzazione di rendering: il browser salta layout, paint e style containment per elementi fuori viewport. Impatto diretto su LCP e INP. È una proprietà di performance, non di hiding: il DOM è intatto, Googlebot indicizza il contenuto normalmente. Zero rischio SEO, alto ROI su pagine lunghe. Approfondimento: ottimizzare il CSS per la SEO.
Pattern visually-hidden per screen reader
.sr-only {
position: absolute;
width: 1px;
height: 1px;
padding: 0;
margin: -1px;
overflow: hidden;
clip: rect(0, 0, 0, 0);
white-space: nowrap;
border: 0;
}Utility class ereditata da Bootstrap 5 e Tailwind (.sr-only). Nasconde visivamente ma mantiene il testo nel accessibility tree, leggibile da screen reader. Pattern WCAG-compliant, non spam: il testo deve descrivere elementi realmente presenti nella pagina (es. etichette aria per button icon-only). Abusarlo per keyword stuffing rientra in hidden text.
aria-hidden=”true”
Rimuove l’elemento dall’accessibility tree. Non è una tecnica per nascondere a Google: Googlebot non usa ARIA per decidere cosa indicizzare, usa il DOM visuale. Il rischio è inverso: abusarlo su contenuto utile viola WCAG senza alcun beneficio SEO.
Pattern UX consigliati: accordion, tab, details
Questi sono i pattern esplicitamente consigliati da Google per nascondere contenuti in modo UX-friendly e SEO-safe. Il contenuto è nel DOM, accessibile al WRS, e raggiungibile dall’utente con un’interazione standard.
La citazione di Gary Illyes del novembre 2016 resta il riferimento dottrinale: “in the mobile-first world content hidden for UX should have full weight”. Nove anni dopo il passaggio al mobile-first indexing è completato (luglio 2024 ha chiuso l’indicizzazione di siti non crawlabili da smartphone crawler) e la regola è operativamente valida su tutto l’indice.
Elemento <details>/<summary> HTML nativo
<details>
<summary>Clicca per espandere</summary>
<p>Contenuto nascosto ma nel DOM, accessibile e SEO-friendly.</p>
</details>Accordion nativo, zero JavaScript, supporto universale (Chrome, Firefox, Safari, Edge). Il contenuto è nel DOM fin dal primo paint, Googlebot lo vede direttamente nella response HTML. Supporta l’attributo open per stato iniziale espanso e name (2024) per raggruppamenti mutuamente esclusivi tipo radio-accordion. Esperienza consulenziale: su siti e-commerce con schede prodotto rework dal 2023, <details> ha sostituito quasi integralmente accordion custom jQuery senza impatti sul ranking.
Accordion e tab via JavaScript
Pattern classico: DOM contiene tutto, JS gestisce display:none o [hidden] dinamico sui pannelli. Il WRS esegue il JS durante il rendering e vede il DOM finale, ma il contenuto inizialmente collassato rimane indicizzato. Controindicazioni:
- Contenuto iniettato on-demand (caricato via fetch al click): se non è nel DOM iniziale o nel DOM post-WRS, Google non lo indicizza.
- Rendering Budget: siti con molti tab JS-heavy su URL ad alto volume possono avere contenuti reso in modo incompleto. Vedi Rendering Budget e SEO.
Read more e clamp di testo
.teaser {
display: -webkit-box;
-webkit-line-clamp: 3;
-webkit-box-orient: vertical;
overflow: hidden;
}Il testo è completamente nel DOM, ma visualmente troncato a 3 righe con ellipsis via line-clamp. Espansione tramite button “Leggi tutto” che rimuove la classe. Pattern UX-only, SEO-safe: niente contenuto davvero “nascosto”, solo troncamento visivo. Ampiamente usato in schede prodotto e-commerce e recensioni utente.
Come Googlebot vede i contenuti nascosti nel 2026
Googlebot esegue due fasi di scansione: il crawl che scarica l’HTML iniziale, e il render che esegue CSS e JavaScript via Web Rendering Service (WRS). Il WRS gira su un evergreen Chromium (versione allineata al Chrome stabile nel giro di poche settimane).
Per un contenuto nascosto via CSS, la pipeline è:
- Fetch HTML iniziale → contenuto presente nel DOM sorgente.
- Parsing CSS → computo degli stili, inclusi
display:none. - Esecuzione JS → eventuali mutazioni del DOM.
- Snapshot finale → inviato all’indexer.
L’indexer ha accesso sia al contenuto che al suo stato di visibilità. Storicamente pre-mobile-first il contenuto collassato veniva depennato in rilevanza; oggi viene considerato a peso pieno se raggiungibile per interazione.
Per debuggare il comportamento reale: usare URL Inspection Tool in Google Search Console (sezione Pagina sottoposta a test in tempo reale → Codice HTML renderizzato) oppure il Rich Results Test. Entrambi restituiscono l’HTML post-WRS e lo screenshot del viewport. Approfondimento: come analizzare il rendering di un sito web da parte di Google.
Nota operativa importante: gli LLM-based crawler (OAI-SearchBot, ClaudeBot, PerplexityBot, Google-Extended) hanno capacità di rendering molto diverse da Googlebot. Alcuni non eseguono JavaScript, altri eseguono solo JS isomorfo. Contenuti caricati via JS dopo il primo paint possono essere invisibili a questi bot. Test dedicato: ChatGPT, Gemini e Claude riescono a leggere siti JavaScript?.
Tabella decisionale: quale tecnica usare
| Tecnica | Classificazione Google | Quando usare |
|---|---|---|
| Cloaking (UA/IP-based) | SPAM grave | Mai |
| Testo = sfondo stesso colore | SPAM | Mai |
| Font-size: 0 / 1px | SPAM | Mai |
| Testo dietro immagine (z-index) | SPAM | Mai |
| Text-indent: -9999em | Sospetto | Solo per image replacement legacy |
| display: none | Neutro | Tab, accordion, modal, dropdown |
| visibility: hidden | Neutro | Skeleton, placeholder, transizioni |
| opacity: 0 | Neutro | Animazioni di entrata, tooltip |
| Attributo hidden | Neutro | Equivalente semantico di display:none |
| hidden=”until-found” | Consigliato | Accordion find-in-page friendly |
| content-visibility: auto | Consigliato | Performance su pagine lunghe |
| .sr-only / .visually-hidden | Consigliato | Accessibilità screen reader |
| <details>/<summary> | Consigliato | FAQ, accordion senza JS |
| Accordion/tab JS | Consigliato | Progressive disclosure mobile |
| Read more con line-clamp | Consigliato | Truncation visivo, testo nel DOM |
Domande frequenti
Google penalizza il display:none?
No, non automaticamente. display:none è CSS standard usato da ogni framework (Bootstrap, Tailwind, Material UI, React Aria). La penalizzazione scatta solo se il contenuto nascosto è keyword stuffing o cloaking. In un accordion UX è totalmente sicuro.
Il testo dietro un accordion ha peso SEO pieno?
Sì, dal passaggio al mobile-first indexing (completato a luglio 2024). Gary Illyes nel 2016 e John Mueller in diversi Search Central office hours hanno confermato l’equivalenza tra contenuto visibile e contenuto collassato quando l’interazione per renderlo visibile è parte della UX standard.
Come verifico cosa vede Googlebot su una pagina con contenuti nascosti?
Tre strumenti: URL Inspection Tool di Google Search Console (test in tempo reale + HTML renderizzato + screenshot), Rich Results Test, Mobile-Friendly Test. In CLI, curl per il sorgente HTML e Chrome DevTools Protocol (puppeteer, playwright) per il DOM post-render.
Posso usare display:none per servire contenuti diversi tra mobile e desktop?
Sì, è un pattern responsive standard. Ma attenzione: nell’indice mobile-first ciò che Googlebot Smartphone vede è ciò che conta. Se nascondi blocchi su mobile e li mostri solo su desktop, quei blocchi potrebbero pesare meno. La regola è: tutto il contenuto SEO-critico deve essere accessibile nel rendering mobile, anche se dietro accordion.
È legittimo nascondere testo per screen reader only?
Sì, è esplicitamente permesso e anzi richiesto da WCAG 2.2 per aria-label su icone, skip-link di navigazione, caption di tabelle dati. Va usato per descrivere elementi già presenti, non per inserire keyword non correlate. Abusarlo come canale SEO parallelo cade in hidden text abuse.
Conclusione
Nel 2026 nascondere contenuti per UX è una pratica standard, non una tecnica SEO. Google tratta il tema con una regola semplice: se il contenuto è raggiungibile dall’utente con interazione normale, pesa pieno; se è nascosto per ingannare l’indice, è spam. Tutto il resto è rumore.
Per audit su siti reali con sospetti di hidden text abuse, combino URL Inspection, crawl con Screaming Frog (rendering JS attivo), diff tra HTML sorgente e DOM post-WRS, e analisi log server per verificare quali URL Googlebot effettivamente visita e renderizza. La chiave non è la tecnica CSS in sé ma la coerenza tra ciò che vede Googlebot e ciò che vede l’utente. Per approfondimenti consulta gli elementi che penalizzano la SEO e HTML vs DOM: differenze e impatto su rendering e SEO tecnica.
Se un utente può vederlo, anche Google può vederlo. Se solo Google può vederlo, qualcosa non va.
Articoli correlati
Autore
Mi chiamo Giovanni Sacheli e dal 2009 aiuto le aziende a farsi trovare online. Sono specializzato in SEO tecnica e PPC, competenze che applico quotidianamente nella mia agenzia, Searcus Swiss Sagl. Mi piace sviluppare strumenti a supporto del mio lavoro, ho creato SEOdata.app e cluster.army e co-scritto il libro SEO Audit Avanzato. Curo maniacalmente questo blog per colleghi e appassionati, dove mi "appunto" quello che imparo. Sono un NERD anni '80, motociclista e orgoglioso papà di due bambini.
Link:
Giovanni Sacheli
SEO Audit Avanzato
Searcus Swiss Sagl
SEOdata.app
cluster.army