Configura la tua auditoria SEO tecnica in 9 passaggi

Un’audit SEO tecnica non inizia con uno strumento aperto né con un PDF di 80 pagine che nessuno legge. Inizia con una domanda scomoda: cosa sta impedendo a Google di scansionare, renderizzare e indicizzare correttamente il tuo sito corporate? Se non riesci a rispondere con i dati, quello che hai è una lista di attività, non un audit.

Questo articolo descrive la sequenza esatta di configurazione che applico in progetti B2B con centinaia o migliaia di URL, ordinata per dipendenze: ogni passaggio produce il dato che alimenta il successivo. Se salti l’ordine, finirai per raccogliere metriche che non riesci a interpretare.

Passo 0: definisci l’ambito prima di toccare uno strumento

In un’azienda con diverse linee di business, l’errore più costoso è fare l’audit di «tutto il dominio». Prima di configurare qualsiasi cosa, delimita:

• Sottodomini inclusi: blog, negozio, area clienti, help center. Decidi se l’area privata rientra (normalmente no, ma conviene documentarlo).
• Lingue e versioni regionali: se hai /es/, /mx/ e /ar/, ognuna necessita di una propria verifica dell’hreflang.
• Stakeholder: chi approva le modifiche ai template di solito è in IT, non nel marketing. Individualo in questa fase o il resto del processo si blocca.

Un caso reale: un’azienda di servizi industriali con 4 lingue ha scoperto nella fase di definizione dell’ambito che il suo help center risiedeva su un sottodominio con CMS diverso e senza accesso ai log. Questo ha cambiato completamente la metodologia del resto dell’audit: senza log, l’analisi della scansione ha dovuto basarsi su campioni di Search Console e su crawl con user-agent di Googlebot.

Passo 1: configura l’accesso ai dati di origine

Senza questa base, qualsiasi audit è speculativo. Ti servono, come minimo:

Search Console

Verifica la proprietà per prefisso di URL ogni volta che puoi (consente di segmentare per sottodirectory) e mantieni la proprietà di dominio come riserva. Controlla che l’utente che utilizzerai abbia permesso completo, non limitato: il permesso limitato nasconde dati di rendimento e di indice che ti serviranno dopo.

Analytics

Se usi GA4, assicurati che il flusso di dati web sia attivo da almeno 90 giorni. Con meno storico, qualsiasi confronto del traffico organico prima/dopo una modifica tecnica è rumore. Configura un segmento di traffico organico che escluda domini di referral interni e parametri di campagna che sporcano l’attribuzione.

Log del server

Richiedi l’accesso ai file di accesso (Apache o Nginx) con un minimo di 30 giorni. Secondo la documentazione ufficiale di Google sulla scansione, l’analisi dei log è l’unica fonte che mostra con certezza quali URL visita realmente Googlebot, rispetto a quelle che tu credi visiti.

Accesso al CMS e al repository

Avrai bisogno di poter leggere i template di intestazione, le regole di reindirizzamento e il file robots.txt. Se non hai accesso al repository, chiedi al team tecnico di esportare la configurazione di .htaccess o del middleware dei reindirizzamenti.

Passo 2: prepara il crawler con precisione

La configurazione del crawler determina la qualità di tutte le scoperte successive. Impostazioni che fanno la differenza:

• User-agent: usa quello di Googlebot per simulare la scansione mobile (Googlebot Smartphone). Molte differenze di contenuto emergono solo con quell’agente.
• Rendering JavaScript: attivalo solo se il tuo sito ne ha bisogno. Nei siti con molto contenuto dinamico, il rendering fa schizzare i tempi di crawl e può esaurire i crediti dello strumento. In un progetto con 12.000 URL, attivare il rendering completo ha costretto a dividere il crawl in segmenti per sezione.
• Limite di velocità: non superare 2-3 richieste al secondo in produzione senza avvisare l’IT. Un crawl aggressivo può attivare il WAF e falsare i risultati con errori 403.
• Autenticazione: se c’è contenuto dietro login rilevante per la SEO (ad esempio, schede prodotto con prezzi nascosti), configura cookie o header di autenticazione.

Salva la configurazione del crawl. Ti servirà identica per confrontare i risultati dopo le modifiche.

Passo 3: valida la salute della scansione con robots.txt e sitemap

Prima di verificare qualsiasi altra cosa, conferma che Google possa raggiungere le tue URL:

1. Controlla il robots.txt riga per riga. Cerca blocchi di risorse CSS/JS (rompono il rendering) e di parametri che invece generano contenuto unico.
2. Verifica che la sitemap XML contenga solo URL canoniche, con stato 200 e non bloccate. Una sitemap con reindirizzamenti o 404 è un segnale di trascuratezza che Google ignora progressivamente.
3. Verifica in Search Console → Sitemap che il file venga elaborato senza errori e che le URL scoperte coincidano con quelle che ti aspetti.
4. Usa lo strumento di ispezione URL per le 10 pagine più importanti per business e conferma «L’URL è su Google» e che la versione scansionata sia quella canonica.

Limitazione onesta: se il tuo sito ha più di 50.000 URL, l’ispezione manuale non è scalabile. In quel caso, dai priorità all’ispezione per template (una URL rappresentativa per tipo) e integra con il report «Pagine» di Search Console.

Passo 4: mappa i codici di stato e i reindirizzamenti

