Struttura degli URL

TL;DR — Un URL è l’indirizzo di una pagina. Gli URL corretti sono leggibili, minuscoli, usano trattini tra le parole e descrivono l’argomento della pagina. Ma non aspettarti che gli URL spostino molto il ranking: servono soprattutto al crawl e alle persone. L’errore più grande è cambiare URL che non hai bisogno di cambiare.

Che cos’è un URL

Un URL — Uniform Resource Locator — è l’indirizzo completo di una pagina sul web. Scomponendolo ottieni una manciata di parti:

https://www.example.com/blog/url-structure/?ref=newsletter#anatomy
└─┬─┘   └┬┘ └────┬────┘└───────┬──────────┘└──────┬──────┘└──┬───┘
scheme  sub   domain         path             query string  fragment

• Schema — https://. Usa HTTPS: è la versione sicura e il default atteso.
• Sottodominio — www. (oppure blog., shop., ecc.). Facoltativo.
• Dominio — example.com. Il nome del tuo sito.
• Percorso — /blog/url-structure/. Cartelle e «slug» della pagina. È la parte che di solito controlli.
• Query string — ?ref=newsletter. Parametri aggiuntivi, spesso usati per tracking o filtri.
• Frammento — #anatomy. Porta a un punto della pagina. I motori di ricerca lo ignorano per lo più.

Che cosa rende buono un URL

Tienilo semplice:

• Usa parole, non numeri. /blog/url-structure/ è meglio di /p?id=4321.
• Usa trattini tra le parole. red-shoes, non red_shoes o redshoes.
• Usa solo lettere minuscole. Page e page possono essere trattati come due URL diversi.
• Mantienilo ragionevolmente breve e leggibile, abbastanza da permettere a una persona di indovinare che cosa contiene la pagina.
• Rispecchia la struttura del sito. Le cartelle dovrebbero riflettere il modo in cui il sito è organizzato.

L’errore più comune

Gli URL sono un fattore di ranking molto piccolo. Google ha detto per anni che le parole chiave in un URL «have hardly any effect» — «hanno un effetto minimo». Quindi non tormentarti per inserire parole chiave negli URL e, soprattutto, non rinominare un gruppo di URL esistenti nella speranza di migliorare il ranking. Quasi mai funziona e cambiare URL comporta rischi reali (link rotti, perdita di equità se i redirect sono configurati male). Se i tuoi URL funzionano già, lasciali stare.

Vuoi le parole di Google su trattini e underscore, i problemi legati alla distinzione tra maiuscole e minuscole e il modo in cui i parametri sprecano crawl budget? Passa alla scheda Advanced.

TL;DR — La struttura degli URL riguarda soprattutto crawl e comprensione, non è una leva di ranking. Le parole chiave negli URL sono un segnale «very light weight» — «molto leggero» — che perde peso dopo l’indicizzazione. Usa i trattini (Google unisce sugli underscore e separa sui trattini). Le maiuscole e minuscole del percorso possono identificare URL distinti in base al comportamento del server, quindi una combinazione incoerente può creare percorsi di crawl duplicati. Il vero rischio per l’efficienza del crawl sono i parametri. E cambiare URL aiuta «very, very rarely» — «molto, molto raramente» —, quindi non farlo se non sono davvero rotti.

Anatomia di un URL

Ogni URL si scompone nelle stesse parti e ciascuna ha implicazioni SEO proprie:

I caratteri riservati devono essere codificati in percentuale secondo lo standard; usa testo non ASCII nella lingua dei tuoi utenti (traslitterato quando aiuta) invece di ID incomprensibili.

Gli URL influenzano il ranking? A malapena.

È la domanda a cui tutti vogliono davvero una risposta. Quella onesta è: in modo minimo.

• Le parole chiave nell’URL sono, secondo la Starter Guide di Google, un fattore per cui «the keywords in the name of the domain (or URL path) alone have hardly any effect beyond appearing in breadcrumbs» — «le parole chiave nel nome del dominio (o nel percorso URL) da sole hanno un effetto minimo oltre alla loro comparsa nei breadcrumb». John Mueller le ha definite «a very small ranking factor» — «un fattore di ranking molto piccolo» — e «a very light weight factor… less so after [the page is] indexed» — «un fattore molto leggero, ancora meno dopo che [la pagina è] indicizzata». Una parola chiave nell’URL può quindi aiutare Google nella scoperta iniziale, prima che abbia sottoposto a crawl il contenuto, ma una volta indicizzata la pagina è il contenuto a parlare.
• Conta più della formulazione dell’URL la profondità del clic, cioè quanti clic separano la pagina dalla homepage. Una struttura logica delle directory aiuta Googlebot a stimare la frequenza del crawl (una cartella /policies/ cambia raramente; /promotions/ cambia spesso), ma questo riguarda il crawl, non il ranking.

