Audit SEO tecnico: le correzioni che incidono subito sul posizionamento

Un imprenditore avvia uno strumento di audit SEO tecnico sul proprio sito.

Il report restituisce quaranta problemi segnalati. JavaScript che blocca il rendering. Un tag hreflang mancante. Diverse immagini senza testo alternativo. Qualche errore 404.

Nel report non c'è scritto quali di questi problemi stiano davvero costando posizionamenti e quali siano solo rumore generato dallo strumento per sembrare completo.

Così il report viene scorso, salvato nei preferiti e in gran parte ignorato, perché non c'è un punto evidente da cui iniziare.

Un audit SEO tecnico non deve coprire quaranta cose per essere utile. Ne bastano quattro: se Google riesce a scansionare le tue pagine, quanto velocemente si caricano, come si visualizzano su uno smartphone e se i tuoi dati strutturati, cioè lo schema markup per piccole imprese, sono validi. Ecco come affrontare queste quattro aree nell'ordine che incide davvero sul posizionamento, invece di scorrere dall'alto in basso una lunga lista.

Cosa controlla davvero un audit SEO tecnico

Un audit SEO tecnico guarda l'impianto di un sito, non i testi che contiene. Verifica se una pagina può essere raggiunta, letta e visualizzata rapidamente, su qualsiasi dispositivo, anziché giudicare se il contenuto di quella pagina è valido.

La differenza è importante, perché una pagina tecnicamente perfetta ma con contenuti sottili e generici non si posizionerà bene, e una pagina scritta benissimo che Google non riesce a scansionare non si posizionerà affatto. I due tipi di audit risolvono problemi diversi.

Le quattro aree trattate in questo articolo

La maggior parte di ciò che compare in un report di audit tecnico rientra in una di quattro categorie: scansionabilità, velocità del sito, visualizzazione su mobile e dati strutturati. La documentazione di Google sulle Search Essentials formula il requisito di base in modo semplice: una pagina deve essere tecnicamente accessibile e visualizzabile prima che qualunque altro aspetto venga valutato.

Questo articolo esamina queste quattro aree nell'ordine che tende a contare di più, partendo dal fatto che Google riesca a raggiungere le tue pagine, perché nulla degli altri punti di un audit tecnico ha senso finché questo non è risolto.

In cosa un audit tecnico si differenzia da un audit dei contenuti

Un audit dei contenuti verifica se una pagina risponde a una domanda reale con sufficiente dettaglio, se è aggiornata e se è la pagina giusta da posizionare per una determinata ricerca. Un audit tecnico non si occupa di nulla di tutto questo. Verifica se la pagina si carica, se è bloccata e se uno smartphone riesce a mostrarla correttamente.

Entrambi gli audit sono importanti e un sito di solito ne ha bisogno di entrambi prima o poi. Questo articolo resta volutamente sul lato tecnico, perché è la parte che la maggior parte dei piccoli imprenditori o trascura del tutto o cerca di sistemare in una volta sola partendo da un elenco di problemi confuso.

Diagramma che mostra le quattro aree di audit tecnico in ordine di priorità: scansionabilità, velocità del sito, visualizzazione mobile e dati strutturati.

Errori di scansione in Google Search Console: cosa impedisce a Google di leggere le tue pagine

Prima che la velocità o il layout mobile di una pagina contino qualcosa, Google deve essere in grado di trovarla, richiederla e aggiungerla al proprio indice. Un errore di scansione interrompe questa catena, e nessun altro punto della lista di un audit tecnico può compensarlo.

Leggere il report Indicizzazione delle pagine in Search Console

Il report Indicizzazione delle pagine di Search Console è il modo più diretto per vedere come Google sta trattando le tue pagine, invece di fare supposizioni dall'esterno. Raggruppa i tuoi URL per stato: indicizzati, oppure non indicizzati con un motivo specifico.

