La maggior parte degli audit SEO tecnici sono report superficiali di Screaming Frog travestiti da strategia. Qualcuno fa un crawl, esporta un foglio di calcolo con 4.000 righe, evidenzia le celle rosse e chiama il tutto “audit”.
Non è un audit. È un report.
Un audit SEO tecnico vero inizia con una domanda: perché questo sito non performa quanto dovrebbe? E risponde a quella domanda guardando segnali che gli strumenti di crawl non vedono affatto: log del server, dati di performance reale degli utenti a livello di pagina, flusso di equity attraverso i link interni e come Googlebot si comporta davvero sul sito rispetto a come pensi che si comporti.
Dopo 18 anni di questo lavoro, posso dirti che i risultati ad alto impatto vengono esattamente da quei posti. Non dall’elenco di 400 righe di meta description sopra i 160 caratteri.
Questa guida copre il framework completo che uso. Non è generico. Contiene specifiche che ti faranno risparmiare molto tempo o ti aiuteranno a vedere problemi nel tuo sito che stai trascurando.
Perché la SEO tecnica è la fondamenta
Contenuto e link sono i due fattori di ranking più citati nella SEO. Entrambi richiedono una base tecnica funzionante per dare qualsiasi valore.
Immagina un sito con 200 articoli di alta qualità e 500 domini di riferimento. Se Googlebot non riesce a crawlare il 30% del sito a causa di regole robots.txt mal configurate, quei contenuti non esistono per Google. Se i tag canonical sono implementati in modo errato su un catalogo prodotto, l’equity dei link che puntano a quelle pagine viene diluita su URL duplicati. Se i punteggi Core Web Vitals sono abbastanza scadenti da innescare i segnali di page experience di Google, posizionamenti che dovrebbero essere alla posizione 3 si trovano alla posizione 8.
La SEO tecnica non è affascinante. I clienti raramente la chiedono perché non è facile spiegare com’è fatto il fix di una catena di redirect. Però in ogni account che ho preso in gestione che underperformava, il debito tecnico stava contribuendo al gap. Sempre.
Correggi prima la base tecnica. Poi costruisci sopra.
Il problema degli audit solo con strumenti di crawl
Screaming Frog, Sitebulb e strumenti simili sono essenziali. Li uso in ogni audit. Però hanno un limite fondamentale: simulano come un crawler potrebbe visitare il tuo sito, non come lo visita davvero Googlebot.
L’analisi dei log del server ti dice cosa ha fatto davvero Googlebot. La differenza è significativa.
Dai log del server puoi rispondere a domande che nessuno strumento di crawl può fare:
- 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 di Googlebot nonostante siano nella sitemap?
- C’è una discrepanza tra le pagine che ritieni importanti e le pagine che Google sta effettivamente crawlando?
Su un sito cliente, una piattaforma di notizie finanziarie, l’analisi dei log ha rivelato che Googlebot stava spendendo il 40% del suo crawl budget su pagine di paginazione (/page/2/, /page/3/) e URL di parametri generati da un sistema di filtri. Il contenuto editoriale di alto valore veniva crawlato raramente. Correggere questo è stato un intervento più significativo di qualsiasi cosa avrebbe portato a galla uno strumento di crawl.
Strumenti per l’analisi dei log: Screaming Frog Log Analyzer e Splunk per file di log più grandi. Se sei su un host gestito che non espone i log del server, questo è un limite che vale la pena sollevare con il team di hosting.
Crawl budget: cos’è e come fare l’audit
Il crawl budget è il numero di pagine che Googlebot crawlerà sul tuo sito in un dato periodo di tempo. Per siti piccoli (sotto qualche migliaio di pagine), è raramente un vincolo. Per siti ecommerce grandi, è uno dei fattori più determinanti per la rapidità con cui i nuovi contenuti vengono indicizzati.
Google determina il crawl budget in base a due cose: limite di velocità di crawl (quanto velocemente Googlebot crawla senza sovraccaricare il server) e domanda di crawl (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 di dati che lavorano insieme.
Prima, Google Search Console. Vai su Impostazioni > Statistiche di crawl. 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 in cui il 20% delle richieste di crawl restituisce 404 sta sprecando crawl budget significativo su URL morti.
Seconda, i log del server. Verifica incrociata con quali URL Googlebot sta visitando più frequentemente. Se sta spendendo budget su URL a basso valore (navigazione a faccette, pagine di parametri, risultati di ricerca interni), è crawl budget che dovrebbe essere reindirizzato verso contenuti che contano.
Terza, la sitemap. La sitemap XML è un segnale per Google su cosa consideri importante. Se contiene pagine 404, URL reindirizzati o pagine noindex, stai inviando a Google segnali confusi. Le sitemap pulite che contengono solo pagine canonical, indicizzabili e con status 200 sono indispensabili.
I principali killer del crawl budget che trovo nei siti ecommerce: la navigazione a faccette (di gran lunga), gli ID di sessione aggiunti agli URL, il filtraggio basato su parametri senza gestione canonical, e gli URL della versione stampabile. Tratto la navigazione a faccette in modo più dettagliato di seguito.
Core Web Vitals: la media del sito non significa nulla
I Core Web Vitals di Google sono tre metriche che misurano l’esperienza reale degli utenti: Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS) e Interaction to Next Paint (INP, che ha sostituito il FID nel marzo 2024).
Ecco la cosa critica che la maggior parte dei team sbaglia: controllano i Core Web Vitals a livello di dominio e riportano un singolo punteggio. È 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 singoli pattern URL, non al sito nel suo complesso. Un template di pagina prodotto con un’immagine hero che si carica lentamente impatta ogni pagina 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 dei singoli URL con dati di campo reali degli utenti (dal Chrome UX Report) insieme ai dati di laboratorio.
Cosa significa in pratica ogni metrica:
LCP (Largest Contentful Paint): Il tempo fino al caricamento dell’elemento visibile più grande. Obiettivo: sotto 2,5 secondi. Le cause più comuni di LCP scarso sono immagini hero non ottimizzate (formato sbagliato, hint di precaricamento mancante, servite da un CDN lento), risorse che bloccano il rendering e tempi di risposta del server lenti (TTFB sopra 800 ms). Sui siti Shopify e WooCommerce, gli script di terze parti caricati nel <head> sono spesso i responsabili.
CLS (Cumulative Layout Shift): Instabilità visiva: elementi che saltano mentre la pagina si carica. Obiettivo: sotto 0,1. Le cause comuni includono immagini senza attributi width e height espliciti, contenuto iniettato dinamicamente above the fold, e web font che causano layout shift al caricamento. Il CLS viene spesso introdotto da reti pubblicitarie e banner di consenso ai cookie che si caricano dopo il rendering iniziale.
INP (Interaction to Next Paint): Reattività alle interazioni dell’utente. Obiettivo: sotto 200 ms. È il più recente e il più complicato da correggere. I task JavaScript lunghi che bloccano il thread principale sono la causa principale. Su Shopify, le app che eseguono JavaScript pesante sull’interazione sono spesso le responsabili.
Correggi prima l’LCP. Ha la relazione più diretta con i posizionamenti e le correzioni più praticabili.
Implementazione dei canonical: errori a livello di scala
I tag canonical dicono a Google quale versione di un URL consideri la versione “master”. Sbagliare a livello di scala significa diluire l’equity dei link su decine o centinaia di URL duplicati.
La checklist dell’audit canonical:
Canonical autoreferenziali. Ogni pagina indicizzabile dovrebbe avere un tag canonical che punta a se stessa. Le pagine senza canonical lasciano la scelta a Google, che potrebbe selezionare un URL che non vuoi.
Canonical cross-domain. Se sindichi contenuti, o hai contenuti che appaiono su più domini, i tag canonical dovrebbero puntare alla fonte originale.
Canonical incoerenti. Se la pagina A punta canonical alla pagina B, ma la pagina B punta canonical alla pagina A, hai creato un loop canonical. Google probabilmente ignorerà entrambe.
Canonical in conflitto con hreflang. Se hai contenuti multilingue, i tag hreflang e canonical devono essere coerenti. Un canonical che punta dalla versione spagnola di una pagina a quella inglese dice a Google che la pagina spagnola è un duplicato di quella inglese, il che rompe il targeting internazionale.
Il problema canonical specifico di Shopify. Shopify genera due URL validi per ogni prodotto: /products/nome-prodotto e /collections/nome-collection/products/nome-prodotto. Shopify canonicalizza l’URL del percorso collection verso l’URL del prodotto standalone per impostazione predefinita. Questo funziona per lo più, però può creare problemi quando i prodotti appaiono in più collection, perché l’URL canonical deve essere coerente indipendentemente dal percorso di ingresso. Approfondisco questo nella guida SEO ecommerce completa.
Strumento per l’audit: esegui un crawl con Screaming Frog, esporta il report Canonical e filtra per qualsiasi canonical che non sia un URL autoreferenziale che punta a una pagina con status 200. Ogni eccezione necessita di revisione manuale.
Catene di redirect e loop di redirect
Una catena di redirect si ha quando l’URL A reindirizza all’URL B, che reindirizza all’URL C. La destinazione è corretta, però il percorso spreca crawl budget e perde equity dei link ad ogni hop.
Il PageRank (il segnale di equity dei link sottostante) passa attraverso i redirect 301, però non al 100%. Google non ha confermato pubblicamente il tasso esatto di diluizione, però i test di Ahrefs suggeriscono una perdita di equity misurabile ad 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 fa due hop prima di raggiungere la pagina live.
La causa più comune delle catene di redirect: migrazioni URL non verificate. Il sito passa attraverso un redesign, vengono impostati i redirect da vecchio a nuovo. Poi avviene un altro redesign, e invece di aggiornare i vecchi redirect per puntare direttamente alla nuova destinazione finale, si aggiunge un altro strato sopra.
Come trovarle: Screaming Frog segnala le catene di redirect nel suo report Redirect. Esportalo, filtra per catene di 2 o più hop e aggiorna ogni redirect per puntare direttamente dall’URL originale alla destinazione finale.
I loop di redirect, dove l’URL A reindirizza a B e B reindirizza a A, causano risposte di errore e devono essere corretti immediatamente.
Schema markup: quali schema contano davvero
Lo schema markup è il dato strutturato leggibile dalle macchine che aiuta i motori di ricerca e i sistemi AI a capire i tuoi contenuti. Non causa direttamente miglioramenti nei posizionamenti, però abilita i rich result (valutazioni con stelle, prezzi, accordion FAQ, breadcrumb) che aumentano i tassi di click, ed è sempre più importante per la visibilità nella ricerca GEO e AI.
L’audit dello schema copre due domande: cosa è implementato e l’implementazione è corretta?
Strumento di verifica: Google Rich Results Test per pagine singole, 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 verificare 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 di contenuto e blog: Article o BlogPosting (con proprietà author, datePublished, dateModified, publisher popolate), FAQPage sulle sezioni FAQ.
Per siti ecommerce: Product (con proprietà name, description, image, sku, offers, aggregateRating), Offer (con price, priceCurrency, availability, url), AggregateRating (richiede recensioni reali, non inventarle).
Per attività locali: LocalBusiness con address, telephone, openingHours, geo.
Errori schema comuni che trovo negli audit: priceCurrency mancante nello schema Offer (richiesto da Google), AggregateRating con un numero di recensioni inferiore al minimo richiesto da Google per i rich result, schema FAQPage con risposte che non corrispondono al contenuto visibile sulla pagina, e schema Product senza la proprietà offers (che rende lo schema inutile per i risultati Shopping).
Navigazione a faccette: il principale killer del crawl budget per l’ecommerce
La navigazione a faccette, ovvero il sistema di filtri che permette agli utenti di sfogliare per colore, taglia, fascia di prezzo, brand e altri attributi, è il problema SEO tecnico più comune nei 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 taglie e 3 fasce di prezzo può teoricamente generare migliaia di URL unici. La maggior parte contiene contenuto quasi duplicato con valore unico minimo. 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 posizionare possono risultare svalutate.
La soluzione non è semplice né universale. Dipende da quali combinazioni di filtri hanno una vera domanda di ricerca (i filtri per brand spesso sì; le combinazioni colore/taglia quasi mai per la maggior parte delle categorie).
L’approccio standard:
- Usa
noindexsulle 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 principale
- Blocca via robots.txt i pattern di parametri a basso valore per pagine senza intento di ricerca
- Per le combinazioni di filtri con vera domanda di ricerca (es. “scarpe da corsa donna” come categoria), crea landing page ottimizzate invece di affidarsi agli URL generati dai filtri
L’approccio robots.txt è diretto 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.
Distribuzione dell’equity dei link interni
I link interni passano autorità attraverso il sito. Le pagine che ricevono più link interni da pagine autorevoli si posizionano meglio, a parità di 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 a lei. Googlebot può trovarla solo tramite la sitemap o un link esterno. Le pagine orfane non accumulano autorità interna. Screaming Frog può identificarle crawlando il sito e filtrando per pagine con zero inlink.
Qual è la profondità di crawl delle pagine prioritarie? La profondità di crawl è il numero di clic dalla homepage per raggiungere una determinata pagina. Google usa la profondità di crawl come indicatore di importanza: le pagine più vicine alla homepage sono considerate più significative. Le pagine prioritarie (pagine servizio principali, categorie di prodotto top, articoli ad alto fatturato) dovrebbero essere raggiungibili in 2-3 clic. Se i tuoi contenuti più importanti sono sepolti a 6 clic di profondità, il link interno ti sta deludendo.
Dove sta fluendo equity dove non dovrebbe? I link nel footer, nella navigazione e nella sidebar passano equity a dove puntano. Se il footer globale linka a 40 pagine diverse, ciascuno di quei link porta valore diluito. Dai priorità ai link interni nel contenuto del corpo: passano più equity e sono più topicamente rilevanti.
Il testo ancora è vario e descrittivo? Il testo ancora nei link interni segnala la rilevanza tematica. “Clicca qui” e “per saperne di più” sono opportunità sprecate. Usa testo ancora descrittivo che include la keyword per cui vuoi posizionare la pagina di destinazione.
Uno strumento pratico: il report Link di Screaming Frog mostra i conteggi di inlink per pagina. Ordina per inlink crescente per trovare le pagine sottolinkate. Verifica incrociata con la tua lista di pagine prioritarie. Qualsiasi pagina prioritaria con meno di 5-10 inlink contestuali da contenuti correlati dovrebbe essere un obiettivo di linking nel prossimo aggiornamento dei contenuti.
Il framework di azione prioritizzato
Ogni audit SEO tecnico porta a galla più problemi di quanti un team possa correggere immediatamente. Il framework di azione prioritizzato trasforma una lista in un piano.
Il sistema di punteggio è diretto. Valuta ogni problema su due dimensioni:
Impatto: Quanto migliora la correzione la performance organica? (Alto/Medio/Basso) Sforzo: Quanto tempo e risorse tecniche richiede la correzione? (Alto/Medio/Basso)
Poi raggruppa in quattro categorie:
Correggi immediatamente (Alto impatto/Basso sforzo): Catene di redirect verso pagine esistenti, tag canonical mancanti su pagine chiave, sitemap XML che contiene URL reindirizzati o 404, robots.txt che blocca accidentalmente sezioni importanti, schema mancante su pagine templatizzate.
Pianifica per il prossimo sprint (Alto impatto/Alto sforzo): Revisione della navigazione a faccette, cleanup di migrazione URL (fixing delle catene di redirect multi-hop a livello di scala), fix dei Core Web Vitals che richiedono modifiche a livello di tema, analisi dei log del server e riallocazione del crawl budget.
Fai quando conveniente (Basso impatto/Basso sforzo): Ottimizzazione delle meta description, aggiustamenti ai tag title, aggiunta di testo alternativo alle immagini per pagine non prioritarie.
Valuta il ROI (Basso impatto/Alto sforzo): Modifiche importanti al CMS che correggono problemi SEO minori, ristrutturazione hreflang complessa per traffico internazionale limitato, implementazioni schema personalizzate per tipi di pagina che non generano rich result.
La cosa più preziosa che un audit può fornire è questa prioritizzazione. La lista dei problemi è spesso prevedibile. Sapere quali tre cose muoveranno l’ago nei prossimi 90 giorni è ciò che distingue 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 d’azione prioritizzato. Se cerchi una consulenza continuativa invece di un audit una tantum, vedi il servizio di consulenza SEO.
FAQ
Cosa include un audit SEO tecnico? Un audit SEO tecnico approfondito copre analisi del crawl budget e dei log del server, Core Web Vitals (LCP, CLS, INP) a livello di gruppo di pagine, implementazione canonical, catene di redirect, accuratezza della sitemap XML, configurazione di robots.txt, validità dello schema markup, gestione della navigazione a faccette (per siti ecommerce) e distribuzione dell’equity dei link interni. Il risultato dovrebbe essere una lista di azioni prioritizzate, non semplicemente una lista grezza 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 concentrato. I siti ecommerce grandi con oltre 100.000 URL, navigazione a faccette complessa e analisi dei log del server possono richiedere 5-10 giorni. Il costo temporale è concentrato all’inizio: una volta completato l’audit, le correzioni sono compiti discreti che possono essere distribuiti su più sprint.
Qual è la differenza tra un audit SEO tecnico e un audit SEO? Un audit SEO tecnico si concentra specificamente su come è costruito un sito e come i motori di ricerca interagiscono con esso: crawlabilità, indicizzazione, velocità della pagina, dati strutturati, configurazione canonical e architettura del sito. Un audit SEO più ampio includerebbe anche un’analisi della qualità dei contenuti, una revisione del targeting delle keyword e una valutazione del profilo di backlink. Gli audit tecnici e dei contenuti affrontano problemi diversi; di solito sono necessari entrambi.
I siti piccoli hanno bisogno di un audit SEO tecnico? Sì, ma la portata è diversa. I siti piccoli (meno di 500 pagine) raramente hanno problemi di crawl budget o navigazione a faccette. Però hanno problemi di canonical, schema mancante, Core Web Vitals scadenti e lacune nei link interni che influenzano i posizionamenti. Un audit tecnico per un sito piccolo potrebbe richiedere mezza giornata invece di diversi giorni, però saltarlo del tutto significa prendere decisioni sui contenuti e sui link su una base potenzialmente rotta.
Di quali strumenti ho bisogno per fare un audit SEO tecnico? Il set minimo: Google Search Console (statistiche di crawl, report di copertura, Core Web Vitals, rich result), 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 Rich Results Test (validazione schema). Per l’analisi dei log del server, Screaming Frog Log Analyzer gestisce la maggior parte dei casi d’uso. Per siti di scala enterprise, strumenti come Botify o Oncrawl forniscono analisi dei log più avanzate con reporting SEO-specifico.
Con quale frequenza dovresti eseguire un audit SEO tecnico? Per siti attivi che pubblicano regolarmente o che apportano 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, come migrazione, redesign, cambio CMS o ristrutturazione importante degli URL, un audit tecnico completo prima e dopo il cambiamento è indispensabile.
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 i grandi siti ecommerce con decine di migliaia di URL, la capacità di crawl di Googlebot è finita, e se viene consumata da pagine di parametri a basso valore, paginazione o combinazioni di filtri, i nuovi contenuti importanti potrebbero non essere indicizzati tempestivamente.
Sull’autore Luciano Bonanno è un consulente SEO e Growth indipendente con 18 anni di esperienza. Fondatore di SameAPI e DeLeak.co. Prenota una chiamata strategica →