Come Condurre un Audit SEO Tecnico: Framework 2026

La maggior parte degli audit SEO tecnici sono report superficiali generati da Screaming Frog spacciati per strategia. Qualcuno lancia una crawllata, esporta un foglio con 4.000 righe, evidenzia le celle rosse e lo chiama audit.

È un report, non un audit.

Un vero audit SEO tecnico parte da una domanda: perché questo sito non performa come dovrebbe? E risponde a quella domanda analizzando segnali che i tool di crawl si perdono completamente — server log, dati di performance reale a livello di pagina, flusso dell’equity attraverso i link interni, e come Googlebot si comporta davvero sul sito rispetto a come pensi che lo faccia.

Dopo 18 anni che faccio questo lavoro, posso dirti che le scoperte ad alto impatto arrivano esattamente da quelle fonti. Non dalla lista di 400 righe con le meta description oltre i 160 caratteri.

Questa guida copre il framework completo che utilizzo. Non è generica. Contiene dettagli specifici che ti faranno risparmiare tempo significativo o ti aiuteranno a vedere problemi nel tuo sito che finora ti sono sfuggiti.

Perché il SEO Tecnico È le Fondamenta

Contenuti e link sono i due fattori di ranking più citati nel SEO. Entrambi richiedono una base tecnica funzionante per avere valore.

Prendi un sito con 200 articoli di alta qualità e 500 referring domain. Se Googlebot non riesce a fare il crawl del 30% del sito a causa di regole robots.txt configurate male, quei contenuti per Google non esistono. Se i tag canonical sono implementati in modo errato su un catalogo prodotti, l’equity dei link che punta a quelle pagine viene diluito su URL duplicati. Se i Core Web Vitals sono abbastanza scarsi da attivare i segnali di page experience di Google, ranking che dovrebbero essere in posizione 3 si ritrovano in posizione 8.

Il SEO tecnico non è glamour. I clienti lo chiedono raramente perché non puoi spiegare facilmente come appare la correzione di una catena di redirect. Ma in ogni account che ho rilevato e che era sotto-performante, il debito tecnico contribuiva al gap. Sempre.

Prima sistema le fondamenta tecniche. Poi costruisci sopra.

Il Problema degli Audit Basati Solo sui Tool di Crawl

Screaming Frog, Sitebulb e tool di crawl simili sono essenziali. Li uso in ogni audit. Ma hanno una limitazione fondamentale: simulano come un crawler potrebbe visitare il tuo sito, non come Googlebot lo visita realmente.

L’analisi dei server log ti dice cosa ha fatto Googlebot davvero. La differenza è significativa.

Con i server log puoi rispondere a domande che nessun tool di crawl può darti:

Quali pagine sta visitando Googlebot, e con quale frequenza?
Googlebot sta spendendo il suo crawl budget su pagine che contano?
Ci sono pagine che non ricevono alcuna visita da Googlebot nonostante siano nella sitemap?
Esiste una discrepanza tra le pagine che pensi siano importanti e le pagine che Google sta effettivamente crawlando?

Su un sito cliente — una piattaforma di notizie finanziarie — l’analisi dei server log ha rivelato che Googlebot stava spendendo il 40% del suo crawl budget su pagine di paginazione (/page/2/, /page/3/) e URL con parametri generati da un sistema di filtri. I contenuti editoriali di alto valore venivano crawlati raramente. Risolvere questo problema è stato un intervento molto più significativo di qualsiasi cosa un tool di crawl avrebbe potuto individuare.

I tool per l’analisi dei server log includono Screaming Frog Log Analyzer e Splunk per file di log più grandi. Se sei su un hosting gestito che non espone i server log, questa è una limitazione che vale la pena segnalare al tuo team di hosting.

Crawl Budget: Cos’È e Come Farne l’Audit

Il crawl budget è il numero di pagine che Googlebot crawlerà sul tuo sito in un determinato periodo di tempo. Per i siti piccoli (sotto qualche migliaio di pagine), raramente è un vincolo. Per i grandi siti ecommerce, è uno dei fattori più decisivi per capire se i nuovi contenuti vengono indicizzati tempestivamente.

