Page experience signals: cosa sono davvero nel 2026 e cosa è cambiato

I page experience signals sono l’insieme di segnali con cui Google valuta se la tua pagina è piacevole da usare o se è una trappola. Nel 2020, quando furono annunciati, sembravano la rivoluzione dell’anno. Sei anni dopo la situazione è molto diversa da come te la raccontano ancora la maggior parte degli articoli in circolazione: una delle tre metriche fondamentali è stata rottamata, il badge promesso non è mai arrivato, AMP è uscito di scena e Google ha smesso di parlare di “aggiornamento” per parlare di qualcosa di più sfumato. Nel frattempo, però, è successa una cosa che quasi nessuno collega ai page experience signals: l’esperienza sulla pagina è diventata un obbligo di legge. Questa guida ti spiega dove siamo davvero, cosa conta ancora, cosa puoi smettere di rincorrere e quali sono le tre cose che ti costano soldi veri se le sbagli.

Che cosa sono i page experience signals, spiegati senza slogan

La definizione ufficiale è semplice: i page experience signals misurano il modo in cui gli utenti percepiscono l’interazione con una pagina web, al di là della pura rilevanza del contenuto. Tradotto in italiano comprensibile: due pagine che rispondono ugualmente bene alla stessa domanda non sono equivalenti se una si carica in un secondo e l’altra ti fa aspettare sei secondi mentre un popup ti copre il testo.

Fin qui è banale. La parte che nel 2020 è stata comunicata male, e che ancora oggi genera confusione nelle riunioni con i clienti, è la natura del segnale. Non esiste un punteggio “page experience”. Non è mai esistito. Google lo dice in modo esplicito nella documentazione ufficiale, che al momento in cui scrivo è stata aggiornata a dicembre 2025: alla domanda se esista un singolo indicatore di esperienza sulla pagina, la risposta è “no, non esiste un singolo indicatore; i nostri sistemi principali di ranking esaminano una varietà di indicatori”. Puoi verificarlo direttamente sulla documentazione di Google sull’esperienza sulle pagine.

Questa frase, apparentemente burocratica, ha una conseguenza pratica enorme. Significa che non puoi “ottimizzare per la page experience” come ottimizzi un title tag. Non c’è una soglia da superare, non c’è un semaforo che diventa verde e ti sblocca la prima posizione. C’è invece un insieme di aspetti che, se sono gravemente compromessi, ti penalizzano; e che, se sono in ordine, semplicemente ti tolgono un ostacolo dai piedi.

Nella mia esperienza, la differenza tra chi capisce questo punto e chi non lo capisce è misurabile in mesi di lavoro sprecato. Ho visto aziende investire budget significativi per portare il punteggio di PageSpeed Insights da 72 a 94 e non guadagnare una singola posizione, perché il problema del loro sito non era la velocità: era che rispondevano alla domanda sbagliata. E ho visto siti tecnicamente mediocri dominare una nicchia per anni, perché il contenuto era insostituibile. L’esperienza sulla pagina è un moltiplicatore, non un sostituto.

Quali sono i page experience signals oggi

Google elenca oggi una serie di domande di autovalutazione, non una checklist di fattori con relativo peso. È una differenza di impostazione che vale la pena prendere sul serio. Le aree che la documentazione invita a verificare sono queste:

• Core Web Vitals: le pagine registrano valori validi per LCP, INP e CLS?
• Sicurezza del protocollo: le pagine sono pubblicate in HTTPS?
• Visualizzazione su mobile: i contenuti si vedono correttamente sugli smartphone?
• Pubblicità non invadente: gli annunci evitano di distrarre o interferire con il contenuto principale?
• Assenza di interstitial invasivi: le pagine evitano sovrapposizioni che bloccano la lettura?
• Chiarezza del contenuto: il visitatore distingue il contenuto principale dagli elementi accessori?

Nota bene le ultime due voci. “Il visitatore distingue il contenuto principale dagli elementi accessori” non è una metrica, è un giudizio. Non esiste un tool che te la misuri. È esattamente il tipo di valutazione che un quality rater umano può fare e che i sistemi automatici approssimano con proxy indiretti. Chi ti vende un audit che promette di “risolvere la page experience” con un report generato in automatico ti sta vendendo metà del problema.

Cosa è cambiato dal 2020 a oggi, e che quasi nessuno ha aggiornato

Qui sta il motivo per cui vale la pena riscrivere questo articolo invece di limarlo. Se cerchi “page experience signals” in italiano, buona parte di ciò che trovi in prima pagina è stato scritto tra il 2021 e il 2023 e non è più accurato. Ecco l’elenco delle cose che sono cambiate.

FID non esiste più. Il First Input Delay, la metrica che misurava il ritardo del primo input, è stato sostituito da INP (Interaction to Next Paint) il 12 marzo 2024. Non è stato un affiancamento: FID è stato deprecato e rimosso dai Core Web Vitals. Se il tuo consulente ti parla ancora di FID nel 2026, sta leggendo appunti vecchi. La transizione è documentata nell’annuncio ufficiale su web.dev sul passaggio a INP, dove si legge che “INP will officially become a Core Web Vital and replace FID on March 12”.

