Quando dovrei usare una barra finale nel mio URL?

Quando dovrebbe essere utilizzata una barra finale in un URL? Ad esempio: il mio URL dovrebbe essere /about-us/ o like /about-us ?

Sono pienamente consapevole delle problematiche relative al SEO: contenuti duplicati e cosa canonica; Sto cercando di capire quale utilizzare nel contesto di servire le pagine correttamente da solo.

Ad esempio, il mio collega sta pensando che una barra finale alla fine significa che è una “cartella” – una “directory”, quindi non è uno stile corretto. Ma penso che senza una barra alla fine – non è del tutto corretto, perché sembra quasi una cartella, ma non lo è e non è neanche un file normale, ma un nome di file senza estensione.

C’è un modo corretto di sapere quale usare?

Nella mia opinione personale, i tagli finali sono abusati.

Fondamentalmente il formato dell’URL proveniva dallo stesso formato UNIX di file e cartelle, in seguito, su sistemi DOS e, infine, adattato per il web.

Un URL tipico per questo libro su un sistema operativo simile a Unix sarebbe un percorso file come file: ///home/username/RomeoAndJuliet.pdf, che identifica il libro elettronico salvato in un file su un disco rigido locale.

Fonte: Wikipedia: identificatore di risorse uniformi

Un’altra buona fonte da leggere: Wikipedia: Schema URI

Secondo la RFC 1738, che ha definito gli URL nel 1994, quando le risorse contengono riferimenti ad altre risorse, possono usare collegamenti relativi per definire la posizione della seconda risorsa come se dicessero “nello stesso posto di questa eccetto con la seguente sentiero”. Ha proseguito affermando che tali URL relativi dipendono dall’URL originale che contiene una struttura gerarchica rispetto alla quale si basa il relativo link e che gli schemi ftp, http e file URL sono esempi di alcuni che possono essere considerati gerarchici, con componenti della gerarchia separati da “/”.

Fonte: Wikipedia Uniform Resource Locator (URL)

Anche:

Questa è la domanda che sentiamo spesso. Avanti alle risposte! Storicamente, è comune per gli URL con una barra finale indicare una directory e quelli senza una barra finale per indicare un file:

http://example.com/foo/ (con la barra finale, convenzionalmente una directory)

http://example.com/foo (senza barra finale, per convenzione un file)

Fonte: Google WebMaster Central Blog – Per tagliare o non tagliare

Finalmente:

  1. Una barra alla fine dell’URL rende l’indirizzo “carino”.

  2. Un URL senza una barra alla fine e senza un’estensione sembra un po ‘”strano”.

  3. Non nominerai mai il tuo file CSS (ad esempio) http://www.sample.com/stylesheet/ .

Ma sono un sostenitore delle best practice del web a prescindere dall’ambiente. Può essere instabile e poco chiaro, proprio come hai detto sull’URL senza ext.

Non è una questione di preferenza. /base e /base/ hanno semantica diversa. In molti casi, la differenza non è importante. Ma è importante quando ci sono URL relativi.

  • child relativo a /base/ è /base/child .
  • child relativo a /base è (forse sorprendentemente) /child .

Sono sempre sorpreso dall’uso estensivo di barre finali su URL non di directory (WordPress tra gli altri). Questo in realtà non dovrebbe essere un o-dibattito, perché mettere una barra dopo una risorsa è semanticamente sbagliata. Il web è stato progettato per fornire risorse indirizzabili e quegli indirizzi – URL – sono stati progettati per emulare una gerarchia di file system in stile * nix. In questo contesto:

  • Le barre indicano sempre le directory, mai i file.
  • I file possono essere nominati qualsiasi cosa (con o senza estensioni), ma non possono contenere o terminare con barre.

Utilizzando queste linee guida, è sbagliato inserire una barra dopo una risorsa non di directory.

Non è davvero una questione di estetica, ma anzi una differenza tecnica. La directory che ne pensa è completamente corretta e praticamente spiega tutto. Risolviamolo:

Sei tornato all’età della pietra ora o servi solo pagine statiche

Hai una struttura di directory fissa sul tuo server web e solo file statici come immagini, html e così via – nessun script lato server o qualsiasi altra cosa.

Un browser richiede /index.htm , esiste ed è consegnato al client. Più avanti hai un sacco di – diciamo – i film in DVD recensiti e una pagina html per ognuno di essi nella directory /dvd/ . Ora qualcuno richiede /dvd/adams_apples.htm e viene consegnato perché è lì.

Qualche giorno qualcuno chiede /dvd/che è una directory e il server sta cercando di capire cosa consegnare. Oltre alle restrizioni di accesso e così via ci sono due possibilità: mostrare all’utente il contenuto della directory (scommetto che l’hai già visto da qualche parte) o mostrare un file predefinito (in Apache è: DirectoryIndex: sets the file that Apache will serve if a directory is requested. )

