Lista di controllo SEO tecnica: L’elenco definitivo per migliorare il vostro sito web

Elenco di controllo SEO tecnico

Crawling e indicizzazione

La prima cosa da esaminare durante l’audit tecnico è il modo in cui il vostro sito viene indicizzato e caricato dai motori di ricerca. Infatti, se le pagine del vostro sito non possono essere carrellate, non saranno indicizzate (con poche eccezioni). Di conseguenza, le pagine non rappresentate nell’indice non parteciperanno alla classifica.

Esaminare il rapporto sull’indicizzazione delle pagine in Google Search Console

Il modo più preciso e affidabile per analizzare l’indicizzazione del vostro sito web è analizzare il rapporto di indicizzazione delle pagine in Google Search Console. Guardate il rapporto delle pagine indicizzate e verificate quali pagine sono presenti nell’indice. Verificate se ci sono pagine con opzioni di filtraggio o di ordinamento, se ci sono pagine di prova o altre pagine che non volete indicizzare. Osservate anche le pagine che sono state escluse. Non tutti gli stati nel rapporto Pagine escluse sono un problema. Non dovreste concentrare la vostra attenzione su tutte le pagine escluse, ma solo su quelle in cui il comportamento di Google non corrisponde alle vostre intenzioni. Nella tabella seguente, potete vedere gli stati che tendono a richiedere attenzione e un’analisi più approfondita:

Stato	Cosa significa	Cosa si dovrebbe fare
Errore di reindirizzamento	Google non è riuscito a seguire l’URL a causa di problemi di reindirizzamento.	Ridurre il numero di reindirizzamenti (a 1-2). Evitare i reindirizzamenti infiniti e circolari – Assicurarsi che l’URL finale restituisca 200 OK e non sia bloccato in robots.txt/noindex.
Errore del server	Il server ha restituito un errore 5xx.	Controllare i log del server. Assicurarsi che il sito non sia sovraccarico.- Correggere gli errori interni, soprattutto se si ripetono.
Scoperto – non indicizzato	Google è a conoscenza della pagina, ma non l’ha ancora scansionata. Indica problemi di budget per il crawling.	Assicurarsi che la pagina sia presente nella sitemap. Aggiungere collegamenti interni alla pagina. Ottimizzare il budget di crawling.
Crawlata – non indicizzata	Google ha visitato la pagina ma ha scelto di non indicizzarla. Di solito indica una bassa qualità della pagina.	Migliorare la qualità e l’unicità dei contenuti. Assicurarsi che la pagina non abbia duplicati. Aggiungere collegamenti interni.
Duplicato senza canonical selezionato dall’utente	Google considera la pagina un duplicato, ma non è stato specificato un canonical.	Controllate le coppie di pagine e specificate il canonical necessario o riconsiderate la struttura del sito.
Duplicato, Google ha scelto un canonical diverso da quello dell’utente	Google ha ignorato il canonical specificato.	Le ragioni possono essere molteplici; è necessario esaminare attentamente i dati della pagina e scegliere la strategia più appropriata (noindex, redirect, rimozione, robots.txt, modifiche alla struttura del sito e al linking interno).
Soft 404	La pagina sembra “vuota” o “non trovata”, ma restituisce uno stato 200 OK.	Restituire 404 o 410. Effettuare un reindirizzamento. Migliorare il contenuto. Bloccare dall’indicizzazione.

Gli altri stati probabilmente non segnalano alcun problema. Tuttavia, vale la pena di esaminare anche questi rapporti per assicurarsi che le pagine non siano state rimosse, reindirizzate, canonicalizzate o bloccate dall’indicizzazione per errore.

