{"id":159,"date":"2026-01-25T11:06:41","date_gmt":"2026-01-25T10:06:41","guid":{"rendered":"https:\/\/seoradaritalia.it\/blog\/?p=159"},"modified":"2026-01-25T11:25:15","modified_gmt":"2026-01-25T10:25:15","slug":"contenuti-javascript-click-seo","status":"publish","type":"post","link":"https:\/\/seoradaritalia.it\/blog\/guide\/contenuti-javascript-click-seo\/","title":{"rendered":"Il “Contenuto Fantasma”: Perch\u00e9 Google ignora quello che carichi al Click."},"content":{"rendered":"\n

Se gestisci un sito moderno come magari un e-commerce con schede prodotto che si aprono in modale (una finestra a parte caricata dinamicamente), un blog con tab che si attivano a richiesta, o una Single Page Application (SPA) complessa fermati un istante. C’\u00e8 un’alta probabilit\u00e0 che Google non stia indicizzando una parte cruciale del tuo contenuto.<\/strong><\/p>\n\n\n\n

Questo \u00e8 uno dei problemi architetturali pi\u00f9 sottovalutati e, paradossalmente, pi\u00f9 diffusi nel 2025 e dibatturi anche nel 2026. Il vero corto circuito informativo \u00e8 che Google lo dichiara esplicitamente nella sua documentazione ufficiale, ma molti sviluppatori e SEO specialist continuano a ignorarlo<\/strong>, vittime di quello che in psicologia cognitiva si chiama “bias di conferma”: se io lo vedo sul mio schermo, allora esiste.<\/em><\/p>\n\n\n\n

In questo articolo dissezioniamo la Fake News #3 L\u2019illusione del \u201cBuffet Servito\u201d<\/strong>, analizzando il comportamento di Googlebot a livello di codice per capire perch\u00e9, agli occhi del motore di ricerca, il tuo sito potrebbe essere “vuoto a met\u00e0”.<\/p>\n\n\n\n

Il Problema: Contenuti che esistono solo “su richiesta”<\/h2>\n\n\n\n

Immagina un sito di abbigliamento. L’utente clicca su “Dettagli” in una scheda prodotto e un JavaScript carica dinamicamente le specifiche tecniche (materiale, peso, istruzioni di lavaggio). L’utente vede tutto. L’esperienza \u00e8 fluida. Ma Google? Google non vede nulla di tutto questo.<\/strong><\/p>\n\n\n\n

Oppure prendiamo un blog con una sezione a schede (Tabs). Il contenuto principale \u00e8 visibile, ma quando clicchi sulla tab “FAQ” o “Prodotti Correlati”, viene iniettato nuovo HTML tramite JavaScript. Ancora una volta: per l’utente \u00e8 tutto l\u00ec. Per Google, quel contenuto non \u00e8 mai arrivato.<\/p>\n\n\n\n

Perch\u00e9 succede? Perch\u00e9 c’\u00e8 una regola d’oro nell’architettura dei crawler che viene spesso dimenticata: Googlebot non \u00e8 un utente. Googlebot non ha le mani.<\/strong><\/p>\n\n\n\n

Come Funziona Googlebot Davvero (La Documentazione)<\/h2>\n\n\n\n

Per comprendere l’errore, dobbiamo guardare sotto il cofano del WRS (Web Rendering Service) di Google. Secondo la guida ufficiale “Understand JavaScript SEO Basics<\/a>“<\/em> (aggiornata a Dicembre 2025) e gli studi di reverse-engineering come quelli di Vercel & MERJ, il processo avviene in tre fasi distinte:<\/p>\n\n\n\n

    \n
  1. Crawl (La richiesta):<\/strong> Googlebot effettua una richiesta HTTP GET e legge l’HTML “grezzo” che il server restituisce.<\/li>\n\n\n\n
  2. Render (L’esecuzione):<\/strong> Google mette la pagina in una coda (la famosa Render Queue<\/em>). Quando le risorse sono disponibili (possono passare secondi o ore), esegue il JavaScript utilizzando una versione headless<\/em> di Chromium (il motore di Chrome, ma senza interfaccia grafica).<\/li>\n\n\n\n
  3. Index (L’archiviazione):<\/strong> Google usa l’HTML renderizzato<\/strong> (il DOM statico che emerge dopo<\/em> l’esecuzione automatica del JS) per indicizzare la pagina.<\/li>\n<\/ol>\n\n\n\n

    Il punto critico (Didattico)<\/h3>\n\n\n\n

    Qui nasce l’equivoco. Molti pensano che “Renderizzare” significhi “Simulare un utente che naviga”. Falso.<\/strong> Il rendering di Googlebot esegue il JavaScript che parte al caricamento<\/em> della pagina (onload<\/code>, onmount<\/code>). Google non esegue<\/strong> click, non fa scroll infiniti, non fa hover col mouse e non interagisce con l’interfaccia.<\/p>\n\n\n\n

    \u00c8 scritto nero su bianco nella documentazione: “If content is not visible in the rendered HTML, Google won’t be able to index it.”<\/em> (Se il contenuto non \u00e8 visibile nell’HTML renderizzato, Google non sar\u00e0 in grado di indicizzarlo.)<\/p>\n\n\n\n

    Analisi del Codice: Quando il Rendering fallisce<\/h2>\n\n\n\n

    Vediamo tre scenari reali, analizzati a livello di codice, dove il contenuto diventa invisibile (Fantasma).<\/p>\n\n\n\n

    1. Il contenuto caricato al Click (Anti-Pattern)<\/h3>\n\n\n\n

    Questo \u00e8 l’errore pi\u00f9 comune. Il contenuto viene chiamato via API solo quando l’utente compie un’azione esplicita.<\/p>\n\n\n\n

    \/\/ \u274c QUESTO CODICE \u00c8 INVISIBILE PER LA SEO\n\/\/ L'evento 'click' \u00e8 il trigger necessario\ndocument.getElementById('btn-dettagli').addEventListener('click', function() {\n  fetch('\/api\/dettagli-prodotto\/' + productId)\n    .then(res => res.json())\n    .then(data => {\n      \/\/ Questo HTML viene iniettato solo se qualcuno clicca\n      document.getElementById('pannello-dettagli').innerHTML = data.html;\n    });\n});<\/code><\/pre>\n\n\n\n
    L’analisi:<\/strong> Quando Googlebot renderizza la pagina, carica il DOM ed esegue gli script iniziali. Tuttavia, poich\u00e9 Googlebot non clicca<\/strong> sul pulsante #btn-dettagli<\/code>, la funzione fetch<\/code> non parte mai. Il div di destinazione rimane vuoto. Per Google, i dettagli del prodotto non esistono.<\/p>\n\n\n\n
    2. Lazy-Loading Aggressivo<\/h3>\n\n\n\n
    Se usi un lazy-loading che carica il contenuto solo quando l’elemento entra nel viewport, c’\u00e8 un rischio concreto. Googlebot ridimensiona il viewport (spesso simulando un dispositivo mobile molto alto), ma non fa uno scroll “umano”. Se il contenuto \u00e8 troppo in basso o richiede uno scroll specifico per attivare il trigger JS, potrebbe rimanere escluso dal rendering.<\/p>\n\n\n\n
    3. Shadow DOM non proiettato<\/h3>\n\n\n\n
    Se utilizzi Web Components con Shadow DOM<\/em> in modalit\u00e0 “closed” o senza usare correttamente gli <slot><\/code>, il contenuto rimane incapsulato in una “bolla” che il crawler potrebbe non penetrare o associare correttamente al documento principale.<\/p>\n\n\n\n
    Cosa cerca un Tool di Analisi Tecnico (Come SEO Radar)<\/h2>\n\n\n\n
    Qui entra in gioco la differenza tra un tool SEO generico e uno strumento di diagnostica tecnica<\/strong>. Fare questa verifica manualmente per ogni pagina \u00e8 impossibile. Un tool moderno deve replicare lo stack tecnologico del crawler:<\/p>\n\n\n\n
      \n
    1. Fetch via cURL:<\/strong> Scarica l’HTML grezzo (Server-Side) per vedere cosa arriva prima del JS.<\/li>\n\n\n\n
    2. Rendering via Playwright\/Puppeteer:<\/strong> Simula un browser headless che esegue il JS, attende il network idle, ma non clicca<\/em>.<\/li>\n\n\n\n
    3. Confronto Differenziale:<\/strong> Sovrappone i due stati.<\/li>\n<\/ol>\n\n\n\n
      Ecco l’output che dovresti cercare in un’analisi tecnica:<\/p>\n\n\n\n
      Stato A: HTML Grezzo (Server Response)<\/strong><\/p>\n\n\n\n
      <div id=\"tab-contents\"><\/div><\/code><\/pre>\n\n\n\n
      Qui il contenuto non c’\u00e8 ancora.<\/p>\n\n\n\n
      Stato B: DOM Renderizzato (Googlebot View)<\/strong> Se il codice \u00e8 scritto bene, dopo l’esecuzione automatica del JS, il tool deve vedere questo:<\/p>\n\n\n\n
      <div id=\"tab-contents\">\n  <div class=\"tab\">Contenuto Tab 1<\/div> <\/div>\n<\/code><\/pre>\n\n\n\n
      Il tool ti dir\u00e0: “\u2713 Contenuto iniettato via JS rilevato. Indicizzabile.”<\/em><\/p>\n\n\n\n
      Stato C: DOM Renderizzato Incompleto (Il problema)<\/strong> Se l’API \u00e8 lenta o il contenuto dipende da un click che il bot non ha fatto:<\/p>\n\n\n\n
      <div id=\"tab-contents\">\n  <\/div>\n<\/code><\/pre>\n\n\n\n
      In questo caso, il tool deve lanciare un allarme: “\u26a0\ufe0f Contenuto assente nel DOM renderizzato. Rischio deindicizzazione.”<\/strong><\/p>\n\n\n\n
      La Soluzione: Come scrivere codice “Google-Friendly”<\/h2>\n\n\n\n
      Non devi rinunciare a JavaScript. Devi solo cambiare il momento<\/strong> in cui il contenuto viene caricato. Google suggerisce due strade principali:<\/p>\n\n\n\n
      1. Server-Side Rendering (SSR) o Static Generation (SSG)<\/h3>\n\n\n\n
      La soluzione aurea. Il server invia l’HTML gi\u00e0 completo. Il contenuto delle tab o dei modali \u00e8 gi\u00e0 nel codice sorgente, magari nascosto via CSS (display: none<\/code>), ma presente semanticamente.<\/p>\n\n\n\n
      2. Client-Side Rendering all’inizializzazione<\/h3>\n\n\n\n
      Se devi usare il rendering lato client, assicurati che il fetch dei dati avvenga al montaggio del componente, non all’evento click.<\/p>\n\n\n\n
      \/\/ \u2705 CORRETTO: Il contenuto si carica automaticamente (Google lo vede)\nuseEffect(() => {\n  \/\/ Parte subito, senza bisogno di click\n  fetch(`\/api\/prodotto\/${productId}`)\n    .then(res => res.json())\n    .then(data => setDettagli(data));\n}, [productId]);\n<\/code><\/pre>\n\n\n\n
      Nel primo caso, Googlebot esegue la pagina, attende il fetch e vede il contenuto. Nel secondo caso (l’anti-pattern visto prima), il contenuto resta per sempre in un limbo digitale.<\/p>\n\n\n\n
      Checklist Operativa: Cosa Fare Adesso<\/h2>\n\n\n\n
      Se sospetti che il tuo sito abbia contenuti “nascosti”, ecco il piano d’azione pratico:<\/p>\n\n\n\n
        \n
      1. Audit con il “Controllo URL”:<\/strong> Usa la Google Search Console. Inserisci un URL, clicca su “Testa URL Pubblicato” e poi su “Visualizza Pagina Testata” -> “HTML”. Cerca nel codice il testo che temi non venga visto (es. “Istruzioni lavaggio”). Se non c’\u00e8 nel codice HTML della GSC, Google non lo vede.<\/li>\n\n\n\n
      2. Identifica le Priorit\u00e0:<\/strong> Se mancano le recensioni, \u00e8 grave ma passabile. Se manca la descrizione del prodotto o i link ai prodotti correlati, \u00e8 un’emergenza SEO.<\/li>\n\n\n\n
      3. Risolvi i contenuti critici:<\/strong>\n