Il badge non è mai arrivato. Nel 2020 Google aveva anticipato l’idea di evidenziare nei risultati di ricerca le pagine con un’ottima esperienza, con un indicatore visivo. Quell’indicatore non è mai stato lanciato. Se hai ancora in un documento di strategia la voce “ottenere il badge page experience”, puoi cancellarla.

AMP ha perso il suo privilegio, e poi la sua ragione d’essere. La grande notizia del 2020 fu che le pagine non-AMP avrebbero potuto entrare nelle Top Stories mobile. Oggi il discorso è superato in radice: AMP non è più un requisito per nulla e mantenerlo su un sito nuovo è quasi sempre un costo di manutenzione senza contropartita. Molti dei siti che ho analizzato negli ultimi due anni portavano ancora impianti AMP dismessi, con URL duplicati e canonical incoerenti che generavano più danni della lentezza che avrebbero dovuto curare.

Il report è stato smontato pezzo per pezzo. Il vecchio report “Esperienza sulla pagina” di Search Console è stato prima semplificato, poi ridotto a un pannello di rimando. Anche il test di ottimizzazione mobile come strumento a sé è stato ritirato. Non è una brutta notizia: significa che Google ti sta dicendo di guardare i dati grezzi invece del cruscotto riassuntivo.

D’altra parte, una cosa non è cambiata affatto: continuano a esserci siti italiani che caricano quattro font, sei script di tracciamento e un carosello da 2 MB nella prima schermata. Se ti interessa il quadro completo di come si sono mossi gli algoritmi in questi anni, ho raccolto la cronologia degli aggiornamenti Google e del loro impatto sui siti.

I Core Web Vitals nel 2026: le tre metriche che contano

I Core Web Vitals restano il cuore misurabile dei page experience signals, e sono l’unica parte del pacchetto che Google conferma essere utilizzata dai sistemi di ranking. Le tre metriche attuali, con le soglie ufficiali riportate nella documentazione Google sui Core Web Vitals, sono queste.

LCP: quanto ci mette a comparire la cosa importante

Largest Contentful Paint misura il tempo necessario perché il blocco di contenuto più grande della prima schermata diventi visibile. La soglia di riferimento è 2,5 secondi. Non misura quando la pagina “ha finito di caricare”, che è un concetto sempre più privo di senso su siti moderni, ma quando l’utente vede qualcosa di sostanziale.

Nella pratica il colpevole è quasi sempre uno di questi quattro: un’immagine hero non compressa e non dimensionata, un font caricato in modo bloccante, un server che risponde lento, un tema che carica l’intero foglio di stile prima di disegnare qualsiasi cosa. Il quarto caso è il più frequente sui siti WordPress costruiti con page builder generalisti, e il più fastidioso da risolvere perché non basta un plugin.

Sul server c’è poco da girarci intorno. Se il tempo di risposta è alto, ogni ottimizzazione a valle è una toppa. Ho scritto una guida separata su come scegliere un hosting performante, perché è la voce di spesa su cui gli imprenditori risparmiano di più e sbagliano di più.

INP: quanto è reattivo il sito quando lo tocchi

Interaction to Next Paint è la metrica che ha sostituito FID, e non è un aggiornamento cosmetico. FID misurava soltanto il ritardo del primo input, cioè un istante isolato e generalmente favorevole. INP osserva tutte le interazioni della sessione e restituisce il comportamento peggiore tra quelli rilevanti: clic, tocchi, digitazioni. La soglia è 200 millisecondi.

Il cambio ha fatto emergere una verità scomoda per molti siti che si consideravano a posto. Un sito può avere un FID eccellente e un INP disastroso, perché il problema non era l’avvio ma il JavaScript che si attiva quando l’utente comincia davvero a usare la pagina: filtri di catalogo, menu a tendina, carrelli, form con validazione in tempo reale. Nei mesi successivi a marzo 2024 ho visto e-commerce italiani perdere posizioni senza aver toccato una riga di contenuto, semplicemente perché la metrica ha smesso di essere indulgente.

Cosa lo peggiora, in ordine di frequenza: script di terze parti caricati in modo sincrono, tag manager con decine di tag mai ripuliti, widget di chat, script di heatmap, plugin che si attivano su ogni evento. È interessante notare che quasi tutti questi elementi sono stati installati da qualcuno con una buona intenzione e non sono mai stati rimossi da nessuno.

CLS: quanto la pagina ti si muove sotto il dito

Cumulative Layout Shift misura la stabilità visiva: quanto gli elementi si spostano mentre la pagina si compone. La soglia è 0,1. È la metrica più facile da capire e la più facile da sistemare, perché le cause sono poche e ben note: immagini senza dimensioni dichiarate, banner pubblicitari inseriti dinamicamente, font che sostituiscono il fallback cambiando ingombro, avvisi che compaiono in cima spingendo tutto in basso.

Il caso più irritante lo conosci per esperienza personale: stai per toccare un link, compare il banner cookie, il layout si sposta e tocchi un’altra cosa. Su questo torneremo, perché è il punto in cui due normative e un algoritmo si scontrano.

Dati di campo e dati di laboratorio: perché il tuo 98 su PageSpeed non conta

Questa è la fonte di equivoco numero uno nelle conversazioni con i clienti, e merita di essere detta con chiarezza. Esistono due tipi di dati sulle prestazioni, e solo uno dei due ha a che fare con il ranking.

