Addio al report di Page Experience: Google ripulisce la Search Console

All’interno della Search Console offerta da Google per seguire come vanno i contenuti che pubblichi online sul tuo sito WordPress è stata di recente eliminata la Page Experience.

Non è una novità il fatto che Google decida di cambiare quello che c’è all’interno della Console. La motivazione è una volontà di eliminare elementi che sono stati ritenuti inutili, si legge per esempio nel post pubblicato sull’account ufficiale sulla piattaforma di LinkedIn.

E in effetti, guardando alla semplice quantità di dati, il report presentato con la Page Experience non era altro che un riassunto di dati raccolti e presentati anche in altre sezioni della Search Console. C’è comunque chi online fa notare che invece proprio il report così presentato e strutturato era estremamente comodo in molte situazioni, soprattutto per ottimizzare i processi di analisi.

Cerchiamo però di entrare più nel dettaglio per comprendere meglio che cosa è stato eliminato con la dismissione del servizio, se hanno ragione quelli che ritengono fosse invece più giusto lasciare il report e cosa fare ora.

Cosa abbiamo perso con la Page Experience nella Search Console?

Google, in qualità di società fornitrice di servizio online e di device, ha una lunga tradizione di progetti che sono stati rilasciati al pubblico e poi, dopo un numero vario di anni, sono stati eliminati. Alcuni esperimenti sono rimasti nella storia come grandi errori, altre volte invece i cambiamenti sono stati positivi.

Stavolta, andando per esempio a leggere l’annuncio sull’account Google Search Central su LinkedIn, viene chiarito che l’abbandono della Page Experience è stato il frutto di una riflessione per “ridurre l’ingrombro non necessario all’interno della Search Console e semplificare la navigazione per raggiungere queste informazioni“. A questo si aggiunge l’incoraggiamento, questo è il termine che viene utilizzato nel post, a concentrarsi “sul fornire una buona esperienza sulla pagina ai lettori e a monitorare lo stato dell’esperienza delle pagine dei siti web all’interno dei report CWV e dei report HTTPS”.

Questo perché i dati in realtà non sono stati eliminati. La Page Experience serviva nella pratica solo a raccogliere in un’unica schermata quello che è comunque raggiungibile e quantificabile andando a guardare ai Core Web Vitals e agli altri strumenti di valutazione forniti da Google.

Chi lamenta che questa scelta non è quella più giusta sottolinea che si trattava di una comodità il poter avere sotto mano tutte le informazioni. A questo si aggiungono quelli che dichiarano che invece rimuovendo la Page Experience c’è necessità ora di avere dei tool di terze parti per conoscere per esempio i tempi di caricamento realistici e l’esperienza degli utenti sulla pagina.

Da ultimo, ed è una prospettiva interessante da cui si può guardare l’annuncio, c’è un utente che domanda in che modo la rimozione della Page Experience e del report che produceva potrebbe influenzare il modo in cui i proprietari di siti web vedono le priorità tra esperienza dell’utente e performance tecniche.

Quello che doveva probabilmente essere solo un piccolo messaggio si è quindi trasformato in una serie di commenti e spunti di riflessione per tutti. La realtà dei fatti è che comunque ora il report all’inizio sezione non è più disponibile. Cerchiamo quindi di capire come navigare le sezioni dedicate ai Core Web Vitals e ai segnali HTTPS.

Page Experience non c’è, è andata via, quindi che si fa?

Come suggerisce il post su LinkedIn è importante comunque controllare che l’esperienza che gli utenti hanno sulla pagina sia positiva. Per farlo si possono guardare ai Core Web Vitals e ha i valori HTTPS. Cominciamo con i Core Web Vitals.

Tra le molte valutazioni che è possibile trovare nel report dei Core Web Vitals ci sono quelle che servono proprio per comprendere se l’esperienza degli utenti sulla pagina è positiva e se quindi si sta lavorando per offrire ai visitatori buoni contenuti in modo ottimizzato. Tra i Core Web Vitals c’è per esempio il valore LCP, Largest Contentful Paint, il valore INP ovvero Interaction to Next Paint, e il famigerato valore CLS ovvero il Cumulative Layout Shift.

Sono quindi elencati quelli che sono tutti gli strumenti attraverso cui poi valutare se un contenuto posizionato all’interno di una URL sta mostrando le performance che dovrebbe. All’interno dell’analisi dei Core Web Vitals sono indicati tre gradi di rendimento: buono, richiede miglioramenti e scadente. Per ciascuna delle tre metriche i valori soglia tra le diverse fasce sono ovviamente diversi.

Per esempio per il valore del Largest Contentful Paint si valuta in secondi mentre il valore Interaction to Next Paint si valuta in millisecondi. Il primo valuta il tempo con cui viene mostrato l’elemento di contenuto più grande nell’area visibile da parte dell’utente mentre il secondo valuta il tempo che la pagina impiega per rispondere a un click. È chiaro che entrambi questi valori devono mantenersi in soglie minime in modo tale che la pagina risulti piacevole da navigare.

Da ultimo il valore CLS, di cui abbiamo parlato approfonditamente, trasforma in valutazione il modo in cui il layout della pagina si modifica mentre i contenuti si stanno caricando. Una situazione che può generare un’esperienza utente poco piacevole.

Con spostamenti imprevisti degli elementi che si trovano all’interno di un layout, infatti, l’utente potrebbe sentirsi preso in giro oppure cliccare dove non vuole. Di conseguenza, la sua esperienza si trasforma in un abbandono rapido della pagina e in un segnale a Google che c’è qualcosa che non va.

Molto più tecnico è invece il report HTTPS che controlla tutti quelli che sono i possibili errori nelle URL. Anche questi segnali vengono registrati da Google e ti forniscono una panoramica di quello che va bene sul tuo sito e di quello che invece dovresti migliorare.

L’analisi approfondita per esempio degli errori presenti nella sezione dedicata a HTTPS consente di migliorare gli errori 404 e tutto ciò che è legato al reindirizzamento, oltre alle pagine che hanno un tag canonical, quelle con certificato non valido e gli URL bloccati.