Audit tecnico SEO: la checklist che nessuno verifica

Digita “technical SEO audit” e la prima pagina ti propone due cose: tool di audit che eseguiranno una scansione del tuo sito gratuitamente, e guide decacomponenti che finiscono sempre nello stesso modo — con un elenco di risultati ordinati per priorità. Scarica la scansione, classifica gli errori, correggi i critici, fatto. Ciò che nessuna guida di ranking ti dice è cosa succede dopo “fatto.” La correzione canonica è stata implementata. Qualcosa è cambiato? Il PDF dell'audit di 40 pagine non può rispondere a questa domanda, perché l'audit è terminato il giorno in cui è stato consegnato — e il numero che proverebbe il funzionamento della correzione non esiste fino a circa tre settimane dopo, nella Search Console.

Questa guida sostiene che un audit che termina all'elenco dei risultati è mezzo lavoro. L'altra metà — la metà che praticamente nessuno consegna — consiste nel correlate ogni correzione a una metrica della Search Console prima che venga implementata, quindi rilleggerla circa tre settimane dopo e registrare se si è mossa. Di seguito è riportata una checklist repository-first su cinque livelli che contano — crawl, indexation, canonicals, structured data, Core Web Vitals — con ogni elemento collegato alla metrica che la valuterà. Questo è il livello tecnico del nostro pilastro agentic SEO; la meccanica di verifica su cui si basa è trattata in profondità nella guida complementare su SEO a ciclo chiuso.

Un audit che termina all'elenco dei risultati è mezzo lavoro

Un audit tecnico SEO è un controllo sistematico per verificare se i motori di ricerca possono eseguire una scansione, indicizzare, comprendere e renderizzare rapidamente il tuo sito. Questo aspetto ogni guida lo affronta correttamente. Dove il playbook standard fallisce è nella sua definizione di conclusione: il deliverable è il documento. Risultati ordinati per gravità, screenshot del dashboard del crawler, un riepilogo con semaforo. Il contratto implicito è che qualcun altro farà le correzioni, e nessuno assoluto farà la prova.

Il risultato è un pattern che chiunque abbia acquistato un audit riconoscerà. Tre mesi dopo, metà dei critici sono corretti, un quarto sono contestati, e nessuna singola correzione può essere collegata a un singolo movimento nei dati. Il recupero dell'indicizzazione è stato causato dalla correzione della sitemap o dalla modifica del crawl budget che è stata implementata la stessa settimana? Nessuno può dirlo, perché nessuno si è impegnato in anticipo sulla metrica che avrebbe valutato ogni correzione, e nessuno ha programmato la rillettura. L'audit ha prodotto lavoro; non ha mai prodotto prova.

Un elenco di risultati ti dice cosa potrebbe essere sbagliato. Solo una metrica riletta ti dice che la correzione ha fatto qualcosa. L'industria dell'audit consegna il primo e spera silenziosamente che nessuno chieda il secondo.

La correzione è strutturale, non eroica: ogni risultato lascia l'audit portando tre campi — l'impatto previsto, la metrica della Search Console che la valuterà (clic, impressioni, CTR o posizione), e il target che conta come successo. Quando la correzione viene implementata, viene registrato un timestamp. Circa tre settimane dopo, la metrica viene riletta e il verdetto viene scritto: confermato, regredito o inconcludente. Questa è l'altra metà intera. Si adatta in tre colonne su una task board, e cambia ciò che la parola “audit” significa.

Repository-first batte crawl-first

Il secondo aspetto che il playbook standard affronta in modo sbagliato è dove guarda l'audit. Il metodo classico è crawl-first: punta un crawler al sito renderizzato, aspetta, e fai reverse-engineering dalle cause ai sintomi. Era l'unica opzione quando gli auditor erano outsider. Ma se tu — o il tuo agente — puoi leggere il repository da cui il sito è costruito, la fonte di verità per la maggior parte del SEO tecnico si trova in una manciata di file, attuali e precisi, senza delay di crawl e senza ambiguità di rendering.

Su un sito di framework moderno, le regole robots, la sitemap, la logica canonica, i metadati, i redirect e i structured data sono tutti codice. Un crawler ti dice che una pagina ha due canonical in conflitto; il repository ti dice quale template scrive ognuno e perché. Un crawler campiona; il repository è esaustivo — un bug canonico in un file layout è un bug canonico su ogni pagina che il layout renderizza, e puoi saperlo da una singola lettura di file. Su un sito Next.js, il primo passaggio di un audit è leggere forse dieci file.

La scansione ha ancora un posto — è il fallback di integrazione-only quando non c'è repository da leggere, e rimane il controllo onesto che ciò che il codice intende è ciò che il server serve. Ma l'ordine conta: leggi la fonte per primo, esegui la scansione per confermare, e usa la Search Console per tutto come record di ciò che Google ha effettivamente fatto con tutto.