I dati di laboratorio sono quelli che ottieni quando lanci un test: Lighthouse, la sezione simulata di PageSpeed Insights, i tool di analisi in genere. Il test viene eseguito in un ambiente controllato, con una connessione simulata e un dispositivo simulato. Ti serve per capire cosa sistemare, perché ti dice quale risorsa blocca cosa. Non è quello che Google usa per valutarti.

I dati di campo sono quelli raccolti dagli utenti reali che visitano il tuo sito con i loro dispositivi, le loro connessioni e i loro browser. Sono aggregati nel Chrome UX Report e sono la base della valutazione. Hanno tre caratteristiche che devi conoscere: si riferiscono a una finestra mobile di 28 giorni, quindi un miglioramento fatto oggi si vede tra settimane; sono disponibili solo se il tuo sito ha traffico sufficiente, altrimenti la valutazione ricade su dati aggregati di origine; e rappresentano il 75° percentile, cioè descrivono l’esperienza dei tre quarti migliori delle visite, non la media.

Questo spiega perché il punteggio 98 su verde brillante convive tranquillamente con Core Web Vitals “da migliorare” in Search Console. Non è un errore di Google. È che stai guardando due cose diverse. Il numero che ti fa sentire bene è quello di laboratorio; quello che pesa è quello sul campo, ed è sempre più severo perché i tuoi utenti reali hanno telefoni più lenti della macchina su cui giri i test.

La conseguenza operativa: usa i dati di laboratorio per la diagnosi e i dati di campo per il verdetto. E soprattutto, misura prima di intervenire. Se ti interessa il metodo completo con cui affronto l’ottimizzazione di una singola pagina, l’ho descritto passo passo nell’autopsia di una pagina ottimizzata, e ho approfondito le tre metriche in un pezzo dedicato ai core web vitals e a quanto pesano sulla SEO.

HTTPS: il segnale più frainteso di tutti

HTTPS è nell’elenco dei page experience signals dal primo giorno, ed è anche il segnale che genera il maggior numero di false sicurezze. La frase che sento più spesso è: “il sito ha il lucchetto, siamo a posto”. No.

Lo dico con il cappello di chi ha una certificazione CPEH (Certified Professional Ethical Hacker) e passa una parte del proprio tempo a guardare siti compromessi, non a guardarli su PageSpeed. Il certificato TLS garantisce che il traffico tra il browser e il server sia cifrato. Non garantisce nient’altro. In particolare non garantisce che il server sia aggiornato, che i plugin non abbiano vulnerabilità note, che i form validino l’input, che i backup esistano.

Ci sono poi tre situazioni tecniche che rendono il lucchetto una bugia parziale, e le trovo con una regolarità che mi sorprende ancora:

• Mixed content: la pagina è servita in HTTPS ma carica risorse in HTTP. Il browser blocca o segnala, l’esperienza degrada, e in alcuni casi il layout salta (danneggiando anche il CLS).
• Certificati che scadono senza che nessuno se ne accorga. Un certificato scaduto produce un avviso a schermo pieno che azzera il traffico organico per la durata del disservizio. Ho visto aziende perdere giorni interi di visite per una notifica finita nella casella di un dipendente che non lavorava più lì.
• Redirect incompleti: la versione HTTP e quella HTTPS restano entrambe raggiungibili, con contenuto duplicato e segnali diluiti.

Il punto dell’angolo è questo: la sicurezza è entrata nei page experience signals con una soglia minima, e quella soglia minima è stata scambiata per un traguardo. Nella realtà i due mondi si toccano in un punto molto più concreto: gli script di terze parti che ti rovinano l’INP sono esattamente la stessa superficie di attacco che ti espone a compromissioni. Ridurre gli script è contemporaneamente un intervento di performance e un intervento di sicurezza. Non capita spesso che una cosa sola risolva due problemi, quindi vale la pena approfittarne.

Usabilità mobile: cosa resta dopo la fine del test dedicato

L’indicizzazione mobile-first è completata da tempo: Google guarda la versione mobile del tuo sito, punto. Il vecchio strumento di test “ottimizzazione mobile” è stato ritirato, e questo ha lasciato molti senza il loro semaforo di riferimento. La domanda giusta però non è mai stata “supero il test”, ma “una persona riesce a fare quello per cui è venuta, con una mano sola, su uno schermo da sei pollici, in metropolitana”.

Le cose che rompono l’esperienza mobile nel 2026 sono queste, in ordine di gravità osservata:

1. Testo che richiede lo zoom, o corpo sotto i 16 pixel su elementi di lettura primaria.
2. Elementi cliccabili troppo vicini tra loro: menu, filtri, bottoni di consenso.
3. Contenuto che eccede la larghezza del viewport, con scorrimento orizzontale involontario.
4. Form che aprono la tastiera sbagliata, o che perdono i dati inseriti al primo errore di validazione.
5. Video e iframe che non si adattano e sfondano il layout.

Nessuna di queste è una questione di algoritmo. Sono tutte questioni di rispetto per chi ti sta leggendo. E si riflettono, indirettamente, su tutte le metriche: chi non riesce a usare la pagina torna indietro, e chi torna indietro non converte. Se stai valutando un rifacimento, ho raccolto quello che ho imparato in trent’anni di progetti nella guida al restyling di un sito web senza perdere quello che funziona.