Fin qui tutto bene, questo è il caso previsto. Mostra già la differenza nella gestione, quindi approfondiamoci:

Alle 5:34 hai commesso un errore durante il caricamento dei tuoi file

(Che è completamente comprensibile.) Quindi hai fatto qualcosa di completamente sbagliato e invece di caricare /dvd/the_big_lebowski.htm hai caricato quel file come dvd (senza estensione) in / .

Qualcuno ha inserito il tuo /dvd/ elenco di directory (ovviamente non volevi creare e aggiornare sempre quel nifty index.htm ) e sta visitando il tuo sito web. Il contenuto della directory viene consegnato – tutto bene.

Qualcuno ha sentito parlare della tua lista e sta scrivendo /dvd . E ora è fregato. Invece della tua directory DVD che elenca il server trova un file con quel nome e sta consegnando il tuo file Big Lebowski.

Quindi, cancelli quel file e dì al ragazzo di ricaricare la pagina. Il tuo server cerca il file /dvd , ma non c’è più. La maggior parte dei server noterà quindi che esiste una directory con quel nome e comunica al client che ciò che stava cercando è effettivamente da qualche altra parte. Molto probabilmente la risposta sarà:

Status Code:301 Moved Permanently con Location: http://[...]/dvd/

Quindi, ignorando totalmente ciò che pensi delle directory o dei file, il server può solo gestire tali cose e – a meno che non venga detto diversamente – decide per te in merito al significato di “barra o no”.

Finalmente dopo aver ricevuto questa risposta, il client carica /dvd/ e tutto va bene.

Va bene? No.

“Va bene” non è abbastanza buono per te

Hai una pagina dynamic in cui tutto viene passato a /index.php e viene elaborato. Tutto ha funzionato abbastanza bene fino ad ora, ma l’intera cosa inizia a sembrare più lenta e tu indaga.

Presto noterai che /dvd/list sta facendo esattamente la stessa cosa: reindirizzamento a /dvd/list/ che viene poi tradotto internamente in index.php?controller=dvd&action=list . Un’ulteriore richiesta – ma anche peggio! customer/login reindirizza al customer/login/ che a sua volta reindirizza all’URL HTTPS del customer/login/ . Finisci per avere tonnellate di reindirizzamenti HTTP non necessari (= richieste aggiuntive) che rallentano l’esperienza dell’utente.

Molto probabilmente hai anche qui un indice di directory predefinito: index.php?controller=dvd senza action semplicemente carica internamente index.php?controller=dvd&action=list .

Sommario:

  • Se finisce con / non può mai essere un file. Nessun server che indovina.

  • Slash o nessuna barra sono significati completamente diversi. Esiste una differenza tecnico / di risorse tra “barra o nessuna barra” e dovresti esserne consapevole e usarlo di conseguenza. Solo perché il server carica molto probabilmente /dvd/index.htm – o carica gli script corretti – quando dici /dvd : Lo fa, ma non perché hai fatto la richiesta giusta. Quale sarebbe stato /dvd/ .

  • Omettendo la barra, anche se si intende effettivamente la versione ridotta, si ottiene una penalità aggiuntiva per la richiesta HTTP. Che è sempre male (pensate alla latenza mobile) e ha più peso di un “bel URL” – soprattutto perché i crawler non sono così stupidi come i SEO credono o vogliono farvi credere;)

Quando crei il tuo URL /about-us/ (con la barra finale), è facile iniziare con un singolo file index.html e poi espanderlo e aggiungere altri file (es. our-CEO-john-doe.jpg ) o persino creare una gerarchia sottostante (ad esempio /about-us/company/ , /about-us/products/ , ecc.) secondo necessità, senza modificare l’URL pubblicato . Questo ti dà una grande flessibilità.

Chi dice che il nome di un file ha bisogno di un’estensione ?? dai un’occhiata a una macchina * nix qualche volta …
Sono d’accordo con il tuo amico, nessun taglio finale.

Altre risposte qui sembrano favorire l’omissione della barra finale. C’è un caso in cui una barra finale aiuterà con l’ottimizzazione dei motori di ricerca (SEO). Questo è il caso in cui il tuo documento ha un’estensione di file che non è .html . Questo diventa un problema con i siti che valutano i siti web. Potrebbero scegliere tra questi due URL:

  • http://mysite.example.com/rated.example.com
  • http://mysite.example.com/rated.example.com/

In tal caso, sceglierei quello con la barra finale . Questo perché l’estensione .com è un’estensione per i file di comando eseguibili di Windows. Ai motori di ricerca e ai programmi di controllo dei virus spesso non piacciono gli URL che possono contenere malware distribuiti attraverso tali meccanismi. La barra finale sembra mitigare qualsiasi preoccupazione, consentendo alla pagina di classificarsi nei motori di ricerca e ottenere dai controllori dei virus.

Se i tuoi URL hanno no . nella parte del file, quindi raccomanderei di omettere la barra finale per semplicità.