Checklist SEO tecnica

TL;DR — Una checklist tecnica SEO è l’elenco delle caselle tecniche che il tuo sito deve spuntare affinché i motori di ricerca possano trovare, leggere e mostrare le tue pagine. La versione breve di Google: una pagina deve essere scansionabile, indicizzabile, comprensibile e renderizzabile. Lavora sull’elenco in ordine di priorità e salta le sezioni che non si applicano alla dimensione del tuo sito — un sito aziendale di 20 pagine non deve preoccuparsi delle stesse cose di un negozio con 500 000 prodotti.

Evidence for this claim Google's minimum technical requirements include accessible Googlebot crawling, a successful HTTP response, and indexable content. Scope: Eligibility prerequisites, not a guarantee of indexing or ranking. Confidence: high · Verified: 2026-07-14 Google Search Essentials: Technical requirements Evidence for this claim Meeting technical requirements does not guarantee that Google will crawl, index, or serve a page. Scope: Google Search eligibility and selection behavior. Confidence: high · Verified: 2026-07-14 Google Search Essentials: Technical requirements

Cos’è questa checklist (e cosa non è)

La SEO tecnica è l’impianto idraulico. Prima che i tuoi contenuti possano posizionarsi, i motori di ricerca devono poter raggiungere le tue pagine, scaricarle, comprenderle e archiviarle. Una checklist tecnica SEO è semplicemente l’elenco ordinato delle cose che rendono possibile tutto ciò.

Non è tutta la SEO. Non copre la scrittura di buoni contenuti, il targeting delle parole chiave giuste o l’ottenimento di link. Queste cose contano enormemente — sono solo un lavoro diverso. Se vuoi la versione completa, quella è una checklist di audit SEO completa, ed è una cosa separata e più ampia. Questa pagina resta tecnica.

L’ordine di priorità

Fai queste cose più o meno dall’alto verso il basso. Più in alto sono nell’elenco, più possono rompere silenziosamente tutto ciò che sta sotto.

1. I motori di ricerca possono eseguire la scansione del tuo sito? Controlla che il tuo robots.txt non stia bloccando pagine che vuoi trovare. Correggi le pagine non trovate e gli errori del server (5xx).
2. Le tue pagine possono essere indicizzate? Assicurati di non dire accidentalmente a Google di mettere noindex su pagine importanti e che le versioni duplicate di una pagina puntino a una versione preferita.
3. Il tuo sito è su HTTPS? Il piccolo lucchetto. Ora è un’aspettativa di base.
4. Funziona bene sui telefoni? Google indicizza la versione mobile del tuo sito, quindi la tua versione per telefono deve avere gli stessi contenuti della versione desktop.
5. Hai una sitemap XML? Un semplice elenco dei tuoi URL che consegni a Google e Bing così non devono trovare tutto seguendo i link.
6. I tuoi dati strutturati sono validi? Opzionale, ma può farti ottenere risultati di ricerca dall’aspetto più ricco. (Non aumenterà il tuo posizionamento — più su questo mito sotto.)
7. Come va la velocità della tua pagina? I Core Web Vitals di Google misurano il caricamento, la risposta e la stabilità visiva.

I due miti da conoscere

• Bloccare una pagina in robots.txt non la rimuove da Google. Impedisce solo a Google di leggerla. Per rimuovere effettivamente una pagina, lascia che Google la esegua la scansione e aggiungi un tag noindex. (Bloccarla in robots.txt e aggiungere noindex è una trappola classica — il bot non può eseguire la scansione della pagina, quindi non vede mai il noindex.)
• I dati strutturati non sono un aumento del posizionamento. Possono rendere il tuo risultato più ricco, il che può aiutare i clic — ma aggiungere schema non ti fa salire nei risultati.

Non tutto si applica a te

La cosa più utile di questa checklist è sapere cosa saltare. Se gestisci un sito piccolo, puoi ignorare completamente la gestione del crawl budget — Google stesso dice che la maggior parte dei siti non deve pensarci. Vuoi il quadro completo, incluso chi ha bisogno di quelle sezioni avanzate? Passa alla scheda Avanzate.

TL;DR — La SEO tecnica è la base, non il soffitto: le pagine devono essere scansionabili → indicizzabili → comprensibili → renderizzabili prima che il lavoro sui contenuti possa dare i suoi frutti. Esegui la checklist in ordine di priorità e filtra le sezioni per tipo di sito — la maggior parte dei siti piccoli può saltare il crawl budget, il controllo della navigazione a faccette, l’analisi dei log e l’ingegneria del rendering JS, come conferma lo stesso documento sul crawl budget di Google. Sfatare due miti al volo: robots.txt non deindicizza e i dati strutturati non sono un fattore di ranking. Tratta i Core Web Vitals come obiettivi, non come porte di passaggio — è il linguaggio “cerca di” di Google stesso. E soddisfare ogni casella non garantisce comunque l’indicizzazione.

Evidence for this claim Google's minimum technical requirements include accessible Googlebot crawling, a successful HTTP response, and indexable content. Scope: Eligibility prerequisites, not a guarantee of indexing or ranking. Confidence: high · Verified: 2026-07-14 Google Search Essentials: Technical requirements Evidence for this claim Meeting technical requirements does not guarantee that Google will crawl, index, or serve a page. Scope: Google Search eligibility and selection behavior. Confidence: high · Verified: 2026-07-14 Google Search Essentials: Technical requirements

Il modello mentale: quattro condizioni

Google inquadra l’intera SEO tecnica attorno a quattro condizioni portanti: una pagina deve essere scansionabile, indicizzabile, comprensibile e renderizzabile. I suoi requisiti tecnici di Search Essentials li riducono a tre minimi: “Googlebot isn’t blocked,” (traduzione) « Googlebot non è bloccato », “The page works” (traduzione) « la pagina funziona » (ed è restituita con stato HTTP 200) e “The page has indexable content.” (traduzione) « la pagina contiene contenuti indicizzabili. » Tutto in questo checklist è in realtà al servizio di questi.

L’avvertenza critica, direttamente dallo stesso documento: “Just because a page meets these requirements doesn’t mean that a page will be indexed; indexing isn’t guaranteed.” (traduzione) «Solo perché una pagina soddisfa questi requisiti non significa che verrà indicizzata; l’indicizzazione non è garantita.» La SEO tecnica è un cancello che devi attraversare, non una leva che garantisce risultati. Ecco perché ho sempre sostenuto che la checklist tecnica è la base — la superi così che contenuti e link possano fare il loro lavoro, non al posto loro.

