Come un motore di ricerca (e una IA) legge la tua pagina

Un motore di ricerca e una IA generativa non "guardano" la tua pagina come farebbe un visitatore umano. Recuperano un flusso di HTML, lo trasformano (o meno) in una struttura dati chiamata DOM, poi ne estraggono un testo grezzo che suddividono in blocchi per indicizzarlo o usarlo come risposta. Capire questo percorso cambia concretamente il modo in cui devi scrivere e strutturare le tue pagine.

Il percorso dall'HTML grezzo al rendering

Quando un crawler visita un URL, riceve prima di tutto una risposta HTTP contenente l'HTML grezzo inviato dal tuo server, prima di qualsiasi esecuzione di JavaScript. È questo HTML iniziale che la maggior parte dei robot analizza in via prioritaria, perché eseguirlo interamente (il "rendering") costa tempo di calcolo e memoria, da moltiplicare per i miliardi di pagine esplorate ogni giorno.

Google è in grado di renderizzare il JavaScript in un secondo momento, tramite una coda separata che può richiedere da pochi secondi a diversi giorni a seconda del carico del momento e della priorità assegnata al tuo sito. In altre parole, esiste un ritardo, a volte significativo, tra il momento in cui il tuo HTML grezzo viene letto e il momento in cui il suo rendering completo (dopo l'esecuzione del JavaScript) viene preso in considerazione. I crawler delle IA generative (ChatGPT, Claude, Perplexity in particolare) sono generalmente più limitati su questo punto: si osserva che si basano maggiormente sull'HTML statico o su versioni già indicizzate da motori terzi, piuttosto che su un rendering JavaScript completo e sistematico a ogni visita.

Questa differenza di trattamento spiega perché due strumenti possono avere una visione diversa della stessa pagina: uno potrebbe aver atteso il rendering completo, l'altro no.

Cosa vede un crawler rispetto a un browser

Un browser esegue il CSS, il JavaScript, carica i font, applica le animazioni e mostra un rendering visivo completo, pixel per pixel. Un crawler, invece, non "vede" nulla di visivo: elabora una stringa di caratteri (l'HTML) e, eventualmente, una struttura ad albero costruita a partire da quella stringa.

In pratica, se un contenuto esiste solo visivamente — un'informazione codificata unicamente in un'immagine senza testo alternativo, un testo generato da un'animazione CSS, un contenuto iniettato dopo un clic dell'utente, un tooltip che appare solo al passaggio del mouse — è probabile che nessun robot lo percepisca mai come testo utilizzabile. Non è che lo ignori volontariamente: semplicemente non ha modo di riprodurre l'interazione umana che ne innesca la comparsa.

Il DOM e l'estrazione del testo

Il DOM (Document Object Model) è la rappresentazione ad albero dell'HTML: ogni tag diventa un "nodo" con genitori, figli e attributi. È a partire da questa struttura ad albero che i motori e le IA estraggono il testo utile, basandosi in particolare su:

la gerarchia dei tag (<header>, <nav>, <main>, <article>, <footer>) per distinguere il contenuto principale dagli elementi periferici;
i tag di titolo (<h1> fino a <h6>) per individuare la struttura logica del contenuto;
l'ordine dell'HTML nel documento (non l'ordine visivo imposto dal CSS).

Un punto spesso trascurato: se usi position: absolute o flex-direction: row-reverse per riorganizzare visivamente dei blocchi, l'ordine letto dalla macchina resta quello del codice sorgente, non quello mostrato a schermo. Un paragrafo posizionato per ultimo nell'HTML ma spostato visivamente in cima alla pagina tramite CSS verrà comunque trattato, dalla maggior parte dei sistemi di estrazione, come l'ultimo blocco di contenuto — il che può falsare la struttura logica percepita da un lettore automatico.

JavaScript: la trappola del contenuto invisibile

I siti costruiti con JavaScript lato client (alcune applicazioni React, Vue o Angular senza rendering server) comportano un rischio reale: se il contenuto testuale appare solo dopo l'esecuzione dello script, e il robot che visita la pagina non lo esegue o lo esegue solo parzialmente, quel contenuto è semplicemente assente da ciò che viene indicizzato. Il rischio è particolarmente alto per i blocchi caricati in modo differito (lazy loading aggressivo), i contenuti dietro una scheda chiusa per impostazione predefinita, o i dati iniettati tramite una chiamata API asincrona dopo il caricamento iniziale della pagina.

Per limitare questo rischio, esistono diversi approcci:

<!-- Rendering lato server (SSR): l'HTML iniziale contiene già il testo -->
<article>
  <h1>Titolo visibile immediatamente nell'HTML sorgente</h1>
  <p>Questo paragrafo è presente prima di qualsiasi esecuzione JS.</p>
</article>

L'SSR (server-side rendering), il rendering statico (SSG) o l'idratazione progressiva garantiscono che il testo essenziale sia presente fin dalla prima risposta HTTP, senza dipendere dall'esecuzione del JavaScript da parte del robot che ti visita. Questi approcci non sono semplici opzioni tecniche riservate agli sviluppatori: hanno un impatto diretto sulla visibilità del tuo contenuto presso qualsiasi sistema automatizzato, che si tratti di un motore di ricerca classico o di una IA generativa che esplora il web per costruire una risposta.

Cosa cambia concretamente per il tuo contenuto

Tre implicazioni dirette per la scrittura e l'integrazione delle tue pagine:

Il contenuto testuale importante (argomentazioni, risposte alle domande, dati numerici) deve esistere nell'HTML grezzo, non solo dopo un'interazione o un'animazione.
La struttura del codice sorgente deve riflettere l'ordine logico di lettura, indipendentemente dalla formattazione visiva imposta dal CSS.
Un markup semantico chiaro aiuta a separare il contenuto principale dal rumore di fondo (menu, pubblicità, footer ripetitivo) — un punto approfondito nella lezione sull'HTML5 semantico.

Per verificare concretamente cosa può leggere un robot, confronta l'HTML grezzo restituito dal tuo server (clic destro → "visualizza sorgente pagina", non l'ispettore che mostra il DOM dopo il rendering) con ciò che viene visualizzato a schermo. Ogni discrepanza notevole — un blocco di testo presente visivamente ma assente dal codice sorgente — è un segnale da correggere con priorità.

Questa questione del percorso tecnico del contenuto si collega direttamente a due argomenti del modulo successivo: il modo in cui un LLM suddivide il tuo contenuto in blocchi una volta estratto il testo, e come gestire l'accesso dei crawler tramite il file robots.txt.