La riscrittura delle URL ed i caratteri speciali (Versione 2.0)

E' passato un po' di tempo da quando ho scritto questo articolo.
Il mondo del digital è sempre in evoluzione e potresti trovare delle informazioni non più aggiornate.

Uno dei principali fattori SEO on page per migliorare la qualità della SERP è la riscrittura delle URL delle pagine web.

Molto spesso ci si trova nella situazione di dover sfruttare qualche elemento della base dati per ottenere un'URL descrittva.

Nel caso di un sito web che pubblica notizie può essere interessante utilizzare il titolo della notizia.

Per l'articolo "Google vuole comprare Yahoo", ad esempio, l'URL del documento potrebbe essere: www.mio-sito.it/google-vuole-comprare-yahoo.html.

Per un e-commerce il nome prodotto e la categoria mercologica, come ed esempio per il cellulare Nokia N70 si può associare www.mionegozioonline.it/cellulari/nokia-N-70.html.

Ma se nei dati che ho a mia disposizione trovo dei caratteri speciali per avere una qualità delle SERP ottimizzata al massimo occorre prevedere qualche accorgimento tecnico.

In un mio post nel Blog TSW, in merito qualche tempo suggerivo la personalizzazione della routine sanitize_title_with_dashes() di Wordpress contenuta nel file wp-includes/formatting.php. (Potete scaricarne il codice qui!)

Questa tecnica permette di fare la riscrittura corretta delle URL per tutte le stringhe che contenevano caratteri quali ü, ö, ä sfruttando la corrispondenza ü=ue, ö=oe, ä=ae.

Da un commento di Johnnie si poteva notare come però questo tipo di tecnica in alcuni casi non funzionasse a dovere.

Il metodo di conversione della stringa causa una riscrittura approssimativa: ad esempio le lettere con gli accenti vengono convertite nella versione non accentata (come è=e, ò=o).

La parola usabilità con il metodo proposto viene convertita dall'algoritmo in usabilita e questa stringa non verrà evidenziata nella SERP se un utente ricercherà la keyword.

Esempio di pagina dei risultati di ricerca

Guardando l'immagine sopra si nota come l'URL di wikipedia ha la grassettatura perfetta, mentre l'URL della pagina di HTML.it ha la stringa usabilita non grassettata.

Il motore, quindi, distingue le lettere accentate da quelle non accentate e se la conversione non è effettuata a dovere non si ha l'effetto sperato nelle SERP.

La corretta pratica di conversione, invece, prevede una codifica dei caratteri in formato UTF-8, come viene anche specificato in questo articolo del w3c "URI encoded program".

Nell'esempio precedente, quindi, Wikipedia utilizza nell'URL la codifica UTF-8 di usabilità, ovvero Usabilit%C3%A0.

Questa soluzione ha ancora un piccolo aspetto da raffinare: gli utenti difficilmente riuscirebbero ricordarsi un URL interna al sito codificata in UTF-8 come ad esempio www.ilmiosito.it/Usabilit%C3%A0.

Per non perdere questo ulteriore vantaggio della riscrittura delle URL è bene prevedere almeno nelle pagine di primo livello una redirezione 301 dalla URL codificata stile "Wordpress" alla URL codificata in UTF-8.

In questo modo anche se un utenta digita www.ilmiosito.it/usabilita direttamente dalla barra degli indirizzi, gli verrà restituita la pagina corretta.

Consigli per la lettura:

Search Engine Optimization in php di Jaimie Sirovich

Come reindirizzare una pagina web di Steve Hargrove

Altri post che potrebbero interessarti:

  • Pingback: Riscrittura delle URL ‘a cartella’: da maneggiare con cautela | Andrea Vit 's blog()

  • Il web si evolve e fortunatamente Google negli snippet dei risultati evidenzia con il grassetto le parole senza accento anche se l’utente le ha inserite con l’accento, e viceversa.
    SERP di esempio per la parola “Cantù”:

    http://www.google.it/search?q=Cant%F9

    Questo è un corollario della funzionalità che era già implementata nell’algoritmo di ricerca, ovvero l’output di ricerche con parole accentate è uguale a quello delle stesse ricerche senza accenti.
    Quindi è stata solo riportata la logica dell’algoritmo anche nella visualizzazione.

    Data questa semplificazione offerta dal motore, il mio suggerimento è quello di eliminare ulteriori livelli di complessità a livello dell’applicativo e usare fin dall’inizio solo plain characters.

  • @emanueleDG
    Dipende molto dal progetto IMHO.
    Per i mercati esteri, ad esempio, la cosa non funziona.
    Penso ad esempio al mercato giapponese, cinese o altro.
    Considera anche che questo post è datato 2008, povero è un po’ vecchiottino 🙂

  • Mi hai chiarito le idee!