Audit SEO tecnico: cosa controllare e come definire le priorità

Quali strumenti e accessi servono per iniziare?

Chiarisci con il proprietario del sito quali servizi, categorie o prodotti devono portare visite e contatti, quali lingue sono attive e che cosa è cambiato di recente. Se stai indagando un calo, confronta la data dell’ultimo rilascio con l’inizio del problema: saprai quali modifiche esaminare, senza attribuire la causa alla sola coincidenza delle date.

Per i controlli nel browser usa Chrome DevTools, che puoi aprire con F12 o dal menu Ispeziona. PageSpeed Insights serve a esaminare le prestazioni, mentre il Test dei risultati avanzati controlla i dati strutturati supportati da Google. Entrambi accettano URL pubblici.

Per esplorare i collegamenti del sito puoi usare Screaming Frog SEO Spider: la versione gratuita arriva a 500 URL per scansione, comprese le risorse raccolte. Se raggiungi il limite, la scansione si interrompe e alcune pagine possono restare fuori. Il rendering JavaScript non è incluso nella versione gratuita: per controllare il contenuto caricato dagli script usa il browser e, se disponibile, Controllo URL.

Come scegliere gli URL da controllare?

Per un sito di servizi con un blog puoi partire dai 13 URL distinti proposti qui sotto. Il campione comprende pagine diverse e alcuni casi da confrontare, come un indirizzo reindirizzato o una pagina volutamente esclusa. Seleziona ogni URL una sola volta. Per template si intende il modello con cui il CMS genera pagine dello stesso tipo: per esempio, le schede dei servizi.

Il totale è 1 + 3 + 3 + 1 + 2 + 1 + 1 + 1 = 13. Se una tipologia non esiste, segna “non applicabile” e riduci il totale. Per un ecommerce aggiungi categorie, prodotti disponibili ed esauriti, varianti e paginazione; per un sito multilingue, coppie di pagine equivalenti. Quando trovi un errore, controlla altri URL generati dallo stesso template per capire quanto è esteso e se ci sono eccezioni.

Per scegliere gli indirizzi parti dalla navigazione e dalla sitemap, aggiungendo gli esempi problematici di Search Console se hai accesso. Per ciascuno annota che cosa dovrebbe accadere: deve poter comparire nelle ricerche, è un duplicato di un’altra pagina, deve reindirizzare altrove oppure deve restare escluso dall’indice? Se un URL è presente nella sitemap ma manca dalla scansione del crawler, controlla come ci si arriva: potrebbe non essere collegato dalle pagine esplorate.

Da dove partire: risposte HTTP, robots.txt e sitemap

1. Leggi la risposta e la destinazione finale

   In DevTools apri Network (Rete), attiva Preserve log (Mantieni log) e ricarica la pagina. Seleziona la richiesta di tipo document, poi apri Headers (Intestazioni): Status Code mostra il codice di risposta e Location indica la destinazione di un eventuale redirect. Annota l’URL iniziale, i passaggi intermedi e l’indirizzo finale.

   Se preferisci il terminale, questo comando salva le intestazioni in headers.txt e l’HTML finale in page.html. Sostituisci l’indirizzo di esempio con quello da verificare. In PowerShell usa curl.exe al posto di curl.

   curl -sS -L -D headers.txt -o page.html https://example.com/servizio/

   Una pagina attiva deve normalmente restituire 200 e mostrare il contenuto previsto. Un vecchio indirizzo trasferito stabilmente può rispondere con 301 o 308 e portare alla pagina equivalente. Per un URL inesistente controlla che la risposta sia 404 o 410: se compare “pagina non trovata” ma il server restituisce 200, annota una possibile soft 404. Se ricevi un errore 5xx, ripeti il test e chiedi all’hosting di controllare i log, così potrai distinguere un episodio isolato da un problema che si ripete.