Google determina il crawl budget basandosi su due elementi: il crawl rate limit (quanto velocemente Googlebot può crawlare senza sovraccaricare il tuo server) e la crawl demand (quanto sono popolari e aggiornate di recente le tue pagine). Puoi influenzare entrambi.

Per fare l’audit del crawl budget, hai bisogno di tre fonti dati che lavorano insieme.

Primo, Google Search Console. Vai su Impostazioni > Statistiche di crawl. Ti mostra quante pagine Googlebot ha crawlato al giorno negli ultimi 90 giorni, quali codici di risposta ha incontrato e quali tipi di file ha crawlato. Un sito dove il 20% delle richieste di crawl restituisce 404 sta sprecando crawl budget significativo su URL morti.

Secondo, i tuoi server log. Incrocia i dati per capire quali URL Googlebot sta visitando più frequentemente. Se sta spendendo budget su URL a basso valore (navigazione faccettata, pagine con parametri, risultati di ricerca interna), quello è crawl budget che dovrebbe essere reindirizzato verso contenuti che contano.

Terzo, la tua sitemap. La tua sitemap XML è un segnale per Google su cosa consideri importante. Se contiene pagine 404, URL con redirect o pagine noindexed, stai mandando a Google segnali confusi. Sitemap pulite che contengono solo pagine canonicalizzate, indicizzabili e con status 200 sono non negoziabili.

I killer del crawl budget più comuni che trovo sui siti ecommerce: la navigazione faccettata (di gran lunga), gli ID di sessione aggiunti agli URL, il filtraggio basato su parametri senza gestione dei canonical, e gli URL della versione stampa. Copro la navigazione faccettata in maggior dettaglio più avanti.

Core Web Vitals: La Media del Sito Non Significa Niente

I Core Web Vitals di Google sono tre metriche che misurano l’esperienza utente reale: Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS) e Interaction to Next Paint (INP, che ha sostituito FID a marzo 2024).

La maggior parte dei team sbaglia una cosa importante: controllano i Core Web Vitals a livello di dominio e riportano un punteggio unico, inutile per la diagnosi.

I Core Web Vitals vengono valutati a livello di gruppo di pagine. I segnali di page experience di Google si applicano a pattern di URL individuali, non al sito nel suo complesso. Un template di pagina prodotto con un’immagine hero che carica lentamente influenza tutte le pagine prodotto del sito. Una homepage che supera i CWV non ti aiuta se le 10.000 pagine categoria stanno fallendo.

Usa il report Core Web Vitals di Google Search Console per vedere i dati a livello di gruppo di pagine. Usa PageSpeed Insights per il test di singoli URL con dati di campo reali (dal Chrome UX Report) insieme ai dati di laboratorio.

Cosa significa ogni metrica nella pratica:

LCP (Largest Contentful Paint): Il tempo necessario affinché l’elemento visibile più grande si carichi. Target: sotto i 2,5 secondi. Le cause più comuni di un LCP scarso sono immagini hero non ottimizzate (formato sbagliato, manca l’hint di preload, servite da un CDN lento), risorse che bloccano il rendering e tempi di risposta del server lenti (TTFB oltre 800ms). Su siti Shopify e WooCommerce, gli script di terze parti caricati nel <head> sono colpevoli frequenti.

CLS (Cumulative Layout Shift): Instabilità visiva — elementi che si spostano durante il caricamento della pagina. Target: sotto 0,1. Le cause comuni includono immagini senza attributi width e height espliciti, contenuti iniettati dinamicamente above the fold e font web che causano shift del layout al caricamento. Il CLS viene spesso introdotto da network pubblicitari e banner per il consenso dei cookie che caricano dopo il rendering iniziale.