In sintesi: non ristrutturare gli URL solo per inserire parole chiave. Il beneficio non vale la compressione.

Trattini e underscore

Questa è l’unica regola tecnica davvero consolidata e riguarda specificamente Google.

Google tratta il trattino come separatore di parole e l’underscore come unione di parole. Quindi red_shoes viene analizzato come un singolo token redshoes, mentre red-shoes viene analizzato come red e shoes. La spiegazione di Gary Illyes è: «many things on the internet have an underscore in them, [Google] can’t easily segment at underscore» — «molte cose su Internet hanno un underscore, [Google] non riesce a segmentare facilmente sull’underscore». Matt Cutts lo ha detto allo stesso modo nel 2007 («we still join on the underscore and separate on the dash» — «uniamo ancora sull’underscore e separiamo sul trattino») e la documentazione attuale di Google raccomanda ancora i trattini.

C’è una sfumatura da conoscere: nel 2016 Mueller ha detto che la differenza «doesn’t matter» — «non importa» —, creando confusione; ma la documentazione attiva dice ancora di usare i trattini ed è la scelta più sicura.

Bing è diverso. Un portavoce di Bing ha confermato: «We do not differentiate between dash and underscore in our URL ranking features» — «non distinguiamo tra trattino e underscore nelle funzioni di ranking degli URL». Quindi gli underscore non ti danneggiano su Bing. Ma, poiché ottimizzi per entrambi, usa i trattini: sono corretti per Google e neutri per Bing.

Lunghezza dell’URL e mito della canonicalizzazione

Sentirai dire che «gli URL più brevi si posizionano meglio». È una lettura errata.

La lunghezza dell’URL non ha un impatto diretto sul ranking. La verità è più circoscritta: quando Google sceglie un canonical tra URL duplicati o quasi duplicati, può preferire quello più breve e pulito, in particolare un URL pulito rispetto allo stesso URL con parametri di tracking aggiunti. Come ho scritto nella mia ricerca sulla canonicalizzazione: «This has been misconstrued over the years by SEOs to say that all your URLs should be shorter. But that’s not what was meant.» — «Nel corso degli anni i SEO hanno frainteso questo punto, interpretandolo come se tutti gli URL dovessero essere più brevi. Ma non era questo il significato». La preferenza è per una versione pulita e senza parametri rispetto a un duplicato ricco di parametri, non una legge universale del tipo «vince il più breve». La lunghezza è solo uno dei circa 40 segnali di canonicalizzazione che Google usa, insieme alla preferenza per HTTPS, www contro non-www, slash finale e maiuscole/minuscole.

La distinzione tra maiuscole e minuscole è un rischio reale

I percorsi, i nomi file e i parametri di query degli URL distinguono maiuscole e minuscole; il nome host no. Quindi example.com/Apple e example.com/apple sono due URL diversi (ma Example.com e example.com sono lo stesso host).

Google in genere riconosce quando due combinazioni di maiuscole e minuscole servono contenuti identici e li canonicalizza, ma non dovresti costringerlo a fare questo lavoro. Se entrambe le versioni sono raggiungibili e non vengono consolidate, ottieni contenuti duplicati. E c’è un problema che molti ignorano: anche robots.txt distingue maiuscole e minuscole. Una direttiva Disallow per /Private/ non blocca /private/. Standardizza sulle minuscole e aggiri tutto il problema.

Le combinazioni esatte di maiuscole e minuscole che risolvono, reindirizzano o restituiscono 404 dipendono dal server e dalla configurazione dell’applicazione: non esiste una regola universale. Testa le risposte effettive (curl -I o un crawler) invece di dare per scontato il risultato.

Slash finali

Uno slash finale conta ovunque tranne che alla radice:

• Dominio radice: example.com e example.com/ sono trattati allo stesso modo: nessuna differenza.
• Tutto il resto: example.com/page e example.com/page/ sono URL diversi. Se entrambi sono raggiungibili e nessuno si consolida sull’altro, hai contenuti duplicati.

Nota che aggiungere uno slash finale a un file reale (page.html/) non carica il file. Come ho scritto nella mia guida agli slash finali: «There’s always a risk with changes, so unless your setup is causing issues I wouldn’t try to force a change to your URLs.» — «Con le modifiche c’è sempre un rischio, quindi, a meno che la tua configurazione non causi problemi, non cercherei di forzare un cambiamento agli URL». Scegli un formato, applicalo con redirect e canonical e mantieni coerenti i link interni. Come per le maiuscole e minuscole, il comportamento effettivo fuori dalla radice dipende da server e applicazione: verifica ciò che la tua configurazione restituisce davvero invece di supporlo.

Parametri URL: il vero problema per il crawl

È con i parametri di query che la struttura URL crea i maggiori danni SEO su larga scala. Nella mia guida ai parametri URL li divido in due categorie:

• Parametri attivi cambiano il contenuto della pagina: filtri, ordinamento, paginazione, lingua, ricerca interna.
• Parametri passivi non cambiano il contenuto: ID affiliati, tag UTM, ID di sessione.

Entrambi creano problemi. I parametri passivi nei link interni creano URL duplicati e sprecano crawl budget; i parametri attivi (soprattutto i filtri a faccette) possono generare combinazioni di URL quasi infinite, una classica trappola per spider. La guida di Google per l’e-commerce avverte proprio di questo: contenuti non trovati, lo stesso contenuto sottoposto a crawl ripetutamente e un crawler che crede che il sito abbia pagine infinite perché un URL contiene un valore che cambia continuamente, come un timestamp.

Come controllarli:

• rel=canonical è oggi la leva principale: punta le varianti all’URL pulito. Per i parametri di variante facoltativi, Google consiglia di usare “the URL with the query parameter omitted as the canonical URL.” (traduzione) «l’URL senza il parametro di query come URL canonical».
• noindex quando una pagina con parametri non dovrebbe davvero stare nell’indice.
• robots.txt per tenere i bot fuori da spazi di parametri chiaramente spazzatura (ma ricorda che controlla il crawl, non l’indicizzazione).
• E per il tracking nello specifico: usa il tracking degli eventi analytics invece dei parametri URL quando puoi; la maggior parte dei sistemi analytics può registrare i dati senza gonfiare gli URL.

Una nota storica: il vecchio URL Parameters tool di Google Search Console è stato deprecato e rimosso nel 2022. I tag canonical sono il sostituto.

Come appare un URL pulito

Riassumendo, il formato obiettivo è:

• Parole descrittive, non ID numerici
• Lettere minuscole
• Trattini tra le parole
• HTTPS
• Nessun parametro non necessario
• Riflette la struttura delle directory del sito
• Stabile e permanente (URL che non dovrai cambiare)

Dovresti cambiare gli URL? Quasi mai.

Questa è la conclusione pratica più importante. A John Mueller è stato chiesto se cambiare gli URL aiuta la SEO: «Will it help the site? Very, very rarely… Will a change negatively affect the site for a while until it’s reprocessed? Probably.» — «Aiuterà il sito? Molto, molto raramente. Il sito subirà un impatto negativo per un po’, finché non verrà elaborato di nuovo? Probabilmente».

Le ragioni giustificate per cambiare URL sono circoscritte: URL davvero criptici o illeggibili (example.com/p?=123), riferimenti obsoleti incorporati nell’URL o la correzione di un problema di trovabilità, non una preferenza estetica per percorsi più brevi, puliti o ricchi di parole chiave su URL che funzionano già. Se un difetto concreto giustifica la modifica, trattala come una vera migrazione, non come una correzione isolata: crea una mappatura completa da vecchio a nuovo URL per ogni percorso interessato, imposta redirect diretti e permanenti (301) su ciascuno (evita catene di redirect che passano da un vecchio URL intermedio), aggiorna link interni e tag canonical affinché puntino direttamente ai nuovi URL, aggiorna le sitemap XML e usa gli strumenti di cambio indirizzo quando si applicano. Poi monitora sia i vecchi sia i nuovi URL: statistiche di crawl, copertura di Search Console e log del server, invece di supporre che la mappa dei redirect sia completa perché alcuni URL campione hanno funzionato. Una gestione solida dei redirect riduce il rischio di perdere equità, ma né Google né altri garantiscono i tempi di recupero o che il ranking venga trasferito senza variazioni. La permanenza conta più che mai ora che gli assistenti AI citano URL: i link che si rompono al cambio diventano citazioni rotte.

