La SEO tecnica decide se Google e l’AI ti leggono

Tutto quello che non riguarda il testo. La SEO tecnica è stata a lungo un’etichetta comoda, buona per tenere insieme attività che fra loro non si assomigliano nemmeno — velocità di caricamento, sitemap, redirect, rendering, dati strutturati. A valle c’era Google, che ha passato vent’anni a costruire tolleranza. Interpreta il JavaScript, scioglie le catene di redirect, tratta il canonical come un suggerimento e quando il tuo non lo convince ne sceglie un altro, ripassa, corregge, indovina. Una macchina di compensazione che ha permesso a una quantità enorme di debito tecnico di restare invisibile.

Adesso Google ne sta ritirando dei pezzi, e ad esempio di una pagina HTML dichiara di scaricare i primi 2MB al posto di 15. Intanto sono arrivati altri lettori — i crawler di ChatGPT, di Perplexity, dei sistemi che raccolgono testo per comporre una risposta — che prendono l’HTML così com’è e se ne vanno. E non dimenticare l’unico che non ha mai compensato niente, la persona che apre la pagina e non aspetta il rendering, non ripassa domani, chiude.

Il conto di quel debito arriva adesso, tutto insieme, e la parte difficile è capire quale pezzo stai pagando. Il bot si è fermato prima di entrare, oppure è entrato e ha portato via metà pagina, oppure ha preso tutto e ha deciso di lasciarla fuori. Le macchine stanno diventando intolleranti quanto lo sono sempre state le persone.

Che cos’è la SEO tecnica

La SEO tecnica è l’insieme degli interventi sull’infrastruttura e sul codice che rendono i contenuti di un sito raggiungibili, prelevabili per intero e interpretabili dai sistemi automatici che ne decidono la visibilità, dai crawler dei motori di ricerca ai bot che alimentano i modelli generativi. Non riguarda il contenuto, riguarda la sua leggibilità da parte delle macchine: l’infrastruttura, il codice, la struttura, le prestazioni e i segnali che permettono a una macchina di estrarre, capire e usare quello che pubblichi.

Serve perché leggerti costa banda, calcolo per eseguire il codice che completa la pagina, spazio per conservarla e per rivalutarla a ogni passaggio successivo. Chi sostiene la spesa la mette a confronto con quello che si aspetta di ricavarne, e regola di conseguenza quanto tempo dedicarti. Un sito che costa poco da leggere viene letto più spesso, più a fondo e da più sistemi.

Il campo si organizza attorno a quattro dimensioni, e ognuna corrisponde a un momento preciso in cui qualcosa può andare storto.

• Crawlability è la facilità con cui un bot raggiunge le tue pagine e ne porta via il contenuto. Il robots.txt stabilisce quali percorsi può chiedere, il server stabilisce che cosa restituire alla chiamata, il livello di protezione dal traffico automatico stabilisce se la richiesta somiglia abbastanza a una persona per meritare risposta. Sono decisioni tue, prese in punti lontani dello stack e quasi sempre da mani diverse, ed è il motivo per cui questo gradino cede in silenzio.
• Rendering è la capacità del sistema di costruire una rappresentazione fedele della pagina eseguendo il codice che la completa. Fra l’HTML che il server consegna e quello che esiste nel browser a script eseguiti c’è una distanza, e quella distanza misura quanto del tuo lavoro dipende da un passaggio che può fallire senza avvisare.
• Indicizzabilità è la possibilità di entrare nell’indice e di restarci. Un documento che risponde correttamente, che nessuna direttiva blocca e che nessun canonical rimanda altrove ha soltanto il diritto di essere valutato: la decisione di conservarlo la prende il motore, e la prende confrontandolo con quello che ha già.
• Interpretabilità semantica è la chiarezza con cui un sistema capisce di che cosa parli e in che relazione stai con il resto del web. Il parser ricava un contenuto principale, cerca le altre copie che girano sul dominio, ne elegge una a rappresentante, la aggancia ai temi che il sito presidia e la mette in relazione con le pagine che la linkano.

Che cosa significa lavorare sulla SEO tecnica oggi

Per anni questa disciplina è stata raccontata come un controllo di igiene, un’attività periodica da spuntare dopo aver lavorato sui contenuti e sui link. È una rappresentazione che oggi non regge. La SEO tecnica è il pavimento su cui poggia tutto il resto, e senza la garanzia che le tue pagine siano accessibili, leggibili e interpretabili ogni livello superiore — scrittura, autorevolezza, brand, collegamenti in ingresso — è costruito sulla sabbia. Qualunque contenuto produci, qualunque segnale EEAT emetti, qualunque investimento sul brand tu faccia resta invisibile a chi lo deve leggere.

Una pagina che non viene scansionata non si posiziona. Una pagina scansionata e renderizzata a metà si posiziona sotto le sue possibilità. Una pagina renderizzata per intero ma sepolta sotto il rumore strutturale viene letta e non scelta come fonte da un sistema generativo. Ogni passaggio di quella filiera è materia di SEO tecnica, e nessuno dei tre si annuncia con un errore in un rapporto.

I motori generativi hanno aggiunto un livello di recupero sopra l’indice classico. Quando ChatGPT, Perplexity o Gemini compongono una risposta fanno ricerche, scelgono fonti, aprono pagine, estraggono contenuto, sintetizzano, e ogni anello di quella catena ha una soglia tecnica: una pagina lenta viene scartata, un HTML denso di rumore viene letto male, una struttura frammentata produce un’estrazione imprecisa. La visibilità in quei sistemi non si conquista con ottimizzazioni dedicate, si guadagna alzando innanzitutto la qualità tecnica complessiva del sito, perché lì lavorano gli stessi crawler che servono Search.

