Michele Eccher
In questa guida
Un audit SEO tecnico deve verificare se le pagine che contano possono essere scoperte, scansionate, renderizzate, comprese e indicizzate correttamente. Deve poi individuare il sistema all’origine di ogni errore e ordinare gli interventi in base all’impatto sul business, all’estensione del problema, alla solidità della diagnosi e al rischio di implementazione. Il risultato è un piano d’azione che può essere testato, implementato e verificato, non un foglio di calcolo pieno di avvisi.
Gli strumenti di SEO tecnica sanno individuare anomalie come un redirect, un canonical mancante, un template lento o una pagina assente dalla scansione. Non possono però stabilire da soli se quell’URL debba esistere, se abbia valore commerciale o se l’anomalia rilevata sia davvero la causa della perdita di visibilità. L’audit aggiunge il contesto necessario.
Sintomo rilevato
Causa e pagine coinvolte
Impatto e rischio del rilascio
Risultato atteso in produzione
Definisci il comportamento atteso del sito prima di iniziare i controlli
Un audit ha bisogno di criteri di riferimento. Parti da prodotti, servizi, mercati e tipologie di pagina che il sito deve supportare. Stabilisci quali URL devono essere indicizzabili, quali esistono soltanto per gli utenti o per funzioni interne e quali devono confluire in un’altra pagina canonica. Senza queste decisioni, la stessa scansione può generare un lungo elenco di raccomandazioni tecnicamente corrette ma inutili per l’azienda.
Definisci il perimetro aziendale
Elenca le tipologie di pagina che intercettano la domanda o accompagnano la conversione. Annota Paesi e lingue prioritari, dispositivi, disponibilità dei prodotti, contenuti soggetti a vincoli e limiti della piattaforma che possono incidere sull’implementazione.
Costruisci un campione rappresentativo di URL
Includi esempi efficaci e problematici per ogni template importante, non soltanto la home page. Aggiungi pagine recenti e datate, varianti con parametri, URL reindirizzati ed esclusioni note, così da confrontare il comportamento previsto con quello reale.
Registra rilasci ed eventi esterni
Metti in relazione le variazioni di traffico con rilasci, migrazioni, rimozioni di contenuti, modifiche al tracciamento, azioni manuali, incidenti di sicurezza, stagionalità e aggiornamenti importanti dei motori di ricerca. La coincidenza temporale non dimostra la causa, ma restringe il campo dell’indagine.
Verifica quali dati sono disponibili
Combina Search Console, analytics, dati di scansione e la risposta del sito online. Quando la complessità del sito o del problema lo richiede, aggiungi log del server, codice sorgente, monitoraggio delle prestazioni e accesso all’ambiente di staging.
Google descrive la ricerca come una sequenza di scansione, indicizzazione e pubblicazione dei risultati. In ogni fase una pagina può fallire o assumere un significato diverso. La spiegazione ufficiale sul funzionamento della Ricerca Google offre un modello diagnostico utile, perché evita di interpretare ogni assenza come un problema di posizionamento.
Verifica come vengono scoperti e richiesti gli URL importanti
La fase di scoperta verifica se un crawler può scoprire l’esistenza di un URL; la scansione verifica invece se può richiederlo e ricevere una risposta utile. Servono entrambi i controlli. Una pagina può restituire un codice 200 quando viene aperta direttamente e rimanere comunque quasi invisibile perché nessun link la rende raggiungibile. Può accadere anche il contrario: un sito può generare attraverso i filtri milioni di URL raggiungibili dai crawler, ma privi di un reale motivo per entrare nell’indice.
| Area di verifica | Dati da controllare | Domanda a cui rispondere |
|---|---|---|
| Risposte HTTP | Codici di stato, destinazioni dei redirect, catene, cicli e comportamento delle soft 404 | Ogni URL restituisce una risposta coerente con il suo stato reale? |
| robots.txt | Regole in produzione, accesso alle risorse, gruppi di user agent e schemi bloccati | Le pagine e le risorse utili sono scansionabili senza generare sprechi? |
| Sitemap XML | URL canonici, date di ultima modifica, codici di stato e indicizzabilità | I file rappresentano l’insieme attuale degli URL preferiti? |
| Scoperta interna | Link HTML, profondità di clic, possibili pagine orfane, paginazione e stati della navigazione | I crawler possono raggiungere le pagine importanti attraverso link stabili? |
| Insieme degli URL | Parametri, filtri, calendari, risultati di ricerca interni, ID di sessione e percorsi duplicati | Il sito sta creando più URL scansionabili di quanti siano quelli realmente utili? |
| Affidabilità del server | Log, risposte 5xx, andamenti della latenza e statistiche di scansione | Il sito resta disponibile e reattivo quando i crawler lo visitano? |
Una sitemap facilita la scoperta e comunica gli URL canonici preferiti, ma non garantisce né la scansione né l’indicizzazione. Le indicazioni di Google sulle sitemap raccomandano di usare URL canonici completi. L’audit deve quindi confrontare la sitemap con il sito online, invece di considerare sufficiente un file XML formalmente valido che contiene redirect, errori o pagine non canoniche.
Analizza esclusioni e scelte canoniche a livello di template
L’indicizzazione è selettiva. La domanda utile non è «Come facciamo a indicizzare ogni URL?», ma «I motori di ricerca scelgono in modo coerente le pagine con cui vogliamo competere?». Per ogni famiglia di URL importante, confronta l’URL canonico dichiarato, quello scelto da Google, le direttive di indicizzazione, la presenza nella sitemap, i link interni e la somiglianza dei contenuti.
Controlla i meta tag robots e le intestazioni X-Robots-Tag sia nella risposta iniziale sia nel documento renderizzato. Verifica che gli URL bloccati non si affidino a una direttiva noindex che Google non può scansionare e leggere.
Confronta destinazioni dei redirect, annotazioni rel="canonical", presenza nella sitemap e link interni. Segnali in conflitto rendono meno chiara la pagina preferita e complicano la misurazione.
Esamina filtri, versioni di stampa, varianti locali, paginazione, parametri di tracciamento e contenuti ripetuti. Decidi se ogni versione debba restare distinta, confluire in un’altra pagina o essere rimossa.
Analizza soft 404, stati vuoti, prodotti scaduti, template con contenuti insufficienti e pagine il cui contenuto utile dipende da una richiesta che può fallire o da un’interazione dell’utente.
Le annotazioni rel="canonical" esprimono una preferenza. Google può scegliere un URL rappresentativo diverso quando gli altri segnali indicano un’altra direzione. La documentazione aggiornata sulla canonicalizzazione spiega che redirect, presenza nella sitemap, annotazioni rel="canonical" e altri segnali di indicizzazione contribuiscono alla scelta. Documenta l’intero gruppo di URL invece di correggere un singolo tag in modo isolato.
Confronta la risposta iniziale con la pagina ricevuta da utenti e crawler
I siti moderni possono affidare a JavaScript titoli, tag canonical, link e contenuti principali. Google è in grado di eseguire JavaScript, ma il rendering aggiunge un ulteriore passaggio che può fallire, restare in attesa di una risorsa o produrre un risultato diverso dall’HTML iniziale. Verifica il DOM renderizzato e le condizioni di rete necessarie per generarlo.
Controlla l’HTML iniziale
Prima dell’esecuzione lato client, verifica codice di stato, titolo, direttive robots, URL canonico, lingua e contenuti essenziali. Controlla che cosa rimane disponibile se uno script o una richiesta API falliscono.
Controlla il DOM renderizzato
Confronta contenuti finali, link, metadati e dati strutturati. Cerca tag duplicati, pagine vuote, errori di routing ritardati e contenuti nascosti dietro interazioni che un crawler non eseguirà.
Verifica risorse e API
Esamina script bloccati, richieste non riuscite, autenticazione, timeout ed errori del browser. La struttura vuota di una pagina può restituire un codice 200 e mostrare comunque uno stato di errore o nessun contenuto indicizzabile.
Verifica il comportamento dei link
Le destinazioni importanti devono essere collegate con link HTML scansionabili e URL stabili. Verifica routing lato client, gestione della cronologia e controlli della navigazione a faccette, senza presumere che un elemento di navigazione visibile generi automaticamente un link scopribile.
La guida di Google alla SEO per JavaScript descrive scansione, rendering e indicizzazione come fasi distinte. Avverte inoltre che una direttiva noindex presente nella pagina iniziale può impedire l’elaborazione della successiva modifica eseguita da JavaScript. L’audit deve verificare il risultato effettivo, non dedurre il comportamento dei motori di ricerca soltanto dal framework utilizzato.
Analizza le relazioni tra le pagine, non soltanto i singoli URL
L’architettura del sito chiarisce quali contenuti appartengono allo stesso insieme, quali pagine sono centrali e come gli utenti passano da un’esigenza ampia a una risposta specifica. Una pagina tecnicamente raggiungibile può comunque essere poco integrata: occorre osservare i percorsi, le etichette e il ruolo delle pagine che la circondano.
| Sistema | Che cosa verificare | Problema ricorrente |
|---|---|---|
| Gerarchia delle informazioni | Sezioni, categorie, relazioni gerarchiche tra le pagine e convenzioni degli URL | Le pagine sono raggruppate secondo la comodità del CMS invece che in base alle esigenze del pubblico. |
| Navigazione | Percorsi di navigazione principali, contestuali, nel footer e da mobile | Le pagine importanti scompaiono da mobile o dopo una riprogettazione. |
| Link interni | Pertinenza della destinazione, contesto dell’anchor text, posizione e link non funzionanti | I link compaiono soltanto in moduli generati automaticamente o usano ovunque testi poco descrittivi. |
| Navigazione a faccette | Combinazioni utili, controllo della scansione, canonical e pagine senza risultati | Combinazioni illimitate di URL disperdono la scansione e rendono i report meno leggibili. |
| Paginazione e archivi | Link agli elementi scopribili, URL stabili e stati di pagina coerenti | Resta raggiungibile soltanto il primo gruppo di prodotti o articoli. |
| Varianti internazionali | Completezza linguistica, canonical autoreferenziali, versioni alternative e link reciproci | I segnali relativi alle lingue alternative puntano a redirect o pagine non tradotte. |
Valuta l’architettura per template e percorso. Una profondità di clic media calcolata sull’intero sito può nascondere una categoria di valore che ha perso tutti i link contestuali. Allo stesso modo, il numero dei link non funzionanti non rivela se gli errori si trovano in un archivio obsoleto o nel percorso principale di acquisto. Segmenta i dati prima di interpretarli.
Distingui i problemi degli utenti dai requisiti di idoneità e dalle supposizioni sul posizionamento
Prestazioni, dati strutturati e usabilità su dispositivi mobili rientrano in un audit tecnico, ma portano a conclusioni diverse. Un’interazione lenta è un problema per l’utente. Dati strutturati non validi possono far perdere l’idoneità a una specifica funzionalità dei risultati di ricerca. Nessuno dei due problemi deve essere trasformato automaticamente nella promessa di un miglior posizionamento.
Prestazioni misurate su utenti reali
Segmenta per template e dispositivo i dati raccolti su utenti reali. Usa i test di laboratorio per individuare la causa, quindi verifica dopo il rilascio se il problema percepito dagli utenti è realmente migliorato.
Mobile e accessibilità
Verifica coerenza dei contenuti, comportamento del viewport, dimensioni delle aree toccabili, compilazione dei moduli e navigazione. I controlli automatici devono portare a test diretti dell’interazione coinvolta.
Dati strutturati
Confronta i markup supportati con i contenuti visibili e con i requisiti di idoneità. Rimuovi entità fuorvianti o duplicate invece di aggiungere dati strutturati a ogni template.
Gli attuali Core Web Vitals di Google sono LCP, INP e CLS e misurano caricamento, reattività e stabilità visiva. Le indicazioni ufficiali sui Core Web Vitals raccomandano di offrire una buona esperienza agli utenti e spiegano le relative soglie. Usa queste metriche come riferimento per l’esperienza, senza lasciare che un punteggio verde metta in secondo piano problemi più gravi di accesso, indicizzazione o conversione.
Definisci le priorità in base al risultato, al sistema coinvolto e alla solidità della diagnosi
Basarsi sul numero di segnalazioni dà troppo peso al rumore. Un metodo migliore chiarisce quale dovrebbe essere il risultato, quante pagine di valore sono coinvolte, quanto sono solide le prove sulla causa e che cosa potrebbe andare storto durante la correzione. Valuta esplicitamente queste dimensioni, poi usa il giudizio professionale per stabilire l’ordine dei rilasci.
| Dimensione | Domanda | Dati |
|---|---|---|
| Valore per l’azienda | Il problema coinvolge pagine legate alla domanda, al fatturato o a un percorso critico? | Ruolo della pagina, traffico qualificato, conversioni, disponibilità e priorità strategica |
| Gravità tecnica | Blocca la scoperta o l’indicizzazione oppure riduce la qualità senza impedirle? | Risposta, rendering, direttive, URL canonico selezionato e comportamento in produzione |
| Estensione del problema | Riguarda un solo URL, un template riutilizzato o uno schema di URL fuori controllo? | Campioni rappresentativi, segmentazione della scansione, log e inventario dei template |
| Solidità della diagnosi | Il team riesce a riprodurre il problema e a collegarlo alla causa ipotizzata? | Test controllati, esempi prima e dopo l’intervento e più fonti di dati |
| Impegno richiesto e rischio | Quali dipendenze, rischi di rilascio e modalità di rollback vanno considerati? | Stima tecnica, responsabilità della piattaforma, test e processo di rilascio |
Priorità critica
Un problema confermato in produzione blocca o rimuove pagine importanti, compromette una migrazione oppure espone a una perdita immediata un template che comprende molte pagine di valore. Assegna subito un responsabile e un piano di contenimento.
Priorità alta
Un problema di sistema riproducibile coinvolge un gruppo significativo di pagine e ha un risultato atteso chiaro. Inseriscilo nel primo rilascio utile con test di regressione.
Priorità media
Il problema è reale ma circoscritto, la diagnosi è meno solida oppure la soluzione dipende da una modifica più ampia del prodotto. Conserva le prove e pianifica la correzione insieme agli interventi correlati.
Priorità bassa o accettata
Secondo i dati disponibili, il problema incide poco, corrisponde a un’eccezione voluta oppure costerebbe più correggerlo in sicurezza che lasciarlo invariato. Documenta la decisione e la condizione che farà scattare un nuovo controllo.
Documenta ogni problema in modo che possa essere corretto senza ambiguità
L’audit è completo quando il team può intervenire senza procedere per ipotesi e verificare il risultato senza ripetere l’intera indagine. Una segnalazione ben documentata è più utile di molte righe che descrivono lo stesso problema di template.
Se l’audit precede un cambio di dominio, CMS o struttura degli URL, usa la checklist per la migrazione SEO per trasformare i risultati in controlli su redirect, ambiente di test, lancio e monitoraggio. Se il lavoro richiede interventi tecnici continuativi e una responsabilità chiara sui rilasci, valuta la consulenza SEO tecnica di Qreativa prima di assegnare le responsabilità.
Definisci il risultato atteso
Descrivi come dovrebbe comportarsi quella tipologia di pagina per gli utenti e per i motori di ricerca. Specifica la risposta HTTP, l’URL canonico atteso, il contenuto renderizzato o il comportamento previsto sul piano delle prestazioni.
Documenta il problema con prove riproducibili
Includi URL rappresentativi, comandi o passaggi di test, eventuali screenshot, data dell’osservazione e fonte dei dati. Distingui i fatti confermati dalla causa probabile.
Individua la logica che genera il problema
Individua il componente, il template, la regola del CMS o il comportamento di routing all’origine del problema. Elenca le eccezioni note invece di chiedere agli sviluppatori di modificare gli URL di esempio uno alla volta.
Assegna responsabilità e condizioni di rilascio
Indica il team responsabile, le dipendenze, i criteri di accettazione, l’ambiente di test, le modalità di rollback e il rilascio in produzione che dovrà contenere la modifica.
Verifica il risultato in produzione
Ripeti lo stesso test dopo il rilascio, controlla un campione rappresentativo e monitora i dati di ricerca pertinenti. Chiudi il problema soltanto quando lo stato atteso è confermato in produzione.
Aggiungi controlli di regressione quando una regola può smettere di funzionare. Test sui template, convalida della sitemap, monitoraggio delle variazioni dei codici di stato e scansioni a campione dopo ogni rilascio prevengono spesso più danni di un altro audit completo. Le indicazioni generali di Google sulla manutenzione SEO sottolineano inoltre l’importanza di comprendere il processo di scansione e indicizzazione, mantenere accessibili le risorse necessarie e usare il controllo corretto a seconda che si voglia intervenire sulla scansione o sull’indicizzazione.
Un buon audit SEO tecnico rende il sito più facile da comprendere e gestire. Spiega perché un problema conta, dove nasce, chi può correggerlo e come verificare che la soluzione abbia funzionato. È questa chiarezza a trasformare l’analisi tecnica in rilasci più sicuri e in una base più affidabile per la visibilità organica.
Domande frequenti sull’audit SEO tecnico
Che cos’è un audit SEO tecnico?
Un audit SEO tecnico verifica se le pagine importanti possono essere scoperte, scansionate, renderizzate, interpretate, indicizzate e mantenute correttamente nel tempo. Collega dati di ricerca, risultati della scansione e dettagli dell’implementazione ai template o ai sistemi che generano ogni problema, trasformando l’analisi in un piano d’intervento ordinato e verificabile.
Ogni quanto conviene eseguire un audit SEO tecnico?
Non esiste una frequenza valida per tutti. Un audit è opportuno prima di una migrazione o di un cambiamento importante della piattaforma, dopo un calo significativo di traffico o un problema di indicizzazione e quando il sito ha accumulato criticità strutturali. Per i siti stabili sono più utili un monitoraggio mirato e controlli sui rilasci rispetto alla ripetizione periodica dello stesso audit generale.
Quali strumenti servono per un audit SEO tecnico?
Nella maggior parte degli audit servono Google Search Console, una piattaforma di analytics, un crawler e l’accesso al sito online. Per siti grandi o complessi possono essere necessari anche log del server, test di rendering, dati sulle prestazioni, codice sorgente, ambiente di staging e dati su prodotti o fatturato. Gli strumenti vanno scelti in base al problema da diagnosticare: esportare ogni report disponibile raramente rende l’analisi più precisa.
Un punteggio elevato assegnato da un tool di audit indica che il sito è in salute?
No. I punteggi riassumono molti controlli in un solo numero e spesso assegnano un peso simile a URL e regole molto diversi. Un sito può ottenere un buon risultato anche se un template strategico è bloccato, oppure un punteggio basso perché migliaia di URL con parametri generano avvisi irrilevanti. Bisogna valutare la tipologia di pagina coinvolta, il suo valore per l’azienda e le prove alla base di ogni problema.
Bisogna correggere ogni segnalazione tecnica SEO?
No. Alcune segnalazioni descrivono scelte progettuali corrette, duplicati di scarso valore o condizioni che non incidono sui risultati organici. Conviene intervenire quando i dati mostrano che il problema impedisce un risultato atteso, crea un rischio evitabile o produce continuamente inefficienze. Le eccezioni accettate vanno documentate, così non ricompaiono senza contesto a ogni audit.
Un audit SEO tecnico può garantire un miglior posizionamento?
No. Un audit può rimuovere ostacoli tecnici e rendere più semplice l’elaborazione delle pagine importanti, ma il posizionamento dipende anche da pertinenza, utilità, concorrenza, reputazione, domanda e altri segnali. Un audit serio definisce il risultato tecnico atteso e il metodo per verificarlo, senza trasformare questa previsione in una garanzia di posizionamento.
Che cosa deve contenere il documento finale di un audit SEO tecnico?
Ogni problema su cui intervenire dovrebbe includere prove, famiglie di URL coinvolte, contesto aziendale, probabile causa, risultato atteso, indicazioni per l’implementazione, responsabile, dipendenze e metodo di verifica. Il piano finale deve raggruppare le criticità per sistema o template e distinguere i blocchi urgenti dai miglioramenti che possono attendere.