Dove si colloca

La struttura URL si sovrappone a diversi argomenti vicini nel mondo della struttura del sito e del crawl: canonicalizzazione (i ~40 segnali che scelgono un URL rappresentativo), parametri URL (l’approfondimento su attivi e passivi), gestione degli slash finali, architettura del sito e crawl depth (dove conta davvero la profondità del clic, non la formulazione dell’URL) e redirect (come spostare gli URL senza perdere equità). Ognuno ha il proprio approfondimento.

Riepilogo AI

Una sintesi della versione Advanced:

• Un URL ha sei parti: schema (https://), sottodominio, dominio, percorso/slug, query string (?key=value) e frammento (#section). Il nome host non distingue maiuscole e minuscole; il percorso sì.
• Gli URL influenzano appena il ranking. Per Google le parole chiave nell’URL sono un segnale con «hardly any effect beyond appearing in breadcrumbs» — «effetto minimo oltre alla comparsa nei breadcrumb» —, «very light weight» — «molto leggero» — e che perde peso dopo l’indicizzazione. La profondità del clic conta più della formulazione dell’URL.
• Trattini e underscore (specifico di Google): Google separa sui trattini e unisce sugli underscore, quindi red_shoes = redshoes. Usa i trattini. Bing non distingue tra i due.
• La lunghezza dell’URL non è un fattore di ranking. L’idea «vince il più breve» nasce da una lettura errata della canonicalizzazione: Google può preferire un URL pulito allo stesso URL con parametri, non «più breve è sempre meglio».
• La distinzione tra maiuscole e minuscole crea un rischio di contenuti duplicati. Percorsi e nomi file distinguono maiuscole e minuscole (/Apple ≠ /apple), così come robots.txt. Standardizza sulle minuscole.
• Slash finale: identico solo sul dominio radice; ovunque altro /page ≠ /page/.
• I parametri sono il vero problema di crawl: parametri passivi (UTM, sessione, affiliati) e attivi (filtri, ordinamento, paginazione) creano duplicati e spreco di crawl. Controllali con rel=canonical (primario), noindex e robots.txt; il tool URL Parameters di GSC è stato rimosso nel 2022.
• Cambiare URL aiuta «very, very rarely» (Mueller): fallo solo per URL davvero rotti o criptici oppure per un difetto concreto, mai per una preferenza estetica. Quando è giustificato, trattalo come una migrazione completa: mappa completa vecchio-nuovo, 301 diretti, link interni, canonical e sitemap aggiornati e monitoraggio di entrambi gli URL, senza tempi di recupero garantiti.

Documentazione ufficiale

Documentazione dei motori di ricerca basata su fonti primarie.

Google

• URL structure best practices — trattini invece di underscore, percorsi descrittivi, coerenza nelle maiuscole, pochi parametri e codifica in percentuale.
• SEO Starter Guide — gli URL come breadcrumb nei risultati; le parole chiave nel percorso URL «hanno un effetto minimo».
• Canonicalization — scelta dell’URL rappresentativo e scenari comuni di URL duplicati (HTTP/HTTPS, www, slash finale, maiuscole e parametri).
• Designing a URL structure for ecommerce sites — contenuti non trovati, crawl duplicato, crawl infinito, percorsi descrittivi invece di ID numerici e canonical senza parametro.

Bing / Microsoft

• Bing Webmaster Guidelines — mantieni gli URL brevi e ricchi di parole chiave; evita variabili di sessione e docID.
• Better than canonical — URL Normalization — il metodo preferito da Bing per unificare le varianti con parametri.

Citazioni dalla fonte

Dichiarazioni registrate di Google e Bing. Ogni link porta direttamente al passaggio citato che la pagina sorgente supporta.

Trattini e underscore

• “We recommend using hyphens (-) instead of underscores (_) to separate words.” — «Raccomandiamo di usare i trattini (-) invece degli underscore (_) per separare le parole». — Google Search Central, documentazione sulla struttura degli URL. Vai alla citazione
• Gary Illyes (Google), sul motivo: Google raccomanda i trattini perché “many things on the internet have an underscore in them, they can’t easily segment at underscore.” (traduzione) «molte cose su Internet hanno un underscore e non riescono a segmentare facilmente sull’underscore». Copertura
• Matt Cutts (Google), 2007: “We still join on the underscore and separate on the dash.” — «Uniamo ancora sull’underscore e separiamo sul trattino». Copertura
• Portavoce di Bing: “We do not differentiate between dash and underscore in our URL ranking features.” — «Non distinguiamo tra trattino e underscore nelle funzioni di ranking degli URL». Copertura

Parole chiave negli URL

• Google SEO Starter Guide: “the keywords in the name of the domain (or URL path) alone have hardly any effect beyond appearing in breadcrumbs.” — «le parole chiave nel nome del dominio (o nel percorso URL) da sole hanno un effetto minimo oltre alla comparsa nei breadcrumb». Vai alla citazione
• John Mueller (Google): le parole chiave negli URL sono “a very light weight factor” — «un fattore molto leggero» — e contano ancora meno dopo l’indicizzazione. Copertura
• John Mueller (Google): gli URL “provide minimal additional signals for search engines.” — «forniscono segnali aggiuntivi minimi ai motori di ricerca». Copertura

Lunghezza dell’URL / canonicalizzazione

• Google: durante la deduplicazione tende a scegliere come canonical l’URL più breve e pulito, non una regola universale secondo cui «il più breve si posiziona meglio». Copertura

Distinzione tra maiuscole e minuscole

• John Mueller (Google): percorso URL, nome file e parametri di query distinguono maiuscole e minuscole; il nome host no, e anche robots.txt distingue maiuscole e minuscole, quindi sii coerente. Copertura

Cambiare gli URL

• John Mueller (Google): “Will it help the site? Very, very rarely… Will a change negatively affect the site for a while until it’s reprocessed? Probably.” — «Aiuterà il sito? Molto, molto raramente. Una modifica influirà negativamente sul sito per un po’, finché non verrà rielaborata? Probabilmente». Copertura

Checklist per l’audit degli URL

Un passaggio per intercettare i problemi URL che causano davvero difficoltà:

• HTTPS ovunque — nessun URL HTTP raggiungibile senza redirect verso HTTPS.
• Un solo host canonical — www e non-www consolidati in una sola versione.
• Minuscole coerenti — nessun percorso con maiuscole miste che crei duplicati; verifica che le regole di robots.txt corrispondano alle maiuscole/minuscole realmente usate.
• Trattini, non underscore o parole concatenate, per separare le parole negli slug.
• Slash finale deciso e applicato — un formato per tutto il sito (tranne il dominio radice), con redirect e canonical a sostenerlo.
• Slug descrittivi, non ID numerici (/url-structure/ non /p?id=4321).
• Parametri controllati — i parametri passivi di tracking (UTM, sessione, affiliati) non sono sui link interni; i parametri attivi (filtro/ordinamento) hanno canonical verso l’URL pulito.
• Nessuna trappola per spider — navigazione a faccette, calendari o URL con timestamp non generano spazi URL quasi infiniti.
• I frammenti non vengono usati per distinguere il contenuto (Google li ignora).
• Caratteri riservati/non ASCII codificati correttamente in percentuale.
• Le due versioni dell’URL non sono entrambe indicizzate — controlla GSC per report divisi tra varianti di maiuscole, slash o parametri.
• Nessuna modifica URL inutile in programma — se gli URL funzionano, lasciali stare; se un difetto concreto giustifica una modifica, sono in coda una mappatura completa vecchio-nuovo, 301 diretti, link interni/canonical/sitemap aggiornati e monitoraggio post-modifica di entrambi, non solo un redirect e un ping della sitemap.

I modelli mentali

1. Gli URL servono al crawl e alle persone, non al ranking. Prima di ottimizzare un URL, chiediti che cosa stai davvero cercando di migliorare. Le parole chiave nell’URL sono «very light weight» — «molto leggere». I vantaggi reali sono leggibilità ed efficienza del crawl: ottimizza per questi, non per un aumento di ranking immaginario.

2. La coerenza batte l’ottimizzazione. Il danno degli URL deriva dall’incoerenza: maiuscole miste, entrambe le versioni con e senza slash, la stessa pagina raggiungibile con e senza parametri. Scegli un formato pulito e applicalo. Uno schema «imperfetto» ma coerente è meglio di uno «ottimale» applicato in modo irregolare.

3. I quadranti degli URL duplicati. La maggior parte dei problemi SEO degli URL nasce da una pagina raggiungibile tramite molti URL: HTTP/HTTPS, www/non-www, slash/no-slash, maiuscole e parametri. Ognuno è una decisione di canonicalizzazione. Mappa le varianti esistenti, poi consolidale con redirect (per i casi rigidi) o canonical (per quelli morbidi).

4. Parametri: attivi e passivi. I parametri passivi (tracking) non dovrebbero mai cambiare il contenuto e idealmente non dovrebbero mai comparire in un link interno: trasferisci questi dati negli eventi analytics. I parametri attivi (filtro/ordinamento/paginazione) cambiano il contenuto e richiedono una gestione deliberata di canonical e indice, per non esplodere in una trappola per spider.

5. La regola decisionale per cambiare un URL. La risposta predefinita è no. Cambia un URL solo se è davvero criptico, rotto o non trovabile, mai per un guadagno marginale di parole chiave. Quando lo fai, 301 + sitemap + cambio indirizzo, ogni volta. Il «very, very rarely» di Mueller è il punto di partenza.

Best practice per gli URL — scheda rapida

Strumenti per l’audit della struttura URL

• Canonicalization Checker — verifica se una variante di parametro, maiuscole o formato invia segnali coerenti di canonical e indicizzabilità.
• Redirect Chain Mapper — esamina ogni passaggio prima che un URL raggiunga il formato HTTPS, host, percorso e slash preferito.
• Redirect Checker — esegue controlli rapidi quando viene pubblicato un piccolo insieme di URL rinominati o normalizzati.
• Un crawler completo del sito — inventaria percorsi, parametri, canonical, codici di stato e destinazioni dei link interni su larga scala; raggruppa le varianti prima di decidere se sono duplicati.
• Log del server e Search Console — conferma quali forme di URL i bot richiedono davvero e quali registra Google, invece di giudicare la struttura solo da un template.

Gli strumenti per gli URL possono mostrare incoerenze, ma non possono giustificare da soli una migrazione. Cambiare URL stabili richiede comunque una ragione aziendale, una mappa completa dei redirect e la dimostrazione che il beneficio atteso superi il rischio della transizione.

Mettiti alla prova: struttura URL

Cinque domande rapide su come sono costruiti gli URL e su ciò che conta davvero per la SEO. Scegli una risposta per ciascuna, poi verifica.

Risorse che meritano il tuo tempo

I miei articoli correlati

• Trailing Slash: To Use or Not to Use? — quando conta lo slash (e l’eccezione del dominio radice).
• URL Parameters: A Complete Guide for SEOs — parametri attivi e passivi e come controllarli.
• Google Uses ~40 Canonicalization Signals — inclusi HTTPS, www, slash, maiuscole e la preferenza per l’URL più breve.
• Redirects for SEO: A Simple (But Complete) Guide — spostare URL senza perdere equità.
• The Beginner’s Guide to Technical SEO — dove la struttura URL si inserisce nel quadro più ampio.

I miei interventi

• A Crash Course in Technical SEO (SlideShare, Beer & SEO Meetup) — include la struttura URL.
• Troubleshooting Technical SEO Problems (SlideShare, Raleigh SEO Meetup) — problemi URL nel loro contesto.

Dal settore

• URL structure best practices (Google Search Central) — la lista canonical di cose da fare e da evitare.
• Google & Bing (Still) Handle Underscores & Dashes Differently (Search Engine Land) — la differenza tra trattini e underscore, con la citazione di Bing.
• Changing URLs for SEO reasons: When is it OK? (Search Engine Land) — la guida di Mueller «very, very rarely».
• Google Says Words In A URL Are A Very Light Weight Factor (Search Engine Roundtable).
• Reminder: Google On Case Sensitivity For URLs (Search Engine Roundtable).
• Google: We Pick Shorter URLs For Canonicalization (Search Engine Roundtable) — la fonte dell’idea fraintesa «vince il più breve».
• Better than canonical — URL Normalization (Bing Webmaster Blog) — l’approccio di Bing per unificare i parametri.

Cronologia modifiche