Un sito tecnicamente medio sopravvive nella SERP classica grazie a contenuti forti, a un brand riconoscibile e a collegamenti in ingresso solidi. Lo stesso sito, davanti a un sistema che compone risposte, viene scavalcato da concorrenti più puliti e più leggibili. Il margine di tolleranza si è ridotto, e quello che fino a ieri era un dettaglio tecnico oggi separa chi viene letto da chi viene saltato.

Chi legge il tuo sito, e con quale pazienza

Googlebot è stato a lungo l’unico interlocutore tecnico da servire bene. Oggi accanto a lui lavorano il Web Rendering Service, che costruisce la versione interpretata delle pagine, Google-Extended per i modelli Gemini e Vertex, GPTBot e OAI-SearchBot per OpenAI, ClaudeBot per Anthropic, PerplexityBot per Perplexity, e una lista che continua ad allungarsi. Ognuno legge con logiche proprie, soglie di attenzione diverse, limiti tecnici precisi, e ognuno decide per conto suo se sei utilizzabile.

Googlebot lavora in due tempi. Scarica l’HTML e lo mette in coda, e più tardi un servizio separato esegue il JavaScript in un browser stateless, che azzera local storage e session storage a ogni passaggio: tutto quello che il tuo sito ricorda fra una pagina e l’altra, per lui non è mai esistito. Fra le due fasi passano ore o giorni. Nel frattempo segue i redirect fino a un limite dichiarato, riprova sulle risposte 5xx, legge il canonical che gli indichi e si riserva di sceglierne un altro. Vent’anni di web mal costruito hanno prodotto quel comportamento, che serve ad assorbirlo.

I crawler di ChatGPT e di Claude prendono il documento in una sola passata. Scaricano i file JavaScript e non li eseguono mai, si portano via il codice e lasciano sul posto quello che avrebbe costruito: Vercel ospita una quota rilevante dei siti costruiti in JavaScript, quindi il traffico dei crawler le passa davanti per mestiere: insieme all’agenzia MERJ ha letto un mese di richieste reali arrivate sulla propria rete, e ne è uscito che l’11,5% delle richieste di GPTBot e il 23,8% di quelle di Claude finiscono su file di script che restano lettera morta. E sono anche più grossolani nel muoversi dentro un sito, tanto che più di un terzo delle richieste di ChatGPT è arrivato su pagine inesistenti, contro l’8% di Googlebot. Gemini e AppleBot fanno eccezione, perché girano su infrastrutture dove il rendering c’è già.

La persona che apre la pagina esegue il JavaScript sul proprio telefono, con la rete che ha in quel momento, e ha una sola occasione. Googlebot e i crawler generativi si stanno avvicinando a quella condizione.

Qual è il perimetro della SEO tecnica oggi

La scelta dei temi da coprire, la qualità di un’analisi, la reputazione del brand fuori dal sito restano fuori dai confini della SEO tecnica. Nel novero delle attività rientra il modo in cui quelle cose vengono esposte: dove sta un contenuto dentro il documento, quanti passaggi servono per raggiungerlo, quanto ne sopravvive al prelievo. HTML pulito e duecento millisecondi non creano domanda per un articolo che nessuno cerca; una ricerca originale che vive dentro un componente caricato via JavaScript, in una pagina raggiungibile solo dal menu a tendina del footer, produce lo stesso risultato di una ricerca che non hai mai fatto.

Dentro il perimetro stanno sei ambiti, le tappe che una pagina attraversa per arrivare in archivio, nell’ordine in cui le incontra.

• L’infrastruttura decide se la richiesta riceve risposta.
• Le direttive di accesso decidono quali percorsi sono percorribili.
• L’architettura decide quali pagine vengono mai raggiunte.
• Il prelievo decide quanto documento viene portato via.
• Il rendering decide quale versione di quel documento viene valutata.
• L’indicizzazione decide se conservarla.

Un guasto a monte cancella tutti i piani superiori insieme, ed è la ragione per cui l’ordine con cui li affronti conta quanto le correzioni che fai.

Infrastruttura: la macchina che risponde

Quando un bot bussa qualcuno deve aprire, e se la porta resta chiusa niente di quello che hai costruito sopra ha valore. Il dialogo fra il tuo server e chi ti legge passa da due variabili: che cosa rispondi, dichiarato da un codice di stato su cui il crawler decide se tornare, e in quanto tempo rispondi, che è il valore su cui il motore calibra quante richieste può permettersi di farti.

I codici coprono quasi tutte le situazioni con cinque numeri. 200 dichiara successo, e il documento allegato viene preso per buono. 301 sposta in modo permanente e trasferisce i segnali alla destinazione. 302 dichiara uno spostamento provvisorio e lascia i segnali sull’origine, che è la ragione per cui usarlo su un trasferimento definitivo costa mesi di recupero. 404 fa uscire la risorsa dall’indice nel giro di qualche passaggio, e 410 fa la stessa cosa in modo definitivo. 503 dice che il problema è temporaneo e il motore riprova senza declassare niente: è la risposta giusta durante una manutenzione, al posto della pagina bianca con stato 200 che molti mettono online.

Il carrello svuotato, la ricerca interna senza risultati, la scheda di un prodotto uscito dal catalogo restituiscono un documento con dentro un messaggio di errore e uno stato che dichiara successo. Google li chiama soft 404, li riconosce da sé leggendo il contenuto, e nel frattempo li ha scansionati tutti: su un ecommerce con migliaia di prodotti fuori catalogo quel meccanismo assorbe la maggior parte delle richieste in arrivo.

Risposte che si allungano, 5xx, un 429 che chiede di rallentare, e la frequenza di passaggio scende; dopo un periodo di errori il ritmo torna al livello precedente nell’arco di giorni.