INP (Interaction to Next Paint): Reattività alle interazioni utente. Target: sotto 200ms. È la più nuova e la più difficile da sistemare. I task JavaScript lunghi che bloccano il thread principale sono la causa primaria. Su Shopify, le app che eseguono JavaScript pesante all’interazione sono colpevoli frequenti.

Sistema prima il LCP. Ha la relazione più diretta con i ranking e le correzioni più chiare.

Implementazione dei Canonical: Errori a Livello di Scala

I tag canonical dicono a Google quale versione di un URL consideri la versione “master”. Sbagliarli su larga scala significa diluire l’equity dei link su decine o centinaia di URL duplicati.

La checklist per l’audit dei canonical:

Canonical auto-referenzianti. Ogni pagina indicizzabile dovrebbe avere un tag canonical che punta a se stessa. Le pagine senza tag canonical lasciano la scelta a Google, che potrebbe selezionare un URL che non desideri.

Canonical cross-domain. Se distribuisci contenuti (syndication), o hai contenuti che appaiono su più domini, i tag canonical dovrebbero puntare alla fonte originale.

Canonical inconsistenti. Se la pagina A punta come canonical alla pagina B, ma la pagina B punta come canonical alla pagina A, hai creato un loop canonico. Google molto probabilmente li ignorerà entrambi.

Canonical in conflitto con hreflang. Se hai contenuti multilingua, i tag hreflang e i tag canonical devono essere coerenti. Un canonical che punta dalla versione spagnola di una pagina alla versione inglese dice a Google che la pagina spagnola è un duplicato di quella inglese — il che rompe il tuo targeting internazionale.

Il problema canonical specifico di Shopify. Shopify genera due URL validi per ogni prodotto: /products/product-name e /collections/collection-name/products/product-name. Shopify di default inserisce un canonical dall’URL della collezione all’URL del prodotto standalone. Questo funziona nella maggior parte dei casi, ma può creare problemi quando i prodotti appaiono in più collezioni, perché l’URL canonical deve essere coerente indipendentemente dal percorso di accesso. Copro questo argomento in maggior dettaglio nella guida completa al SEO per ecommerce.

Tool per l’audit: lancia una crawllata con Screaming Frog, esporta il report Canonical e filtra per qualsiasi canonical che non sia un URL auto-referenziante che punta a una pagina con status 200. Ogni eccezione richiede revisione manuale.

Catene di Redirect e Loop di Redirect

Una catena di redirect è quando l’URL A reindirizza all’URL B, che reindirizza all’URL C. La destinazione è corretta, ma il percorso spreca crawl budget e perde equity dei link a ogni hop.

Il PageRank (il segnale di equity dei link sottostante) passa attraverso i redirect 301, ma non al 100%. Google non ha confermato pubblicamente il tasso esatto di diluizione, ma i test di Ahrefs suggeriscono che si verifica una perdita di equity misurabile a ogni hop di redirect. Ancora più importante: se siti esterni linkano all’URL originale (A), e quell’URL ha una catena, l’equity che stanno inviando richiede due hop prima di raggiungere la pagina live.

La causa più comune delle catene di redirect: migrazioni URL non auditate. Il sito passa attraverso un redesign, si impostano i redirect da vecchio a nuovo. Poi arriva un altro redesign, e invece di aggiornare i vecchi redirect per puntare direttamente alla nuova destinazione finale, si aggiunge un ulteriore livello sopra.

Come trovarle: Screaming Frog segnalerà le catene di redirect nel suo report Redirects. Esportalo, filtra per catene di 2 o più hop, e aggiorna ciascuna per reindirizzare direttamente dall’URL originale alla destinazione finale.

I loop di redirect — dove l’URL A reindirizza a B e B reindirizza ad A — causano risposte di errore e vanno sistemati immediatamente.

Schema Markup: Quali Schema Contano Davvero

Lo schema markup è structured data leggibile dalla macchina che aiuta i motori di ricerca e i sistemi AI a capire i tuoi contenuti. Non causa direttamente un miglioramento dei ranking, ma abilita i rich results (stelle, prezzi, FAQ a fisarmonica, breadcrumb) che aumentano il click-through rate, ed è sempre più importante per la visibilità GEO e nella ricerca AI.

