Hai ottimizzato i tuoi contenuti. Il tuo sito ha competenza, autorevolezza e segnali di fiducia. Ma quando un crawler AI arriva alla tua pagina e si trova davanti a un timeout, cioè quando il tuo server impiega 6 secondi a rispondere o quando l'LCP non ha finito il rendering dopo 5 secondi, il crawler va oltre. I tuoi contenuti non vengono mai indicizzati. Le tue citazioni non arrivano mai.
La lentezza uccide la visibilità. Non lentamente. In modo istantaneo, con uno stop netto.
I crawler AI operano con vincoli che i motori di ricerca tradizionali non hanno. Hanno finestre di timeout rigide, budget di calcolo limitati e poca pazienza. Una pagina che si posiziona alla perfezione per Google può essere del tutto invisibile a ChatGPT, Perplexity o Claude perché non si carica entro la scadenza del crawler. Questo capitolo spiega come funzionano i Core Web Vitals per l'AI, quali metriche contano di più e quali cambiamenti devi fare.
Cosa misurano i Core Web Vitals e perché esistono
I Core Web Vitals sono tre metriche create da Google per misurare l'esperienza reale degli utenti. Catturano il momento in cui il browser inizia a mostrare i contenuti, il momento in cui gli utenti possono interagire con la pagina e quanto resta stabile il layout durante il caricamento. Google li tratta come fattori di posizionamento. Ma per i crawler AI sono fattori di sopravvivenza.
Le tre metriche sono:
Largest Contentful Paint (LCP): quanto tempo passa prima che si carichi l'elemento visivo più grande. L'obiettivo è sotto i 2,5 secondi. È ciò che gli utenti vedono per primo: se la tua immagine principale, il titolo o la sezione di contenuto principale impiegano 4 secondi ad apparire, sia le persone sia i crawler devono aspettare.
Interaction to Next Paint (INP): quanto tempo impiega il browser a rispondere dopo che un utente clicca qualcosa. L'obiettivo è sotto i 200 millisecondi. Questa metrica verifica se il tuo JavaScript è eccessivo o se la tua pagina si blocca quando i crawler simulano un'interazione.
Cumulative Layout Shift (CLS): quanto la pagina "rimbalza" mentre si carica. L'obiettivo è sotto 0,1. Quando gli elementi si spostano in modo inatteso, i crawler estraggono contenuti confusi o incompleti. I tuoi paragrafi scritti con cura diventano illeggibili nell'analisi del crawler.
Per la ricerca tradizionale sono indicazioni. Per i crawler AI sono limiti rigidi.
Perché i crawler AI hanno requisiti di velocità diversi da Google
Il crawler di Google distribuisce il lavoro. Esplora milioni di URL su migliaia di server. Può permettersi di aspettare 10 secondi che una pagina si carichi perché l'attesa è distribuita su un'infrastruttura enorme.
I crawler AI operano con un'inferenza per ogni ricerca. Quando un utente fa una domanda a ChatGPT, Perplexity ha da 3 a 5 secondi per trovare, recuperare e analizzare i tuoi contenuti prima che la risposta debba iniziare a essere generata. Ogni secondo conta. Ogni millisecondo viene contato sul budget di esplorazione.
Gli studi sul comportamento dei crawler AI mostrano che i siti con First Contentful Paint sotto 0,4 secondi ottengono in media 6,7 citazioni, mentre i siti che si caricano in più di 1,13 secondi ne ottengono in media 2,1. Non è correlazione. È causalità. Le pagine lente vengono saltate.
Il crawler di recupero di ChatGPT ha una soglia di timeout documentata. Le pagine che non rispondono entro quella finestra vengono segnate come irraggiungibili e perdono priorità nei futuri tentativi di esplorazione. Il bot di Perplexity fa lo stesso. Un sito che impiega 6 secondi a rispondere non ha una seconda possibilità.
Time to First Byte (TTFB): la metrica che ai crawler AI importa di più
Il TTFB misura il tempo tra l'invio di una richiesta e la ricezione del primo byte di risposta dal server. È la misura più pura della reattività del server.
Per i crawler AI, il TTFB decide se tentano il rendering. Se il tuo server impiega 700 millisecondi a rispondere, il crawler ha già sprecato 700 millisecondi della sua finestra di 3-5 secondi. Il crawler abbandona del tutto il rendering e ripiega sull'analisi del solo HTML, il che rende invisibili i contenuti generati da JavaScript.
I valori di riferimento sono chiari. Un TTFB sotto i 200 millisecondi è considerato eccellente. Da 200 a 500 millisecondi è accettabile ma non ideale. Sopra i 600 millisecondi hai un problema di infrastruttura del server.
La maggior parte degli articoli sulle prestazioni tratta il TTFB come secondario rispetto alle metriche visive. Per i crawler AI è il guardiano all'ingresso. Se il TTFB fallisce, nient'altro conta.
Le cause più comuni di un TTFB lento sono query lente al database dietro ogni caricamento di pagina, hosting sovraccarico con troppi siti per server, instradamento geografico scadente delle richieste e mancanza di cache su una rete di distribuzione dei contenuti (CDN). Non sono problemi di design. Sono problemi di infrastruttura.
Largest Contentful Paint (LCP): l'attesa dell'elemento più grande
L'LCP misura il tempo fino al caricamento completo dell'elemento visivo più grande. Di solito è un'immagine principale, un'immagine di sfondo o un grande blocco di testo. Per le pagine ricche di contenuto, è l'area del contenuto principale.
Un LCP sotto i 2,5 secondi è la soglia "buona". I crawler AI citano le pagine in questo intervallo 2,8 volte più spesso delle pagine con LCP più lento. La differenza non è sottile.
Il crawler non aspetta che ogni elemento finisca di caricarsi. Ma aspetta che compaia il contenuto principale. Se la tua immagine principale pesa 4 megabyte e non l'hai ottimizzata per il web, il crawler resta fermo mentre l'immagine si scarica. Quando l'immagine finisce di caricarsi, hai già superato il timeout del crawler.
Le cause più comuni di un LCP lento sono immagini troppo grandi senza compressione, video incorporati non ottimizzati che bloccano il rendering, font web non ridotti che non si caricano in fretta e script di terze parti che vengono renderizzati nella parte alta della pagina. Ognuna di queste cose aggiunge secondi all'LCP.
La soluzione non è aspettare di più. La soluzione è far avvenire l'LCP più in fretta. Significa ottimizzare le immagini, caricare in modo differito i contenuti sotto la parte visibile, caricare gli script in modo asincrono e, se serve, sostituire gli incorporamenti pesanti di terze parti con alternative in HTML statico.
Interaction to Next Paint (INP): prestazioni di esecuzione del JavaScript
L'INP misura la reattività. Quando un utente (o un crawler che simula un utente) interagisce con la pagina, quanto tempo ci vuole perché qualcosa cambi sullo schermo? L'obiettivo è sotto i 200 millisecondi.
Per i crawler AI, l'INP rivela se il tuo JavaScript è ottimizzato o eccessivo. Un cattivo punteggio INP segnala che la tua pagina ha troppo codice in esecuzione sul thread principale, oppure che il codice non è suddiviso e differito come dovrebbe.
I crawler che simulano l'interazione lo fanno per estrarre contenuti dinamici. Se la tua pagina carica HTML statico ma dipende da JavaScript per mostrare moduli, contenuti condizionali o elementi interattivi, il crawler deve eseguire quel JavaScript. Se il JavaScript è lento, il crawler ottiene un cattivo punteggio INP e segna la tua pagina come inefficiente.
Il problema nascosto del rendering lato client è che la maggior parte dei crawler AI non esegue affatto il JavaScript. Le ricerche mostrano che l'HTML statico con schema markup raggiunge il 94% di successo nell'analisi, mentre i contenuti generati da JavaScript si fermano al 23%. Significa che se i tuoi contenuti sono nascosti dietro il JavaScript, i crawler AI potrebbero non vederli mai.
Se il tuo sito usa il rendering lato client, il problema dell'INP diventa un problema di visibilità. Il crawler non può aspettare l'esecuzione del JavaScript, quindi salta i contenuti che dipendono dal JavaScript.
Cumulative Layout Shift (CLS): stabilità durante l'estrazione
Il CLS misura l'instabilità visiva. Quando gli elementi della pagina si spostano durante il caricamento, il Cumulative Layout Shift aumenta. L'obiettivo è sotto 0,1.
Per i crawler, il CLS non riguarda l'esperienza utente. Riguarda l'accuratezza dell'analisi. Quando il DOM si sposta mentre il crawler estrae i contenuti, può prendere gli elementi sbagliati. Un titolo può spostarsi nello spazio di un altro titolo. Una barra laterale può spingere il contenuto principale fuori posizione. Il crawler estrae il testo che si trova in una posizione, non il testo che logicamente le appartiene.
Le cause più comuni di un CLS alto sono spazi pubblicitari che si caricano in ritardo e spingono giù il contenuto, immagini senza dimensioni specificate che si caricano e spostano il layout, font web che si scambiano e cambiano la spaziatura e caroselli con riproduzione automatica che spostano il contenuto. Ognuna di queste cose fa muovere il layout.
La soluzione è riservare spazio per tutto ciò che verrà caricato. Specifica le dimensioni delle immagini nell'HTML. Imposta font-display su swap così i font non bloccano il rendering. Carica annunci e contenuti dinamici in contenitori riservati che non causano spostamenti del layout.
Come ottimizzare per la velocità dei crawler AI
Ottimizzare la velocità per i crawler AI è diverso dall'ottimizzarla per le persone. Gli utenti tengono a quando vedono la pagina e quando possono interagire con essa. I crawler tengono a quando il server risponde e se tutti i contenuti finiscono il rendering.
Parti dal TTFB. Se il tuo server impiega più di 500 millisecondi a rispondere, nient'altro conta. Verifica le query al database, passa a un fornitore di hosting più veloce, implementa la cache a livello di applicazione o usa una CDN. L'investimento sul TTFB si ripaga subito nella copertura dei crawler.
Ottimizza le immagini. Ogni immagine della pagina dovrebbe essere compressa, ridimensionata per le dimensioni con cui viene mostrata e servita in formati moderni come WebP con alternative PNG. Usa uno strumento di compressione delle immagini. Per le immagini principali, usa una CDN con ottimizzazione automatica.
Differisci il JavaScript non critico. Carica solo il JavaScript assolutamente necessario perché il crawler veda i contenuti. Gli script che tracciano le analisi, caricano gli annunci o alimentano funzioni interattive dovrebbero essere differiti o caricati in modo asincrono. Così il thread principale resta libero e l'esecuzione veloce.
Esegui sul server il rendering dei contenuti critici. Se il tuo sito usa un framework lato client, esegui il rendering del percorso critico sul server e fai l'idratazione sul client. Così i crawler vedono subito i contenuti. La generazione di siti statici (SSG) è ancora meglio: costruisci le pagine in HTML al momento della pubblicazione.
Evita grandi incorporamenti di terze parti. Se incorpori lettori YouTube, lettori audio o grandi widget esterni, bloccano il rendering. Sostituiscili con segnaposto che si caricano al clic, oppure estrai le informazioni essenziali in HTML statico.
Riserva spazio per i contenuti dinamici. Definisci dimensioni esplicite per immagini, annunci e sezioni dinamiche. Evita gli spostamenti del layout e garantisce che il crawler estragga i contenuti giusti.
Usa una CDN. Una rete di distribuzione dei contenuti instrada le richieste al server geograficamente più vicino, riducendo latenza e TTFB. La maggior parte delle CDN offre anche ottimizzazione e compressione automatica delle immagini.
Cosa include WEMASY per velocità e ottimizzazione dei crawler
Il creatore di siti di WEMASY include hosting con cache CDN automatica, ottimizzazione delle immagini al caricamento e rendering lato server di tutti i contenuti del sito. Le pagine costruite con WEMASY rispettano per impostazione predefinita gli standard dei Core Web Vitals.
Quando pubblichi un sito con WEMASY, il tuo TTFB è ottimizzato dalla nostra CDN, le tue immagini vengono ridimensionate e compresse in automatico e il tuo HTML viene servito come pagine statiche, non generate su richiesta. Significa che i crawler AI vedono subito i tuoi contenuti, senza aspettare rendering o elaborazione.
Scopri cosa include ogni piano WEMASY.
Domande frequenti
La velocità della pagina influisce sulle citazioni dell'AI più che sulla SEO tradizionale?
I crawler AI sono più sensibili alla velocità perché operano con vincoli di tempo più stretti. I crawler tradizionali di Google possono aspettare 10 secondi che una pagina si carichi. I crawler AI di solito vanno in timeout dopo 3-5 secondi. Nella SEO tradizionale la velocità è un segnale di posizionamento. Nella GEO la velocità è una soglia. Se non la superi, le citazioni non arrivano affatto. Con il creatore di siti di WEMASY puoi impostarlo direttamente sul tuo sito.
Come faccio a sapere se il mio TTFB è abbastanza veloce per i crawler AI?
Usa Google PageSpeed Insights (eseguilo come se fosse un crawler, controllando la versione desktop). Cerca un TTFB sotto i 500 ms. Se è più alto, devi indagare su hosting, database o codice dell'applicazione. Anche altri strumenti gratuiti di test della velocità mostrano il TTFB. Se il tuo TTFB è costantemente sopra i 600 ms, contatta il tuo fornitore di hosting o valuta di passare a un hosting più veloce.
Devo ottimizzare i Core Web Vitals se non monitoro i posizionamenti tradizionali su Google?
Sì. I Core Web Vitals influenzano direttamente la visibilità nell'AI. Gli studi mostrano che l'85% dei siti citati dalle piattaforme di AI supera tutte e tre le soglie dei Core Web Vitals. Anche se i posizionamenti su Google non contano per la tua attività, la visibilità nell'AI sì. L'ottimizzazione è la stessa.
Vale la pena passare a un hosting più veloce solo per i Core Web Vitals?
Se il tuo TTFB attuale è sopra i 600 ms, sì. La differenza di costo tra hosting base e hosting veloce di solito è di 5-15 dollari al mese. Il ritorno dal miglioramento delle citazioni dell'AI e della copertura dei crawler è molto più alto. Un hosting veloce migliora anche l'esperienza utente e i tassi di conversione, non solo la possibilità di essere esplorati.
La cache migliora i Core Web Vitals?
La cache è essenziale. La cache del browser dice ai browser dei visitatori di salvare in locale immagini e file statici, così non devono scaricarli di nuovo. La cache del server salva in memoria le pagine già generate, così non devono essere ricostruite da zero. Entrambe riducono molto TTFB e LCP. Implementa le intestazioni di cache in modo deciso e usa una CDN con cache automatica.
Ottimizzare la velocità per i crawler AI danneggerà l'esperienza utente?
No. Le ottimizzazioni per la velocità dei crawler, come server più veloci, compressione delle immagini e JavaScript differito, migliorano l'esperienza utente in generale. Le pagine che si caricano più in fretta per i crawler si caricano più in fretta anche per le persone. L'unica eccezione è se cerchi di ottimizzare solo per i crawler togliendo immagini o svuotando i contenuti, il che danneggerebbe gli utenti. Non farlo. Ottimizza la velocità senza togliere valore.