L’effetto si vede quando pubblichi molto e le pagine nuove entrano in indice con settimane di ritardo, e il collo di bottiglia sta in una macchina che sotto carico impiega tre secondi a rispondere. Fra il crawler e quel server, poi, c’è quasi sempre qualcos’altro — una rete di distribuzione, un firewall applicativo, un sistema di gestione dei bot — le cui regole vengono scritte in emergenza e restano attive per anni: un bot che riceve un challenge JavaScript archivia la pagina di verifica come se fosse il tuo contenuto.

Su questo ambito si lavora così:

• leggere la distribuzione dei codici di stato su tutto il sito e cercare catene di redirect oltre due salti, soft 404 e gruppi ricorrenti di 5xx;
• misurare il tempo al primo byte sui template principali — home, categoria, scheda prodotto, articolo, approdo di campagna — e trattare come problema infrastrutturale tutto quello che sta sopra il mezzo secondo;
• verificare nei log che i crawler ricevano 200 e non challenge o 403, controllando con una risoluzione inversa che chi si dichiara Googlebot lo sia davvero;
• rivedere le regole del firewall e la configurazione di gestione bot, che quasi nessuno rilegge dopo averle scritte.

Crawling: quali percorsi sono percorribili

Le direttive di accesso sono tre file e una manciata di righe, e insieme decidono quali parti del tuo sito esistono per chi ti legge. Il robots.txt dichiara i percorsi che un bot può chiedere. La sitemap dichiara gli indirizzi che vuoi far conoscere e la data della loro ultima modifica. Il meta robots, dentro la pagina, dichiara che cosa il motore può farne una volta letta.

Disallow impedisce la richiesta, non l’indicizzazione: un indirizzo bloccato che riceve link da fuori può comparire in SERP senza descrizione, perché il motore ne conosce l’esistenza e non ha potuto leggerlo. Per tenere una pagina fuori dall’indice serve il percorso opposto, lasciarla raggiungibile e metterci sopra un noindex, che il crawler vede solo se entra. Il blocco delle risorse è il caso che nessun rapporto segnala. Un Disallow: /assets/ chiude i fogli di stile e gli script che compongono la pagina, il renderer li chiede e riceve un rifiuto, e quello che finisce in valutazione è un documento smontato senza che nessun rapporto segnali niente.

Ogni link rotto è una chiamata buttata, ogni catena di redirect è una chiamata moltiplicata, ogni parametro non consolidato è una variante da valutare e scartare.

La documentazione di Google sul crawl budget si apre dichiarando che riguarda siti oltre il milione di pagine uniche a cambiamento settimanale, o siti da diecimila pagine che cambiano ogni giorno, e che sotto quelle soglie non serve leggerla. La vera misura utile non è quante pagine vengono scansionate, è quale percentuale della scansione finisce su indirizzi che non producono niente.

Su questo ambito si lavora così:

• leggere il robots.txt riga per riga dopo ogni migrazione, cambio di CMS o aggiornamento di plugin, e controllare che non chiuda le cartelle di fogli di stile e script;
• tenere nella sitemap soltanto indirizzi canonici, indicizzabili e che rispondono 200, e aggiornarla quando il sito cambia;
• distinguere quello che va bloccato alla richiesta da quello che va lasciato entrare con un noindex;
• misurare nei log la quota di scansione che finisce su pagine senza ritorno, invece di contare le pagine scansionate.

Architettura: quali pagine vengono raggiunte

I collegamenti interni sono il modo in cui dichiari che cosa conta, e il motore li legge come una gerarchia anche quando tu non ne hai progettata nessuna. La distanza fra la home e una pagina, misurata in numero di clic, predice quanto spesso quella pagina viene scansionata: un documento a due passaggi riceve visite regolari, uno a sei entra in una coda che si svuota lentamente.

Un collegamento apre una strada al crawler e dichiara che la destinazione ha a che fare con l’origine. Il testo dell’ancora è la parte che porta significato, e sostituirlo con «clicca qui» butta via l’unico segnale esplicito che stai emettendo. Le pagine che vuoi difendere devono ricevere collegamenti dalle sezioni che ne parlano, non da un blocco identico ripetuto ovunque: un rimando dal corpo di un articolo pertinente vale più di venti voci in un menu, perché il primo dichiara una relazione e il secondo segnala soltanto che esiste una voce di navigazione. All’estremo opposto stanno le pagine orfane, raggiungibili solo se ne conosci l’indirizzo, che si trovano confrontando gli indirizzi raggiunti da una scansione con quelli che Search Console dichiara di conoscere.

Un catalogo con cinque filtri combinabili genera decine di migliaia di indirizzi diversi a partire dagli stessi prodotti, e ogni combinazione consuma richieste. Far esistere un indirizzo ha senso dove c’è una domanda che lo cerca: una categoria e un filtro singolo la intercettano, perché qualcuno cerca davvero «scarpe da running donna», mentre tre filtri incrociati e un ordinamento servono a chi sta già comprando e a nessun altro. Gli archivi generati per ogni tag, per ogni autore, per ogni mese rientrano nella stessa famiglia e su un blog con qualche anno di storia superano di molte volte gli articoli veri.

Una risposta generativa si compone da più ricerche simultanee sull’indice, il query fan-out: il sistema scompone la domanda in interrogazioni parallele e mette insieme quello che trova su ciascun ramo. Un sito indicizzato a metà perde su tutti i rami insieme, e la copertura granulare di un tema pesa più della singola pagina forte.

Su questo ambito si lavora così:

• misurare la profondità di clic delle pagine che portano fatturato, e riportare sotto il terzo livello quelle che contano;
• isolare le pagine orfane e decidere se collegarle o rimuoverle;
• contare quante combinazioni di filtri sono raggiungibili da un crawler e chiudere quelle oltre la soglia, con parametri esclusi, collegamenti non navigabili o noindex;
• controllare i testi delle anchor interne verso le pagine strategiche.