Motivi come Bloccata da robots.txt, Errore del server (5xx), Errore di reindirizzamento e Soft 404 indicano ciascuno una causa diversa e richiedono una correzione leggermente diversa. Leggere questo report una volta al mese richiede pochi minuti e intercetta i problemi molto prima che si traducano in un calo di traffico.

Errori di scansione più comuni e le loro cause

Una pagina bloccata deriva di solito da una riga di robots.txt pensata per un'altra sezione del sito che ha catturato per errore più di quanto previsto. Un errore del server di solito significa che la pagina ha restituito una risposta di livello 500 quando Google ha provato a recuperarla, spesso a causa di un problema di hosting o di un plugin e non del contenuto della pagina.

Un errore di reindirizzamento significa che Google ha seguito un reindirizzamento che ha portato in un punto inatteso, spesso un ciclo o un vicolo cieco. Un soft 404 è una pagina che restituisce il normale stato 200 ma ha così pochi contenuti che Google la tratta come sostanzialmente vuota. Vale la pena verificarlo, perché a volte è il segnale di una pagina che ha davvero bisogno di più testo.

Perché una pagina importante bloccata viene prima di ogni altra correzione

Un sito può avere un'ottima velocità, un layout mobile impeccabile e dati strutturati validi su ogni pagina, e nulla di tutto questo conta se la pagina di servizio principale è bloccata per errore in robots.txt. Una pagina bloccata non viene giudicata male. Non viene giudicata affatto.

Per questo gli errori di scansione vengono sempre per primi in un audit tecnico, prima di qualsiasi punto su velocità o visualizzazione. La nostra guida su come far indicizzare il tuo sito da Google approfondisce questo controllo, incluso cosa fare quando una pagina che dovrebbe essere indicizzata non lo è.

Correggere robots.txt, sitemap e catene di reindirizzamento

Una volta capito cosa ti sta dicendo il report Indicizzazione delle pagine, le correzioni concrete si trovano di solito in tre punti: il file robots.txt, la sitemap e gli eventuali reindirizzamenti concatenati nel sito.

Controllare robots.txt per blocchi accidentali

Apri direttamente il file robots.txt del tuo sito, di solito situato alla radice del dominio, e leggi ogni regola. Una singola riga pensata per bloccare una cartella di amministrazione o un sottodominio di staging può catturare per errore un'intera directory di pagine reali se è scritta in modo troppo ampio.

Il Robots.txt Checker gratuito di RepGet indica in modo chiaro cosa viene bloccato per i motori di ricerca e per i bot IA insieme, il che è più veloce che leggere la sintassi riga per riga. La nostra guida al generatore di robots.txt spiega come creare da zero un file sicuro se quello esistente va riscritto e non solo ritoccato.

Tenere la sitemap allineata alle pagine reali

Una sitemap XML è utile solo se elenca le pagine che esistono davvero e restituiscono il normale stato 200. Una sitemap che elenca ancora pagine eliminate mesi fa, o che non include pagine aggiunte dopo l'ultima generazione, invia a Google segnali contraddittori su ciò che è attuale nel sito.

Il Sitemap Checker & Finder gratuito di RepGet trova e valida la sitemap di un sito, segnalando gli URL che non si risolvono come dovrebbero. La maggior parte delle piattaforme per siti web rigenera automaticamente la sitemap, ma conviene verificare che accada davvero invece di darlo per scontato.

Individuare e correggere le catene di reindirizzamento

Una catena di reindirizzamenti si forma quando un URL reindirizza a un secondo, che a sua volta reindirizza a un terzo, invece di puntare direttamente alla pagina finale. Ogni passaggio in più aggiunge tempo di caricamento e dà a Google un'altra occasione perché qualcosa vada storto.

Catene come queste si accumulano silenziosamente nel corso degli anni, di solito dopo che un sito è stato riprogettato più di una volta senza che nessuno ripulisse i vecchi reindirizzamenti rimasti. Per trovarle bisogna controllare le pagine più linkate e seguire dove atterra ciascun reindirizzamento, poi puntare direttamente alla destinazione finale qualsiasi reindirizzamento con più di un passaggio.