Esporta dal crawl tutte le URL con stato diverso da 200 e classificale:

• 301/302: verifica che le catene di reindirizzamento non superino un salto e individua i loop. Un pattern abituale nelle aziende dopo le migrazioni: /prodotto → /prodotto/ → /es/prodotto/ → 404. Ogni salto perde segnale e aggiunge latenza.
• 404/410: incrocia la lista con Search Console per individuare le URL che ricevono ancora link esterni. Quelle sono quelle che necessitano di reindirizzamento o recupero, non quelle che semplicemente esistono.
• 5xx: se compaiono nel crawl, fermati. Un server instabile invalida qualsiasi altra analisi.

Documenta ogni reindirizzamento con la sua origine, destinazione e motivo. Quel registro è ciò che permetterà all’IT di eseguire le modifiche senza interpretazioni.

Passo 5: risolvi canoniche e duplicazioni

Configura la verifica su tre livelli:

1. Canoniche dichiarate: confronta il tag rel=canonical con l’URL finale dopo i reindirizzamenti. Una canonica che punta a una URL reindirizzata è un errore frequente nei CMS con plugin SEO mal configurati.
2. Parametri: individua quelli che generano duplicati (ordinamento, filtri, paginazione) e decidi tra canonica, noindex o blocco. Attenzione: bloccare nel robots.txt una URL con canonica impedisce a Google di leggere quella canonica.
3. Varianti di URL: maiuscole, barra finale, http/https, www/no-www. Forza una sola versione con reindirizzamenti a livello di server, non dal CMS.

Questo non funziona allo stesso modo in tutti i casi: nell’ecommerce con filtri sfaccettati, la canonica da sola non risolve il problema se i filtri ricevono link interni. Lì hai bisogno inoltre del controllo del linking interno e, a volte, del rendering condizionale dei link dei filtri.

Passo 6: verifica il rendering e il JavaScript

Confronta l’HTML iniziale con il DOM renderizzato nei template chiave. Cerca:

• Contenuto principale che appare solo dopo l’esecuzione di JavaScript (rischio alto se non c’è rendering lato server).
• Link interni generati da JS che il crawler non scopre senza rendering.
• Metadati (title, canonical, hreflang) iniettati da JS e che potrebbero non riflettersi nell’HTML servito.

Secondo la documentazione ufficiale sul rendering, Google può eseguire JavaScript, ma con budget di scansione limitato e senza garanzia che tutti gli script vengano eseguiti. La conclusione pratica: se un link o un canonical esiste solo dopo il JS, trattalo come non affidabile.

Passo 7: misura i Core Web Vitals con dati di campo

Non fermarti a Lighthouse. Configura la verifica con dati reali:

1. Esporta il report dei Core Web Vitals di Search Console per tipo di dispositivo e raggruppamento di URL.
2. Individua quali template non superano LCP, INP o CLS, non quali pagine singole.
3. Dai priorità per impatto: un template di scheda prodotto con migliaia di URL e LCP insufficiente pesa più della home.

Sfumatura importante: i dati di campo hanno latenza (28 giorni nel report di Search Console). Se hai appena ottimizzato le immagini, non aspettarti di vedere il cambiamento nella stessa settimana. E se il tuo traffico è basso, potrebbe non esserci un numero sufficiente di campioni per valutare un template specifico; in quel caso, combina laboratorio e campo, e dillo nel report.

Passo 8: consolida il report e dai priorità per dipendenze

Il deliverable non è una lista di errori. È una sequenza di esecuzione con dipendenze:

• Bloccanti: 5xx, robots.txt che blocca risorse, reindirizzamenti rotti. Senza questo, il resto non conta.
• Strutturali: canoniche, duplicazioni, architettura dei link interni.
• Prestazioni: Core Web Vitals per template.
• Miglioramenti: dati strutturati, hreflang, ottimizzazione delle immagini.

Ogni attività deve indicare la URL o il template interessato, il team responsabile e come verrà verificata la modifica (ad esempio, «ricrawl delle 200 URL del template X e confronto dei codici di stato»).

Errori di configurazione che vedo ripetersi

• Fare l’audit con lo user-agent desktop su siti dove il mobile serve contenuto diverso. Le scoperte non coincidono con ciò che Google indicizza.
• Fidarsi della copertura di Search Console senza incrociarla con i log. Ci sono URL scansionate che non compaiono mai nei report e altre che compaiono come «escluse» senza motivo apparente.
• Modificare robots.txt e canoniche contemporaneamente. Se qualcosa peggiora, non saprai cosa l’ha causato. Una modifica per iterazione, con data registrata.
• Ignorare l’area clienti nel robots.txt e scoprire mesi dopo che Googlebot consuma budget di scansione su URL di sessione.

Cosa non copre questa metodologia

Un audit tecnico non risolve un problema di intento di ricerca né di qualità dei contenuti. Se il tuo sito scansiona e indicizza correttamente ma le pagine non rispondono a ciò che l’utente cerca, i dati tecnici saranno puliti e il traffico resterà piatto. Non sostituisce nemmeno una revisione dei link tossici né dell’autorità di dominio: sono discipline diverse che si completano, non si sovrappongono.

E un avvertimento finale: nessun audit garantisce miglioramenti di posizionamento. Ciò che garantisce è che elimini ostacoli misurabili. Il resto dipende da fattori che non controlli dal server.