Prelievo: quanto documento viene portato via

Il documento che il motore valuta è quasi sempre più corto di quello che hai pubblicato, e la differenza non compare in nessun rapporto. Googlebot scarica i primi 2MB di una pagina HTML e si ferma alla soglia, che vale per il file HTML e non per il peso complessivo della pagina con immagini, fogli di stile e script.

La soglia si misura sui byte non compressi. Negli strumenti di sviluppo del browser leggi il peso trasferito, che con la compressione attiva è tre o quattro volte più piccolo: un documento che ti risulta da 400KB può superare il limite senza darti motivo di sospettarlo. Il controllo giusto è salvare il sorgente e guardare il peso del file sul disco.

La mediana dell’HTML sul web sta intorno ai ventidue kilobyte, quindi il limite non riguarda la maggior parte dei siti. Morde su una famiglia precisa di architetture: applicazioni che serializzano dentro il documento lo stato dell’interfaccia, pagine con fogli di stile e script scritti in linea, listati generati sul server con centinaia di elementi, cataloghi che caricano tutte le varianti di prodotto nel markup iniziale. Se il tuo sito appartiene a quella famiglia, tutto quello che sta dopo il taglio è materiale che hai scritto e che nessuno leggerà, e l’ordine dei blocchi smette di essere una scelta estetica: un contenuto principale che comincia dopo tremila righe di navigazione e widget arriva più tardi, e su una pagina pesante può non arrivare affatto.

Un crawler non scorre, non clicca, non apre schede. Lo scroll infinito lascia fuori tutto quello che sta oltre la prima schermata, se le pagine successive non hanno anche indirizzi propri e collegamenti veri. Nelle applicazioni a pagina singola l’indirizzo cambia senza che il server consegni un documento nuovo, quindi chi non esegue il codice riceve sempre la stessa pagina. I contenuti che arrivano con una chiamata di rete al momento del clic — schede, tab, commenti — per i tuoi lettori non esistono, mentre quelli già presenti nel documento e soltanto nascosti vengono letti.

Su questo ambito si lavora così:

• salvare il sorgente dei template principali e misurare il peso del file HTML non compresso, tenendo il megabyte come soglia di attenzione;
• spostare il contenuto principale più in alto nel documento e alleggerire quello che lo precede;
• dare indirizzi propri e collegamenti navigabili a tutto quello che oggi si raggiunge solo scorrendo;
• aprire “Visualizza sorgente pagina” su una scheda interna e cercare il testo, per vedere il documento come lo consegna il server invece del DOM ricostruito dal browser; chi lavora da terminale ottiene lo stesso con una richiesta curl.

Rendering: quale versione viene valutata

Il rendering è il passaggio in cui un sistema esegue il codice della pagina per costruire la versione definitiva del documento, e su molti siti è il punto in cui il contenuto sparisce senza lasciare traccia. La distanza fra l’HTML che esce dal server e quello che esiste nel browser a script eseguiti misura quanto del tuo lavoro dipende da quel passaggio.

Il servizio che esegue il JavaScript per conto di Google lavora senza memoria fra una richiesta e l’altra. Cancella local storage e session storage, non conserva cookie fra i passaggi, tratta ogni pagina come la prima: un contenuto che compare solo dopo un consenso salvato, o dopo un’interazione, per il motore non compare mai. E il passaggio può interrompersi in silenzio — una chiamata esterna che va in timeout, una risorsa bloccata dal robots.txt, un errore JavaScript che ferma l’esecuzione a metà — senza che nessuna delle tre cose produca una segnalazione.

Il punto in cui la pagina prende forma decide quanti dei tuoi lettori riescono a vederla. Nel rendering lato client il server consegna un documento minimo e il browser costruisce tutto, ed è la configurazione che espone di più. Nel rendering lato server la pagina arriva completa a chiunque la chieda, crawler compresi. La generazione statica fa lo stesso lavoro in anticipo, al momento della pubblicazione, ed è la soluzione più solida per i contenuti che cambiano di rado, mentre le forme ibride rigenerano a intervalli e tengono insieme freschezza e completezza. Il rendering dinamico, cioè servire una versione pre-renderizzata ai bot, resta fuori da questo elenco perché è un rimedio: richiede di riconoscere i bot, tenere due percorsi allineati e aggiornare la lista a ogni crawler nuovo, e come scelta permanente produce una manutenzione che nessuno fa.

Su questo ambito si lavora così:

• confrontare il sorgente consegnato dal server con il DOM finale sui template critici, e pretendere che il contenuto principale stia già nel primo;
• provare le pagine con JavaScript disattivato e guardare che cosa resta;
• portare su rendering lato server o generazione statica tutto quello che deve essere letto da chi il codice non lo esegue;
• controllare che nessuna risorsa necessaria alla costruzione della pagina sia bloccata nel robots.txt.

Indicizzazione: che cosa viene conservato

Una pagina indicizzabile e una pagina indicizzata sono due cose diverse, e la seconda la decide il motore. Come spiegano le stesse linee guida di Google, un documento che risponde correttamente, che nessuna direttiva blocca e che nessun canonical rimanda altrove ha soltanto il diritto di essere valutato.

La valutazione riguarda quasi sempre gruppi di pagine. Il sistema cerca gli altri documenti del dominio che dicono la stessa cosa, ne elegge uno a rappresentante, gli attribuisce i segnali che gli altri hanno raccolto e mette da parte il resto. Quando trovi migliaia di indirizzi lasciati fuori, il problema sta nella regola che le produce, non nella qualità del singolo documento. Il sito ha generato pagine che nessuno ha progettato, e vanno contate e raggruppate per schema di indirizzo, perché la correzione riguarda la regola che le produce.

