Report di audit SEO: come farlo leggere e agire

Fare un audit SEO e scrivere un report che qualcuno legge davvero, e su cui qualcuno agisce, sono due competenze diverse. La prima è tecnica: crawl, backlink, Core Web Vitals, cannibalizzazione dei contenuti. La seconda è comunicativa, e la maggior parte degli audit si ferma prima, alla prima. Il risultato tipico è un PDF di novanta pagine, uno screenshot di ogni report dello strumento usato, zero priorità e nessuna decisione presa in conseguenza. Nessuno lo legge fino in fondo, e anche chi lo apre non sa da dove cominciare lunedì mattina.

Questo articolo non parla di come condurre l'audit — quello è un lavoro tecnico che dipende dal sito, dal settore, dagli strumenti a disposizione. Parla di cosa succede dopo: come trasformare un elenco di problemi trovati in un documento che qualcuno legge, capisce e usa per decidere. È la parte che separa un audit che genera lavoro reale da uno che finisce archiviato in una cartella condivisa, mai più riaperto.

Per chi scrivi, prima di cosa scrivi

Prima di aprire l'editor, decidi chi leggerà il report, perché cambia tutto quello che segue: il linguaggio, l'ordine delle informazioni, persino cosa includere.

Un titolare d'azienda o un direttore marketing che approva i budget vuole sapere due cose: quanto costa non risolvere il problema, e quanto costa risolverlo. Non gli interessa se il problema è un tag canonical mal configurato o una sitemap non aggiornata — gli interessa che sta perdendo traffico su una categoria che genera fatturato, e quanto tempo o persone servono per sistemarlo.

Un responsabile marketing che gestisce l'esecuzione vuole priorità e tempistiche: cosa si fa questa settimana, cosa questo trimestre, cosa può aspettare. Ha bisogno di un piano che possa portare in una riunione con il team, non di una spiegazione tecnica di perché il problema esiste.

Uno sviluppatore che dovrà effettivamente intervenire vuole il contrario di entrambi: ticket specifici e riproducibili. Non "migliorare la velocità di caricamento" ma "comprimere le immagini hero sopra i 500KB nella cartella /prodotti, verificabile su questo URL di esempio".

Un solo documento raramente serve bene a tutti e tre. Se il tuo cliente o il tuo capo è il titolare, scrivi per il titolare e allega — senza integrarli nel corpo — i dettagli tecnici in appendice per chi dovrà eseguire. Se sai che il report finirà direttamente nelle mani degli sviluppatori, scrivi ticket, non narrativa. Decidere il destinatario prima di scrivere evita il difetto più comune: un documento che prova a essere tutto per tutti e finisce per non essere davvero utile a nessuno.

La struttura che fa muovere le cose

Un report che funziona ha tre caratteristiche strutturali, indipendentemente da chi lo legge.

La prima è un riepilogo che un decisore può leggere in due minuti. Non un'introduzione neutra su quanto conti la SEO oggi, ma poche righe che dicono: abbiamo trovato un certo numero di problemi, i più gravi sono questi, l'impatto stimato è questo, l'azione richiesta questo trimestre è questa. Se chi legge si ferma qui, deve comunque sapere cosa sta succedendo e cosa gli viene chiesto.

La seconda è l'ordine dei findings. La tentazione naturale è raggrupparli per categoria tecnica — tutto ciò che riguarda il crawling, poi i contenuti, poi i backlink — perché è così che li hai trovati durante il lavoro. È l'ordine sbagliato per chi legge. Ordina per impatto atteso, dal più alto al più basso: il problema che sta bloccando l'indicizzazione di duecento pagine di prodotto viene prima del title tag subottimale sulla pagina "chi siamo", anche se tecnicamente appartengono alla stessa categoria on-page.

La terza è che ogni singolo finding, per essere utile, deve rispondere a cinque domande — fermarsi alla prima, cioè descrivere solo cosa non va, è la forma più comune nei report generati automaticamente da uno strumento, e obbliga chi legge a fare da solo il lavoro di tradurre il problema in un'azione concreta:

• Cosa non va, in una frase chiara
• Quanto costa non risolverlo, in traffico perso, conversioni perse o rischio
• Cosa fare concretamente per risolverlo
• Quanto è difficile o costoso risolverlo, in ore, competenze richieste, dipendenze
• Chi se ne occupa: sviluppo, contenuti, o un fornitore esterno

La priorizzazione è il vero prodotto

Chiunque sappia usare uno strumento di audit può produrre un elenco di cento problemi in un pomeriggio. Il valore che porti come consulente o come team SEO interno non è trovarli — lo strumento li trova già da solo. Il valore è sapere quali cinque contano davvero in questo trimestre, con queste risorse, per questo sito specifico.

Un report che elenca cento problemi ordinati solo per severità tecnica, senza dire quali cinque affrontare prima, ha delegato la parte più difficile del lavoro a chi lo legge — e chi lo legge, nella maggior parte dei casi, non ha né il tempo né il contesto tecnico per farla bene. Se il tuo report richiede una riunione di un'ora solo per capire da dove iniziare, la priorizzazione non è stata fatta nel documento: è stata semplicemente rimandata a dopo. La priorizzazione reale considera almeno tre fattori insieme, non uno alla volta:

• L'impatto stimato, cioè quanto traffico, visibilità o conversioni sono in gioco
• Lo sforzo richiesto, cioè quante ore, quali competenze e quali dipendenze tecniche servono per risolvere
• Le dipendenze tra findings — a volte un problema va risolto prima che un altro abbia senso; migrare la struttura degli URL prima di ottimizzare i contenuti di quelle stesse pagine è un ordine obbligato, non un elenco intercambiabile

Le prove: mostrare, non scaricare

Ogni finding importante ha bisogno di una prova concreta — uno screenshot dell'errore, l'export dei dati che lo dimostra, l'URL specifico dove si verifica. Senza prove, un report è una lista di affermazioni che chi legge deve prendere sulla parola, e la fiducia si consuma in fretta quando la prima affermazione risulta imprecisa o esagerata.

Ma c'è una differenza netta tra mostrare la prova giusta e scaricare l'intero export dello strumento nel corpo del documento. Uno screenshot annotato che isola l'errore specifico, o una tabella di cinque righe con i dati essenziali, comunica in dieci secondi quello che quattro pagine di tabella grezza nascondono dietro il rumore. Il crawl completo, l'export di tutti gli URL scansionati, la lista intera dei backlink: tutto questo ha un posto, ed è un'appendice o un file allegato separato — non il corpo del report che il decisore sta leggendo in quel momento.

Questa distinzione conta doppiamente per chi dovrà eseguire, non solo per chi deve decidere il budget. Uno sviluppatore a cui viene chiesto di guardare l'export completo e trovare da solo i link rotti farà molto più fatica — e sarà molto meno propenso ad agire subito — di uno che riceve la lista già filtrata degli errori con priorità alta e il link diretto a ciascuno.

Cosa lasciare fuori dal report

Tanto quanto decidere cosa includere, un report efficace richiede di lasciare fuori alcune cose, anche quando lo strumento usato le ha segnalate in rosso.

Il punteggio di uno strumento non è un obiettivo di business. Un punteggio di performance perfetto, o un punteggio complessivo generato da un tool qualsiasi, misura quanto il sito si avvicina a un ideale tecnico astratto — non quanto traffico o fatturato genera davvero per l'azienda. Presentare l'aumento di quel numero come l'obiettivo del trimestre confonde lo strumento di misura con il risultato che interessa a chi paga il conto.

Un finding di cui non riesci a spiegare la conseguenza di business non appartiene al corpo del report. Se non sai dire, nemmeno approssimativamente, cosa cambia per il sito risolvendo un determinato problema, è probabile che tu lo stia includendo solo perché lo strumento l'ha segnalato, non perché conti davvero per chi legge. Meglio ometterlo, o spostarlo in un'appendice tecnica separata, che diluire i findings che contano davvero con rumore che sembra importante ma non lo è.

E ci sono problemi tecnicamente veri ma commercialmente irrilevanti — un attributo alt mancante su un'immagine decorativa in fondo a una pagina che riceve poche visite l'anno è un'imperfezione reale, ma includerla accanto a un problema di indicizzazione che blocca la categoria principale del sito comunica, implicitamente, che i due meritano attenzione comparabile. Non è così, e il report non dovrebbe mai suggerire che lo sia.

La consegna non è la fine: l'handoff

Un audit che si conclude con la consegna del documento ha fallito, anche se il documento in sé è perfetto. Il report è uno strumento per far succedere qualcosa, non il traguardo del lavoro.

Perché succeda davvero qualcosa, ogni finding prioritario ha bisogno di tre elementi oltre alla descrizione: un responsabile con nome e cognome — non genericamente "il team di sviluppo", ma una persona che sa di essere proprio quella persona — una sequenza chiara di cosa viene prima e cosa dopo, e una data di verifica concreta segnata sul calendario, non un vago "controlleremo tra qualche mese".

In pratica questo significa chiudere la consegna del report con una riunione, non solo con un'email e l'allegato. In quella riunione si assegnano i findings prioritari, si concorda la sequenza — cosa parte questa settimana, cosa il mese prossimo — e si fissa già la data della verifica successiva. Senza questo passaggio, un report ottimo finisce archiviato esattamente come un report mediocre: il problema non è mai stato la qualità dell'analisi, è stato il fatto che nessuno si è sentito responsabile di trasformarla in lavoro vero.

Ri-auditare per dimostrare cosa è cambiato

Il valore di un audit non si esaurisce nel momento in cui viene consegnato. Un secondo audit, condotto qualche mese dopo sugli stessi findings prioritari, è quello che trasforma un esercizio isolato in un processo che si può difendere davanti a chi ha approvato il budget iniziale.

Questo secondo giro non deve ripetere l'intero lavoro fatto la prima volta. Basta rivedere puntualmente gli elementi segnalati come prioritari nel primo report — l'indicizzazione delle pagine che risultavano bloccate, il tempo di caricamento della categoria critica, la struttura degli URL migrata — e documentare cosa è effettivamente cambiato, in positivo o in negativo. Un problema segnalato che non si è mosso in tre mesi merita la stessa attenzione di un problema del tutto nuovo: significa che l'handoff non ha funzionato come previsto, oppure che la priorità era sbagliata fin dall'inizio, ed entrambe sono informazioni utili quanto un problema mai visto prima.

Questo passaggio è anche ciò che, nel tempo, costruisce fiducia in chi legge i tuoi report: non la promessa che qualcosa migliorerà in futuro, ma la prova ripetuta che le cose segnalate vengono davvero verificate in seguito, report dopo report.