L’audit dello schema copre due domande: cosa è implementato, ed è implementato correttamente?

Tool di verifica: Rich Results Test di Google per pagine individuali, Schema Markup Validator (schema.org) per il controllo della sintassi, e il report Rich Results di Google Search Console per lo stato a livello di sito.

Schema da audittare per tipo di sito:

Per tutti i siti: Organization (homepage), BreadcrumbList (tutte le pagine), SiteLinks Searchbox (opzionale ma utile per la ricerca branded).

Per siti con contenuti/blog: Article o BlogPosting (con le proprietà author, datePublished, dateModified, publisher compilate), FAQPage sulle sezioni FAQ.

Per siti ecommerce: Product (con le proprietà name, description, image, sku, offers, aggregateRating), Offer (con price, priceCurrency, availability, url), AggregateRating (richiede recensioni reali — non fabbricarle).

Per attività locali: LocalBusiness con address, telephone, openingHours, geo.

Errori schema comuni che trovo negli audit: priceCurrency mancante sullo schema Offer (richiesto da Google), AggregateRating con un numero di recensioni inferiore al minimo che Google richiede per i rich results, schema FAQPage dove le risposte non corrispondono ai contenuti visibili sulla pagina, e schema Product che manca completamente della proprietà offers (rende lo schema inutile per i risultati Shopping).

Navigazione Faccettata: Il Killer #1 del Crawl Budget per l’Ecommerce

La navigazione faccettata — il sistema di filtri che permette agli utenti di navigare per colore, taglia, fascia di prezzo, brand e altri attributi — è il problema tecnico SEO più comune sui siti ecommerce con cataloghi grandi.

Il problema: ogni combinazione di filtri genera un nuovo URL. Una categoria con 200 prodotti, 5 opzioni di colore, 4 opzioni di taglia e 3 fasce di prezzo può teoricamente generare migliaia di URL unici. La maggior parte di questi contiene contenuti quasi duplicati con minimo valore unico. Googlebot li crawla comunque.

Il risultato: il crawl budget viene consumato da pagine filtro a basso valore, i segnali canonical si confondono, e le pagine categoria principali che vuoi effettivamente far rankare possono finire svalutate.

La soluzione non è semplice né universale. Dipende da quali combinazioni di filtri hanno una reale domanda di ricerca (i filtri a livello di brand spesso ce l’hanno; le combinazioni colore/taglia quasi mai per la maggior parte delle categorie).

L’approccio standard:

Usa noindex sulle combinazioni di filtri senza domanda di ricerca (le mantiene crawlabili ma fuori dall’indice)
Aggiungi tag canonical sulle pagine filtro che puntano all’URL della categoria radice
Blocca i pattern di parametri a basso valore tramite robots.txt per le pagine senza intento di ricerca
Per le combinazioni di filtri con reale domanda di ricerca (es. “scarpe da running da donna” come categoria), crea landing page ottimizzate correttamente piuttosto che affidarti agli URL generati dai filtri

L’approccio robots.txt è grezzo ma veloce. L’approccio canonical è più sfumato ma può lasciare Googlebot a crawlare pagine che non indicizzerà, consumando comunque budget. In produzione, una combinazione di entrambi è di solito la risposta giusta.

Per la gestione dettagliata specifica per ecommerce, consulta la guida al SEO per ecommerce.

Distribuzione dell’Equity dei Link Interni

I link interni trasferiscono autorità attraverso il sito. Le pagine che ricevono più link interni da pagine autorevoli rankano meglio, a parità di altre condizioni. La maggior parte dei siti distribuisce l’equity dei link interni per caso piuttosto che per design.

Le domande dell’audit:

Quali pagine sono orfane? Una pagina orfana non ha link interni che puntano verso di essa. Googlebot può trovarla solo tramite la sitemap o un link esterno. Le pagine orfane non accumulano autorità interna. Screaming Frog può identificarle facendo il crawl del sito e filtrando le pagine con zero inlink.