Nel rapporto Indicizzazione delle pagine di Search Console due stati si somigliano e portano in direzioni opposte. Sotto «Rilevata, ma attualmente non indicizzata» finiscono gli indirizzi trovati e mai richiesti, di solito perché il server ha dato segni di affanno. Sotto «Pagina scansionata, ma attualmente non indicizzata» finiscono i documenti prelevati per intero, letti, e lasciati fuori. Il primo caso è un problema di accesso, il secondo di merito.

Il canonical è lo strumento con cui dichiari il rappresentante del gruppo, e Google lo tratta come un’indicazione forte conservando il diritto di ignorarla: lo fa quando il contenuto delle due pagine diverge, quando i collegamenti interni puntano in massa altrove, quando la sitemap dice una terza cosa. Il Controllo URL mostra sia il canonical dichiarato sia quello scelto, e se differiscono hai una diagnosi diretta. Sul piano editoriale il caso gemello è la cannibalizzazione: due documenti che rispondono alla stessa domanda si dividono segnali e storia, e il sintomo è l’oscillazione settimanale fra i due in SERP. Sui siti con più mercati, infine, l’attributo hreflang dichiara le corrispondenze fra le versioni, e la regola che salta più spesso è la reciprocità — se la pagina italiana dichiara quella inglese, quella inglese deve dichiarare l’italiana, altrimenti il motore scarta l’intero gruppo. Il valore x-default indica dove mandare chi non rientra in nessuna versione dichiarata.

Su questo ambito si lavora così:

• contare gli indirizzi nei due stati di Search Console e raggrupparli per schema, per correggere la regola invece delle singole pagine;
• verificare nel Controllo URL che canonical dichiarato e canonical scelto coincidano sui template che contano;
• consolidare i parametri di tracciamento e le varianti di ordinamento su un rappresentante unico;
• controllare la reciprocità delle dichiarazioni hreflang e la presenza di x-default.

Quello che l’indice non garantisce

Una pagina conservata in archivio non ha ancora incontrato nessuno. L’indicizzazione riuscita dice che il documento è arrivato integro e che il sistema ha deciso di tenerlo, ed è un permesso di partecipare. Non dice niente su chi lo aprirà né su che cosa ne farà.

Chi ci arriva da un clic giudica la pagina nel tempo che impiega a diventare usabile, e quel tempo lo misura sul telefono che ha in mano, con la rete di quel momento. Non aspetta che gli script finiscano di costruire il contenuto, non riprova più tardi per vedere se nel frattempo è comparso, e non ha nessun motivo per concederti una seconda occasione.

Un sistema che compone una risposta la pagina non la apre nemmeno. Ne prende una porzione — un paragrafo, una tabella, una definizione — e la monta dentro un testo scritto altrove, davanti a qualcuno che il tuo sito non lo vedrà mai. Un blocco che nomina il proprio soggetto con un pronome riferito a due paragrafi più su, staccato dal resto, non significa niente.

Un documento ordinato — titoli che dichiarano di che cosa parla la sezione, blocchi che si reggono da soli, contenuto presente prima che il codice parta — serve alla persona che scorre col pollice e al sistema che estrae. La velocità di caricamento riguarda quasi solo chi apre la pagina, l’eleggibilità allo snippet riguarda quasi solo chi la riusa.

Le performance si misurano con meno strumenti e pesano di più

Negli ultimi tre anni Google ha smontato buona parte dell’apparato costruito attorno all’esperienza di pagina. A dicembre 2023 sono spariti il rapporto sull’usabilità mobile e il test di ottimizzazione per dispositivi mobili, e poco dopo è stato dismesso anche il rapporto sull’esperienza sulla pagina; a marzo 2024 la metrica INP ha sostituito FID. AMP è stato svuotato per sottrazione, e il primo luglio 2026 sono spariti dalla documentazione il viewer, la cache e gli scambi firmati senza che il formato venisse mai deprecato formalmente.

Di quell’apparato restano le tre metriche dei Core Web Vitals, che stanno dentro i sistemi di ranking senza che esista un punteggio unico a riassumerle. LCP misura quanto tempo passa prima che l’elemento principale sia visibile, INP quanto la pagina è pronta a rispondere quando la tocchi, CLS quanto gli elementi si spostano mentre la stai già guardando. Il dato che conta è quello di campo, raccolto dagli utenti reali di Chrome, mentre il punteggio di PageSpeed Insights è una simulazione in condizioni scelte. Un sito con novantacinque in laboratorio e utenti che percepiscono lentezza ha un problema vero che il laboratorio non vede, perché la simulazione gira su una macchina veloce con una rete stabile mentre il tuo pubblico apre la pagina in mobilità.

Una pagina media trasferisce oggi 2,6MB su mobile, l’8,4% in più di un anno fa, e su una home tipica quasi tutto quel peso sta nelle immagini e nel JavaScript, cioè nelle due voci che decidono quanto tardi arriva l’elemento principale e quanto la pagina resta sorda al tocco. Meno della metà delle pagine mobile supera i Core Web Vitals con giudizio buono.

Chi pubblica se n’è accorto guardando i propri numeri: le stesse pagine portano meno visite organiche di due anni fa. Dove in SERP compare una AI Overview il tasso di clic sulla prima posizione può calare del 58%, e su un totale che si contrae ogni visita persa mentre la pagina si carica pesa di più di prima. La velocità, del resto, è uno dei fattori che Google ha nominato pubblicamente fra quelli che contano per AI Mode.

Su questo si lavora così:

• leggere i Core Web Vitals sui dati di campo, e usare il punteggio di laboratorio soltanto per confrontare un prima e un dopo sullo stesso template;
• pesare le immagini della home e dei template principali, convertirle in formati moderni e dichiarare width e height per non produrre spostamenti di layout;
• attivare la compressione sul server e togliere il codice CSS e JavaScript che la pagina non usa;
• impostare criteri di cache efficaci sulle risorse statiche e ridurre le richieste di terze parti che bloccano il thread principale.

L’HTML semantico serve macchine e persone insieme

Un sistema che legge la tua pagina deve capire di che cosa parli, chi lo dice e come quel contenuto si aggancia al resto del web. La struttura del documento dichiara la funzione di ogni blocco, i dati strutturati dichiarano l’identità delle entità di cui parli.

Un H1 che apre, H2 che segnano i passaggi principali, H3 che scendono di livello senza saltare gradini: quella scala permette a un sistema di capire dove comincia e dove finisce un argomento, e permette a chi usa un lettore di schermo di raggiungere il punto giusto invece di ascoltare tutta la pagina. Gli elementi che dichiarano la funzione di un blocco — l’intestazione, la navigazione, il contenuto principale, il piè di pagina — separano il testo che conta dal contorno che si ripete ovunque.

Ma per chi legge la pagina da fuori, la scala esiste solo se sta nell’HTML che il server consegna. Il contenuto che il codice costruisce dopo non c’è per il crawler che il codice non lo esegue, non c’è per la persona con una connessione instabile, non c’è per il browser che ha bloccato uno script per motivi di sicurezza.

Su questo si lavora così:

• controllare sui template che la gerarchia dei titoli non salti livelli e che ci sia un solo H1;
• dichiarare con gli elementi giusti intestazione, navigazione, contenuto principale e piè di pagina;
• verificare che i dati strutturati dichiarino le stesse cose scritte nella pagina;
• limitare il markup ai tipi che producono ancora un risultato supportato.

Che cosa fanno davvero i dati strutturati

I dati strutturati dichiarano in forma leggibile dalla macchina informazioni che il testo lascia ambigue: chi è l’organizzazione che pubblica, chi è l’autore e a quali profili esterni corrisponde, quale prodotto è in vendita e a quale prezzo, quali passaggi compone una procedura. Lo standard è Schema.org in formato JSON-LD, che Google preferisce ed è più facile da gestire e validare rispetto ai microformati.

Servono alla disambiguazione delle entità e restano la condizione di eleggibilità per i tipi di risultato avanzato ancora supportati. Un sito marcato bene diventa un nodo identificabile nel Knowledge Graph; un sito marcato male resta una stringa di testo da interpretare ogni volta da capo.

Quanti siano i tipi ancora supportati, però, cambia da un anno all’altro, e sempre per sottrazione. I risultati avanzati per le istruzioni HowTo sono stati chiusi e quelli per le FAQ ridotti fino alla rimozione definitiva del maggio 2026. Da giugno 2025 sette tipi di dati strutturati sono usciti dalla documentazione, seguiti a novembre dallo schema per i problemi di matematica. Il markup applicato ovunque, su ogni tipo disponibile, produce manutenzione per risultati che nel frattempo Google ha chiuso.

Per comparire nelle funzioni AI, poi, non serve alcun markup dedicato, e l’unica raccomandazione che Google formula è che i dati strutturati corrispondano al testo visibile in pagina. Un markup che dichiara cose diverse da quelle scritte nella pagina fa più danno della sua assenza.

L’accessibilità come vincolo tecnico

L’accessibilità raccoglie i requisiti che rendono una pagina utilizzabile da chi non la guarda con gli occhi e non la comanda con un mouse. Chi usa un lettore di schermo ricostruisce il documento dalla gerarchia dei titoli e dagli elementi che ne dichiarano la funzione, e si sposta da una sezione all’altra saltando di H2 in H2.

È la stessa struttura da cui un parser ricava dove comincia e dove finisce un argomento, ed è la stessa etichetta collegata al campo che permette a un agente software che compila moduli al posto di chi lo usa di capire che cosa gli stai chiedendo. Un pulsante che è un div con un gestore di eventi non esiste per nessuno dei due. Struttura dei titoli, elementi semantici, alternative testuali, contenuto presente senza esecuzione di codice, moduli con etichette collegate ai campi: le voci sono queste da entrambe le parti, e conviene farne un lavoro solo.

Compilare un’alternativa testuale non richiede nessuna competenza tecnica, e il campo sta nel pannello di caricamento di qualunque CMS. Gli attributi alt sono presenti sul 60% delle immagini in mediana, e il 15% porta un valore vuoto.

La direttiva europea 2019/882 si applica ai servizi forniti ai consumatori dopo il 28 giugno 2025, e per i siti che vi rientrano quel campo non è più una voce che decidi tu se compilare. Il commercio elettronico rientra nel perimetro esplicito insieme ai servizi bancari al consumo, ai libri elettronici, al trasporto passeggeri e alle comunicazioni elettroniche. Le microimprese fornitrici di servizi sono escluse, con la soglia fissata a meno di dieci dipendenti e due milioni di euro di fatturato annuo. In Italia il recepimento è il decreto legislativo 82/2022, con la stessa decorrenza e disposizioni transitorie fino al 2030 per i contratti già in essere.

Su questo si lavora così:

• compilare le alternative testuali, e lasciare l’attributo vuoto soltanto sulle immagini decorative;
• collegare ogni etichetta al proprio campo nei moduli;
• usare pulsanti e collegamenti veri al posto di div con un gestore di eventi;
• attraversare le pagine principali con la sola tastiera e vedere dove ti fermi.

Nelle risposte generative si entra solo dall’indice