2. Verifica le regole di scansione

   Apri https://example.com/robots.txt, sostituendo il dominio di esempio con quello effettivo e usando lo stesso protocollo del sito. Cerca il gruppo di regole applicabile a Googlebot e controlla se Allow o Disallow corrispondono al percorso della pagina. Annota la regola trovata e verifica anche l’accesso ai CSS e agli script necessari per caricare il contenuto. Se hai Search Console, confronta il risultato con la voce “Scansione consentita?” di Controllo URL.

   Se una pagina pubblica importante è bloccata per errore, passa la regola a chi gestisce la configurazione. Ricorda che Disallow limita la scansione: per escludere una pagina dall’indice Google deve invece poter leggere noindex. Bloccare la stessa pagina in robots.txt può impedirgli di vedere quella direttiva, come spiega la documentazione su noindex. I contenuti riservati vanno protetti con l’autenticazione: robots.txt non ne impedisce l’apertura.

3. Confronta sitemap e pagine reali

   Cerca la riga Sitemap in robots.txt oppure chiedi il percorso al gestore del sito. Se il file elenca altre sitemap, apri anche quelle. Per gli URL del campione che vuoi far indicizzare, verifica che la sitemap riporti l’indirizzo preferito, che la pagina risponda con 200 e che non abbia noindex. Segnala redirect, errori e duplicati non preferiti da togliere dal file. Controlla anche lastmod: deve riflettere le modifiche sostanziali della pagina, non aggiornarsi per tutte le pagine a ogni pubblicazione.

   In Search Console → Sitemap verifica che Google abbia letto il file e apri gli eventuali errori. La sitemap facilita la scoperta degli URL, ma la loro inclusione nell’indice resta da controllare. Le indicazioni ufficiali sulle sitemap spiegano quali indirizzi e date usare.

La pagina può essere indicizzata? Google quale URL sceglie?

Apri l’HTML salvato oppure Visualizza sorgente pagina e cerca name="robots", eventuali direttive per googlebot e rel="canonical". Nelle intestazioni HTTP cerca X-Robots-Tag. Il canonical indica l’indirizzo che il sito propone come versione principale: annotalo e aprilo per verificare che esista e mostri il contenuto previsto.

Per una pagina autonoma che vuoi far comparire su Google, un noindex inatteso è un problema da correggere. Per una variante duplicata, invece, può essere corretto indicare come canonical la pagina principale. Prima di modificare un tag, confronta quindi ciò che trovi con lo stato atteso che hai scritto nel registro.

In Search Console incolla l’URL in Controllo URL. Leggi prima i dati della versione indicizzata: stato, ultima scansione, canonical dichiarato dal sito e canonical selezionato da Google. Poi scegli Testa URL pubblicato per esaminare la versione attuale. Salva i due risultati con la data, perché Google potrebbe non aver ancora letto l’ultima modifica.

Il test dell’URL pubblicato verifica le condizioni attuali della pagina, ma non conferma che sia nell’indice e non prevede quale canonical sceglierà Google. Queste informazioni si leggono nei dati indicizzati, come chiarisce la guida a Controllo URL. Se non hai accesso, lascia quelle due verifiche in attesa e annota soltanto ciò che hai potuto osservare.

Il contenuto resta leggibile dopo il rendering JavaScript?

Confronta page.html con la pagina caricata nel browser. In Elements (Elementi), cioè nel DOM che il browser ha costruito, cerca una frase del testo principale, l’H1, il canonical e un link importante. Se qualcosa compare soltanto lì e manca dal sorgente, annota quale contenuto o tag viene aggiunto da JavaScript. In Network e Console cerca richieste fallite ed errori che lasciano la pagina vuota o impediscono la navigazione.

Per leggere titolo, canonical e direttive del DOM, puoi digitare questo comando di sola lettura nella Console di DevTools. Ti aiuta a confrontare i tag finali con il sorgente; non interroga l’indice di Google.

({
  title: document.title,
  canonical: [...document.querySelectorAll('link[rel="canonical"]')].map(e => e.href),
  robots: [...document.querySelectorAll('meta[name="robots"], meta[name="googlebot"]')].map(e => e.content)
})