Qual è la profondità di crawl delle pagine prioritarie? La profondità di crawl è il numero di click dalla homepage per raggiungere una data pagina. Google usa la profondità di crawl come proxy dell’importanza — le pagine più vicine alla homepage sono considerate più significative. Le pagine prioritarie (pagine servizio core, categorie prodotto top, articoli con maggiori ricavi) dovrebbero essere raggiungibili entro 2-3 click. Se i tuoi contenuti più importanti sono seppelliti a 6 click di profondità, il linking interno ti sta tradendo.

Dove sta fluendo equity che non dovrebbe? I link nel footer, i link di navigazione e i link nella sidebar passano equity ovunque puntino. Se il tuo footer globale linka a 40 pagine diverse, ciascuno di quei link porta valore diluito. Dai priorità ai link interni nel contenuto del body — passano più equity e sono più rilevanti a livello tematico.

L’anchor text è diversificato e descrittivo? L’anchor text nei link interni segnala la rilevanza tematica. “Clicca qui” e “scopri di più” sono opportunità sprecate. Usa anchor text descrittivi che includono la keyword per cui vuoi che la pagina di destinazione ranki.

Uno strumento pratico: il report Link di Screaming Frog mostra il conteggio degli inlink per pagina. Ordina per inlink crescenti per trovare le pagine sotto-linkate. Incrocia con la tua lista di pagine prioritarie. Qualsiasi pagina prioritaria con meno di 5-10 inlink contestuali da contenuti correlati dovrebbe essere un target di linking nel tuo prossimo aggiornamento dei contenuti.

Il Framework di Azioni Prioritarie

Ogni audit SEO tecnico fa emergere più problemi di quanti qualsiasi team possa risolvere immediatamente. Il framework di azioni prioritarie trasforma una lista in un piano.

Il punteggio è semplice. Valuta ogni problema su due dimensioni:

Impatto: Quanto migliora le performance organiche risolvere questo problema? (Alto / Medio / Basso) Sforzo: Quanto tempo e risorsa tecnica richiede la risoluzione? (Alto / Medio / Basso)

Poi raggruppa in quattro categorie:

Risolvi subito (Alto Impatto / Basso Sforzo): Catene di redirect verso pagine esistenti, tag canonical mancanti su pagine chiave, sitemap XML contenente URL con redirect o 404, robots.txt che blocca accidentalmente sezioni importanti, schema mancante su pagine templated.

Pianifica per il prossimo sprint (Alto Impatto / Alto Sforzo): Ristrutturazione della navigazione faccettata, pulizia post-migrazione del sito (correzione di catene di redirect multi-hop su larga scala), correzioni Core Web Vitals che richiedono modifiche a livello di tema, analisi dei server log e riallocazione del crawl budget.

Fai quando conveniente (Basso Impatto / Basso Sforzo): Ottimizzazione meta description, modifiche ai title tag, aggiunta di alt text alle immagini per pagine non prioritarie.

Valuta il ROI (Basso Impatto / Alto Sforzo): Modifiche importanti al CMS che risolvono problemi SEO minori, ristrutturazione hreflang complessa per traffico internazionale ridotto, implementazioni schema personalizzate per tipi di pagina che non generano rich results.

La cosa più preziosa che un audit può consegnare è questa priorizzazione. La lista dei problemi è spesso prevedibile. Sapere quali tre cose produrranno il maggior impatto sui ranking nei prossimi 90 giorni è ciò che separa un audit utile da un report.

Se vuoi un audit SEO tecnico professionale condotto sul tuo sito, il servizio di audit SEO copre tutto quanto sopra più un piano di azioni prioritarie. Se cerchi una consulenza continuativa piuttosto che un audit una tantum, consulta il servizio di consulenza SEO.

Riferimenti Utili

FAQ