Stato	Cosa significa	Cosa occorre sapere
Pagina alternativa con tag canonico corretto	Google ha riconosciuto correttamente il canonical specificato.	Tutto funziona come previsto. Non è necessaria alcuna azione. Assicurarsi di aver specificato il canonical desiderato.
URL bloccato da robots.txt	Google non può eseguire il crawling della pagina.	Controllare il file robots.txt. Consentire l’accesso se si desidera che la pagina venga indicizzata.
URL contrassegnato come “noindex	La pagina ha la direttiva noindex.	Assicurarsi che il tag noindex sia impostato intenzionalmente. Se la pagina è importante, rimuovere questo tag.
Non trovato (404)	La pagina non esiste.	Se è importante, ripristinare la pagina. Se la pagina è stata eliminata in modo permanente, assicurarsi che non vi siano collegamenti interni ad essa.
Bloccato per richiesta non autorizzata (401)/Bloccato per accesso vietato (403)	La pagina è bloccata per autorizzazione o vietata.	Consentire l’accesso se la pagina deve essere indicizzata.
Pagina con reindirizzamento	La pagina reindirizza a un’altra.	Verificare se il reindirizzamento è previsto e corretto.
URL bloccato a causa di un altro problema 4xx	La pagina è inaccessibile a causa di un errore 4xx diverso da 404 (ad es. 403, 401, 410, ecc.).	Verificare manualmente il codice di stato HTTP. Correggere le impostazioni di accesso. Impostare codici di stato o reindirizzamenti corretti. Consentire l’accesso a Googlebot, se necessario.

Nel Centro assistenza di Google è disponibile una descrizione completa del rapporto sulle pagine, con esempi di problemi e una spiegazione dettagliata di ogni stato. Screaming Frog può anche aiutare ad analizzare le pagine indicizzate o escluse dall’indice. Per farlo, è necessario connettersi all’API di Google Search Console prima di avviare la scansione del sito. Per connettersi, andare a Configurazione -> Accesso API -> Google Search Console. Fare clic su Accedi con Google e seguire le istruzioni.

Una volta connessi, attivare l’ispezione degli URL, e si può anche attivare l’opzione per ignorare l’ispezione dell’indicizzazione per gli URL che non possono essere indicizzati.

Sarà quindi possibile vedere e confrontare lo stato di ogni pagina secondo Search Console (come lo vede Google) e lo stato effettivo determinato durante il processo di crawling.

Si noti che per ogni sito sono disponibili solo 2000 URL al giorno, quindi questo metodo è più adatto a siti di piccole dimensioni.

Controllare il contenuto della sitemap.xml

Sitemap.xml è un file XML che fornisce ai crawler dei motori di ricerca un elenco delle pagine di un sito, oltre a informazioni (opzionali) sulla loro data di ultima modifica, sulla frequenza di aggiornamento e sulla priorità di crawl consigliata. Di solito è collocato nella radice del sito, ad esempio: https://example.com/sitemap.xml. Sitemap.xml aiuta i motori di ricerca a trovare più velocemente le pagine nuove o aggiornate. Inoltre, l’inclusione di una pagina in questo file è uno dei segnali per determinare la versione canonica di una pagina, anche se debole.

Il file sitemap.xml è particolarmente utile per:

• siti nuovi con pochi link esterni
• siti di grandi dimensioni con molte pagine
• siti con molti contenuti multimediali
• siti di notizie che vengono aggiornati frequentemente.

Sitemap.xml deve contenere tutte le pagine che si desidera indicizzare. È possibile utilizzare lo stesso Screaming Frog o altri crawler per analizzare le pagine incluse in Sitemap.xml. In Screaming Frog, sitemap.xml può essere analizzato separatamente in modalità Elenco, oppure può essere incluso in una normale scansione del sito. A tal fine, in Configurazione -> Spider -> Crawl, attivare la scansione delle sitemap XML e aggiungere gli URL assoluti delle sitemap che si desidera sottoporre a crawling. Non è consigliabile utilizzare vari servizi online per la generazione di una Sitemap, in quanto potrebbero generare solo una sitemap statica che non verrà aggiornata automaticamente. L’opzione ottimale è quella di generare la sitemap.xml utilizzando i plugin per il CMS su cui è in esecuzione il sito, oppure di scrivere uno script personalizzato che generi la sitemap in base a condizioni specifiche e la aggiorni automaticamente quando vengono apportate modifiche al sito. Quando si genera la sitemap.xml, assicurarsi che il file sia conforme al protocollo sitemap.xml. A tale scopo è possibile utilizzare diversi validatori online, come https://www.xml-sitemaps.com/validate-xml-sitemap.html. È necessario includere tutti i tag elencati nel protocollo? Non sempre. Ad esempio, Google considera solo i tag <loc> e <lastmod>. Assicuratevi che la data del tag <lastmod> sia accurata. Se ci sono tentativi di manipolazione, Google potrebbe ignorare questo tag.

