Introduzione: Passato e Presente degli URL
Una volta tanto tempo fa un Uniform Resource Locator era solo un modo per puntare a una risorsa nel Web.
L'Inglese era la lingua usata nel mondo IT, i percorsi su Web Server riflettevano i file system di vecchio stampo, e i caratteri ASCII erano più che sufficienti per rappresentare gli URL.
Quando il Web oltrepassò i confini USA, la gente dovette capire come scrivere URL nella propria lingua.
Per la maggior parte delle nazioni Europee la gente poteva arrangiarsi con convenzioni ancora in uso: "appiattire" la propria lingua rinunciando ad accenti e diacritici. Ciò funziona abbastanza bene in lingue con alfabeto Latino come l'Italiano o lo Spagnolo.
Alcune lingue – come il Russo, basate sull'alfabeto Cirillico – dovettero fare ricorso a una traslitterazione all'alfabeto Latino, anche chiamata Romanizzazione
Altre lingue furono ancora più sfortunate, perché proprio non possono essere rappresentate con caratteri Latini.
Tali utenti dovettero rinunciare all'uso della propria lingua, o trovare un modo per adattarla negli URL.
Come fare stare dei caratteri non ASCII nelle specifiche originali dell'URL?
Estendere HTTP e i protocolli a latere per supportare gli insiemi di caratteri estesi (o in seguito Unicode) non era possibile, non avrebbe garantito una transizione senza intoppi.
Si dovette fare ricorso a qualche tipo di codifica, tra cui il Percent Encoding è stato il vincitore.
Il Percent encoding più o meno funzionava:
Era compatibile con le specifiche per gli URL, per cui poteva passare nel protocollo di comunicazione HTTP, ma non c'erano troppi altri vantaggi a suo favore, e gli svantaggi iniziarono:
- Non era leggibile agli umani. Questo era proprio il motivo per cui fu introdotto!
OK, i browser erano in grado di accettare percorsi Unicode di URL, e codificarli in automatico prima di effettuare la richiesta HTTP (ossia prima di richiedere una pagina web), ma l'URL mostrato nella barra degli indirizzi del browser era illeggibile. - I motori di ricerca iniziarono a usare il percorso dell'URL come un fattore di ranking. URL "User-friendly" iniziarono così a essere anche URL "SEO-friendly", ma ciò almeno all'inizio funzionava solo per lingue occidentali.
Per esempio, i due seguenti URL offrono esperienze utente alquanto differenti:
Percorso Unicode, Human-Readable e URL-Encoded
A complicare ulteriormente le cose, arrivarono gli Internationalized Domain Names, e ora pure la parte del nome di dominio di un dominio può avere caratteri Unicode.
Come farli rientrare nelle specifiche RFC degli URL? Il Percent Encoding qui non era utilizzabile, perché il simbolo di percentuale non è ammesso dalle specifiche del DNS, così ci si inventò una nuova codifica per esprimere nomi Unicode in nomi di dominio validi.
Di nuovo, stava al browser gestire la conversione in maniera trasparente.
Per quanto concerne chi lavora nella Ottimizzazione per i Motori di Ricerca, ci sono tre tipi di strumenti coinvolti:
- I Motori di Ricerca devono riconoscere i percorsi Unicode, estrarre da essi informazioni relative alle parole chiave, mostrarli in una forma leggibile agli utenti quando elencati nella SERP, e permettere agli utenti di cercarli.
- I Browsers devono accettare un URL in Unicode, codificarlo correttamente prima di comunicare con il server web, e mostrarlo nella barra degli indirizzi in un formato comprensibile al lettore umano.
- I Tool SEO devono gestire gli URL in Unicode e mostrarli in un formato leggibile agli umani così che i professionisti SEO che lavorano con lingue non occidentali possano comprendere gli URL su cui stanno lavorando.
Prenderò in considerazione due categoria di strumenti per SEO: Back links Intelligence Providers e SEO Spider Off-line.
Come caso di test, ho usato un sito web di cui non ho alcun coinvolgimento, scelto fra tanti per il solo motivo che ha sia dominio IDN sia l'uso dei percorsi Percent-encoded. I sui URL sono completamente composti da caratteri Unicode.
экскурсии.рф è un sito per escusioni turistiche
Motori di Ricerca e URL Unicode
Oltre agli ovvi Google e Bing, ho aggiunto Yandex tra i concorrenti in corsa.
Ci sono diversi altri motori di ricerca nel mondo, Baidu il più grosso tra essi, ma anche Seznam, Nazer... ho scelto Yandex per due motivi:
Opera in russia dove è usato il più diffuso dominio IDN domain (.рф), e perché è in espansione e penso noi dei paesi occidentali lavoreremo sempre di più con esso nel futuro prossimo.
URL Unicode e Motori di Ricerca
Come atteso, tutti i Motori di Ricerca mostrano gli URL decodificati, in un formato human-readable.
Sfortunatamente Bing fallisce nel ritrovare le pagine di un sito ricercando il nome di dominio con l'operatore "site:". Funziona soltanto utilizzando la versione codificata, cosa che un normale utente non farebbe.
Per un momento ho pensato funzionasse cercando il nome di dominio senza l'operatore "site:", ma poi ho capito che i risultati venivano restituiti solo perché il nome di dominio era presente in ogni titolo di pagina.
Vincitori: Google, Yandex
Perdenti: Bing
Disclaimer: ogni comparazione prende in considerazione solo il supporto agli URL Unicode, nulla circa pertinenza, numero e qualità dei risultati restituiti o qualsiasi altro servizio fornito dai tre motori di ricerca.
Browsers e URL Unicode
Oggigiorno tutti i maggior browser moderni possono gestire i percorsi Percent-encoded in modo fluido e visualizzarli in modo che un utente possa leggerli.
Sfortunatamente, il supporto a IDN ancora non è universale. Per quanto in grado di codificarli automaticamente, entrambi i due browser più diffusi – Chrome e IE – deludono fallendo nel mostrare i domini IDN in un formato leggibile all'utente umano.
URL Unicode e supporto da parte dei browser
Va notato, Yandex.Browser fa un passo in più nell'usabilità:
Non solo rappresenta correttamente sia i nomi di dominio IDN che i percorsi "percent encoded", ma non appena il titolo è disponibile lo utilizza per sostituire il percorso nella barra degli indirizzi. La trovo una buona scelta: spesso i percorsi non sono user-friendly, e titoli lunghi non si notano nella limitata ampiezza delle "tab".
Vincitori: Yandex.Browser (con una menzione speciale), Firefox, Safari
Perdenti: Chrome, IE
Disclaimer: questa comparazione prende in considerazione solo il supporto agli URL Unicode, nulla riguardo il support di altri standard, la velocità di rendering, o qualsiasi altra caratteristica offerta dai cinque browser.
Strumenti SEO: back links intelligence providers
Qui i concorrenti sono i soliti sospetti: Open Site Explorer, MajesticSEO e aHrefs. Tutti offrono account gratuiti, che sono stati sufficienti per valutare il loro supporto agli URL Unicode.
Tutti e tra hanno accettato un dominio IDN e sono stati in grado di trovare backlink che lo puntino, ma il modo in cui i risultati sono presentati varia.
Open Site Explorer è il primo ho provato, e sembra essere il peggiore:
Open Site Explorer e URL Unicode
non solo mostra gli URL completamente codificati sia nella parte di nome dominio che nel percorso, ma ...forse confonde la codifica per un redirect a un URL che non riesce a rappresentare?
Anche MajesticSEO non è in grado di mostrare gli URL dei siti decodificati
MajesticSEO e URL Unicode
aHrefs supporta appieno sia i domini IDN che i percorsi percent-encoded, un chiaro vincitore per chi deve lavorare con siti non occidentali nella valutazione di un profilo di link.
aHrefs e URL Unicode
Vincitore: aHrefs
Perdenti: MajesticSEO, Open Site Explore
Disclaimer: questa comparazione prende in considerazione solo il supporto agli URL Unicode, nulla riguardo a numero e qualità dei backlink trovati o qualsiasi altro servizio i tre strumenti possa offrire.
Strumenti SEO: Spider SEO off-line
Esistono molti tipi di Tool SEO, ma in questa occasione prenderò solo in considerazione gli spider SEO off-line utilizzati da professionisti SEO per fare degli audit SEO.
Anche qui, utilizzo strumenti disponibili gratuitamente: Xenu's Link Sleuth, Screaming Frog SEO Spider e Visual SEO Studio (disclaimer: per chi non lo sapesse ancora, rappresento il produttore di Visual SEO Studio).
Il primo strumento testato, Xenu rel. 1.3.8, non riesce nemmeno a esplorare un sito web IDN:
Xenu con un sito IDN in ingresso
Accetta il valore in ingresso, ma...
Risultato di Xenu per un indirizzo IDN
Per poterlo esplorare, devi utilizzare la versione puny-coded dell'URL:
Xenu con un dominio punycode in ingresso
Il risultato dell'esplorazione non è troppo male: considerando che il programma è datato 2010. I nomi IDN non sono gestiti (anche se in realtà fecero la loro apparizione a Maggio 2010), ma i percorsi sono mostrati dopo una decodifica dell'URL così che siano leggibili all'essere umano:
Risultati di Xenu output per un indirizzo di sito punycoded
Il secondo concorrente è Screaming Frog rel. 2.20
Accetta un nome di domino IDN in ingresso:
Screaming Frog con un sito IDN in ingresso
e lo codifica prima di esplorarlo. Stranamente, il suo sviluppatore non si è curato di mostrarlo poi decodificato:
Risultato di Screaming Frog per un sito IDN
L'altro concorrente, Visual SEO Studio 0.8.7, è il netto vincitore.
Visual SEO Studio supporta appieno siti IDN e percorsi Unicode
Nessuna sorpresa qui: Visual SEO Studio è stato concepito, pianificato e ingnegnerizzato per essere Internazionale. Non solo può esplorare e mostrare nomi IDN e mostrare percorsi percent-encoded in formato "human readable", il suo supporto agli URL Unicode è completo e ubiquo: sono mostrati in tutte le viste e tutti gli strumenti di reportistica, e le versioni percent-encoded sono disponibili tra le proprietà di pagina e in tutte le viste a griglia con una colonna – normalmente nascosta – dedicata.
Visual SEO Studio introdusse i percorsi URL leggibili all'umano con la rel. 0.8.5 del 6 Aprile 2013, e il supporto a Internationalized Domain Names con la rel. 0.8.6 del 1 Maggio 2013
All'epoca Screaming Frog non era in grado di esplorare i siti IDN, e mostrava i percorsi percent-encoded nel formato illeggibile. Oggi ha recuperato con i percorsi codificati, e sebbene ancora non mostri di domini IDN user-friendly, riesce a esplorarli senza problemi. In pratica già in tale senso era meglio di Xenu, penso non passerà tanto prima che mostri anche i siti IDN in formato leggibile all'occhio umano.
È una buona notizia per gli utenti di paesi non occidentali che possono scegliere il migliore strumento per le proprie necessità.
Vincitore: Visual SEO Studio
Perdenti: Xenu, Screaming Frog (un po' meglio di Xenu)
Disclaimer: questa comparazione prende in considerazione solo il supporto agli URL Unicode, nulla riguardo alla qualità o le altre caratteristiche offerte dai tre Spider SEO.
Conclusioni: URL Unicode, presente e futuro
Non mi stancherò mai di rimarcarlo: gli URL sono anche per gli umani, e lo Unicode negli URL è qui per restare.
Agli utenti Web users non importa di questioni tecniche, non interessa di difficoltà di indicizzazione dei motori di ricerca. Si aspettano che tutto funzioni subito, di usare la propria lingua e avere strumenti per gestire il tutto. Compresi gli URL.
Motori di Ricerca e Browser si stanno evolvendo per soddisfare tali aspettative. I tool SEO sono rimasti un po' indietro, ma stanno recuperando terreno.
Spero questo articolo sia uno sprone per accelerare verso il completo supporto agli URL Unicode da parte di tutti gli strumenti coinvolti, così da rendere il web ancora più accessibile.
Penso che oggi le cosiddette "best practices" per gli URL SEO-friendly debbano essere presto riviste.
Immagino cesseremo di evitare l'uso di accenti e diacritici negli URL in lingue Latine, e ci abitueremo sempre più a lavorare con URL Unicode.
My attendo permanga tuttavia l'uso di evitare spazi negli URL come buona pratica: gli URL sono spesso copiati come testo nelle e-mail ed è comodo quando il programma di e-mail genera automaticamente un link su di essi, gli spazi nell'URL – per URL non percent-encoded – impedirebbero a tali programmi di generare il link correttamente.
E tu, hai mai dovuto lavorare con URL Unicode? Eri soddisfatto dagli strumenti a tua disposizione?