Quando la tua pagina finisce dentro una risposta generata, la SEO tecnica resta la sola condizione che puoi ancora controllare, perché la domanda, il modo in cui il sistema la scompone e la frase che ne estrae stanno tutti fuori dal tuo sito. La documentazione di Search Central sulle funzioni AI dice che per comparire come link di supporto in AI Overviews o in AI Mode una pagina deve essere indicizzata ed eleggibile allo snippet, soddisfacendo i requisiti tecnici di Search, e che non esistono requisiti tecnici aggiuntivi. La stessa pagina aggiunge che soddisfare i requisiti non garantisce scansione, indicizzazione o pubblicazione.

Una pagina esclusa dallo snippet — con nosnippet, con max-snippet:0, o con data-nosnippet sul blocco che conta — esce dalle risposte generative insieme allo snippet, e quelle direttive capita di trovarle attive per scelte prese anni prima contro gli aggregatori di notizie.

Fuori dall’indice di Google la condizione cambia, perché ogni sistema arriva sul tuo sito per conto proprio. GPTBot e ClaudeBot scaricano il JavaScript senza eseguirlo, Gemini e AppleBot lo eseguono perché girano su infrastrutture che il rendering ce l’hanno. Scrivere che «i crawler AI non eseguono JavaScript» generalizza oltre quello che i dati dicono. Per chi non lo esegue, il contenuto deve esistere nell’HTML che il server consegna, e questo riporta al centro scelte architetturali che la SEO tradizionale aveva smesso di considerare perché il motore compensava.

Il recupero per passaggi

I sistemi che compongono risposte non riprendono pagine intere, riprendono porzioni. Un blocco che si regge da solo — che nomina il soggetto invece di richiamarlo con un pronome, che contiene il dato e la sua fonte, che non dipende dai due paragrafi precedenti — può essere estratto e citato.

I titoli di sezione descrivono il contenuto della sezione, le tabelle portano intestazioni vere, le cifre stanno nel testo invece che dentro un’immagine. Sono accorgimenti di struttura, e restano utili anche quando nessun sistema generativo entra nel discorso, perché sono gli stessi che rendono la pagina scorribile da una persona.

Le scorciatoie proposte al mercato

Il file llms.txt è presente sul 2,1% dei siti secondo il Web Almanac 2025, e il 39,6% di quelle occorrenze è generato automaticamente da un plugin. La maggioranza di chi lo ha non ha deciso di averlo, e la documentazione di Google dichiara che per comparire nelle funzioni AI non serve creare documenti leggibili dalle macchine, testi dedicati all’AI o markup speciali.

Google-Extended serve a escludere i tuoi contenuti dall’addestramento dei modelli Gemini, non dalla comparsa in AI Overview, che usa l’indice di Search costruito da Googlebot. Il controllo che riguarda davvero le funzioni generative è arrivato a giugno 2026 come impostazione dentro Search Console, e il rapporto associato espone le impressioni senza esporre i clic.

Dal 2025 diversi provider hanno introdotto il rifiuto dei crawler AI come impostazione predefinita, e vale sapere quale configurazione hai attiva, perché un crawler bloccato non ti cita. Cloudflare ha pubblicato a settembre 2025 la Content Signals Policy, tre segnali dichiarabili nel robots.txt — search, ai-input, ai-train — rilasciati con licenza aperta, che la stessa Cloudflare distingue da una contromisura tecnica.

Su questo si lavora così:

• controllare che nessuna direttiva nosnippet o max-snippet sia attiva sulle pagine che vuoi far citare;
• verificare nel robots.txt e nella configurazione del provider quali crawler AI stai accettando e quali stai rifiutando;
• controllare che il contenuto esista già nell’HTML consegnato dal server;
• rendere autosufficienti i blocchi che rispondono a una domanda precisa.

Il sintomo non compare dove sta il guasto

Una pagina costruita nel browser supera ogni verifica che puoi farle. Il server risponde 200. Il Controllo URL mostra l’indirizzo come idoneo. Il test dei risultati avanzati convalida il markup. Il testo, al momento del prelievo, non c’era, e in nessuno di quei tre controlli esiste un punto dove leggerlo.

I collegamenti interni che portano a una sezione irraggiungibile per il crawler restano un esercizio grafico. I dati strutturati aggiunti a una pagina che risponde con un challenge finiscono dentro una verifica di sicurezza. Il titolo riscritto su una pagina consolidata su un altro indirizzo cambia un documento che il motore ha smesso di considerare. Lavori fatti bene su un sito che si è rotto altrove, e il tempo speso non torna.

Su siti diversi quei sintomi si ripetono quasi identici, e la corrispondenza fra quello che vedi e il punto in cui guardare si scrive una volta e si riusa.

Quali verifiche eliminano più ipotesi

Un calo di traffico su una sezione intera può venire da un blocco a monte o da una perdita di posizioni. Guardare se quelle pagine sono ancora in indice, dal rapporto Indicizzazione delle pagine o con una ricerca site:, costa un minuto e fa cadere metà delle ipotesi.

Dopo un rilascio, il confronto fra il documento che esce dal server e quello che esiste nel browser a script eseguiti separa un problema di rendering da un problema di contenuto. Si fa in due finestre affiancate, il sorgente della pagina da una parte e il pannello degli elementi dall’altra, prima di aprire qualsiasi strumento di analisi.

Le verifiche si ordinano per quanto campo eliminano, mai per quanto somigliano alla causa che sospetti. Il sospetto iniziale è quasi sempre l’ipotesi che avevi in testa prima di guardare i dati, e le ore peggiori si spendono a confermarla.

Gli strumenti per fare SEO tecnica

Una parte dei controlli non richiede nessuno strumento. «Visualizza sorgente pagina» mostra il documento come lo consegna il server, e cercare lì dentro il testo del contenuto principale separa in dieci secondi un problema di rendering da qualunque altra cosa; salvare quel sorgente sul disco e guardarne il peso dice se sei vicino ai 2MB.