Interstitial invasivi e banner cookie: la contraddizione che nessuno vi racconta

Arriviamo al punto che, nelle prime dieci posizioni italiane su questa keyword, non tratta nessuno. Google ti chiede di evitare gli interstitial invasivi. Il Garante per la protezione dei dati personali ti impone di mostrare un banner al primo accesso. Sono la stessa cosa vista da due autorità diverse, e devi soddisfarle entrambe.

Vediamo cosa dice ciascuna delle due parti. Per Google un interstitial è problematico quando copre il contenuto principale subito dopo l’arrivo dall’organico, quando è impossibile o difficile da chiudere, quando occupa una porzione dominante dello schermo. Sono ammessi i banner richiesti dalla legge (verifica dell’età, informative), purché usino uno spazio ragionevole.

Per il Garante, invece, le regole sono molto più stringenti di quanto la maggior parte dei siti italiani applichi. Nelle linee guida su cookie e altri strumenti di tracciamento del 10 giugno 2021 si stabilisce che il banner deve avere dimensioni tali da creare “una percettibile discontinuità” nella fruizione, che lo scroll da solo non è idoneo a raccogliere un consenso valido, che i cookie wall di tipo “prendere o lasciare” sono illeciti perché violano il requisito di libertà del consenso ai sensi dell’art. 4, n. 11 del GDPR, e che deve esserci una X per chiudere il banner mantenendo le impostazioni predefinite, con un’azione “immediata, usabile e accessibile” quanto quella per acconsentire. In più: pulsanti con pari evidenza grafica, opzioni granulari preimpostate sul diniego, e nessuna riproposizione entro sei mesi in assenza di cambiamenti sostanziali.

Ora metti insieme le due esigenze e guarda cosa succede a un sito medio. Il banner deve essere percettibile ma non dominante. Deve avere una X ben visibile, che è esattamente l’elemento che le implementazioni aggressive nascondono per aumentare il tasso di accettazione. Deve comparire senza spostare il layout, altrimenti fa esplodere il CLS. E deve caricarsi in fretta, altrimenti la piattaforma di consenso, che è quasi sempre uno script di terze parti, ti degrada l’INP proprio nel momento in cui l’utente sta per interagire.

Nella mia pratica di consulenza questo è uno dei punti in cui vedo più danni fatti in buona fede. La sequenza tipica è: l’azienda installa una piattaforma di consenso perché il legale l’ha chiesto; la piattaforma viene configurata sui valori predefiniti, che sono pensati per massimizzare il consenso e non per rispettare le linee guida italiane; nessuno collega quella scelta ai numeri di prestazione; sei mesi dopo il sito ha un CLS peggiorato, un INP peggiorato e una configurazione di consenso che, in caso di controllo, è indifendibile. Tre problemi, una sola causa, e nessuno dei tre reparti che l’hanno generata parla con gli altri.

Come membro Federprivacy dico la parte scomoda: il banner cookie fatto bene converte meno di quello fatto male. È così, e chi ti dice il contrario ti sta vendendo una configurazione a rischio. La differenza è che quello fatto bene non ti espone a un procedimento e non ti fa perdere posizioni. Se vuoi il quadro completo degli adempimenti, l’ho trattato nella guida alla cookie policy per essere a norma.

L’obbligo che ha superato il segnale: l’accessibilità dal 28 giugno 2025

Ed eccoci alla parte che cambia davvero l’inquadramento dell’intero tema, e che nel 2020 non esisteva.

Mentre Google ridimensionava il peso dei page experience signals e li declassava da “aggiornamento dell’algoritmo” a “domande di autovalutazione”, il legislatore europeo faceva il percorso opposto. Con la Direttiva 2019/882, il cosiddetto European Accessibility Act, recepita in Italia dal D.Lgs. n. 82/2022, l’accessibilità dei servizi digitali è diventata un obbligo giuridico. La data di applicazione è il 28 giugno 2025.

Come si legge nella comunicazione di AgID sulle linee guida sull’accessibilità dei servizi, “a partire dal 28 giugno 2025 tutti gli operatori economici che immetteranno sul mercato o forniranno i prodotti e i servizi previsti dal decreto dovranno garantire che questi siano progettati e realizzati in modo da essere accessibili alle persone con disabilità”. Tra i servizi coperti ci sono il commercio elettronico, i servizi bancari, gli e-book, i documenti elettronici, i siti web e le applicazioni mobili.

Fermati un secondo su cosa significa. Se hai un e-commerce, la leggibilità del testo, il contrasto dei colori, la navigabilità da tastiera, la corretta etichettatura dei form e la comprensibilità dei messaggi di errore non sono più consigli di usabilità che puoi rimandare al prossimo restyling. Sono requisiti. E il livello di conformità si valuta rispetto alla norma tecnica UNI CEI EN 301549, che a sua volta rimanda alle WCAG.

Qui sta l’angolo di tutto questo articolo, ed è il motivo per cui vale la pena rileggere i page experience signals nel 2026 invece di archiviarli come una notizia del 2020. Google ha reso l’esperienza sulla pagina una faccenda sfumata, senza punteggio, senza badge, senza soglia netta. L’Unione Europea l’ha resa una faccenda binaria: conforme o non conforme. Il segnale di ranking ti fa perdere qualche posizione. L’obbligo di legge ti espone a contestazioni, e potenzialmente a un contenzioso.