Velocità del sito e Core Web Vitals: cosa è davvero un fattore di posizionamento

Nei report di audit velocità sito la velocità della pagina riceve molta attenzione, in parte perché è misurabile e in parte perché i siti lenti sono davvero comuni. La cosa utile da chiarire è quali metriche di velocità Google documenta ufficialmente come segnale di posizionamento e quali sono semplicemente buone pratiche.

Le tre metriche Core Web Vitals, in parole semplici

I Core Web Vitals, documentati su web.dev, misurano tre aspetti dell'esperienza di caricamento di una pagina. La Largest Contentful Paint (LCP) misura quanto tempo impiega a comparire l'elemento visibile più grande, di solito un'immagine o un blocco di testo. La Interaction to Next Paint (INP) misura quanto rapidamente la pagina risponde quando qualcuno clicca o tocca qualcosa. La Cumulative Layout Shift (CLS) misura se gli elementi si spostano in modo inatteso mentre la pagina è ancora in caricamento.

Cosa è un segnale di posizionamento documentato e cosa è un consiglio generico sulla velocità

Google ha documentato i Core Web Vitals come parte dei suoi segnali di esperienza della pagina. È diverso da molti dei consigli sulla velocità che circolano online, come comprimere ogni immagine alla dimensione di file più piccola possibile o inseguire un punteggio perfetto di 100 su uno strumento di test della velocità, cosa che va ben oltre ciò che Google misura davvero.

Una pagina che supera le soglie dei Core Web Vitals ha rispettato il limite documentato. Guadagnare un altro mezzo secondo oltre quel limite a volte vale la pena per i visitatori, ma non è un vantaggio di posizionamento documentato rispetto a una pagina che già supera la soglia.

Controllare i punteggi del tuo sito

Il report Core Web Vitals di Search Console mostra come le tue pagine stanno effettivamente performando con i visitatori reali, raggruppate in base a se superano, necessitano di miglioramenti o non superano ciascuna metrica. È una lettura più affidabile del tuo sito rispetto a un singolo test eseguito da una località su un dispositivo, perché riflette le condizioni reali dei tuoi visitatori effettivi.

Per un rapido controllo su una singola pagina, uno strumento dedicato al test della velocità può mostrare quali elementi specifici la rallentano, come un'immagine principale troppo pesante o uno script che si carica prima del contenuto che influisce. In entrambi i casi, l'obiettivo non è un punteggio perfetto. È portare ogni pagina importante oltre le soglie documentate.

Rendering mobile: cosa vede Google su un telefono e cosa vedi tu

Una pagina che sembra perfetta su un monitor desktop può comportarsi in modo molto diverso su uno schermo di smartphone e, per la maggior parte dei siti oggi, è la versione per telefono quella che conta.

Perché l'indicizzazione mobile-first cambia ciò che conta

Google ha documentato che utilizza principalmente la versione mobile del contenuto di una pagina per l'indicizzazione e il posizionamento, una prassi che chiama indicizzazione mobile-first. Questo significa che la versione della tua pagina che Google valuta con più attenzione non è necessariamente quella che vedi quando controlli il tuo sito su un portatile.

Se una versione desktop nasconde un blocco di testo su mobile, oppure carica contenuti extra solo dopo un clic che un visitatore da telefono non fa mai, la visione principale di Google di quella pagina non include ciò che non è arrivato alla versione mobile. Un audit tecnico che controlla il sito solo da desktop sta verificando la copia sbagliata della pagina.

Problemi di usabilità mobile tipici delle piccole imprese

Alcuni problemi mobile si ripresentano spesso sui siti delle piccole imprese. Il testo leggibile su desktop si rimpicciolisce fino a una dimensione scomoda su un telefono, costringendo i visitatori a ingrandire con due dita. Pulsanti e link sono così vicini che un tocco su uno attiva accidentalmente un altro.