Assicurarsi che non ci siano errori nel file robots.txt

Il file robots.txt è il primo posto in cui un bot di ricerca guarda prima di effettuare il crawling di un sito. Determina quali sezioni del sito possono o non possono essere scansionate e, di conseguenza, quali pagine saranno indicizzate dai motori di ricerca. Dovrebbe sempre trovarsi all’indirizzo https://example.com/robots.txt. Questo file è uno strumento per gestire il crawling (non l’indicizzazione!) del sito. Alcune pagine, anche se bloccate in robots.txt, possono comunque essere indicizzate (di solito se vi sono collegamenti interni o esterni). Tali pagine (indicizzate nonostante siano bloccate da robots.txt) possono essere visualizzate in Google Search Console nel rapporto “Indicizzate, ma bloccate da robots.txt”.

Ecco cosa controllare del file robots.txt nell’ambito di un audit SEO tecnico:

1. Disponibilità del file

Il file deve essere accessibile all’indirizzo https://example.com/robots.txt e fornire uno stato di risposta 200 OK. La sua assenza, gli errori di download o i reindirizzamenti (301, 302, 403, 404) possono impedire ai motori di ricerca di comprendere correttamente le regole di crawling del sito.

1. Sintassi e correttezza

Verificare che la struttura dei file sia conforme allo standard. Esempio di template di base:

• User-agent: *
• Disallow: /admin/
• Consenti: /public/
• Mappa del sito: https://example.com/sitemap.xml

1. Direttive Disallow e Allow

Controllate che le pagine importanti non vengano accidentalmente disabilitate, ad es:

• Home (/)
• Schede prodotto (/product/)
• Blog o articoli (/blog/, /articoli/)

Un errore comune è quello di bloccare immagini, stili e script quando si bloccano le cartelle amministrative. In questo caso, occorre specificare che, sebbene la cartella amministrativa sia bloccata, alcuni tipi di file devono essere aperti per la scansione. Questo accade spesso nei siti WordPress quando la cartella con tutti i contenuti dell’utente, Disallow: /In questo caso, solo i file di un determinato formato possono essere aperti per la scansione:

• Consenti: /wp-content/uploads/*.css
• Consenti: /wp-content/uploads/*.js
• Consenti: /wp-content/uploads/*.jpeg

Per convalidare il vostro robots.txt e testare le direttive da aggiungere, potete usare questo strumento.

1. Verificare la compatibilità con altre direttive

Spesso si verificano errori quando il robots.txt entra in conflitto con:

• meta tag <meta name=”robots” content=”noindex”>.
• canonico

Ad esempio, se una pagina è aperta in robots.txt ma bloccata tramite noindex, verrà strisciata, ma non entrerà nell’indice. Questo è accettabile, ma è importante che sia fatto intenzionalmente. Inoltre, un problema comune è quando ci sono altre istruzioni per i bot nel codice sorgente e un contemporaneo blocco della pagina in robots.txt. I robot dei motori di ricerca non scansionano le pagine bloccate in robots.txt. Non vedono i tag specificati nel codice, ad esempio la canonicalizzazione. In altre parole, un canonical di questo tipo non viene rilevato.

Controllare il linking interno

Uno dei compiti principali di un audit tecnico è assicurarsi che il linking interno del sito funzioni correttamente. Ciò significa che tutti i link interni devono condurre a pagine reali ed esistenti, aperte all’indicizzazione, che restituiscano un codice di stato 200 OK, che non contengano reindirizzamenti e, soprattutto, che non puntino a pagine con errori 4xx/5xx. A prima vista, questo può sembrare un dettaglio di poco conto, ma in pratica anche i link interni non corretti possono influire negativamente:

• L’efficienza del crawling del sito web da parte dei motori di ricerca,
• La distribuzione del peso SEO interno (PageRank),
• L’esperienza dell’utente.

Il primo passo dell’analisi consiste nel verificare la presenza di errori in tutti i link interni. È particolarmente importante identificare i link interrotti che portano a pagine con un errore 404, 410 o altri errori (come 403, 500). Di seguito è riportata una tabella con i principali tipi di errori che possono verificarsi nei link interni, il loro significato e le azioni consigliate per risolverli.

Tipo di errore	Cosa significa	Cosa fare
404	Pagina non trovata	Rimuovere il link o sostituirlo con uno funzionante.
403	Accesso vietato	Controllare le impostazioni di accesso
301/302	Reindirizzare	Aggiornare il link all’URL finale
5xx	Errore del server	Controllare il server o il CMS

È importante anche analizzare la profondità della gerarchia delle pagine, ossia determinare a quale livello e a quanti clic di distanza dalla homepage si trovano i contenuti chiave. È preferibile che le pagine importanti non si trovino più in basso del terzo livello: questo ne aumenta l’accessibilità sia per i motori di ricerca sia per gli utenti. Uno degli elementi chiave dell’analisi è l’identificazione delle pagine “orfane”, ovvero quelle che non hanno link interni che puntano ad esse. Anche se queste pagine sono incluse nella sitemap, la mancanza di link interni le rende meno accessibili. Inoltre, è importante analizzare gli anchor text, ossia le parole e le frasi che contengono i link. Devono essere pertinenti e significativi, poiché i testi di ancoraggio aiutano i motori di ricerca a capire il contesto del link.

Analizzare le statistiche di crawl

L’analisi delle statistiche di crawl è un modo per capire come Googlebot interagisce con un sito: quali pagine vengono crawlate, con quale frequenza e come questo influisce sulla SEO. Questi dati sono disponibili in Google Search Console → Impostazioni → Statistiche crawl. Nella tabella seguente sono riportati i problemi più comuni che è possibile individuare in questo report:

Problema	Cosa cercare nel rapporto	Possibili cause
Forte diminuzione delle scansioni	Meno crawl al giorno	Problemi di accessibilità, impostazioni errate in robots.txt, blocchi, errori 5xx
Molti errori 4xx e 5xx	Errori negli URL	Pagine cancellate, link non funzionanti, problemi del server
Tempo di risposta aumentato	>1 secondo – un segnale di allarme	Problemi di hosting, sovraccarico del server
Molti reindirizzamenti 3xx	Reindirizzamenti invece di URL diretti	Reindirizzamenti errati, catene di reindirizzamenti, un gran numero di link interni con reindirizzamenti
CSS/JS non crawlati	Mancano nelle statistiche	Bloccati da robots.txt

Inoltre, è possibile analizzare i log del server. Essi consentono di visualizzare le richieste effettive dei bot di ricerca (non solo Googlebot, ma anche Bingbot, YandexBot e altri), anziché i dati aggregati di Google Search Console. Si tratta di un metodo diagnostico avanzato e “grezzo” che richiede una notevole quantità di tempo. Per visualizzare i dati, è possibile utilizzare strumenti open-source come GoAccess o Screaming Frog Log File Analyser.

Implementare i dati strutturati

I dati strutturati sono uno speciale formato di markup di una pagina web che aiuta i motori di ricerca a comprendere il contenuto della pagina in modo più accurato e approfondito. Servono come “suggerimento” a Google e agli altri motori di ricerca su cosa si trova esattamente nella pagina – un articolo, un prodotto, una ricetta, una recensione, un video, ecc. Pur non essendo un segnale di ranking ufficiale, influisce indirettamente sulle classifiche migliorando la comprensione della pagina da parte dei motori di ricerca. Il principale standard o protocollo utilizzato per i dati strutturati dei siti web è Schema.org. Esistono altri protocolli, come OpenGraph, ma è utilizzato per i social network. Schema.org è un progetto collaborativo di Google, Microsoft, Yahoo e Yandex, creato per sviluppare e mantenere uno standard unificato per i dati strutturati sul web. Schema.org include centinaia di tipi di entità, i più utilizzati sono elencati nella tabella seguente:

Categoria	Entità (@tipo)	Scopo
Contenuti e pagine	Articolo	Un articolo o un contenuto di notizie
	BlogPosting	Un post del blog
	Articolo di notizie	Un articolo di notizie per Google News
	Pagina FAQ	Una pagina di domande frequenti (FAQ)
	Come fare	Una guida passo-passo
	Pagina web	Informazioni generali su una pagina web
Prodotti e offerte	Prodotto	Descrizione del prodotto
	Offerta	Offerta di prezzo
	AggregatoOfferta	Fascia di prezzo per un prodotto di diversi venditori
Recensioni e valutazioni	Recensioni	Una recensione di un prodotto o servizio
	Valutazione	Una valutazione numerica (spesso all’interno di una recensione)
	Valutazione aggregata	Valutazione media basata su più recensioni
Organizzazioni e persone	Organizzazione	Descrizione di un’azienda o di un marchio
	Azienda locale	Un’azienda locale con informazioni di contatto e orari
	Persona	Una persona (ad esempio, autore di un articolo, oratore, ecc.)
Eventi	Evento	Un evento online o offline
Navigazione e struttura	Elenco di briciole di pane	Navigazione a briciole di pane
	Elemento di navigazione del sito	Voci del menu principale
Multimedia	VideoOggetto	Video con metadati (per gli snippet video)
	Oggetto Immagine	Immagine con descrizione
Formazione e lavoro	Corso	Un corso o un programma di formazione online
	Annuncio di lavoro	Offerta di lavoro (per Google for Jobs)

Si consiglia di implementare i dati strutturati nel formato JSON-LD. Questo blocco viene inserito nel <head> o <body> del documento HTML, ma non viene visualizzato dall’utente, bensì letto dai bot di ricerca. Tutti i principali motori di ricerca, come Google, Bing e Yahoo, supportano questo formato. Un esempio di codice JSON-LD è mostrato di seguito: <script type=”application/ld+json”> { “@context”: “https://schema.org”, “@type”: “Articolo”, “Titolo”: “Cos’è JSON-LD?”, “author”: { “@type”: “Person”, “name”: “John Smith” }, “datePublished”: “2025-12-01” } </script> Quando implementate i dati strutturati, seguite il protocollo Schema.org e utilizzate il validatore per verificare la correttezza dei tipi di microdati implementati.Alcuni tipi di dati strutturati del protocollo Schema.org possono anche essere utili per la visualizzazione dei rich snippet nei risultati di ricerca di Google. Si noti che i requisiti di Google per i dati strutturati per i rich snippet differiscono leggermente dallo standard Schema.org. Spesso è necessario specificare un numero maggiore di campi rispetto a quanto richiesto dal protocollo Schema.org. Quindi, se volete ottenere un Rich Snippet, seguite le linee guida di Google per i dati strutturati. È possibile verificare la correttezza dell’implementazione dei microdati utilizzando il validatore di rich snippet. Esistono anche molti generatori di microdati, ma possono creare solo codice statico che non verrà aggiornato con le modifiche del contenuto della pagina. Garantire che le informazioni contenute nei microdati corrispondano a ciò che è visibile agli utenti sulla pagina fa parte dei requisiti di Google per i dati strutturati. Se la politica relativa ai dati strutturati viene violata, la pagina può perdere tutti i rich snippet e, in alcuni casi, subire penalizzazioni manuali. Pertanto, assicuratevi che i vostri microdati siano generati e aggiornati automaticamente.

Contenuto

Nell’ambito di un audit SEO tecnico, è importante valutare le caratteristiche di base dei contenuti: dalla struttura delle intestazioni e dei meta tag alla presenza degli attributi alt per le immagini e alle potenziali pagine duplicate. Questi elementi influenzano direttamente l’indicizzazione e la percezione del sito da parte dei motori di ricerca.

Verificate che il vostro sito non abbia duplicati completi

I duplicati completi si verificano quando contenuti identici sono accessibili attraverso URL diversi del sito. I duplicati possono danneggiare completamente le classifiche del vostro sito. I tipi più comuni di duplicati completi sono:

• Accessibilità tramite HTTP e HTTPS
• Accessibilità con e senza WWW
• Accessibilità con o senza barra finale
• Accessibilità degli URL in maiuscolo e minuscolo
• La pagina è accessibile con estensioni di file come .html, .htm, .php, .aspx, e senza di esse
• Parametri che non modificano il contenuto della pagina, come i tag UTM.
• Contenuti identici sotto URL diversi. Ad esempio, un prodotto è elencato in due categorie, accessibili tramite due URL diversi. Oppure la pagina del prodotto è accessibile con e senza la categoria nell’URL.
• Versioni di prova del sito (dominio DEV utilizzato per lo sviluppo).

Per trovare i duplicati di pagina legati alle variazioni di URL, verificate manualmente gli URL e controllate il codice di risposta del server per queste varianti di URL. È possibile utilizzare qualsiasi strumento per verificare i codici di risposta del server, ad esempio https://httpstatus.io/. Inserite le variazioni di URL e verificatene l’accessibilità.

Per risolvere i problemi relativi alle variazioni HTTP/HTTPS, www/senza-www, con/senza slash, maiuscole/minuscole e all’accessibilità delle pagine con estensioni come .html, .htm, .php, .aspx e senza, è necessario impostare un reindirizzamento 301 alla versione preferita. Quando si riscontrano duplicati dovuti alla disponibilità di contenuti identici aggiungendo o rimuovendo parti dell’URL (ad esempio, un prodotto è disponibile in due categorie), è meglio riconsiderare la struttura dell’URL e del sito. Per gli UTM e altri parametri, anche la canonicalizzazione può essere una soluzione. Tuttavia, è importante notare che Google tratta il tag canonico come una raccomandazione e la decisione finale su quale URL scegliere spetta a Google. Se una versione di prova del sito viene trovata nell’indice di Google, dovrebbe essere bloccata dall’indicizzazione e una richiesta di rimozione dovrebbe essere inviata tramite Google Search Console.

Risolvere i duplicati parziali di pagina

I duplicati parziali di pagina si verificano quando due o più pagine del sito contengono contenuti molto simili, ma non del tutto identici. I tipi più comuni di duplicati parziali sono:

• Ordinamento delle pagine
• Pagine filtro
• Pagine di paginazione
• Pagine con prodotti simili (ad esempio, i prodotti differiscono solo per il colore)
• Versioni multiple del sito nella stessa lingua, ma per regioni diverse (ad esempio, tre siti in inglese per Stati Uniti, Regno Unito e Australia).

Naturalmente, ogni sito è unico e durante l’audit tecnico si possono individuare altri casi di contenuti duplicati che richiedono soluzioni specifiche. Tuttavia, gli esempi di cui sopra sono i più comuni. I duplicati parziali vengono in genere trovati durante il processo di crawling del sito da parte di vari crawler. Hanno parametri ripetuti e possono avere lo stesso titolo e H1 delle pagine della categoria principale. Per eliminare i duplicati parziali, non è possibile impostare un reindirizzamento, poiché queste pagine sono necessarie per la funzionalità del sito. Di seguito verranno illustrati i metodi per gestire i duplicati parziali.

Ordinamento e filtraggio delle pagine

Queste pagine possono essere bloccate dal crawling nel file robots.txt, anche se ciò può essere ignorato da Google, soprattutto se i link puntano a queste pagine. È anche possibile bloccarle tramite la direttiva <meta name=”robots” content=”noindex, nofollow” />, che impedirà l’indicizzazione di queste pagine, ma non dirà a Google che non devono essere carrellate. L’approccio migliore in questo caso è utilizzare JavaScript per aggiornare il contenuto della pagina quando l’utente applica l’ordinamento o i filtri, senza generare URL e collegamenti aggiuntivi alle pagine di ordinamento o di filtraggio.

Varianti di prodotto disponibili su URL diversi

Idealmente, tutte le varianti di prodotto dovrebbero essere riunite in un’unica pagina, dove l’utente può selezionare il colore o la taglia desiderata senza modificare l’URL, utilizzando JavaScript. Tuttavia, se si utilizza una pagina separata per ogni variante, è necessario specificare un link canonico alla pagina principale del prodotto. Tuttavia, come già detto, Google potrebbe ignorare il canonical impostato dall’utente.

Pagine di paginazione

Le pagine di paginazione non devono essere bloccate dall’indicizzazione. Per garantire che Google consideri la prima pagina della categoria come principale:

• Includere solo la prima pagina nel file sitemap.xml.
• Aggiungere un link alla pagina principale della categoria in tutte le pagine di paginazione.
• Aggiungere i numeri di pagina al titolo e all’H1 delle pagine di paginazione. Ad esempio, “Camicie bianche – Pagina 2”.

Pagine disponibili in una lingua ma per regioni diverse

In questo caso, è necessario utilizzare gli attributi Hreflang. Vengono utilizzati per indicare ai motori di ricerca la lingua e la versione regionale di una pagina web da mostrare agli utenti in base alle loro preferenze linguistiche e alla loro posizione geografica. Esistono diversi modi per implementare gli attributi Hreflang:

• Nelle intestazioni HTTP
• Tramite tag nella sezione <head
• Tramite tag in sitemap.xml

Il metodo più semplice da implementare è quello dei tag nella sezione <head>. Ci sono delle regole che gli attributi hreflang implementati tramite tag nella sezione <head> devono rispettare:

• • L’attributo deve avere il seguente formato: <link rel=”alternate” hreflang=”lang_code_country_code” href=”url-di-pagina” />
  • I codici della lingua e del Paese devono essere validi. Per scegliere il codice valido per ciascuna mutazione linguistica, consultare questa pagina.

• Ogni versione linguistica deve elencare se stessa e tutte le altre versioni linguistiche nei suoi attributi hreflang. Ciò significa che ogni pagina deve avere lo stesso numero di attributi hreflang.

• I link negli attributi hreflang devono essere assoluti e indicizzabili.

Un esempio di codice: <link rel=”alternate” href=”https://example.com/en-us/page” hreflang=”en-us” /> <link rel=”alternate” href=”https://example.com/en-gb/page” hreflang=”en-gb” /> <link rel=”alternate” href=”https://example.com/en-us/page” hreflang=”x-default” />

Controllare i titoli, gli h1, gli h2 e le descrizioni per individuare eventuali duplicati

Sebbene i titoli, le descrizioni e le intestazioni H1-H6 siano legati alla SEO on-page, la loro analisi nell’ambito di un audit tecnico può essere utile per individuare i duplicati. Per analizzarli, è possibile utilizzare qualsiasi crawler che raccolga questi tag. Quando si trovano titoli, tag H1-H6 e descrizioni duplicati, analizzare i dati della pagina e identificare la causa della duplicazione. Ciò può essere dovuto alla disponibilità del sito sia via HTTP che HTTPS, alla duplicazione dei tag delle categorie principali sulle pagine filtro o semplicemente a un errore umano in cui questi tag sono stati compilati in modo errato.

Ottimizzare gli attributi alt per le immagini

Gli attributi alt sono un attributo HTML utilizzato all’interno del tag <img> come questo: <img src=”image.jpg” alt=” Descrizione dell’immagine”>. Il suo scopo principale è fornire una descrizione testuale del contenuto dell’immagine. Questo testo viene mostrato se l’immagine non si carica e viene letto ad alta voce dagli screen reader per aiutare gli utenti ipovedenti. Un testo alt corretto e descrittivo può aiutare le immagini a posizionarsi nella ricerca per immagini e a migliorare la rilevanza complessiva della pagina. Se avete un sito web con molti contenuti visivi, l’ottimizzazione degli attributi alt è un passo più importante rispetto ai siti web classici che si basano su contenuti testuali. Molti crawler come Screaming Frog, Ahrefs, SemRush, ecc. analizzano gli attributi alt e possono fornire dati sugli attributi alt mancanti o vuoti. Potete leggere ulteriori informazioni sulla creazione di attributi alt descrittivi nei documenti ufficiali di Google.

Velocità, mobilità e facilità d’uso del sito web

Utilizzare il protocollo HTTPs

L’uso del protocollo sicuro HTTPS è essenziale per garantire la sicurezza della trasmissione dei dati tra l’utente e il server. Non solo aumenta la fiducia degli utenti, ma ha anche un impatto positivo sulla SEO. Per verificare la presenza di HTTPS, è sufficiente guardare la barra degli indirizzi del browser: dovrebbe apparire l’icona di un lucchetto. Per un’analisi dettagliata, è possibile utilizzare il servizio SSL Labs, che fornirà un rapporto completo sullo stato del certificato SSL e identificherà eventuali problemi. È inoltre importante assicurarsi che non vi siano contenuti misti – risorse HTTP su pagine HTTPS. Per questa analisi, è possibile utilizzare il rapporto HTTPS di Google Search Console, che mostra gli URL con HTTP e HTTPS.

Fonte: Search Console del nostro cliente

Migliorare i Core Web Vitals

Core Web Vitals è un insieme di metriche proposte da Google per valutare la qualità dell’esperienza utente su un sito web. Queste metriche si concentrano sulla velocità di caricamento, sull’interattività e sulla stabilità visiva dei contenuti della pagina. Comprendono tre indicatori chiave:

Metrica	Descrizione	Valore ottimale
Contenuto più grande (LCP)	Misura il tempo di caricamento dell’elemento visibile più grande della pagina (ad esempio, immagine o testo).	Meno di 2,5 secondi
Ritardo del primo ingresso (FID)	Misura il tempo necessario alla pagina per rispondere alla prima interazione dell’utente (ad esempio, il clic su un pulsante o un link).	Meno di 100 millisecondi
Spostamento cumulativo del layout (CLS)	Valuta la stabilità visiva della pagina, ossia il grado di spostamento degli elementi durante il caricamento della pagina.	Meno di 0,1

I dati raccolti da utenti reali possono essere visualizzati nel report di Search Console “Core web vitals” (dati aggregati) o in PageSpeed Insights (per i singoli test). Mentre si lavora sui Core Web Vitals, è necessario definire i problemi che hanno una grande influenza sulle metriche CWV. Ad esempio, durante l’ottimizzazione dell’LCP, è necessario definire quale dei 4 aspetti (TTFB, Ritardo di caricamento, Tempo di caricamento o Ritardo di rendering) contribuisce maggiormente a un punteggio LCP elevato. Nell’esempio seguente, è evidente che non è necessario concentrarsi sull’ottimizzazione di TTFB o Tempo di caricamento. Possiamo invece concentrare tutte le nostre energie sul miglioramento del Load Delay e poi del Render Delay.

Fonte: https://pagespeed.web.dev/ – test del sito webnike.com (a titolo di esempio). Il dominio è sfocato

Assicuratevi che il vostro sito sia mobile-friendly

La compatibilità con i dispositivi mobili è diventata un fattore cruciale dal 2018, quando Google è passato a un approccio di indicizzazione mobile-first. Ciò significa che Google ora utilizza principalmente la versione mobile di un sito web per il ranking e l’indicizzazione, piuttosto che la versione desktop. In Google Search Console, è possibile testare le proprie pagine facendo clic su “Test Live URL” nello strumento di ispezione degli URL e vedere come Googlebot-Mobile lo vede.

Comprimere le immagini

L’ottimizzazione delle immagini, finalizzata a comprimerle senza perdere qualità, contribuisce a velocizzare il caricamento del sito web, soprattutto se le pagine contengono molti contenuti grafici. Per comprimere le immagini si possono utilizzare strumenti online come TinyPNG o Squoosh. Vale anche la pena di verificare se vengono utilizzati formati di immagine moderni, come WebP, che possono ridurre notevolmente le dimensioni dei file.

Utilizzare un CDN per i siti web internazionali

L’uso di un CDN è sensato se il vostro sito web serve un’ampia gamma di regioni geograficamente distanti. Un CDN (Content Delivery Network) distribuisce il contenuto del sito su server situati più vicino agli utenti, riducendo la latenza durante il caricamento. È possibile verificare l’utilizzo di una CDN esaminando le intestazioni delle richieste HTTP negli strumenti per sviluppatori del browser (scheda Rete), dove possono comparire i riferimenti al provider della CDN, come Cloudflare o Akamai. Esistono anche strumenti online per testare le CDN. La configurazione della CDN si effettua in genere attraverso il pannello di hosting o il CMS. Utilizzare la cache La cache consente ai browser e ai server proxy di memorizzare copie delle risorse, riducendo il carico del server e accelerando il caricamento nelle visite successive. È possibile verificare la correttezza della cache negli strumenti per sviluppatori del browser: nella sezione Rete, osservare le intestazioni Cache-Control, Expires e ETag. Anche Google PageSpeed Insights fornisce raccomandazioni per il caching. È importante che le risorse statiche (immagini, script, stili) abbiano impostazioni di caching corrette e che il server abbia le regole corrispondenti configurate (ad esempio, in .htaccess o nella configurazione di nginx). Per verificare la cache, è possibile utilizzare servizi online come GiftOfSpeed.

Conclusioni

L’audit tecnico di un sito web non è una procedura una tantum, ma un processo continuo che richiede un’attenzione regolare ai fattori tecnici che possono influire sulle prestazioni e sulla visibilità del sito. Poiché ogni sito web è unico, l’attenzione specifica e la frequenza dei controlli varieranno. Questa lista di controllo per un audit tecnico SEO vi aiuterà a garantire che non abbiate dimenticato nulla di importante.