Aggiungo un elemento che deriva dal mio ruolo di Consulente Tecnico d’Ufficio presso il Tribunale di Lodi: quando una controversia su un progetto digitale finisce davanti a un giudice, il perito non guarda il punteggio di PageSpeed. Guarda se il fornitore ha consegnato un prodotto conforme a quello che la legge richiedeva al momento della consegna. È una prospettiva che raramente entra negli articoli di SEO, e che negli ultimi due anni ha cominciato a comparire nei contratti di sviluppo che mi capita di esaminare. Chi commissiona un sito nel 2026 e non mette per iscritto i requisiti di accessibilità sta costruendo un problema che si manifesterà quando sarà costoso risolverlo.

La buona notizia, ed è una notizia vera, è che il lavoro si sovrappone. Un sito accessibile ha contrasto adeguato, gerarchie di heading coerenti, testi alternativi sulle immagini, elementi cliccabili di dimensione sufficiente, form etichettati e navigabili. Sono le stesse cose che rendono una pagina comprensibile agli utenti mobili, ai sistemi automatici che leggono i contenuti e, in ultima analisi, ai motori di ricerca. Non ti sto proponendo due progetti: ti sto dicendo che ne stavi già facendo uno a metà.

Come si misura tutto questo senza perdere tempo

Gli strumenti sono pochi e sono gratuiti. Il problema non è la disponibilità, è l’ordine in cui li usi. Ecco la sequenza che seguo io.

Primo: Search Console, rapporto Core Web Vitals. Ti dice quali gruppi di URL hanno problemi sui dati di campo, distinti tra mobile e desktop. Parti sempre da qui, perché è l’unica fonte che riflette la valutazione reale. Guarda i gruppi, non le singole pagine: Google raggruppa URL con comportamento simile, e risolvere il gruppo risolve decine di pagine insieme.

Secondo: PageSpeed Insights sull’URL rappresentativo del gruppo. Nella parte alta trovi i dati di campo, se disponibili; nella parte bassa quelli di laboratorio con la diagnostica. Ignora il numerone e leggi le opportunità, in particolare quelle relative al blocco del rendering e al tempo di esecuzione JavaScript.

Terzo: la scheda Prestazioni del browser, con throttling attivo. È il passaggio che quasi nessuno fa e che risolve la maggior parte dei casi difficili di INP. Registri un’interazione reale, guardi quale task lunga blocca il thread principale, e generalmente scopri che è uno script che nessuno ricorda di aver installato.

Quarto: una verifica di accessibilità. Un controllo automatico intercetta forse un terzo dei problemi reali. Il resto lo trovi provando a navigare la pagina solo con la tastiera, cosa che richiede cinque minuti e produce più risultati di qualunque report.

Quinto: il test manuale sul telefono più lento che hai in ufficio. Non quello nuovo. Quello che stavi per buttare. È il dispositivo del tuo cliente medio.

Il piano operativo, in ordine di priorità

Se dovessi mettere in fila gli interventi per una PMI con risorse limitate, l’ordine sarebbe questo. Non è l’ordine che troverai in un audit automatico, è quello che tiene conto del rapporto tra fatica e risultato.

1. Elimina gli script che non servono. Apri il tag manager e chiedi a ogni tag di giustificare la propria esistenza. Nella mia esperienza, tra il 30% e il 50% dei tag installati su un sito con qualche anno di vita non serve più a nessuno. È l’intervento con il miglior rapporto tra tempo e beneficio su INP, e riduce anche la superficie di rischio.
2. Sistema il banner di consenso. Verifica la X, la pari evidenza dei pulsanti, il diniego preimpostato, e assicurati che il banner non sposti il layout. Risolvi contemporaneamente un problema di CLS e uno di conformità.
3. Dichiara le dimensioni di tutto ciò che occupa spazio. Immagini, iframe, contenitori pubblicitari. Il CLS si risolve quasi sempre così.
4. Lavora sull’elemento LCP. Individua qual è, comprimilo, servilo in formato moderno, caricalo con priorità alta, e smetti di caricare font bloccanti prima di lui.
5. Verifica la coerenza HTTPS. Mixed content, redirect, scadenze monitorate. È lavoro di manutenzione, non di ottimizzazione, e per questo viene sempre rimandato.
6. Affronta l’accessibilità come progetto, non come patch. Contrasto, gerarchia degli heading, navigazione da tastiera, form etichettati, messaggi di errore comprensibili.

Vale la pena notare cosa non c’è in questa lista: non c’è “raggiungere 90 su PageSpeed”. Non è un obiettivo, è un effetto collaterale. Se ti interessa un elenco più ampio di cosa costa davvero traffico e cosa invece puoi tranquillamente ignorare, l’ho messo insieme nell’articolo sugli errori SEO che contano davvero.

Tre errori che vedo ancora nel 2026

Chiudo la parte operativa con tre situazioni che continuano a ripresentarsi, raccontate in forma anonima perché i clienti hanno diritto alla riservatezza, ma che sono reali.