Un popup a schermo intero che copre la pagina prima che il visitatore abbia letto qualcosa è un altro problema comune, soprattutto sui siti costruiti con un modello che lo attiva di default. E un menu di navigazione pensato per il mouse a volte semplicemente non si apre su uno schermo touch, tagliando silenziosamente fuori il visitatore dal resto del sito.

Come testare la versione mobile del tuo sito

Il test più diretto è aprire il tuo sito su un telefono vero, con i dati mobili invece del wifi, e usarlo come farebbe un visitatore reale: toccare il menu, leggere il paragrafo principale, provare a raggiungere la pagina dei contatti. Fai attenzione a tutto ciò che sembra compresso, nascosto o non reattivo.

La nostra guida su come visualizzare il tuo sito come Googlebot descrive un metodo più tecnico per verificare cosa vede davvero il crawler di Google quando esegue il rendering di una pagina, che va oltre il semplice controllo visivo del layout.

Dati strutturati e schema: cosa aggiungono (e cosa no)

Lo schema markup è una delle voci più fraintese in un report di audit tecnico, in parte perché sembra più potente di quanto sia in realtà.

Cosa fa davvero lo schema per una pagina

Lo schema è un modo standardizzato di etichettare le informazioni in una pagina affinché un programma informatico possa leggerle in modo affidabile, invece di tirare a indovinare da un blocco di testo normale. La documentazione di Google sui dati strutturati spiega che lo schema può rendere una pagina idonea a determinate funzionalità più ricche nei risultati di ricerca, come le valutazioni a stelle o un menu a tendina delle FAQ, ma non migliora direttamente la posizione di una pagina nel ranking.

Questa distinzione è importante. Una pagina con uno schema perfetto e contenuti sottili e generici non supererà una pagina senza schema ma con testi davvero utili. Lo schema è un livello di presentazione che si appoggia su contenuti che devono comunque essere validi di per sé.

Tipi di schema utili per una piccola impresa

La maggior parte delle piccole imprese non ha bisogno di una configurazione di schema estesa. Alcuni tipi bastano a coprire le situazioni che si presentano davvero, e schema documenta l'intero vocabolario nel caso serva un tipo più specifico.

Validare il markup prima della pubblicazione

Uno schema scritto in modo errato, anche con un piccolo errore di sintassi, spesso fallisce in silenzio invece di mostrare un errore evidente nella pagina. Un validatore controlla che il markup sia strutturato come il vocabolario dello schema prevede prima della pubblicazione, intercettando errori che resterebbero inosservati per mesi.

Search Console segnala inoltre gli errori dei dati strutturati nelle pagine già scansionate, ed è utile controllarli periodicamente anche dopo che il markup è online da tempo, perché un aggiornamento del sito può a volte romperlo senza che nessuno se ne accorga. Questo fa parte degli errori di scansione Google Search Console da tenere d'occhio.

Ordinare i problemi tecnici per impatto e sforzo

Dopo aver trattato le quattro aree, la domanda successiva è in quale ordine lavorare su un report di audit reale, soprattutto quando mescola problemi di più di queste categorie.

Perché i problemi di scansione e indicizzazione vengono prima

Una pagina bloccata o non indicizzata supera tutto il resto di questo elenco, perché nient'altro conta finché non è risolta. Un miglioramento della velocità su una pagina che Google non riesce a leggere è sforzo sprecato, così come lo è aggiungere uno schema a una pagina che non è nemmeno nell'indice.

Per questo l'ordine di questo articolo non è casuale. Gli errori di scansione vengono prima perché possono rendere inutile ogni altra correzione. Velocità e rendering mobile vengono dopo perché incidono su pagine che Google già vede e può posizionare, solo non così bene come potrebbero. Lo schema viene per ultimo perché aggiunge valore di presentazione a una pagina che già funziona.

Dove si collocano velocità, mobile e schema dopo

Una volta sistemata la scansionabilità, i problemi di velocità e mobile di solito meritano il turno successivo, perché entrambi sono documentati come parte del modo in cui Google valuta l'esperienza di pagina e perché incidono su ogni visitatore che arriva sulla pagina, non solo su quelli che Google scansiona. Lo schema va inserito dopo, come aggiunta utile ma a priorità più bassa.