Se hai Search Console, apri Visualizza pagina testata dal test dell’URL pubblicato e confronta HTML, screenshot e risorse con il browser. Per esempio, se prezzo e descrizione di un prodotto compaiono solo dopo un clic, controlla se sono presenti anche nell’HTML della pagina testata da Google. La guida SEO per JavaScript segnala inoltre che Google può saltare il rendering quando incontra noindex nell’HTML iniziale: rimuoverlo soltanto con uno script non è una soluzione affidabile.

Verifica che il contenuto principale sia disponibile, che i tag non si contraddicano e che i collegamenti importanti usino <a href="…"> con indirizzi stabili. Se il browser carica tutto ma il test di Google fallisce, conserva il messaggio di errore e l’indirizzo della risorsa coinvolta: lo sviluppatore avrà un punto preciso da cui iniziare l’indagine.

I link rendono raggiungibili le pagine importanti?

In Screaming Frog avvia una scansione in modalità Spider dall’URL della home, rispettando robots.txt. Annota data e impostazioni usate e verifica se il limite gratuito ha interrotto il lavoro. Seleziona un URL nella scheda Internal e apri Inlinks in basso: vedrai da quali pagine arriva un link verso quell’indirizzo. Esporta l’origine, la destinazione e il testo del collegamento. Se una pagina è nella sitemap ma manca dal crawl, controlla prima che la scansione sia completa e che i link non dipendano da JavaScript.

Percorri poi il sito nel browser, sia su desktop sia su mobile: dalla home apri una categoria e raggiungi una pagina del campione. Annota il percorso e il punto in cui manca un collegamento utile. Negli archivi e nei cataloghi prova ad andare oltre la prima pagina, verificando che si possano raggiungere anche gli elementi successivi. Prima di definire una pagina “orfana”, cioè priva di link interni in entrata, confronta i risultati della scansione con navigazione e inventario del CMS.

Per filtri e varianti, confronta il contenuto delle pagine e osserva quali indirizzi producono i link. Se ogni combinazione genera un nuovo URL, chiarisci con il gestore quali versioni devono comparire su Google. Nei siti multilingue controlla che ciascuna pagina indichi il proprio URL come canonical e rimandi alle versioni equivalenti nelle altre lingue, che devono ricambiare il collegamento. La SEO per ecommerce approfondisce prodotti e filtri; la checklist SEO internazionale spiega i controlli sulle versioni linguistiche.

Come controllare prestazioni, mobile e dati strutturati?

Inserisci in PageSpeed Insights un URL per ogni template importante e confronta mobile e desktop. Tieni separati i dati raccolti dalle visite reali e il test di laboratorio eseguito dallo strumento. Se mancano dati per il singolo URL, controlla se il report si riferisce all’origine, cioè alle pagine che condividono protocollo, dominio e porta. Per i Core Web Vitals, i valori considerati buoni sono LCP fino a 2,5 secondi, INP fino a 200 millisecondi e CLS fino a 0,1, valutati al 75° percentile delle visite. Il TBT del test di laboratorio non è una misura dell’INP.

Se la pagina carica lentamente, cerca nel report l’elemento LCP e le risorse segnalate, quindi passa al tecnico il problema da verificare: può riguardare, per esempio, un’immagine, i font o la risposta del server. Le stime di risparmio indicano quanto il tool ritiene possibile migliorare, non un risultato già ottenuto. Dopo la modifica ripeti il test nelle stesse condizioni e controlla in seguito i dati delle visite reali. La documentazione sui Core Web Vitals spiega come leggere le misure.

Su un telefono o con la modalità dispositivo di DevTools apri il menu, segui i link e prova i moduli. Controlla che il contenuto sia leggibile e che pulsanti, etichette e scorrimento funzionino; prova la navigazione anche da tastiera. Nel Test dei risultati avanzati apri gli errori dei tipi rilevati e confronta i valori, come prezzo, disponibilità o autore, con ciò che la pagina mostra. Correggi dati errati e campi obbligatori mancanti. Superare il test rende la pagina idonea per le funzionalità supportate, ma non assicura che Google le mostri.