Il primo caso. Un e-commerce di articoli tecnici, buon posizionamento storico, perdita costante di visibilità a partire dalla primavera del 2024 senza alcun cambiamento sui contenuti. La diagnosi ha richiesto mezza giornata: il passaggio da FID a INP aveva scoperchiato un filtro di catalogo che rieseguiva l’intera logica di ordinamento a ogni clic. Con FID quel comportamento era invisibile, perché la prima interazione avveniva prima che il filtro fosse in gioco. Con INP era il valore peggiore della sessione, su ogni pagina di categoria. La correzione ha richiesto due giorni di sviluppo. I mesi persi prima di capirlo sono stati sei.

Il secondo caso. Un sito di servizi professionali con un punteggio Lighthouse eccellente su desktop e Core Web Vitals in rosso in Search Console. Il titolare era convinto che Google sbagliasse. Il sito aveva un pubblico in larga parte mobile, con una quota significativa di connessioni non ottimali, e il 75° percentile raccontava una storia completamente diversa dal test di laboratorio eseguito da un ufficio in fibra. Non c’era nulla da correggere nella misurazione: c’era da smettere di misurare la cosa sbagliata.

Il terzo caso, il più costoso. Un’azienda che aveva commissionato un e-commerce nuovo nel 2024, consegnato nel 2025, senza alcun requisito di accessibilità nel capitolato. Nessuna delle due parti aveva sollevato il tema. Quando il tema è emerso, la discussione su chi dovesse pagare l’adeguamento è durata più a lungo dell’adeguamento stesso. È il tipo di controversia che sto vedendo comparire sempre più spesso, e che si previene con una riga di contratto scritta al momento giusto.

Il filo comune tra i tre casi è sempre lo stesso: nessuno stava guardando il dato giusto al momento giusto. Non è un problema di competenza tecnica, è un problema di attenzione. Ed è anche il motivo per cui ho scritto “Siti da Incubo”, che raccoglie i disastri più istruttivi che ho incontrato in trent’anni e che puoi scaricare gratuitamente.

Risorse e letture di approfondimento

Se stai affrontando il tema per la prima volta, ti consiglio di procedere in quest’ordine. Prima la documentazione ufficiale di Google, che è la sola fonte non interpretata: la pagina sull’esperienza sulle pagine e quella sui Core Web Vitals, entrambe disponibili in italiano e aggiornate. Poi il rapporto Core Web Vitals in Search Console, per capire dove sei. Poi, se il sito è un e-commerce o eroga un servizio al consumatore, le indicazioni AgID sull’accessibilità dei servizi, perché quello è il perimetro dell’obbligo.

Sul fronte interno, se stai partendo da zero o stai valutando la ricostruzione, ho raccolto costi, obblighi e scelte tecniche nella guida su come creare un sito web nel 2026, e ho trattato a parte il rapporto tra velocità del sito e posizionamento, che è il pezzo di questo discorso su cui circolano più leggende.

WordPress, temi e page builder: dove si perde davvero la performance

Una parte consistente dei siti aziendali italiani gira su WordPress, quindi vale la pena essere specifici invece di restare sul generico. Nella maggior parte dei casi che ho analizzato, il problema di prestazioni non è WordPress: è la stratificazione di scelte fatte da persone diverse in momenti diversi, senza che nessuno abbia mai fatto il bilancio complessivo.

Il primo punto è il tema. Un tema commerciale “multiuso” carica per definizione il codice di tutte le varianti che offre, anche di quelle che non userai mai, perché deve funzionare per chiunque lo compri. Il risultato è un foglio di stile enorme e un pacchetto JavaScript che si attiva su ogni pagina. Non è una critica ideologica: è che stai pagando in millisecondi una flessibilità che hai usato una volta sola, il giorno dell’installazione.

Il secondo punto è il page builder. Gli editor visuali costruiscono il layout annidando contenitori, e ogni livello di annidamento è markup in più da elaborare. Su una pagina semplice non si nota. Su una pagina di categoria con trenta prodotti, un carosello e tre sezioni animate, la differenza fra un markup pulito e uno costruito a strati è visibile a occhio nudo su un telefono di fascia media. In più, molti builder caricano le proprie animazioni tramite librerie che entrano in gioco esattamente quando l’utente comincia a scorrere, cioè nel momento peggiore per l’INP.

Il terzo punto sono i plugin, e qui la questione si intreccia con la sicurezza. Ogni plugin attivo è codice di terze parti che gira sul tuo server con i tuoi permessi. Dal punto di vista delle prestazioni aggiunge query al database e risorse da caricare; dal punto di vista del rischio è una porta in più da tenere chiusa. Da certificato CPEH ti dico che la stragrande maggioranza delle compromissioni WordPress che ho esaminato non sfruttava una vulnerabilità sofisticata: sfruttava un plugin abbandonato dallo sviluppatore e mai aggiornato dal proprietario del sito. Il conteggio dei plugin installati è, con buona approssimazione, anche un indice di rischio.

Il quarto punto è la cache, e qui la buona notizia è che un plugin di caching serio risolve una fetta consistente dei problemi di LCP con poco sforzo. Attenzione però a due effetti collaterali che vedo spesso: la minificazione aggressiva dei file può rompere funzionalità in modo silenzioso, e le ottimizzazioni che rimandano il caricamento delle immagini, se applicate anche all’elemento principale della prima schermata, peggiorano l’LCP invece di migliorarlo. La regola pratica è semplice: l’immagine più grande sopra la piega non va mai caricata in modo differito.