Lo stesso ragionamento sforzo-contro-impatto che vale per qualsiasi lista di audit vale anche qui. Una pagina bloccata richiede poco sforzo e ha un impatto alto, quindi va sempre sistemata per prima, indipendentemente da cosa c'è altro nell'elenco. Una pagina lenta e ricca di immagini richiede più lavoro ma conta comunque. Il testo alternativo mancante su qualche immagine è rapido da sistemare ma di importanza minore. E una pagina d'archivio poco visitata, sepolta in profondità nel sito, di solito non vale affatto il tempo che richiede.

Matrice 2x2 che ordina i problemi dell'audit SEO tecnico per sforzo e impatto, con esempi in ogni quadrante: una pagina importante bloccata come vittoria rapida, pagine lente e ricche di immagini come progetto più impegnativo, testo alternativo mancante come intervento rapido ma minore, e una pagina d'archivio poco visitata da saltare per ora.

Un esempio pratico: l'audit di un piccolo sito aziendale

Immagina una piccola impresa di giardinaggio che effettua un audit tecnico del proprio sito per la prima volta da diversi anni. Questo esempio è a scopo illustrativo.

Cosa è cambiato e in quale ordine

L'audit fa emergere quattro problemi che coprono tutte e quattro le aree trattate in questo articolo: una pagina di servizio bloccata per errore nel robots.txt, una homepage appesantita da immagini grandi non compresse, un menu mobile che non si apriva su uno schermo touch e nessun markup di schema in tutto il sito. Affrontarli nell'ordine suggerito da questo articolo appare così.

Questi dati sono a scopo illustrativo.

La pagina bloccata è stata sistemata per prima, perché nient'altro contava finché Google non poteva effettivamente leggerla. Velocità e mobile sono venute dopo, perché incidevano sui visitatori reali ed entrambe fanno parte del modo in cui Google documenta l'esperienza di pagina. Lo schema è arrivato per ultimo, aggiunto una volta che tutto ciò che stava sotto funzionava già.

Un controllo tecnico settimanale di 20 minuti

Un audit tecnico completo non va ripetuto ogni settimana, ma un controllo breve evita che i piccoli problemi diventino quelli che emergono solo mesi dopo, sotto forma di un calo di traffico.

Cosa controllare ogni settimana

Inizia dal rapporto Indicizzazione delle pagine in Search Console e cerca eventuali novità nella colonna delle pagine non indicizzate. Una pagina che la settimana scorsa funzionava e questa settimana è bloccata o restituisce errori di solito segnala una modifica recente da qualche parte nel sito, che è molto più facile da rintracciare finché è fresca.

Poi dai un'occhiata al rapporto Core Web Vitals, per verificare se una metrica è passata da superata a da migliorare. Basta a volte un'immagine o uno script nuovo aggiunto senza ridimensionamento per far scendere una pagina sotto la soglia documentata, e intercettarlo subito significa una correzione di cinque minuti invece di un'indagine più lunga in seguito.

Infine controlla le nuove segnalazioni di usabilità mobile e gli eventuali errori dei dati strutturati che Search Console ha iniziato a segnalare. Entrambi tendono a comparire dopo un aggiornamento del tema, una modifica a un plugin o un restyling, anche piccolo, e si correggono molto più in fretta la settimana in cui compaiono che tre mesi dopo.

Come si presenta un problema ricorrente

Una singola pagina bloccata o un'immagine lenta è una correzione una tantum. Uno schema, come tre pagine diverse che perdono la validazione dello schema nello stesso mese, di solito significa che qualcosa a monte, un template, un plugin o una recente modifica al sito, lo causa ripetutamente, invece di essere ogni volta un incidente isolato e non correlato.

Individuare questo schema durante il controllo settimanale, anziché scoprirlo durante un audit annuale, è il vero vantaggio di mantenere questa routine breve e regolare invece di rimandarla finché qualcosa non si rompe in modo visibile.

