John Smith
You have 4 new messages
You have 4 new messages
Il web può essere paragonato ad una città in continua espansione, in cui ogni pagina rappresenta un edificio e ogni collegamento ipertestuale una strada che conduce ad altre destinazioni. Gli spider (o crawler) possono essere immaginati come esploratori automatizzati che percorrono queste strade al fine di analizzare i contenuti e inserirne tutte le informazioni nell’indice del motore di ricerca. Al loro arrivo in un sito, gli spider non si limitano a interpretarne il contenuto ma seguono i collegamenti interni ed esterni, ampliando progressivamente la propria “mappa” del territorio digitale.
Prima dell’era di Google, che oggi è certamente il motore di ricerca dotato della tecnologia di scansione più avanzata, il c.d. web invisibile era infinitamente più vasto rispetto a oggi e, conseguentemente, il raggio d’azione degli spider risultava molto più limitato. Già nel febbraio 1994, agli albori dell’era dei motori di ricerca, Martijn Koster – un software engineer danese – propose l’adozione di un protocollo per consentire ai webmaster di limitare l’attività degli spider sul proprio sito web, indicando bot indesiderati e/o aree del sito interdette al loro accesso. Si deve considerare che a quel tempo l’attività degli spider, per quanto molto ridotta, poteva impattare non poco sulla funzionalità dei webserver, dalle risorse decisamente limitate.
L’idea piacque così tanto che nell’arco di pochi mesi il RobotsNotWanted.txt poi semplificato in robots.txt divenne uno standard di fatto, supportato dai principali motori dell’epoca quali WebCrawler o Altavista.
Il robots.txt è un file di testo contenente le istruzioni dirette agli spider. È la prima segnaletica che un crawler verifica quando atterra su un sito e agisce come un “protocollo di esclusione” (Robots Exclusion Protocol). Ad oggi, si tratta di un protocollo cui i motori aderiscono su base volontaria, quindi inefficace nei confronti dei bot malevoli (malbot).
Per permettere a tutti gli spider di accedervi al fine di modulare la propria attività di scansione nel rispetto delle sue direttive, il robots.txt deve essere sempre raggiungibile all’indirizzo principale del nome host:
https://www.dominio.com/robots.txt
Qualsiasi altra collocazione lo rende inefficace. Inoltre, il file fa riferimento solo alle risorse presenti sullo specifico dominio su cui è stoccato e, salvo l’indirizzo delle sitemap.xml, non può contenere istruzioni relative a domini diversi.
Ad esempio, il robots.txt del terzo livello shop:
https://shop.dominio.com/robots.txt
Non avrà alcun impatto sul dominio www.
Predisporre il robots.txt è sempre fortemente consigliato in quanto, se il file non esiste, lo spider riceve una risposta 404 (risorsa non trovata), cosa da evitare in quanto può rallentare il processo di scansione del sito. In presenza di un errore 404, infatti, i bot potrebbero sospendere ogni attività di crawling per evitare di violare eventuali direttive temporaneamente irraggiungibili. Per questa ragione è buona prassi implementarlo sempre anche senza istruzioni specifiche, semplicemente per dichiararne l’esistenza.
Robots.txt e Sitemap: strumenti complementari per il percorso degli spider. Per comprendere il rapporto tra robots.txt e Sitemap si può proseguire con l’analogia urbana: Il robots.txt rappresenta, come abbiamo detto, la segnaletica, i cartelli di divieto d’accesso e le strade interdette.
La Sitemap equivale a una guida turistica, che indica agli spider i punti di interesse e i percorsi raccomandati.
Insieme costituiscono due strumenti complementari di gestione della scansione e dell’indicizzazione.
Il robots.txt appartiene ad una più ampia famiglia di strumenti di gestione degli spider. Questi ultimi si distinguono in particolare, si distinguono:
Strumenti di interdizione (Exclusion): bloccano l’accesso a risorse (es. robots.txt).
Strumenti di segnalazione (Inclusion): segnalano le risorse da indicizzare (es. Sitemap).
Strumenti di controllo e diagnostica: monitorano l’andamento del crawling (es. Google Search Console)
Il linguaggio utilizzato nel robots.txt è lineare e basato su direttive con ruoli specifici.
Direttiva | Funzione | Esempio | Note |
---|---|---|---|
User-agent: | Indica a quale spider si rivolge l'istruzione. | User-agent: Googlebot | Il simbolo * vale per tutti. |
Disallow: | Indica quale file o cartella si vuole bloccare dalla scansione. | Disallow: /cgi-bin/ | Blocca l'intera cartella. |
Allow: | Crea un'eccezione all'interno di un blocco Disallow più ampio. | Allow: /cgi-bin/file.html | Permette il file specifico anche se la cartella è bloccata. |
Regola della Specificità: In caso di direttive contrastanti, gli spider tendono ad attenersi a quelle più specifiche (ad esempio, un Allow su un file specifico prevale su un Disallow sulla cartella) o più restrittive (ad esempio, tra Disallow: / e Allow: / prevarrà sempre il Disallow Dove con lo slash (/) si intende tutte le pagine del sito).
Direttiva | Funzione | Utilizzo | Note |
---|---|---|---|
Wildcard (*) | Utilizzata per bloccare tutti gli URL contenenti una stringa o un parametro. | Disallow: /*?sessionid=* | |
Fine Stringa ($) | Utilizzata per specificare che la direttiva si applica solo all’URL che finisce esattamente in quel modo. | Disallow: /pippo.htm$ (Blocca solo .htm, non .html) | In questo caso blocca .htm e non .html. |
Clean-param (Yandex) | Indica quali parametri ignorare per evitare di scansionare pagine duplicate. | Clean-param: sessionid&sort&ref /catalog/ |
Un esempio pratico di uso congiunto di wildcard e fine stringa è costituito dall’interdizione (o il permesso) di tutti i file di un sito con una certa estensione:
Disallow: /*.doc$ (risultano interdetti i file .doc ma non quelli .docx)
Per quanto riguarda invece il clean-param, questa direttiva usata da Yandex istruisce lo spider a considerare un set di URL come identici se differiscono solo per i parametri elencati. Questo risparmia risorse di scansione gestendo i contenuti duplicati, rappresentando, di fatto – una soluzione molto più efficace del canonical meta link.
Direttiva | Funzione | Nota Importante |
---|---|---|
Sitemap: | Indica agli spider dove trovare la mappa completa delle risorse da indicizzare (XML Sitemap). | Fondamentale. Viene posizionata tipicamente alla fine del file, rivolta a tutti gli agenti. Non supporta wildcard (*). |
Crawl-delay: | Suggerisce il tempo di attesa (in secondi) tra le richieste. | Ignorata da Googlebot, ma utile per altri motori (es. Bing) per ridurre il carico del server. |
Il tag canonical può essere implementato in due modi principali:
Nell’HTML
Aggiungendo il tag <link rel=”canonical” href=”URL”> nella sezione <head> di tutte le versioni del contenuto.
Negli header HTTP
Utile per risorse non HTML (es. PDF). Esempio:
Link: <https://www.esempio.it/pagina>; rel=”canonical”
Usare URL assoluti e corretti (incluso protocollo https).
Inserire un solo canonical per pagina.
Evitare catene o loop di canonical (canonical che punta a pagina canonizzata altrove o che effettua redirezione)
Indicare come canonico un URL indicizzabile evitando, quindi, URL disallowed, rediretto, non disponibile, dotato di noindex, canonicalizzato
Non bloccare via robots.txt le versioni duplicate: il motore di ricerca deve poterle scansionare per leggere il canonical.
Includere il canonical anche nella versione originale della risorsa (self-canonical)
I CMS, specialmente in siti e-commerce o blog complessi, possono generare URL multiple in automatico.
E-commerce: lo stesso prodotto può essere accessibile da diverse categorie (/scarpe/nike e /promo/nike).
Filtri e parametri: i filtri di ricerca creano URL dinamici (?taglia=42, ?colore=rosso).
Pagine stampabili e PDF: versioni alternative della stessa pagina HTML.
Parametri di tracciamento: spesso aggiunti da tool di marketing (?utm_source=facebook)
Esempi di URL duplicati:
https://esempio.it/categoria/prodotto
https://esempio.it/offerte/prodotto
https://www.esempio.it/prodotto?utm_source=facebook
https://esempio.it/prodotto/stampa
https://esempio.it/prodotto.pdf
Senza un’adeguata gestione delle duplicazioni, il motore di ricerca potrebbe scegliere da solo quale versione indicizzare, con possibili conseguenze negative per SEO e UX.
Un esempio comune in cui il canonical tag diventa essenziale è quando lo stesso contenuto è disponibile in più formati, come una pagina HTML e una sua versione PDF scaricabile. L’obiettivo è comunicare a Google che la versione principale e da indicizzare è quella HTML, che offre una migliore esperienza di navigazione.
HTML (pagina web):
<head>
<title>Articolo</title>
<link rel=”canonical” href=”https://esempio.it/articolo” />
</head>
PDF (HTTP header):
HTTP/1.1 200 OK
Link: <https://esempio.it/articolo>; rel=”canonical”
Content-Type: application/pdf
In questo modo Google capirà che la versione da mostrare è quella HTML, non il PDF.
Vantaggi: migliore UX, coerenza delle metriche di analytics, niente cannibalizzazione SEO.
Nella sezione “Pagine” della Google Search Console, possono comparire avvisi come:
Questi report possono aiutare a identificare duplicate content e a verificare a livello macro la funzionalità dei nostri interventi di canonicalizzazione.
Pagina duplicata senza URL canonico selezionato dall’utente
Pagina duplicata, Google ha scelto una pagina canonica diversa da quella specificata dall’utente
Pagina alternativa con tag canonical appropriato”
Lo strumento “Controllo URL” (URL Inspection Tool) è essenziale per diagnosticare lo stato di una singola pagina. Inserendo un URL, si può verificare:
quale canonical è dichiarato;
quale canonical Google ha effettivamente scelto.
Esistono anche altri strumenti utili quali plugin SEO (es. Yoast per WordPress), estensioni browser e crawler SEO (Screaming Frog, Oncrawl, Botify etc…) che permettono di controllare rapidamente i canonical su larga scala.
I contenuti duplicati rappresentano un problema reale e comune che può compromettere la visibilità di un sito e complicare la gestione delle metriche. Il canonical tag è lo strumento chiave per gestirli in modo efficace, a patto di ricordarsi che agisce come un segnale e non una direttiva assoluta.
Implementarlo correttamente — sia in HTML che via HTTP header — permette di:
consolidare i segnali SEO su un unico URL;
offrire una migliore esperienza utente, mostrando la versione più adatta del contenuto;
garantire coerenza nei dati di analytics;
ottimizzare il crawl budget.
Verificare con regolarità in Google Search Console e mantenere un’architettura del sito pulita aiuta a evitare problemi e a garantire che le versioni canoniche siano correttamente recepite dai motori di ricerca.
In sintesi: la canonicalizzazione non è un optional, ma un pilastro della SEO tecnica moderna.
Se non sai come gestire i contenuti duplicati del tuo sito o ti risulta complesso, ricorda che con Ismartframe è possibile risolvere ogni problema in modo pratico e veloce, senza attività di sviluppo complesse e costose!