Ultimo punto, quello che nessuno vuole sentirsi dire: se il sito ha sei anni, quattro restyling parziali e tre agenzie che si sono passate le consegne, la strada più economica non è ottimizzare. È ricostruire il livello di presentazione partendo da requisiti chiari, portandosi dietro i contenuti e gli URL. Ho visto progetti di ottimizzazione durare più a lungo e costare più di una ricostruzione, semplicemente perché nessuno voleva ammettere che la base non reggeva.

Page experience e risposte generate dall’AI: cosa cambia nel 2026

C’è un aspetto che nel 2020 non poteva esistere e che oggi vale la pena aggiungere al ragionamento, con la cautela che merita una materia in movimento.

Una quota crescente di ricerche non produce più soltanto un elenco di link, ma una risposta sintetizzata da un sistema automatico che cita alcune fonti. Questo cambia il modo in cui la tua pagina viene consumata. Il sistema che legge il tuo contenuto non aspetta il rendering, non vede il tuo carosello e non è infastidito dal tuo banner. In apparenza, quindi, i page experience signals dovrebbero contare meno.

La realtà che osservo è più sottile, e va in due direzioni opposte. Da un lato è vero: la parte di esperienza che riguarda la percezione visiva conta poco per una macchina. Dall’altro, le stesse caratteristiche che rendono una pagina accessibile e ben strutturata la rendono anche più facilmente estraibile: gerarchie di heading coerenti, contenuto principale distinguibile dagli elementi accessori, testo che esiste nell’HTML e non solo dopo l’esecuzione di uno script, risposte compatte a domande esplicite. Sono le stesse cose dell’elenco di autovalutazione di Google, arrivate da un’altra porta.

C’è poi un elemento che pesa più di quanto si dica. Quando l’utente clicca su una citazione dentro una risposta generata, arriva sulla tua pagina con un’aspettativa già formata e con pochissima pazienza residua: ha già ottenuto una risposta, sta verificando. Se in quel momento trova un banner che copre il testo e una pagina che impiega quattro secondi a mostrare qualcosa, non aspetta. Il traffico che arriva dai sistemi generativi è, per sua natura, il meno tollerante che tu abbia mai avuto.

Detto questo, evito di trasformarlo in una previsione. Non so quanto peserà questo canale fra due anni e chi te lo dice con precisione sta indovinando. So che le azioni utili sono le stesse in entrambi gli scenari, il che è la condizione ideale per decidere: quando due futuri diversi richiedono lo stesso investimento, l’investimento si fa.

Riepilogo dei punti chiave

I page experience signals sono l’insieme di aspetti con cui Google valuta la qualità dell’interazione fra utente e pagina: Core Web Vitals, HTTPS, corretta visualizzazione su mobile, assenza di interstitial invasivi e chiarezza del contenuto principale. Non esistono come punteggio unico, e Google lo conferma nella documentazione aggiornata a dicembre 2025. Dal 2020 a oggi sono cambiate tre cose sostanziali: FID è stato sostituito da INP il 12 marzo 2024, il badge nei risultati di ricerca non è mai stato lanciato, AMP ha perso ogni privilegio. Le soglie attuali sono LCP sotto 2,5 secondi, INP sotto 200 millisecondi, CLS sotto 0,1, valutate sui dati di campo del Chrome UX Report e non sul punteggio di laboratorio di PageSpeed Insights. Il punto meno discusso e più rilevante nel 2026 è però normativo: il banner cookie imposto dalle linee guida del Garante è esattamente l’elemento che degrada CLS e INP, e dal 28 giugno 2025 l’accessibilità dei servizi digitali è un obbligo di legge in forza del D.Lgs. 82/2022. L’esperienza sulla pagina è passata da consiglio di ranking a requisito giuridico, e conviene affrontarla in quest’ordine di priorità: ridurre gli script inutili, sistemare il banner di consenso, dichiarare le dimensioni degli elementi, ottimizzare l’elemento LCP, verificare la coerenza HTTPS, pianificare l’accessibilità come progetto.

Domande frequenti sui page experience signals

I page experience signals sono un fattore di ranking?

In parte. Google conferma che le metriche dei Core Web Vitals vengono utilizzate dai sistemi di ranking, ma precisa che non esiste un singolo indicatore di esperienza sulla pagina e che avere buoni valori non garantisce di per sé un buon posizionamento. Gli altri aspetti, come HTTPS, visualizzazione mobile e assenza di interstitial invasivi, sono indicati come elementi di qualità da presidiare, senza che sia dichiarato un peso specifico. In pratica: un’esperienza pessima ti danneggia, un’esperienza eccellente non compensa un contenuto che non risponde alla domanda dell’utente.

Esiste un punteggio page experience?

No, e non è mai esistito. La documentazione ufficiale di Google, aggiornata a dicembre 2025, risponde esplicitamente che non esiste un singolo indicatore e che i sistemi di ranking esaminano una varietà di segnali. Il punteggio da 0 a 100 che vedi in PageSpeed Insights è un punteggio di prestazione calcolato in laboratorio da Lighthouse, non un punteggio di page experience e non un valore usato per il ranking.

