La domanda “trailing-slash o no” viene posta di tanto in tanto, quindi John Mueller ha pensato di scrivere qualcosa a riguardo nel suo profilo su G+. In questa guida cercherò di riassumere i concetti chiave e di arricchire andando a fondo in certe spiegazioni.
tl; dr (Too long; didn’t read)
La barra (slash) posizionata dopo un nome host o un nome di dominio è irrilevante, puoi usarla o meno quando fai riferimento all’URL, finisce per essere la stessa cosa.
Gli URL http://www.esempio.com/ e http://www.esempio.com hanno lo stesso valore dal punto di vista dell’indicizzazione.
Tuttavia, una barra in qualsiasi altro punto rappresenta una parte significativa dell’URL e cambierà l’URL se è presente o meno. Questa nota non è specifica per la SEO, ma fa riferimento al funzionamento dei siti web.
Come è formato un URL
Lo standard W3C ha definito la composizione dell’URL, puoi trovare i dettagli al punto 5.1 di questa pagina. Questa sezione specifica che ogni richiesta effettuata su un server deve contenere un URI (Uniform Resource Identifier) e, se si sta richiedendo la homepage, la richiesta corrisponde a “/”. Pensa agli URL relativi, usando solo lo slash viene richiamata la homepage.
Quando invece si richiede una sotto cartella oppure un file, uno slash di troppo può creare problemi con la richiesta, ad esempio interrogando https://www.google.com/humans.txt la pagina si apre, invece interrogando con lo slash finale https://www.google.com/humans.txt/ ricevo un messaggio di errore.
Queste regola vanno considerate quando si crea la tag rel canonical oppure hreflang, uno slash sbagliato può creare problemi.
Partiamo dalle basi
Questi due URL in genere si riferiscono ad entità differenti:
- http://esempio.it/prodotti/ (con slash finale, si riferisce per convenzione ad una directory)
- http://esempio.it/prodotti (senza slash finale, si riferisce per convenzione ad un file)
Google è furbo si sa, tratta ogni URL separatamente (e allo stesso modo) indipendentemente dal fatto che si tratti di un file o di una directory o che contenga una barra finale o che non contenga una barra finale.
Contenuti diversi in URL che terminano con e senza slash vanno bene per Google, ma non sono ottimali per gli utenti. Da un punto di vista tecnico, del motore di ricerca, è certamente possibile che queste due versioni di URL contengano contenuti diversi. Gli utenti, tuttavia, potrebbero trovare questa configurazione confusionaria: immagina solo se www.esempio.it/prodotti e www.esempio.it/prodotti/ generassero due esperienze separate con contenuti differenti.
Per questo motivo, URL con lo slash finale e senza slash finale spesso mostrano lo stesso contenuto. Il caso più comune è quando un sito è configurato con una struttura a cartelle:
- http://esempio.it/cartella/sotto-cartella/
Verifica la corretta configurazione del tuo sito web
Puoi fare un rapido controllo sul tuo sito per vedere se gli URL:
- http://<tuo-dominio>/<cartella>/ (con barra finale)
- http://<tuo-dominio>/<cartella> (nessuna barra finale)
non restituiscono entrambi un codice di risposta di 200, ma una versione reindirizza all’altra. Spera di non avere status code 200 su entrambi o verrebbero considerati duplicati in mancanza di un tag rel canonical corretto!
- Se è possibile restituire solo una versione (ad esempio, l’altra reindirizza ad essa), è ottimo! Questo comportamento è utile perché riduce il contenuto duplicato. Nel caso particolare dei reindirizzamenti agli URL con barra finale, i risultati di ricerca di Google mostreranno probabilmente la versione dell’URL con il codice di risposta 200 (il più delle volte l’URL della barra finale), indipendentemente dal fatto che il reindirizzamento sia 301 o 302.
- Se entrambe le versioni con e senza barra finale contengono lo stesso contenuto e ciascuna restituisce 200, è possibile:
- Valuta la possibilità di modificare questo comportamento (ulteriori informazioni di seguito) per ridurre i contenuti duplicati e migliorare l’efficienza della ricerca per indicizzazione.
- Lascia stare così com’è. Molti siti hanno contenuti duplicati. Il processo di indicizzazione di Google spesso gestisce questo in autonomia, per i webmaster e gli utenti. Anche se non è un comportamento totalmente ottimale, è perfettamente legittimo.
- Sicuramente, per l’indirizzo della root (la homepage), con o senza slash non cambia. Esempio.it è equivalente a Esempio.it/ e non può essere reindirizzato, nemmeno se sei Chuck Norris.
Evita una situazione con contenuti duplicati su due URL differenti:
- http://<tuo-dominio>/<cartella>/ (con barra finale)
- http://<tuo-dominio>/<cartella> (nessuna barra finale)
questo significa che entrambi gli URL restituiscono 200 (non è presente un redirect e nemmeno il tag rel canonical). La configurazione del sito web è pericolosa e andrebbe corretta.
- Scegli un URL come versione preferita. Se il tuo sito ha una struttura a directory, è più convenzionale utilizzare una barra finale con i tuoi URL di directory (ad es. esempio.it/cartella/ piuttosto che esempio.it/cartella), ma sei libero di scegliere quale preferisci.
- Sii coerente con la versione preferita. Usa l’URL con la versione preferita nei tuoi link interni. Se hai una Sitemap, includi la versione preferita (e non includere l’URL duplicato).
- Utilizza un reindirizzamento 301 dal duplicato alla versione preferita. Se non è possibile usare il tag rel canonical usa un redirect 301. Il redirect funziona in modo simile a un canonical per gli scopi di indicizzazione di Google e anche per altri importanti motori di ricerca.
- Prova la tua configurazione tramite Fetch as Googlebot in Strumenti per i Webmaster. Assicurati che i tuoi URL:
esempio.it/cartella/
esempio.it/cartella
si comportino come previsto. La versione preferita dovrebbe restituire status code 200. L’URL duplicato deve andare in 301 verso l’URL preferito. - Controlla gli errori di scansione in Strumenti per i Webmaster e, se possibile, i log del web server. Verifica che i 301 siano implementati.
Spero che questa spiegazione ti abbia chiarito le idee, se hai dubbi o domande lascia un commento!
Articoli correlati
Autore
Mi chiamo Giovanni Sacheli e dal 2009 aiuto le aziende a farsi trovare online. Sono specializzato in SEO tecnica e PPC, competenze che applico quotidianamente nella mia agenzia, Searcus Swiss Sagl. Mi piace sviluppare strumenti a supporto del mio lavoro, ho creato SEOdata.app e cluster.army e co-scritto il libro SEO Audit Avanzato. Curo maniacalmente questo blog per colleghi e appassionati, dove mi "appunto" quello che imparo. Sono un NERD anni '80, motociclista e orgoglioso papà di due bambini.
Link:
Giovanni Sacheli
SEO Audit Avanzato
Searcus Swiss Sagl
SEOdata.app
cluster.army
Commenti |2
Lascia un commentoGrazie, Giovanni, per il suo articolo pratico e ben comprensibile!
Se è possibile vorrei chiedere un chiarimento: se si ha un redirect 301 di questo genere (impostati nel file .htaccess i primi due passaggi, poi WordPress credo che faccia il terzo redirect all’url con / in fondo automaticamente) http://miosito.it/mio–> https://miosito.it/mio –> https://miosito.it/mio/
Ovvero, redirect 301 da http ad https poi ad https con / in fondo, è possibile/consigliabile fare un unico passaggio di Redirect 301 del tipo http://miosito.it/mio –> https://miosito.it/mio/
tutto nel file .htaccess?
Nel caso, avendo anche come impostazione su wordpress il redirect 301 all’url con / in fondo, si andrebbe in conflitto (i redirect 301 fatti da WordPress per esempio quando si imposta la visualizzazione del link delle pagine vedo che non compaiono sul file .htaccess, ecco perché lo chiedo) ?
Spero di essermi spiegata bene, non è stato semplice :)
Grazie,
Francesca
Ciao Francesca,
per massimizzare la distribuzione del PageRank sarebbe meglio evitare catene di redirect e passare direttamente dal primo all’ultimo URL, senza passaggi intermedi.
Non credo andrebbe in conflitto con la regola di WP che appende lo slash se non presente. Ad ogni modo sempre meglio testare ;)