Audit SEO del sito e reporting Lighthouse: la dashboard con cui le agenzie mostrano il lavoro tecnico

Ogni conversazione sui Vitals finisce con la stessa domanda: quale pagina? Questo report risponde tenendo due misurazioni accanto. Il valore sul campo è ciò che i visitatori hanno davvero vissuto: Largest Contentful Paint, Interaction to Next Paint e Cumulative Layout Shift al 75° percentile, confrontati con le soglie di buono e scarso definite da Google. L’audit di laboratorio è ciò che il crawler ha misurato su ogni URL in condizioni controllate, su richiesta, il giorno in cui esce una correzione. Uno dice se il sito è promosso; l’altro dice quale template ne è responsabile.

La tabella delle pagine controllate è dove questo abbinamento diventa visibile. Ogni URL scansionato porta i propri quattro punteggi accanto al proprio LCP e CLS di laboratorio, e un anello di valutazione conta quante pagine sono promosse senza riserve, quante hanno bisogno di miglioramenti e quante sono bocciate. Così «il sito sembra lento» diventa un ordine di lavoro che indica il template, il traffico dietro di esso e la metrica in difetto. Le tendenze a livello di property e la suddivisione per dispositivo pubblicate da Google appartengono al report Search Console; questa pagina è il banco di prova sottostante.

La scheda «Opportunità» elenca ciò che l’audit ha trovato e quanto vale correggerlo: millisecondi per le risorse che bloccano il rendering, i suggerimenti di preconnessione e il tempo di risposta del server; kibibyte per immagini sovradimensionate, formati di nuova generazione, media fuori schermo, JavaScript inutilizzato, CSS non minificato e durata della cache. Ogni riga porta l’area a cui appartiene e una gravità derivata dalla dimensione del risparmio, così una stima dello sviluppatore e una priorità dell’agenzia si possono discutere partendo dallo stesso elenco invece che da due esportazioni diverse.

La diagnostica sta accanto come spiegazione e non come lista di cose da fare: dimensione del DOM, lavoro sul thread principale, tempo di esecuzione JavaScript, numero di richieste, peso trasferito, catene di richieste critiche, l’elemento che definisce il Largest Contentful Paint e gli elementi che si spostano dopo il rendering. Ognuno arriva con l’obiettivo sotto cui dovrebbe stare e una frase semplice sul perché conta: di solito la differenza tra un report che un cliente inoltra al suo sviluppatore e uno che torna indietro pieno di domande.

I controlli automatici di accessibilità sono raggruppati come si organizza davvero la correzione: per impatto. I rilievi critici, come campi di modulo senza etichetta e immagini senza testo alternativo, stanno separati da quelli gravi, come errori di contrasto e link senza nome, che a loro volta stanno separati dai problemi moderati, come dimensione delle aree di tocco, ordine delle intestazioni e ordine del focus. Ogni riga porta il numero di elementi coinvolti, così un preventivo si costruisce su conteggi e non su una vaga promessa di migliorare l’accessibilità.

Il report è deliberatamente onesto su cosa copre un controllo automatico. Questi controlli individuano una frazione delle barriere che trova una revisione manuale, e la superficie lo dichiara, il che protegge un’agenzia dal rischio che un cliente legga un esito pulito come un certificato di conformità. Usato correttamente è il primo passaggio più economico disponibile: elimina gli errori meccanici, lascia una traccia documentata di cosa è stato corretto e quando, e riduce di molto la superficie su cui deve lavorare una revisione manuale.

Dieci controlli su scansione e markup vengono eseguiti come un elenco superato/non superato con una frase che spiega cosa ha trovato la scansione: elementi title, meta description, link scansionabili, dichiarazioni canonical, annotazioni hreflang, un file robots valido, attributi alt sulle immagini, dimensioni dei caratteri leggibili, spaziatura delle aree di tocco e validità dei dati strutturati. Un conteggio in testa sta sopra la tabella, così la prima cosa che chiunque vede è quanti dei dieci sono puliti e quanti restano lavoro aperto.

Questo è l’audit on-page, non il report sull’indicizzazione: ciò che un crawler riesce a leggere sulla pagina, non ciò che Google ha scelto di mantenere. I due rispondono a domande diverse e appartengono a posti diversi, ed è per questo che copertura, query e impressioni vivono nel report Search Console e questa pagina resta sul markup. Rivederli insieme è lo schema abituale: prima correggere ciò che l’audit segnala qui, poi osservare come copertura e posizione reagiscono nelle settimane seguenti.

Ogni audit è limitato a un solo cliente tramite il selettore dello spazio di lavoro ed è presentato con il branding della tua agenzia, così la stessa struttura porta la revisione di gennaio e quella di giugno. Punteggi, Vitals, opportunità, diagnostica, accessibilità e controlli tecnici mantengono i loro posti tra un incarico e l’altro, il che rende il confronto mese su mese una questione di leggere due volte la stessa sezione invece di riconciliare due documenti costruiti in modo diverso. Lo spazio di lavoro fornisce la superficie di revisione; collegare la fonte dati resta un passaggio a parte.

Questa ripetizione è ciò che trasforma il lavoro tecnico in qualcosa che un cliente rinnova. Uno sviluppatore vede un elenco di correzioni classificato con il risparmio stimato; un account manager vede quattro punteggi, una cifra di salute e le pagine dietro di essi, ed entrambi guardano lo stesso report. I team passano il tempo a decidere cosa correggere dopo invece di ricostruire un layout di presentazione, e l’audit smette di essere il deliverable che nessuno ha voglia di scrivere.