Quali sono i Core Web Vitals nel 2026?

Sono tre: LCP (Largest Contentful Paint), che misura le prestazioni di caricamento e ha come riferimento un valore inferiore a 2,5 secondi; INP (Interaction to Next Paint), che misura la reattività e ha come riferimento un valore inferiore a 200 millisecondi; CLS (Cumulative Layout Shift), che misura la stabilità visiva e ha come riferimento un valore inferiore a 0,1. Le soglie si valutano al 75° percentile dei dati raccolti da utenti reali.

FID esiste ancora?

No. Il First Input Delay è stato sostituito da INP il 12 marzo 2024 ed è stato ufficialmente deprecato. La differenza è sostanziale: FID misurava soltanto il ritardo della prima interazione, mentre INP osserva tutte le interazioni della sessione e riporta il comportamento peggiore fra quelle rilevanti. Molti siti che avevano un FID eccellente hanno scoperto di avere un INP problematico, perché il rallentamento non era all’avvio ma durante l’uso reale della pagina.

Perché il punteggio di PageSpeed è alto ma Search Console segnala problemi?

Perché stai guardando due dati diversi. Il punteggio di PageSpeed Insights deriva da una simulazione di laboratorio eseguita su un dispositivo e una connessione standardizzati. Search Console riporta invece i dati di campo raccolti dagli utenti reali del tuo sito, aggregati su una finestra mobile di 28 giorni e valutati al 75° percentile. Se il tuo pubblico è prevalentemente mobile e usa dispositivi meno performanti della macchina su cui giri il test, il verdetto sul campo è più severo. Per il ranking contano i dati di campo.

Il banner cookie è considerato un interstitial invasivo da Google?

Non di per sé: Google considera accettabili i banner richiesti dalla legge, purché occupino una porzione ragionevole dello schermo e siano facili da chiudere. Diventa un problema quando copre il contenuto in modo dominante, quando la chiusura è nascosta o difficoltosa, o quando la sua comparsa sposta il layout e degrada il CLS. Le linee guida del Garante del 10 giugno 2021 impongono comunque una X di chiusura immediata e accessibile, pari evidenza grafica fra le opzioni e divieto di cookie wall: rispettarle, in buona parte, coincide con il rendere il banner meno invasivo anche agli occhi di Google.

L’accessibilità del sito è obbligatoria per un’azienda privata in Italia?

Per una parte rilevante delle attività sì. Il D.Lgs. n. 82/2022, che recepisce la Direttiva 2019/882 nota come European Accessibility Act, prevede che dal 28 giugno 2025 gli operatori economici che immettono sul mercato o forniscono i prodotti e i servizi indicati dal decreto debbano garantirne l’accessibilità alle persone con disabilità. Fra i servizi coperti rientrano il commercio elettronico, i servizi bancari, gli e-book, i documenti elettronici, i siti web e le applicazioni mobili. La conformità si valuta rispetto alla norma tecnica UNI CEI EN 301549. Poiché il perimetro esatto e le esenzioni dipendono dal tipo di attività, conviene farsi valutare il caso specifico invece di dedurlo per analogia.

Quanto tempo serve per vedere i miglioramenti dei Core Web Vitals?

Sui dati di laboratorio il miglioramento è immediato: rilanci il test e lo vedi. Sui dati di campo, che sono quelli che contano, serve pazienza. La finestra di osservazione è di 28 giorni, quindi un intervento fatto oggi comincia a incidere sul valore aggregato dopo qualche settimana e si stabilizza in circa un mese e mezzo. È il motivo per cui ha poco senso rifare la misurazione il giorno dopo la correzione, e per cui conviene raggruppare gli interventi invece di distribuirli.

Da dove partire domani mattina

Se hai letto fin qui, il messaggio che vale la pena portarti a casa è uno solo. I page experience signals non sono più la notizia del 2020, e non sono nemmeno il punteggio verde che qualcuno prova ancora a venderti. Sono il punto in cui si incontrano tre pressioni diverse: quella dell’algoritmo, che è diventata sfumata; quella dell’utente, che non è mai cambiata; e quella normativa, che è l’unica delle tre a essere diventata più netta.

Il percorso più sensato per una PMI è banale nella forma e difficile nella disciplina: guarda i dati di campo in Search Console invece del punteggio di laboratorio, togli quello che non serve prima di aggiungere ottimizzazioni, sistema il banner di consenso perché risolve due problemi in un colpo solo, e metti l’accessibilità nel piano dei prossimi dodici mesi invece che nella lista dei desideri. Non ti serve un progetto da centinaia di ore. Ti serve smettere di guardare il numero sbagliato.

Ti dico anche cosa non posso prometterti, perché sarebbe disonesto: sistemare i page experience signals non ti porta in prima pagina. Toglie un ostacolo. Se il contenuto non risponde alla domanda dell’utente meglio di quello degli altri, nessuna ottimizzazione tecnica colma quella distanza. La tecnica serve a non perdere ciò che il contenuto si è guadagnato.

Se vuoi una valutazione concreta del tuo sito, con i numeri reali invece delle impressioni, Richiedi una consulenza gratuita: scrivimi e guardiamo insieme cosa dicono i dati di campo del tuo dominio.