Il robots.txt si legge riga per riga in un minuto. Il Controllo URL di Search Console mostra sullo stesso schermo il canonical che hai dichiarato e quello che Google ha scelto. PageSpeed Insights restituisce due numeri che conviene non confondere: il punteggio di laboratorio, calcolato su una macchina simulata, e i dati di campo raccolti dai browser degli utenti reali, che compaiono soltanto se la pagina riceve abbastanza visite.

Quei controlli valgono per una pagina alla volta, e i difetti che contano stanno nei template, ripetuti su migliaia di indirizzi.

Gli strumenti che scansionano al posto tuo

Un crawler percorre i collegamenti come farebbe un bot e restituisce per ogni indirizzo lo stato della risposta, i tag, i collegamenti in entrata e in uscita, la profondità di clic. Screaming Frog gira sul tuo computer e non ha altri limiti che quelli della macchina; i crawler in cloud fanno lo stesso lavoro senza tenerti occupato il portatile per due ore.

Nessuno dei due sa che cosa succede dopo la scansione. Quali di quelle pagine siano davvero in indice, quante impressioni raccolgano e quanto traffico portino lo sanno solo Search Console, per la parte Google, e i log del tuo server, che registrano ogni richiesta arrivata e sono l’unico posto dove leggi che cosa hanno chiesto davvero i crawler, Googlebot come GPTBot.

Che cosa aggiunge SEOZoom

Il SEO Spider di SEOZoom fa la scansione e mette i dati tecnici sulla stessa riga dei dati di visibilità. Per ogni indirizzo trovi il codice di stato, se è bloccato dal robots.txt, quanti clic lo separano dalla home, i collegamenti interni ed esterni, e accanto quante keyword posiziona quella pagina, quante stanno in prima pagina, quanto volume di ricerca muovono. È la differenza fra sapere che una pagina sta a sei clic di profondità e sapere che sta a sei clic e presidia cinquanta keyword.

Il pannello SEO Elements raggruppa i difetti per tipo e li usa come filtro sulla griglia: i codici di risposta separano gli indirizzi bloccati dal robots.txt, quelli che non rispondono, i 2xx, i 3xx, i 4xx e i 5xx, e allo stesso modo si isolano title, meta description, H1, H2, immagini, canonical, direttive, link e hreflang. La Crawl Tree mostra la stessa scansione come un albero, e per ogni pagina espone profondità, codice di risposta, direttive robots, canonical, title, description e hreflang.

Rendimento pagine risponde alla domanda che una scansione da sola non può porre: quanta parte della scansione se ne va su pagine che non producono niente. La tabella distribuisce le pagine per fascia di traffico e per ciascuna dice quanto crawl budget consuma, così la decisione — consolidare, mettere in noindex, restituire 410 — si prende su un gruppo invece che su un indirizzo alla volta. Nella stessa area stanno la scheda sulla cannibalizzazione e una colonna che conta le menzioni AI raccolte da ogni pagina.

Dentro i Progetti la sezione Core Web Vitals misura la home e fino a cinque template, su desktop e su mobile, e ne conserva lo storico, così una correzione si verifica invece di essere dichiarata. Vale sapere che cosa restituisce: sono rilevazioni Lighthouse, quindi dati di laboratorio, con le opportunità e la diagnostica che ne derivano — utili per confrontare un prima e un dopo, non per sapere che cosa hanno vissuto gli utenti, che resta il mestiere dei dati di campo.

In Reportistica il SEO Audit trasforma una scansione in un documento con l’analisi tecnica e le indicazioni operative, e il Quick Audit dà la panoramica rapida sullo stato di un sito. Sono la forma in cui il lavoro esce dalla piattaforma e arriva a un team di sviluppo o a un cliente, con l’intestazione personalizzabile.

Sul fronte generativo l’AEO Audit analizza come il brand emerge dalle ricerche dei sistemi che recuperano fonti in tempo reale, e il GEO Audit interroga la memoria dei modelli per verificare che cosa hanno appreso del dominio. Presuppongono tutto quello che sta sopra. Su un sito che perde contenuto al prelievo, restituiscono il riflesso del lavoro che non è stato fatto sotto.

La soglia che si è alzata

Per due decenni la SEO tecnica si è misurata su una domanda sola: Google riesce ad arrivare, a leggere, a mettere in archivio? La risposta era quasi sempre sì, perché dall’altra parte c’era un sistema che rimediava agli errori mentre li incontrava. Una generazione intera di progetti è cresciuta sopra fondamenta che nessuno ha mai verificato, e ha funzionato.

Oggi quella domanda la pongono in tre. Il motore rimedia ancora, con qualche attrezzo in meno. I crawler che raccolgono testo per le risposte generative prendono quello che trovano nell’HTML e non ripassano. La persona ha una sola occasione, come ha sempre avuto. Lo stesso difetto, sul tuo sito, produce tre danni di peso diverso, e su un web dove il 68% delle ricerche si chiude senza un clic ognuno costa più di quanto costasse cinque anni fa.

Il mestiere, in sé, è rimasto quello di sempre. Un robots.txt che non chiude quello che non deve chiudere, un server che regge sotto carico, il testo che esiste già nel documento consegnato al primo passaggio, un indirizzo per ogni cosa e una cosa per ogni indirizzo, un’architettura che dice che cosa conta. Nessuna di queste voci è nuova, e nessuna sembrava urgente finché qualcuno la rattoppava per conto tuo.

Il debito accumulato in quegli anni non si presenta come un errore dentro un rapporto. Si presenta come assenza: risposte in cui non compari, pagine che nessuno apre. Il momento per andare a contarlo è prima che ci arrivi qualcun altro, nel tuo settore.