Prima di iniziare: quali sezioni ti riguardano?

Ogni checklist concorrente organizza per argomento e applica tutto a ogni sito. Questa è l’impostazione predefinita sbagliata. L’asse organizzativo migliore è il tipo di sito, perché Google stesso limita le sue linee guida più avanzate in base alla dimensione del sito. Dalla guida sul crawl budget per i siti di grandi dimensioni: “If your site doesn’t have a large number of pages that change rapidly, or if your pages seem to be crawled the same day that they are published, you don’t need to read this guide.” (traduzione) «Se il tuo sito non ha un gran numero di pagine che cambiano rapidamente, o se le tue pagine sembrano essere scansionate lo stesso giorno in cui vengono pubblicate, non hai bisogno di leggere questa guida.»

Le soglie (volutamente approssimative) di Google per quando il crawl budget inizia a contare:

• Siti grandi — 1 milione+ di pagine uniche con contenuti che cambiano circa settimanalmente.
• Siti medio-grandi — 10 000+ pagine uniche con contenuti che cambiano molto rapidamente (giornalmente).
• Siti con una grande quota di URL bloccati nello stato “Discovered - currently not indexed” (traduzione) « Rilevato: attualmente non indicizzato » di Search Console.

Quindi ecco la suddivisione che eseguirei davvero:

Percorso base — siti piccoli / brochure / attività locali (< ~10K URL): verifica della scansionabilità, verifica di indicizzazione/canonical, HTTPS, parità mobile, una sitemap XML, un giro di Core Web Vitals, dati strutturati validi dove ottengono un rich result. Salta crawl budget, controllo della navigazione a faccette, analisi dei log file e ingegneria del rendering JS completamente.

Percorso avanzato — siti grandi / ecommerce / con molto JS / enterprise: tutto nel percorso base più gestione del crawl budget, controllo della navigazione a faccette, audit del rendering JavaScript, analisi dei log del server e (se internazionale) hreflang.

1. Scansionabilità

• Correttezza di robots.txt. Conferma di non disalloware nulla che vuoi indicizzare. Google: “A robots.txt file tells search engine crawlers which URLs the crawler can access on your site. This is used mainly to avoid overloading your site with requests; it is not a mechanism for keeping a web page out of Google.” (traduzione) «Un file robots.txt dice ai crawler dei motori di ricerca quali URL il crawler può accedere sul tuo sito. Viene usato principalmente per evitare di sovraccaricare il tuo sito con richieste; non è un meccanismo per tenere una pagina web fuori da Google.» Usalo per tenere i bot fuori da spazi a basso valore (ricerca interna, combinazioni infinite di parametri), non come strumento di deindicizzazione. Questo è lo stesso territorio che l’approfondimento su robots.txt copre per intero.
• La trappola della contraddizione robots.txt + noindex. Non bloccare un URL in robots.txt e fare affidamento su un noindex su di esso. Google: “While Google won’t crawl or index the content blocked by a robots.txt file, we might still find and index a disallowed URL if it is linked from other places on the web.” (traduzione) «Mentre Google non scansionerà né indicizzerà il contenuto bloccato da un file robots.txt, potremmo comunque trovare e indicizzare un URL non consentito se è linkato da altri posti sul web.» Il bot non può scansionare la pagina, quindi non vede mai il noindex, e l’URL può comunque apparire nudo nei risultati. Per rimuovere una pagina: consenti la scansione + noindex, o proteggila con password.
• Errori di scansione. Correggi 4xx e 5xx inaspettati. Google indicizza solo pagine servite con un 200, e “Client and server error pages aren’t indexed.” (traduzione) «Le pagine di errore client e server non vengono indicizzate.»
• Catene e loop di redirect. Comprimi A→B→C→D in A→D. Le catene sprecano scansione e perdono un po’ a ogni salto. Il materiale su scansione e redirect approfondisce qui.

2. Indicizzabilità

• Copertura dell’indice. Nel report sull’indicizzazione delle pagine di Search Console, confronta ciò che vuoi indicizzare con ciò che è effettivamente indicizzato. Indaga su grandi gruppi “Discovered/Crawled - currently not indexed” (traduzione) « Rilevate o sottoposte a scansione: attualmente non indicizzate ».
• Canonicalizzazione. Punta gli URL duplicati e quasi duplicati a una versione preferita. Google definisce rel="canonical" “a strong signal that the specified URL should become canonical” (traduzione) « un forte segnale che l’URL specificato dovrebbe diventare canonico »: un segnale, non una direttiva che il motore deve necessariamente seguire. E soprattutto: “Don’t use the robots.txt file for canonicalization purposes.” (traduzione) « Non usare il file robots.txt per la canonicalizzazione. » Controlla di non inviare segnali canonici contrastanti tra tag HTML, header HTTP e sitemap — l’approfondimento sulla canonicalizzazione spiega come consolidarli.
• Contenuti duplicati. Parametri, versioni di stampa, fughe di staging, divisioni http/https e www/non-www creano tutti duplicati. Scegline uno, canonicalizza o reindirizza il resto.

3. HTTPS

Base, non opzionale. Servi l’intero sito su HTTPS, reindirizza http a https e cerca contenuti misti (una pagina sicura che carica un’immagine, uno script o un foglio di stile non sicuri). Il riscontro di Chris Green in SEO nel 2026 stima l’adozione di HTTPS al “91%+” — non vuoi essere nel 9% in coda.

4. SEO mobile

Google utilizza l’indicizzazione mobile-first: “Google uses the mobile version of a site’s content, crawled with the smartphone agent, for indexing and ranking.” (traduzione) « Google usa la versione mobile dei contenuti di un sito, sottoposta a scansione con lo user agent per smartphone, per l’indicizzazione e il posizionamento. » La checklist di parità, direttamente dal documento mobile-first di Google:

• “Make sure that your mobile site contains the same content as your desktop site.” (traduzione) « Assicurati che il sito mobile contenga gli stessi contenuti del sito desktop. »
• “Make sure that the title element and the meta description are equivalent across both versions of your site.” (traduzione) « Assicurati che l’elemento title e la meta description siano equivalenti nelle due versioni del sito. »
• “Make sure that your mobile and desktop sites have the same structured data.” (traduzione) « Assicurati che i siti mobile e desktop contengano gli stessi dati strutturati. »
• “Use the same robots meta tags on the mobile and desktop site.” (traduzione) « Usa gli stessi meta tag robots nei siti mobile e desktop. »
• “Don’t lazy-load primary content upon user interaction.” (traduzione) « Non caricare i contenuti principali in lazy loading dopo un’interazione dell’utente. »
• “Make sure that the mobile site has the same alt text for images as the desktop site.” (traduzione) « Assicurati che le immagini del sito mobile abbiano lo stesso testo alternativo di quelle del sito desktop. »