La checklist repository-first, livello per livello

Cinque livelli, in ordine di dipendenza — ognuno è un prerequisito per quelli dopo. Una pagina che non può essere scansionata non può essere indicizzata; una pagina indicizzata sotto il canonical sbagliato divide i segnali che guadagna; schema su una pagina che nessuno può trovare marca nulla. Per ogni livello: cosa leggere, cosa cercare, e la metrica della Search Console che verificherà la correzione.

1. Crawl — i motori di ricerca riescono a raggiungerlo?

Leggi le regole robots e il middleware prima di fidarti di qualsiasi output del crawler. I fallimenti classici sono tutti visibili nella fonte: una regola disallow scritta per staging che è finita in produzione, middleware che reindirizza o sfida i bot user-agent, catene di redirect montate tra config e codice, e link interni che puntano a URL reindirizzati o morti. Su un sito che abbiamo auditato, le pagine di un intero template erano invisibili ai motori non a causa della qualità dei contenuti ma perché una regola a livello di route silenziosamente le escludeva — una ricerca di una riga nella fonte che nessuna quantità di staring al dashboard aveva portato alla luce. Metrica di verifica: impressioni sugli URL interessati — pagine che diventano scannable iniziano a essere mostrate, e questo si vede entro la finestra di tre settimane.

2. Indexation — il set giusto di pagine è nell'indice?

Confronta tre set: cosa dichiara la sitemap, cosa il repository effettivamente instrada, e cosa la Search Console segnala come indicizzato. I gap sono i risultati. Pagine nella sitemap che restituiscono errori, pagine instradate mancanti dalla sitemap, noindex direttive lasciate dalla launch, e il problema delle erbacce silenziose — URL con parametri, archivi tag, e duplicati paginati che assorbono l'attenzione del crawl che le tue pagine di denaro hanno bisogno. L'indicizzazione è anche dove si nasconde il gonfiore: mille pagine sottili, auto-generate nell'indice diluiscono piuttosto che aiutano. Metrica di verifica: impressioni per pagine che hai indicizzato; posizione sulle pagine che hai potato intorno, che smettono di competere con se stesse.

3. Canonicals — ogni pagina ha esattamente un indirizzo?

La lettura di leva più alta di tutto l'audit, perché la logica canonica di solito vive in uno o due file template e un errore lì si moltiplica su tutto il sito. Verifica che ogni route emetta esattamente un canonical, che sia assoluto e auto-consistente (barra finale, protocollo, www), che le varianti parametrizzate e paginate puntino dove dovrebbero, e che nulla si canonicalizzi a un redirect o a un 404. I problemi di indirizzo duplicato raramente sembrano drammatici in una scansione — sembrano un sito che si classifica leggermente peggio di quanto dovrebbe ovunque in una volta, perché ogni URL diviso divide i suoi segnali. Metrica di verifica: posizione su le query che la pagina consolidata serve — il consolidamento si mostra come l'URL superstite classifica dove due semi-URL erano abituati a stare.

4. Structured data — i motori riescono a classificare ciò che leggono?

Leggi i componenti JSON-LD, non l'output renderizzato, e fai tre domande: lo schema è valido, è veritiero, e è allegato al template giusto? I fallimenti comune visibili nel repository sono schema che descrive contenuto che la pagina non ha più, markup FAQPage le cui domande si sono allontanate dall'FAQ visibile, e markup di articolo mancante dei campi autore e data che i motori effettivamente usano. Lo schema conta due volte adesso — per i rich result classici, e perché un passaggio che un motore può classificare fiduciosamente è un passaggio che può quotare in una risposta AI, che è il territorio dell' ottimizzazione del motore di risposta. Metrica di verifica: CTR sulle query delle pagine marcate — i rich result cambiano come sembra il listing, e come sembra un listing cambia chi clicca.

5. Core Web Vitals — si renderizza abbastanza velocemente per mantenere?

Le soglie sono documentate e non negoziabili: il bar “buono” di Google è LCP entro 2,5 secondi, INP entro 200 millisecondi, CLS entro 0,1, giudicato al 75esimo percentile delle visite utente reale. Le letture lato repository: immagini non ottimizzate o non dimensionate, font caricati senza una strategia di scambio, script di terze parti che bloccano il thread principale, e JavaScript lato client che idrata componenti che avrebbero potuto rimanere statici. Conferma con i dati di field — i punteggi di lab fanno sembrare migliore ogni sito. CWV è il livello più probabile essere eccessivamente prioritizzato, quindi segnalo onestamente: è un tie-breaker e un floor di user-experience, non una leva di rankings. Metrica di verifica: posizione su head query dove siedi entro un luogo o due di un competitor più veloce — e aspetta che questo verifichi inconcludente più spesso degli altri quattro.

L'altra metà: verificare ogni correzione nella Search Console