Errori comuni nell'audit SEO tecnico

Alcune abitudini vanificano regolarmente il valore di un audit tecnico altrimenti accurato, e la maggior parte nasce dal lavorare su un rapporto nell'ordine sbagliato o dall'inseguire il numero sbagliato.

Correggere lo schema prima di risolvere un blocco di scansione è uno degli errori più comuni. Passare un pomeriggio ad aggiungere markup FAQ a una pagina bloccata in robots.txt significa che quel markup resta inutilizzato finché il blocco sottostante non viene rimosso, e questo rende l'ordine in cui si lavora più importante della qualità del lavoro stesso.

Inseguire un punteggio di velocità perfetto è un altro errore. Una pagina che già supera le soglie documentate di Core Web Vitals non ottiene un ulteriore vantaggio di posizionamento strappando un altro decimo di secondo, anche se il punteggio 100 su 100 di uno strumento di test può far sembrare comunque utile farlo.

Saltare i test specifici per il mobile, e controllare solo una finestra del browser desktop ridimensionata, fa perdere problemi reali. Una finestra ridotta non riproduce uno schermo touch, una connessione mobile più lenta o il modo in cui il sistema operativo del telefono visualizza i caratteri, quindi i problemi che compaiono solo su un dispositivo reale passano inosservati.

Non ricontrollare dopo che le correzioni sono online completa l'elenco. Una correzione che non è stata salvata davvero, o che è stata sovrascritta da una modifica successiva, può restare rotta per mesi se nessuno torna a verificare che abbia funzionato.

Dove si inserisce RepGet

Gran parte di questo articolo è lavoro che puoi fare con Search Console e un telefono in mano, ma una prima verifica di un intero sito va più veloce con uno strumento pensato per questo. Il controllo gratuito del sito di RepGet analizza un sito e gli assegna un punteggio SEO da 0 a 100, segnalando i problemi tecnici da approfondire insieme a quelli di contenuto, inclusi diversi trattati in questo articolo: se le pagine sono raggiungibili e indicizzate, e i problemi di base di esperienza della pagina. È un punto di partenza ragionevole per vedere a che punto è un sito rispetto a gran parte di questo elenco in una sola volta. Non serve un account né una carta di credito.

RepGet non sostituisce i rapporti Indicizzazione delle pagine e Core Web Vitals di Search Console, che si basano su dati sui visitatori reali che una scansione una tantum non può vedere. Non sostituisce neppure la valutazione su quale correzione conti di più per il tuo sito in questa settimana, né garantisce un posizionamento, una posizione su Maps o un risultato in termini di traffico derivante da una correzione tecnica, per quanto accurata sia.

In sintesi

Per la maggior parte dei siti di piccole imprese, un audit SEO tecnico deve coprire solo quattro aspetti: se Google riesce a scansionare e indicizzare le tue pagine, quanto velocemente si caricano, come si visualizzano su un telefono e se i dati strutturati sono validi.

Lavorarci in questo ordine conta più che affrontare tutti i quaranta punti che un rapporto lungo potrebbe segnalare. Una pagina bloccata vanifica tutto il resto dell'elenco, quindi viene prima. Velocità e mobile incidono su ogni visitatore reale, quindi vengono subito dopo. Lo schema aggiunge valore a una pagina che già funziona, quindi viene per ultimo.

Nessun audit, per quanto completo, può promettere la posizione di una pagina nei risultati di ricerca una volta applicate le correzioni. Ciò che può fare è assicurarsi che Google veda davvero la versione migliore del tuo sito, invece di basarsi su una versione con problemi che nessuno ha notato.

Scopri subito di cosa ha bisogno il tuo sito

Prima di lavorare a mano su un lungo elenco di problemi, scopri a che punto si trova davvero il tuo sito. Esegui un controllo gratuito del sito con RepGet per verificare scansionabilità, indicizzazione e l'esperienza di base delle pagine insieme ai contenuti. Non serve un account né una carta di credito.