Quali problemi correggere prima?

Riunisci le segnalazioni che dipendono dallo stesso template o dalla stessa regola. Per stabilire l’ordine degli interventi, chiediti quali pagine sono coinvolte, che cosa non funziona e quanto è certa la diagnosi. Concorda poi con lo sviluppatore tempi, modifiche necessarie e possibili effetti sulle altre pagine. Un errore che esclude un servizio importante da Google può avere la precedenza su molti avvisi relativi a duplicati che il sito gestisce già correttamente.

Ad esempio: un noindex nelle pagine dei servizi

Immaginiamo che, nei 13 URL del campione, due delle tre pagine di servizio rispondano con 200 ma contengano <meta name="robots" content="noindex">. La terza non ha questa direttiva e tutte e tre dovrebbero poter comparire su Google.

Nel registro riporta i due URL, la riga HTML e la data del controllo. Chiedi al tecnico di confrontare il modello e le impostazioni di quelle pagine con il terzo servizio. Hai trovato il problema in due dei tre servizi esaminati: per sapere quali altri URL coinvolge, controlla le pagine generate dalla stessa regola, comprese quelle che devono invece restare escluse.

Dopo la correzione, verifica che le due pagine rispondano con 200, mostrino il contenuto previsto e abbiano il canonical corretto. Il noindex deve essere assente da HTML iniziale, DOM e intestazioni. Ripeti il test anche sul terzo servizio e su una pagina volutamente esclusa, per accertarti che la modifica non ne abbia cambiato il comportamento. Lo stato nell’indice di Google andrà verificato separatamente in Search Console.

Come consegnare i risultati al tecnico?

Prepara una scheda per ogni problema, indicando gli URL su cui l’hai riscontrato e il template o la regola che li accomuna. Allega intestazioni, HTML o screenshot con data e strumento usato. Descrivi prima ciò che hai osservato e poi la causa da verificare. Aggiungi il risultato atteso, chi deve intervenire e il test da ripetere dopo la modifica. Conserva anche qualche controllo riuscito: ti servirà per capire se la correzione ha introdotto nuovi errori.

Quando la correzione richiede di leggere i log, cambiare il CMS o gestire una pubblicazione, coinvolgi chi ha accesso a quei sistemi. Puoi affidare l’analisi e il coordinamento degli interventi alla consulenza SEO tecnica. Se il sito deve cambiare dominio o piattaforma, usa anche la checklist di migrazione SEO per preparare la mappatura degli URL, i redirect e i controlli al lancio.

Come verificare una correzione dopo il rilascio?

1. Ripeti il test sulla versione online

   Annota quando è stata pubblicata la modifica ed esegui lo stesso comando o percorso sugli URL controllati prima. Confronta i risultati con quelli attesi: la correzione deve funzionare sul sito pubblico, anche se era già stata provata nell’ambiente di test.

2. Controlla anche le altre pagine

   Ripeti il test su una pagina che funzionava correttamente e su quelle volutamente escluse, così da verificare che la modifica non le abbia alterate. Se sono cambiate le destinazioni, aggiorna anche sitemap e link. Quando l’errore può ripresentarsi con una regola condivisa, chiedi al tecnico di aggiungere un controllo automatico prima delle pubblicazioni successive.

3. Verifica quando Google legge la modifica

   In Search Console esegui il test dell’URL pubblicato e richiedi una nuova indicizzazione per le pagine che hai corretto e vuoi rendere visibili. In seguito controlla la data dell’ultima scansione, lo stato nell’indice e il canonical scelto da Google. La richiesta non assicura tempi o inclusione: la guida sui tempi dei risultati SEO spiega come distinguere questi passaggi dalla crescita delle visite.

Quando i test sul sito pubblico confermano la correzione, segnala nel registro che l’intervento tecnico è concluso. Se Google non ha ancora riletto la pagina, lascia aperta soltanto quella verifica. Se il problema ricompare, aggiorna la stessa scheda con la nuova prova e la data della modifica dopo cui l’hai osservato.