Ecco la disciplina che separa un audit da un elenco di risultati. Prima di implementare qualsiasi correzione, il risultato viene registrato come un task che porta il suo contratto di prova: l'impatto previsto in termini semplici, la metrica verify dalla tabella precedente, e il target che conta come successo. La correzione viene implementata con un timestamp e una nota di esattamente cosa è cambiato — il commit, la PR, i file. Poi il clock gira. Google deve ricercare la pagina, rielaborarla, e accumulare abbastanza dati di query freschi da confrontare con la finestra prima. In pratica questo richiede circa tre settimane — più corto e stai leggendo rumore, molto più lungo e altre cause si affollano.

Al marchio di tre settimane, la metrica viene riletta su gli URL e le query interessati, e il verdetto viene scritto. Confermato: la metrica assegnata ha colpito il suo target e si è mantenuta — la correzione è provata, e adesso sai qualcosa del tuo sito che non sapevi prima. Regredito: si è mosso nel modo sbagliato — la correzione si riapre con informazioni migliori. Inconcludente: i dati non possono ancora dire — programma un'altra lettura, poi accetta l'onesto nulla. Tutti e tre sono risultati. L'unica modalità di fallimento è quella che l'audit standard istituzionalizza: contrassegnato fatto, mai misurato.

Nota cosa assegnare la metrica in anticipo silenziosamente previene: spostamento dei pali. Se il consolidamento canonico era supposto muovere la posizione e invece le impressioni sono salite da qualche altra parte, il verdetto onesto è non confermato — non un giro di vittoria intorno a qualsiasi grafico che è diventato verde. La tassonomia completa di quali numeri possono portare quel peso, e quali sono vanità, è l'oggetto della guida complementare su SEO KPI; la versione breve è che una metrica dimostra qualcosa solo se è stata scelta prima della correzione e può essere tracciata a essa.

Eseguilo come una board, non un documento

Il motivo per cui la metà della verifica quasi mai viene consegnata non è che qualcuno la contesti — è che nessun umano ricorda in modo affidabile, tre settimane dopo ognuno di trenta correzioni, di rilleggere una metrica specifica su uno specifico set di URL. La vigilanza non scala; i sistemi sì. La forma di lavoro è una task board dove ogni risultato audit arriva come un task con il suo contratto di prova allegato, ogni correzione implementata gira a fatto con il suo timestamp e PR, e un monitor settimanale legge la Search Console e scrive verdetti su qualcosa passato la sua data di verifica. L'audit smette di essere un documento con una data di consegna e diventa un loop con una cadenza — che è l'intera tesi della SEO a ciclo chiuso, applicata al livello tecnico.

Esegui questo per un paio di trimestri e appare un asset di second-order: un record per-sito di quali tattiche tecniche effettivamente verificano. I consolidamenti canonici confermano in modo affidabile; le aggiunte di schema muovono il CTR su template commerciali ma non su quelli informativi; il lavoro CWV legge inconcludente due volte di fila. L'audit successivo inizia da quella prova invece che da una scala di gravità generica — che è precisamente la differenza tra auditare un sito per la prima volta per sempre, e diventare più intelligenti su un sito ogni ciclo.

Cosa la verifica ti dirà onestamente

Una cautela che le guide a forma di tool non includono mai: esegui questo loop onestamente e una quota significativa delle tue correzioni tecniche verificheranno inconcludente. Questo non è un difetto nel metodo — è il metodo che funziona. Molto del lavoro tecnico è igiene: reale, vale la pena fare, e singolarmente troppo piccolo per muovere una metrica a livello di query contro il rumore di fondo. Il loop non esiste per lusingare ogni correzione. Esiste per impedirti di spendere un altro trimestre su la categoria di correzione che mai conferma, e per raddoppiare la categoria che fa.

Ricalibra anche la gravità. I dashboard dei crawler puntano i problemi per quanto sono rilevabili, non per quanto ti costano — mille avvertimenti “mancano testi alt” fotografano bene in un report, mentre un bug canonico a livello di template silenziosamente dimezza i segnali di ogni pagina che tocca. Dopo pochi cicli di verdetti, la gravità smette di essere l'opinione del crawler e inizia a essere la tua storia misurata del sito. E in una pagina di risultati sempre più guidata da risposte AI — la query che questo articolo è mirato ha una AI Overview e all'incirca mille ricerche al mese — la pagina scannable, canonica, classificabile è anche la pagina che può essere citata affatto, che è dove il livello tecnico incontra SEO zero-click.

Se vuoi vedere la metà find eseguita sui tuoi dati, il report SEO gratuito connette la tua Search Console e evidenzia dove il livello tecnico ti costa — le pagine mostrate ma mai scelte, gli URL che competono con se stessi. E se preferisci che l'intero loop funzioni senza che tu guidi ogni passo — risultati archiviati, correzioni implementate, verdetti letti tre settimane dopo — prenota una call e ti mostreremo come l'audit diventa un sistema.