Cosa è incluso in un audit SEO tecnico? Un audit SEO tecnico approfondito copre il crawl budget e l’analisi dei server log, i Core Web Vitals (LCP, CLS, INP) a livello di gruppo di pagine, l’implementazione dei canonical, le catene di redirect, la precisione della sitemap XML, la configurazione del robots.txt, la validità dello schema markup, la gestione della navigazione faccettata (per siti ecommerce) e la distribuzione dell’equity dei link interni. L’output dovrebbe essere una lista di azioni prioritarie, non solo un elenco grezzo di problemi.

Quanto tempo richiede un audit SEO tecnico? Per un sito con meno di 10.000 pagine, un audit approfondito richiede tipicamente 2-4 giorni di lavoro focalizzato. Grandi siti ecommerce con 100.000+ URL, navigazione faccettata complessa e analisi dei server log possono richiedere 5-10 giorni. Il costo in tempo è concentrato all’inizio: una volta fatto l’audit, le correzioni sono task discreti che possono essere distribuiti negli sprint.

In cosa differisce un audit SEO tecnico da un audit SEO? Un audit SEO tecnico si focalizza specificamente su come è costruito un sito e su come i motori di ricerca interagiscono con esso: crawlability, indicizzazione, velocità delle pagine, structured data, configurazione canonical e architettura del sito. Un audit SEO più ampio includerebbe anche analisi della qualità dei contenuti, revisione del targeting keyword e valutazione del profilo backlink. Audit tecnici e di contenuti affrontano problemi diversi; di solito servono entrambi.

I siti piccoli hanno bisogno di un audit SEO tecnico? Sì, ma con un ambito diverso. I siti piccoli (sotto le 500 pagine) raramente hanno problemi di crawl budget o navigazione faccettata. Ma hanno problemi canonical, schema mancanti, Core Web Vitals lenti e lacune nel linking interno che influenzano i ranking. Un audit tecnico per un sito piccolo potrebbe richiedere mezza giornata anziché diversi giorni, ma saltarlo completamente significa prendere decisioni su contenuti e link su una base potenzialmente compromessa.

Quali tool servono per un audit SEO tecnico? Il toolkit minimo: Google Search Console (statistiche di crawl, report di copertura, Core Web Vitals, rich results), Screaming Frog SEO Spider (analisi del crawl, catene di redirect, audit canonical, link interni), PageSpeed Insights o Lighthouse (dati di laboratorio Core Web Vitals) e il Rich Results Test (validazione schema). Per l’analisi dei server log, Screaming Frog Log Analyzer gestisce la maggior parte dei casi d’uso. Per siti a livello enterprise, tool come Botify o Oncrawl offrono analisi dei log più avanzate con report specifici per il SEO.

Con quale frequenza dovresti fare un audit SEO tecnico? Per siti attivi che pubblicano regolarmente o fanno frequenti modifiche ai template, un audit di crawl leggero mensile più un audit completo ogni 6 mesi è una cadenza ragionevole. Ogni volta che un sito subisce un cambiamento significativo — migrazione, redesign, cambio di CMS, grande ristrutturazione URL — un audit tecnico completo prima e dopo il cambiamento è non negoziabile.

Cos’è il crawl budget e perché è importante? Il crawl budget è il numero di pagine che Googlebot crawlerà sul tuo sito in un dato periodo. Per la maggior parte dei siti piccoli non è una preoccupazione pratica. Per grandi siti ecommerce con decine di migliaia di URL, la capacità di crawl di Googlebot è finita, e se viene consumata da pagine con parametri a basso valore, paginazione o combinazioni di filtri, i nuovi contenuti importanti potrebbero non essere indicizzati tempestivamente. Il crawl budget è più rilevante su siti con 10.000+ pagine, pubblicazione frequente di contenuti e strutture URL complesse generate da sistemi di filtraggio.

Informazioni sull’Autore Sono un SEO e Growth Consultant indipendente con 18 anni di esperienza. Fondatore di SameAPI e DeLeak.co. Prenota una chiamata strategica →