L’errore più comune è un modello mobile ridotto che elimina silenziosamente contenuti, link o dati strutturati presenti sul desktop — Google indicizza la versione più sottile.

5. Sitemap e scoperta

• Igiene della sitemap XML. Usa URL assoluti e canonici; rimani sotto il limite di 50 MB / 50 000 URL per file; elenca solo URL indicizzabili e canonici; mantieni lastmod accurato. Riferiscilo in robots.txt (Sitemap: https://example.com/sitemap.xml) così i motori lo scoprono automaticamente. Trattamento completo nel materiale sulle sitemap XML.
• Bing conta ancora. Dalle linee guida di Bing di luglio 2025: “Sitemaps remain a foundational signal for ensuring comprehensive URL coverage across your site,” (traduzione) « Le sitemap restano un segnale fondamentale per garantire una copertura completa degli URL del sito », “XML remains the preferred format for sitemaps,” (traduzione) « XML resta il formato preferito per le sitemap » e “The lastmod field in your sitemap remains a key signal, helping Bing prioritize URLs for recrawling.” (traduzione) « Il campo lastmod della sitemap resta un segnale importante, che aiuta Bing a dare priorità agli URL da sottoporre nuovamente a scansione. »
• IndexNow. La maggior parte delle checklist incentrate su Google lo omette, ma è un intervento semplice, attuale e gratuito: il consiglio di Bing è di “Use IndexNow for real-time URL submission, instantly notifying Bing and participating search engines” (traduzione) « Usa IndexNow per inviare gli URL in tempo reale e avvisare immediatamente Bing e i motori di ricerca aderenti » quando il contenuto cambia. Completa le sitemap piuttosto che sostituirle. (Nota: Google non usa IndexNow per le pagine generali.)

6. Dati strutturati

• Cosa fa: ottiene l’idoneità per i rich result e aiuta le macchine (e gli LLM) a comprendere la tua pagina. “Adding structured data can enable search results that are more engaging to users… which are called rich results.” (traduzione) «L’aggiunta di dati strutturati può abilitare risultati di ricerca più coinvolgenti per gli utenti… che vengono chiamati rich result.»
• Cosa non fa: aumentare il posizionamento. I documenti di Google descrivono lo schema strettamente come idoneità per i rich result e comprensione da parte delle macchine — non come un segnale di ranking. Non venderlo né stanziare budget come strategia di ranking.
• Formato: “In general, Google recommends using JSON-LD for structured data if your site’s setup allows it, as it’s the easiest solution for website owners to implement and maintain at scale.” (traduzione) «In generale, Google consiglia di usare JSON-LD per i dati strutturati se la configurazione del tuo sito lo consente, poiché è la soluzione più semplice da implementare e mantenere su larga scala per i proprietari di siti web.» Valida con il Rich Results Test. Il materiale sui dati strutturati copre i tipi specifici che vale la pena implementare.

7. Core Web Vitals ed esperienza di pagina

Obiettivi, non vincoli — la formulazione reale di Google è “strive to,” che la maggior parte delle checklist sovrastima come soglie rigide di superamento/fallimento:

• LCP — “strive to have LCP occur within the first 2.5 seconds of the page starting to load.” (traduzione) «cerca di far sì che l’LCP avvenga entro i primi 2,5 secondi dall’inizio del caricamento della pagina.»
• INP — “strive to have an INP of less than 200 milliseconds.” (traduzione) «cerca di avere un INP inferiore a 200 millisecondi.»
• CLS — “strive to have a CLS score of less than 0.1.” (traduzione) «cerca di avere un punteggio CLS inferiore a 0,1.»

E il rapporto con il posizionamento, che le persone sovrastimano notevolmente: “Google Search always seeks to show the most relevant content, even if the page experience is sub-par.” (traduzione) «Google Search cerca sempre di mostrare i contenuti più pertinenti, anche se l’esperienza di pagina è sotto la media.» Buone Core Web Vitals sono un criterio di spareggio tra risultati pertinenti, non un superamento della pertinenza. Misura con dati reali degli utenti (CrUX/field), non solo con punteggi di laboratorio.

8. Aggiunte avanzate (solo per siti grandi / ecommerce / con molto JavaScript)

• Crawl budget. Solo se hai superato le soglie di Google sopra. Capacità + domanda; guadagni budget rimuovendo sprechi (esplosioni di parametri, combinazioni di navigazione a faccette, trappole per spider, URL duplicati) molto più che cercando di far indicizzare a Google “di più.” Vedi l’approfondimento sul crawl budget.
• Rendering JavaScript. Conferma che contenuti critici e link esistano nell’HTML renderizzato e siano raggiungibili tramite veri link <a href>, non solo navigazione al clic. Questo è territorio della JavaScript SEO.
• Controllo della navigazione a faccette. Decidi quali combinazioni di filtro/ordinamento siano indicizzabili/indicizzabili e controlla il resto.
• Analisi dei file di log. La verità di base su cosa i bot effettivamente recuperano, con quale frequenza e quali codici di stato ottengono.
• hreflang — solo se sei realmente multiregionale/multilingue. È un argomento abbastanza ampio da meritare un materiale SEO internazionale dedicato; non aggiungerlo a metà.

9. Accesso dei crawler AI / LLM (breve, mirato)

Due elementi essenziali nel 2026, e niente di più — il lavoro approfondito su GEO/AEO vive nel materiale sull’AI-search, non qui:

• Decidi l’accesso dei crawler AI in robots.txt. Consenti o blocca esplicitamente gli user-agent AI che ti interessano (i bot per training, AI-search e fetch su richiesta dell’utente sono bot diversi). La prospettiva di Chris Green: “Robots.txt is no longer just crawl housekeeping. It’s becoming a policy surface.” (traduzione) «Robots.txt non è più solo manutenzione del crawling. Sta diventando una superficie di policy.»
• I dati strutturati fungono anche da contesto macchina per gli LLM — un motivo in più per avere uno schema valido, non un nuovo flusso di lavoro.

10. Come dare priorità a ciò che trovi

È qui che la maggior parte delle checklist fallisce: ti danno 90 elementi senza alcuna ponderazione. Non sistemare tutto — sistema ciò che fa la differenza. Il consiglio del mio amico Patrick sugli audit clienti, a cui torno sempre: “If clients are coming to you asking for an audit, they already have a pain point. Talk to them. Solve that one thing and they’ll be happy with the audit.” (traduzione) «Se i clienti vengono da te chiedendo un audit, hanno già un problema concreto. Parla con loro. Risolvi quella singola cosa e saranno soddisfatti dell’audit.» Lo stesso Modello di audit SEO lo inquadra come “sweating the small stuff rarely does much for your rankings” (traduzione) «sudare per le piccole cose raramente fa molto per il tuo posizionamento» — meglio spendere “80% of your time fixing the 20% of things that matter.” (traduzione) «l’80% del tuo tempo a sistemare il 20% delle cose che contano.»

E fai un passo indietro sull’intero esercizio: una checklist ti porta a okay. John Mueller di Google ha ripetutamente sottolineato che i fondamentali da soli portano a risultati decenti ma non eccezionali — la vera dominanza deriva dalla profondità tematica e dall’autorità, non dallo spuntare ogni casella tecnica. La checklist sgombera il campo; contenuti e link costruiscono la casa.

Vuoi la versione completa del sito?

Questa pagina è volutamente solo tecnica. Se vuoi un audit più ampio — tecnico più on-page, contenuti e off-page — quello è il SEO Audit Checklist, una cosa separata e più estesa. Non cercare di far fare a questa pagina entrambi i lavori.

Riepilogo AI

Una sintesi della versione Advanced:

• La SEO tecnica è il minimo indispensabile. Le quattro condizioni di Google: scansionabile, indicizzabile, comprensibile, renderizzabile. Soddisfarle è necessario ma non sufficiente — “indexing isn’t guaranteed.” (traduzione) « l’indicizzazione non è garantita. »
• Filtra per tipo di sito, non solo per argomento. La maggior parte dei piccoli siti può saltare il crawl budget, il controllo della navigazione a faccette, l’analisi dei log e l’ingegneria del rendering JS. Le soglie di Google: 1M+ pagine che cambiano settimanalmente, o 10K+ che cambiano giornalmente, o molti “Discovered - currently not indexed.” (traduzione) « Rilevato: attualmente non indicizzato. »
• Ordine di priorità: scansionabilità (robots.txt, 4xx/5xx, catene di redirect) → indicizzazione (copertura, canonicalizzazione, duplicati) → HTTPS + contenuto misto → parità mobile-first → sitemap XML + IndexNow → dati strutturati → Core Web Vitals.
• Due miti da sfatare: robots.txt non deindicizza (gli URL bloccati ma collegati possono comunque apparire nudi); i dati strutturati non sono un fattore di ranking (solo idoneità ai rich result).
• I CWV sono obiettivi, non porte — il linguaggio “cerca di” di Google: LCP < 2,5 s, INP < 200ms, CLS < 0,1. E “Google Search always seeks to show the most relevant content, even if the page experience is sub-par.” (traduzione) « Google Search cerca sempre di mostrare i contenuti più pertinenti, anche quando l’esperienza sulla pagina è inferiore alla media. »
• Parità mobile-first: stessi contenuti, titoli/meta, dati strutturati, meta tag robots e testo alternativo su mobile e desktop; non caricare pigramente il contenuto primario all’interazione.
• Dai priorità all’impatto (risolvi il vero problema del cliente; 80/20). Una checklist ti porta a “ok”; la profondità tematica vince.
• Versione completa del sito (tecnica + contenuti + link) = la checklist SEO Audit separata.

Documentazione ufficiale

Documentazione di fonte primaria dai motori di ricerca.

Google

• Requisiti tecnici di Google Search — i requisiti minimi di scansionabilità, funzionamento e indicizzabilità e l’avvertenza “l’indicizzazione non è garantita”.
• Introduzione a robots.txt — cosa fa e cosa non fa robots.txt.
• Creare e inviare una sitemap — formati, il limite di 50 MB/50 000 URL e il riferimento in robots.txt.
• Consolidare URL duplicati — segnali di canonicalizzazione e “non usare robots.txt per la canonicalizzazione”.
• Introduzione al markup dei dati strutturati — rich result e raccomandazione JSON-LD.
• Comprendere i Core Web Vitals — gli obiettivi “cerca di” LCP/INP/CLS.
• Esperienza della pagina nei risultati di Google Search — pertinenza vs. esperienza della pagina.
• Best practice per l’indicizzazione mobile-first — i requisiti di parità mobile/desktop.
• Ottimizza il tuo crawl budget — chi ha davvero bisogno della gestione del crawl budget, con soglie (precedentemente intitolato “Guida del proprietario di siti di grandi dimensioni alla gestione del crawl budget”; il documento è stato spostato sotto la documentazione di Google Crawling Infrastructure).

Bing / Microsoft

• Mantenere i contenuti rilevabili con le sitemap nella ricerca basata sull’IA — la guida di Bing di luglio 2025 su sitemap + IndexNow.
• Bing Webmaster Guidelines — crawling, indicizzazione, ranking e qualità (cita per riferimento; la pagina è renderizzata in JS).

Citazioni dalla fonte

Dichiarazioni ufficiali di Google e Bing. Dove un link è un deep link, salta al passaggio citato nella pagina di origine.

Google — i requisiti minimi

• “Client and server error pages aren’t indexed.” (traduzione) «Le pagine di errore del client e del server non vengono indicizzate.» — Google Search Central, Google Search technical requirements. Vai alla citazione
• “Just because a page meets these requirements doesn’t mean that a page will be indexed; indexing isn’t guaranteed.” (traduzione) «Il fatto che una pagina soddisfi questi requisiti non significa che verrà indicizzata; l’indicizzazione non è garantita.» Vai alla citazione

Google — robots.txt e canonicalizzazione

• “A robots.txt file tells search engine crawlers which URLs the crawler can access on your site. This is used mainly to avoid overloading your site with requests; it is not a mechanism for keeping a web page out of Google.” (traduzione) «Un file robots.txt indica ai crawler dei motori di ricerca a quali URL del sito possono accedere. Viene utilizzato principalmente per evitare di sovraccaricare il sito con richieste; non è un meccanismo per escludere una pagina web da Google.» Vai alla citazione
• “rel=“canonical” link annotations are a strong signal that the specified URL should become canonical… Don’t use the robots.txt file for canonicalization purposes.” (traduzione) «Le annotazioni del link rel=“canonical” sono un forte segnale che l’URL specificato dovrebbe diventare canonico… Non utilizzare il file robots.txt per scopi di canonicalizzazione.» — Google, Consolidate duplicate URLs. Leggi il documento

Google — dati strutturati e Core Web Vitals

• “Adding structured data can enable search results that are more engaging to users… which are called rich results.” (traduzione) «L’aggiunta di dati strutturati può consentire risultati di ricerca più coinvolgenti per gli utenti… chiamati rich results.» — Google, Intro to structured data markup. Leggi il documento
• “In general, Google recommends using JSON-LD for structured data if your site’s setup allows it, as it’s the easiest solution for website owners to implement and maintain at scale.” (traduzione) «In generale, Google consiglia di utilizzare JSON-LD per i dati strutturati se la configurazione del tuo sito lo consente, poiché è la soluzione più semplice da implementare e mantenere su larga scala per i proprietari di siti web.» Leggi il documento
• “strive to have LCP occur within the first 2.5 seconds” (traduzione) « cerca di ottenere un LCP entro i primi 2,5 secondi »; “strive to have an INP of less than 200 milliseconds” (traduzione) « cerca di mantenere l’INP sotto i 200 millisecondi »; “strive to have a CLS score of less than 0.1.” (traduzione) « cerca di mantenere il punteggio CLS sotto 0,1. » — Google, Understanding Core Web Vitals. Leggi il documento
• “Google Search always seeks to show the most relevant content, even if the page experience is sub-par.” (traduzione) «Google Search cerca sempre di mostrare i contenuti più pertinenti, anche se l’esperienza della pagina è al di sotto della media.» — Google, Page experience. Leggi il documento

Google — indicizzazione mobile-first

• “Google uses the mobile version of a site’s content, crawled with the smartphone agent, for indexing and ranking.” (traduzione) «Google utilizza la versione mobile dei contenuti di un sito, indicizzata con l’agente smartphone, per l’indicizzazione e il posizionamento.» — Google, Mobile-first indexing best practices. Leggi il documento

Google — crawl budget (chi ne ha bisogno)

• “If your site doesn’t have a large number of pages that change rapidly, or if your pages seem to be crawled the same day that they are published, you don’t need to read this guide.” (traduzione) «Se il tuo sito non contiene molte pagine che cambiano rapidamente, oppure se le pagine sembrano essere sottoposte a scansione il giorno stesso della pubblicazione, non è necessario leggere questa guida.» — Google, Ottimizza il crawl budget. Vai alla citazione

Bing — sitemap e IndexNow (luglio 2025)

• “XML remains the preferred format for sitemaps.” (traduzione) « XML resta il formato preferito per le sitemap. » / “The lastmod field in your sitemap remains a key signal, helping Bing prioritize URLs for recrawling.” (traduzione) « Il campo lastmod della sitemap resta un segnale importante, che aiuta Bing a dare priorità agli URL da sottoporre nuovamente a scansione. » — Fabrice Canel & Krishna Madhavan, Bing Webmaster Blog. Leggi il post

Patrick Stox — come dare priorità a un audit

• “If clients are coming to you asking for an audit, they already have a pain point. Talk to them. Solve that one thing and they’ll be happy with the audit.” (traduzione) «Se i clienti vengono da te chiedendo un audit, hanno già un problema. Parla con loro. Risolvi quella singola cosa e saranno soddisfatti dell’audit.» — Patrick Stox, citato nel Free SEO Audit Template di Ahrefs. Vai alla citazione

Quale checklist dovrei eseguire davvero?

Non eseguire la stessa lista di 90 elementi su ogni sito. Inizia da qui.

D1. Quanti URL ha il tuo sito e quanto velocemente cambiano i contenuti?

• Meno di ~10 000 URL, che cambiano occasionalmente → esegui il percorso base e fermati: controllo di base della scansionabilità, controllo di base di indicizzazione e canonicalizzazione, HTTPS, parità mobile, una sitemap XML, un ciclo di Core Web Vitals, dati strutturati validi dove meritano un rich result. Salta crawl budget, controllo della navigazione a faccette, analisi dei log e gestione del rendering JS. Vai a D3.
• 10 000+ URL che cambiano ogni giorno, o 1M+ che cambiano ogni settimana, o molti “Scoperti - attualmente non indicizzati” → esegui il percorso avanzato (percorso base + crawl budget + navigazione a faccette + rendering JS + log). Vai a D2.

D2. Il sito è ricco di JavaScript o internazionale?

• Ricco di JS (SPA, contenuti/link renderizzati lato client) → aggiungi un audit del rendering: conferma che i contenuti critici e i link <a href> esistano nell’HTML renderizzato. Questo è l’elemento che più probabilmente ti sta costando indicizzazione in silenzio.
• Davvero multi-regione / multilingua → aggiungi hreflang, fatto correttamente, nel suo flusso di lavoro dedicato. Se non sei davvero internazionale, saltalo.
• Nessuno dei due → procedi a D3.

D3. Cosa ha evidenziato l’audit — e cosa dovresti sistemare per primo?

• Un blocco di crawl/indicizzazione (disallow in robots.txt su pagine importanti, noindex di massa, canonical errato, 5xx a livello di sito) → sistema prima, sempre. Questi bloccano tutto il resto.
• Molti problemi medi, tempo limitato → applica l’80/20: sistema il ~20% che fa la differenza, e se è un cliente, sistema prima il problema specifico per cui è venuto da te. Non consegnare 90 elementi indifferenziati.
• Rimangono solo problemi estetici/di confine → hai superato la soglia minima. Smetti di ottimizzare l’infrastruttura e dedicati a contenuti e link.

D4. Vuoi davvero la versione completa del sito?

• Sì — tecnico + contenuti + on-page + link → questa checklist tecnica non fa per te. Esegui invece la Checklist SEO Audit più ampia; questa pagina è solo tecnica per progettazione.
• No — solo la base tecnica → sei nella pagina giusta.

Versione in una riga: piccolo + stabile → solo percorso base; grande/JS/internazionale → aggiungi le sezioni avanzate; poi sistema prima i blocchi di crawl/indicizzazione e dai priorità al resto in base all’impatto.

La checklist SEO tecnica

Due percorsi. Esegui il percorso base su qualsiasi sito; aggiungi gli elementi avanzati solo se rientri nei tipi di sito indicati (10K+ URL che cambiano ogni giorno, 1M+ ogni settimana, oppure un sito con molto JavaScript o internazionale).

Percorso base — ogni sito

Scansionabilità

• robots.txt non blocca nulla che vuoi indicizzare (e blocca spazi a basso valore come la ricerca interna).
• Nessun URL importante è bloccato in robots.txt e fa affidamento su un noindex (la trappola).
• 4xx/5xx inattesi corretti; le pagine importanti restituiscono 200.
• Catene/cicli di redirect ridotti a un singolo salto.

Indicizzabilità

• Report sull’indicizzazione delle pagine riconciliato — ciò che vuoi indicizzare lo è davvero.
• I canonical puntano a una versione preferita; nessun segnale contrastante tra tag HTML, header HTTP e sitemap.
• http→https e www/non-www consolidati in un’unica versione.

HTTPS

• Intero sito su HTTPS; http reindirizza a https.
• Nessun contenuto misto (pagina sicura che carica risorse non sicure).

Mobile

• La versione mobile ha stesso contenuto, titoli/meta, dati strutturati, tag robots meta e testo alternativo come il desktop.
• Il contenuto primario non viene caricato in modo lazy all’interazione dell’utente.

Sitemap

• La sitemap XML elenca solo URL canonici e indicizzabili; lastmod accurato; sotto 50MB/50.000 URL per file.
• Sitemap inviata in Search Console e Bing Webmaster Tools, e referenziata in robots.txt.

Dati strutturati

• Schema (JSON-LD) valido nel Rich Results Test, e usato solo dove ottiene un rich result.

Core Web Vitals

• LCP, INP, CLS revisionati su dati field/CrUX rispetto agli obiettivi di Google (2,5 s / 200ms / 0,1) — trattati come obiettivi, non come porte di passaggio/fallimento.

Percorso avanzato — solo per siti grandi / ecommerce / con molto JS / internazionali

• Budget di crawl revisionato (solo se oltre le soglie di Google); sprechi rimossi (parametri, facet, trappole, duplicati).
• Rendering JS verificato — contenuto critico e link <a href> presenti nell’HTML renderizzato.
• Navigazione a faccette: stabilisci quali combinazioni sono scansionabili e indicizzabili.
• Log del server analizzati per sprechi di scansione e URL importanti mai sottoposti a scansione.
• IndexNow configurato per l’invio in tempo reale delle modifiche a Bing e ai motori partecipanti.
• hreflang corretto e reciproco (solo se realmente multi-regione/multilingua).
• Accesso dei crawler AI deciso esplicitamente in robots.txt.

I modelli mentali

1. Le quattro condizioni — scansionabile → indicizzabile → comprensibile → renderizzabile. Ogni elemento tecnico serve a una di queste. Quando una pagina non performa, trova quale condizione sta fallendo prima di toccare qualsiasi cosa: è almeno scansionabile? Indicizzabile? Compresa? Renderizzata?

2. Base, non traguardo. La SEO tecnica crea le basi perché contenuti e link possano fare il loro lavoro. “Indexing isn’t guaranteed” (traduzione) « l’indicizzazione non è garantita » anche quando superi — quindi non trattare un audit tecnico verde come “SEO fatta.”

3. Filtra per tipo di sito. La mossa più utile: decidere in anticipo quali sezioni non si applicano. Sito piccolo/stabile → percorso base, salta la parte avanzata. Grande/JS/internazionale → aggiungila. Google filtra le sue stesse linee guida sul crawl budget in questo modo; dovresti farlo anche tu.

4. Segnali vs. direttive. Sapere quali controlli Google deve rispettare e quali sono solo forti segnali. noindex è una direttiva; rel=canonical è “a strong signal” (traduzione) « un forte segnale » che Google può sovrascrivere; gli obiettivi CWV sono “strive to” (traduzione) « obiettivi da perseguire », non porte. Etichettare male un segnale come garanzia è da dove viene la maggior parte dei consigli sbagliati.

5. Impatto sulla completezza (80/20). Una checklist di 90 elementi è un menu, non una lista di cose da fare. Risolvi il ~20% che fa la differenza, risolvi prima il problema concreto e smetti di ottimizzare la parte tecnica una volta che la base è solida.

6. Questa è la parte tecnica. Le meccaniche di crawl/indicizzazione/rendering/servizio vivono qui; qualità dei contenuti, targeting delle parole chiave e link vivono nella più ampia Checklist di Audit SEO. Mantieni il confine pulito così nessuno dei due lavori viene fatto a metà.

SEO tecnico — riferimento rapido

Cosa fa ogni controllo

Obiettivi Core Web Vitals (i numeri “da perseguire” di Google)

Soglie “mi interessa?” del crawl budget (quelle di Google, volutamente approssimative)

• ~1M+ pagine che cambiano circa settimanalmente → sì.
• 10K+ pagine che cambiano quotidianamente → sì.
• Grande gruppo “Discovered - currently not indexed” (traduzione) « Rilevato: attualmente non indicizzato » → sì.
• Altrimenti → “you don’t need to read this guide.” (traduzione) « non è necessario leggere questa guida. »

Fatti rapidi

• Limite sitemap: 50 MB / 50 000 URL per file; XML preferito; referenziala in robots.txt.
• Dati strutturati: rich results, non posizionamenti. JSON-LD raccomandato.
• IndexNow: Bing/Yandex/altri — non Google. Google indicizza la versione mobile.
• Parità mobile: stessi contenuti, titoli/meta, dati strutturati, meta tag robots, testo alternativo.

Miti ed errori da evitare

Le trappole più comuni — molte sono miti ampiamente ripetuti che vale la pena correggere:

• “Bloccare un URL in robots.txt lo tiene fuori da Google.” No. Google: “it is not a mechanism for keeping a web page out of Google.” (traduzione) « non è un meccanismo per escludere una pagina web da Google. » Un URL non consentito può essere comunque indicizzato (nudo, senza snippet) se è linkato esternamente. Usa noindex o la protezione con password.
• “Bloccalo in robots.txt e metti noindex per maggiore sicurezza.” La ferita autoinflitta più comune. Se l’URL è bloccato, Googlebot non ne esegue mai la scansione, quindi non vede mai il noindex — e l’URL può comunque emergere nudo. Scegli una delle due: consenti il crawl + noindex, oppure non consentire (accettando che possa comunque apparire).
• “Aggiungere schema migliora il posizionamento.” No. Google inquadra i dati strutturati puramente come idoneità ai rich results e comprensione da parte delle macchine — non come segnale di ranking. Vendilo come risultati più ricchi, non posizioni più alte.
• “Superare i Core Web Vitals batte un concorrente più pertinente.” No. “Google Search always seeks to show the most relevant content, even if the page experience is sub-par.” (traduzione) « Google Search cerca sempre di mostrare i contenuti più pertinenti, anche quando l’esperienza sulla pagina è inferiore alla media. » CWV è un segnale simile a un criterio di spareggio, non un elemento che prevale sulla pertinenza.
• “Le soglie CWV sono cancelli rigidi di superato/fallito.” La parola di Google è “strive to” (traduzione) « cercare di » — sono obiettivi. Inseguire un punteggio di laboratorio perfetto a scapito di tutto il resto è uno sforzo sprecato.
• “Il crawl budget conta per ogni sito.” No. Google limita la propria guida a 1M+ pagine (cambiamenti settimanali) o 10K+ (quotidiani). Alla maggior parte dei siti viene detto apertamente “non hai bisogno di leggere questa guida.” Non sprecare un incarico su un piccolo sito con interventi di crawl budget puramente formali.
• “rel=canonical è una direttiva che Google deve seguire.” No — è “a strong signal.” (traduzione) « un forte segnale. » Google può e sceglie un canonico diverso quando altri segnali sono in conflitto. Riduci i segnali in conflitto piuttosto che assumere che il tag vinca.
• “Un audit tecnico verde significa che la SEO è fatta.” No. “Indexing isn’t guaranteed” (traduzione) « l’indicizzazione non è garantita » anche quando superi. La SEO tecnica è la base; contenuti e link devono comunque esserci.
• “Esegui la stessa lista di 90 elementi su ogni sito.” Il differenziatore è sapere cosa saltare. Segmenta le sezioni per tipo di sito e dai priorità in base all’impatto, o annegherai i clienti in voci irrilevanti.

SOP: eseguire una checklist SEO tecnica (ricorrente)

Un controllo ripetibile. Circa 60–90 minuti per un piccolo sito; un giorno o più per siti grandi o con molto JavaScript. Eseguilo ogni trimestre, oppure dopo una migrazione importante, una riprogettazione o una modifica del CMS.

1. Conferma il tipo di sito e scegli un percorso. Conta gli URL (Search Console → Pagine, o un crawl) e nota quanto velocemente cambiano i contenuti. Sotto ~10K e stabile → solo percorso base. Oltre le soglie, o con molto JavaScript/internazionale → aggiungi le sezioni avanzate. Questo stabilisce cosa saltare.
2. Esegui un crawl del sito con Screaming Frog, Ahrefs Site Audit o simili. Cattura i codici di stato, le catene di reindirizzamento, gli URL bloccati, i canonical, l’indicizzabilità e la profondità.
3. Controlla prima robots.txt. Recupera /robots.txt, conferma che nulla di importante sia disallow, e controlla la trappola disallow-più-noindex. Conferma che la riga Sitemap: sia presente.
4. Riconcilia l’indicizzazione. Nel report Page Indexing di Search Console, confronta ciò che è indicizzato con ciò che vuoi indicizzare. Indaga sui grandi gruppi “Discovered/Crawled - currently not indexed” (traduzione) « Rilevate o sottoposte a scansione: attualmente non indicizzate » e nello stato “Duplicate” (traduzione) « Duplicata ».
5. Verifica HTTPS e parità mobile. Conferma HTTPS su tutto il sito senza contenuti misti. Poi confronta la pagina renderizzata su mobile con quella desktop per contenuti, titoli/meta, dati strutturati, meta tag robots e testo alt (Google indicizza la versione mobile).
6. Valida sitemap e dati strutturati. Conferma che la sitemap XML elenchi solo URL canonical, indicizzabili con lastmod accurato; esegui i template chiave attraverso il Rich Results Test.
7. Preleva i Core Web Vitals dai dati di campo. Usa il report CrUX/field in Search Console o PageSpeed Insights — non solo i punteggi di laboratorio — e confronta con gli obiettivi 2,5 s / 200ms / 0,1 s.
8. (Percorso avanzato) Analizza i log e il crawl budget. Leggi i log del server per sprechi di scansione e URL importanti non scansionabili; controlla il rendering JS e le combinazioni di navigazione a faccette.
9. Dai priorità ai risultati per impatto, non per numero. Metti i blocchi di crawl/indicizzazione in cima; applica l’80/20 al resto; se è un cliente, inizia con il suo problema concreto.
10. Registra un riferimento e ricontrolla al ciclo successivo. Registra lo stato così il passaggio del prossimo trimestre misura i progressi, non un nuovo inizio.

Prompt AI pronti all’uso

Punti di partenza copia-incolla per fare triage di una checklist SEO tecnica con un LLM. Verifica sempre l’output dell’LLM rispetto ai documenti primari e ai tuoi dati di crawl — trattali come aiuti alla bozza, non come fonti di verità.

Scegli il percorso giusto per un sito

Gestisco un sito web con circa [N] URL, e i contenuti cambiano circa [ogni quanto]. È costruito su [CMS/framework], è [monolingue / multiregionale], ed è [statico / renderizzato con JavaScript]. In base alle soglie di dimensione del sito di Google per il crawl budget, dimmi quali sezioni di una checklist SEO tecnica si applicano davvero a me e quali posso saltare tranquillamente. Sii esplicito su cosa saltare e perché.

Fai triage di un export di crawl per impatto

Ecco un export CSV da un crawl del sito [incolla le colonne: URL, codice di stato, indicizzabilità, canonical, catena di reindirizzamento, stato robots.txt]. Raggruppa i problemi in (1) blocchi di crawl/indicizzazione da risolvere per primi, (2) correzioni a impatto medio, (3) cosmetici/basso impatto. Per ogni gruppo, spiega la conseguenza SEO in una frase. Non dirmi di “sistemare tutto” — classifica per impatto.

Spiega uno stato di indicizzazione specifico

Un lotto dei miei URL mostra “[stato esatto di Search Console, es. Discovered - currently not indexed]”. Spiega le cause probabili in ordine di priorità, come diagnosticare ciascuna e la correzione concreta. Segnala qualsiasi cosa che sia un sintomo di crawl budget vs. un problema per pagina.

Controllo di sanità per la trappola robots.txt + noindex

Ecco il mio robots.txt [incolla] e un elenco di URL che sto cercando di tenere fuori da Google [incolla]. Per ogni URL, dimmi se la mia configurazione attuale lo terrà davvero fuori dall’indice o cadrà nella trappola “bloccato in robots.txt ma ancora indicizzabile tramite link”, e dai la correzione corretta (allow-crawl + noindex, o protezione con password).

Prepara un piano di correzione in ordine di priorità

Trasforma questi problemi tecnici confermati [incolla] in un piano di correzione ordinato per uno sviluppatore: prima gli ostacoli a scansione e indicizzazione, poi gli altri interventi in ordine di impatto. Per ciascuno indica la modifica precisa e una motivazione in una riga. Il problema principale dichiarato dal cliente è [X]: metti in evidenza per prime le correzioni pertinenti.

Strumenti per lavorare sulla checklist di SEO tecnica

Inizia con test mirati per il problema che stai verificando. Un singolo punteggio tutto-in-uno spesso nasconde la differenza tra accesso di crawling, comportamento di risposta, segnali di indicizzazione, rendering e prestazioni sul campo.

Gli strumenti gratuiti di Patrick

• Google Index Checker controlla lo stato osservabile, reindirizzamenti, noindex e blocchi canonici, poi ti indirizza a URL Inspection per lo stato di indicizzazione effettivo di Google.
• robots.txt Tester testa gli URL rispetto alle regole dei bot e mostra la regola allow o disallow vincente. Usalo prima di modificare i controlli di crawling.
• XML Sitemap Validator controlla la sintassi della sitemap, l’inventario degli URL e i problemi del file prima di inviarlo.
• Canonicalization Checker confronta i segnali canonici HTML e HTTP e testa l’URL di destinazione per conflitti.
• Bulk HTTP Status Code Checker controlla i codici di stato, le destinazioni, le catene e i loop su un insieme di URL.
• Schema Markup Validator valida la sintassi dei dati strutturati e i requisiti dei rich result di Google prima della pubblicazione.
• Render Gap confronta l’HTML iniziale con l’output renderizzato per contenuti, link, canonici e direttive robots dipendenti da JavaScript.
• Core Web Vitals Checker separa i dati di campo disponibili da un controllo delle prestazioni attuale, così non confondi una singola esecuzione di laboratorio con i dati utente.
• Mobile-Friendly Tester controlla viewport, layout responsive, target di tocco e altri segnali di implementazione mobile correlati.
• Log File Analyzer trasforma i log del server in prove di ciò che i bot di ricerca hanno effettivamente scaricato, il che è più utile sui siti di grandi dimensioni.

Strumenti dei motori di ricerca

• Google Search Console fornisce Page Indexing, URL Inspection, Crawl Stats, Sitemaps, Core Web Vitals, report sui rich result, azioni manuali e problemi di sicurezza.
• Bing Webmaster Tools aggiunge le viste di indicizzazione e prestazioni di prima parte di Bing, IndexNow, Site Explorer, Site Scan e Crawl Control.

Crawler e strumenti del browser

• Ahrefs Site Audit o Screaming Frog SEO Spider è il livello scalabile per eseguire il crawl di template, codici di stato, direttive, link interni e dati strutturati.
• Chrome DevTools espone la risposta di rete, il DOM renderizzato, gli errori della console e la traccia delle prestazioni per singole pagine.
• PageSpeed Insights e CrUX forniscono le viste di prestazioni di laboratorio e sul campo di Google; usa i dati di campo come riferimento stabile per l’esperienza utente quando disponibili.

Mettiti alla prova: Checklist di SEO tecnica

Cinque domande rapide su cosa dovrebbe esserci in una checklist di SEO tecnica e su come dare priorità. Scegli una risposta per ciascuna, poi controlla.

Risorse che meritano il tuo tempo

I miei scritti correlati

• Guida introduttiva alla SEO tecnica — il quadro più ampio in cui si inserisce questa checklist.
• Modello di audit SEO — il mio approccio 80/20, incentrato sull’impatto, e il consiglio “risolvi il loro problema concreto”; anche la cosa più vicina all’audit completo del sito.
• Cosa è successo bloccando con robots.txt due pagine ben posizionate — il mio esperimento di prima parte su cosa fa realmente il blocco tramite robots.txt.
• Indicizzata, nonostante il blocco in robots.txt — il meccanismo dietro la trappola disallow-plus-noindex.
• Robots.txt e SEO: tutto quello che devi sapere.

I miei interventi

• Come funziona la ricerca (SlideShare) — la mia spiegazione di crawling, rendering, indicizzazione e ranking, ovvero il processo che questa checklist intende proteggere.

I miei lavori pubblicati degni di citazione

• Web Almanac 2021 — capitolo sulla SEO — sono stato autore principale; la fonte per i tassi di conflitto canonico tra segnali sul web reale.
• Rankable, episodio 65 — Come ordinare le priorità della SEO tecnica (iPullRank) — io su come dare priorità ai problemi tecnici in una roadmap, che è esattamente il principio organizzativo di questa checklist.

Dal resto del settore

• Requisiti tecnici di Google Search — la dichiarazione definitiva dei requisiti minimi e l’avvertenza che “l’indicizzazione non è garantita”.
• Ottimizza il crawl budget (Google) — la fonte per la soglia basata sulla dimensione del sito (pagina rinominata da “Guida del proprietario di un sito di grandi dimensioni alla gestione del crawl budget” e spostata sotto Crawling Infrastructure).
• Mantenere i contenuti rilevabili con le sitemap nella ricerca basata sull’IA (Bing) — le indicazioni su sitemap e IndexNow che la maggior parte delle checklist solo Google tralascia.
• SEO nel 2026: standard più elevati, influenza dell’IA e un web ancora in ritardo (Chris Green, Search Engine Land) — una verifica della realtà su dove si trovano realmente i siti (HTTPS 91%+, robots.txt come “superficie politica”).
• Web Almanac 2022 — capitolo sulla SEO (HTTP Archive) — dati su metodi di canonicalizzazione e adozione di schema sul web.
• Checklist SEO tecnica: la guida completa (DebugBear) — una prospettiva fortemente orientata alle performance sullo stesso territorio.
• Checklist SEO tecnica in oltre 90 punti (Kristina Azarenko) — una checklist alternativa approfondita e orientata alla priorità.

Statistiche da citare

• Adozione HTTPS ~91%+. Dove si trovano realmente i siti rispetto al requisito HTTPS di base in vista del 2026 (dati HTTP Archive, tramite Chris Green). Fonte
• L’adozione del canonical è salita dal 65% (2024) al 67%+ (2025). La copertura del tag canonical sta crescendo ma è lungi dall’essere universale. Fonte
• ~67% delle immagini manca di un attributo loading; il 91%+ degli iframe ne è privo. Vittorie di performance facili che la maggior parte dei siti lascia ancora sul tavolo. Fonte
• Segnali canonici in conflitto apparsi su ~0,3–0,4% delle pagine. Piccolo ma reale — un motivo per cui i siti più grandi dovrebbero verificare i conflitti canonici tra segnali (capitolo SEO del Web Almanac 2021, che ho guidato). Fonte
• Limite file sitemap: 50 MB / 50 000 URL per file — il tetto massimo oltre il quale suddividere le sitemap grandi (Google). Fonte

Cronologia modifiche