Quando dovrei usare una barra finale nel mio URL?

283

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

Sono pienamente consapevole dei problemi relativi alla SEO: contenuti duplicati e cose canoniche; Sto cercando di capire quale dovrei usare nel contesto di servire le pagine correttamente da solo.

Ad esempio, il mio collega sta pensando che una barra finale alla fine significhi che è una "cartella" - una "directory", quindi questo non è uno stile corretto. Ma penso che senza una barra alla fine - non è nemmeno del tutto corretto, perché sembra quasi una cartella, ma non lo è e non è nemmeno un file normale, ma un nome file senza estensione.

Esiste un modo corretto di sapere quale usare?

— Denis
fonte

Trailing slash, ma secondo me è soprattutto estetica. Guardare e sentire.

— Eric Herlitz,

3

Stessa domanda su Pro Webmaster: fa differenza se il tuo percorso URL termina in una barra finale o no?

— Stephen Ostermiller,

4

Questa domanda si pone come una delle preferenze , e quindi sembrerebbe fuori tema come principalmente basata sull'opinione pubblica . Tuttavia, come mostra la mia risposta , in effetti porre questa domanda come una questione di preferenza è un errore: questo è un problema XY, e la domanda "reale" sottostante ha una risposta tecnica precisa, e quindi non è principalmente basata sull'opinione .

— Raedwald,

Domande su quali tipi di URL piacciono a Google non sono correlate alla programmazione (come menzionato nel tag wiki ) e sono fuori tema per StackOverflow.

— Quentin,

Ho apportato alcune modifiche alla tua domanda, per favore ricontrollale quando hai l'opportunità di farlo. Grazie :)

— Tim Post

131

Secondo la mia opinione personale, le barre finali sono usate in modo improprio.

Fondamentalmente il formato 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 di file come file: ///home/username/RomeoAndJuliet.pdf, che identifica il libro elettronico salvato in un file su un disco rigido locale.

Fonte: Wikipedia: Uniform Resource Identifier

Un'altra buona fonte da leggere: Wikipedia: URI Scheme

Secondo RFC 1738, che ha definito gli URL nel 1994, quando le risorse contengono riferimenti ad altre risorse, possono utilizzare i collegamenti relativi per definire la posizione della seconda risorsa come per dire "nello stesso posto di questa tranne che con il seguente parente sentiero". Ha continuato affermando che tali URL relativi dipendono dall'URL originale contenente una struttura gerarchica su cui si basa il collegamento relativo e che gli schemi ftp, http e URL dei file sono esempi di alcuni che possono essere considerati gerarchici, con il componenti della gerarchia separati da "/".

Fonte: Wikipedia Uniform Resource Locator (URL)

Anche:

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

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

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

Fonte: Blog di Google WebMaster Central - Per tagliare o non tagliare

Finalmente:

Una barra alla fine dell'URL rende l'indirizzo "carino".
Un URL senza barra alla fine e senza estensione sembra un po '"strano".
Non nominerai mai il tuo file CSS (ad esempio) http://www.sample.com/stylesheet/ vorresti?

MA sto proponendo le migliori pratiche del web indipendentemente dall'ambiente. Può essere traballante e poco chiaro, proprio come hai detto sull'URL senza ext.

— Dementic
fonte

1

Questo è strano, non puoi nominare un file "foglio di stile /" - e barra o nessuna barra sono risorse completamente diverse sul server, non importa come appare l'URL

— nico gawenda

10

@nicogawenda, .htaccess può fare ogni sorta di magia;) il tuo CSS potrebbe effettivamente essere un file php!

— rmorse

4

I server Web sono spesso configurati per impostazione predefinita per servire index.html(o file con nomi simili) quando si accede a una directory, quindi /foo/è /foo/index.htmlsenza il disordine aggiuntivo. Inoltre, in passato i browser aggiungevano /al nome di dominio, ma da allora (Firefox, Chrome, Opera) sono cambiati per omettere l' /accesso quando si accede alla homepage.

— 0b10011

4

Sono d'accordo con @bfrohs. Sicuramente le pagine predefinite per le directory contravvengono a questo principio. Se vogliamo imporre "trailing slash = directory", sicuramente tutti gli URL che puntano a una directory devono restituire un elenco di directory o una risposta HTTP proibita 403.

— Marvin,

11

Non sono sicuro che i punti 1 e 2 nella sezione "Finalmente" siano ancora precisi. Nel corso degli anni da quando questo è stato originariamente scritto, i gusti sono cambiati. Non l'ho studiato in dettaglio, ma sembra che sui siti web più recenti, sia più comune e "più bello" omettere la barra.

— speedplane il

172

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

childrispetto a /base/è /base/child.
childrispetto a /baseè (forse sorprendentemente) /child.

— Raedwald
fonte

5

Articolo utile che approfondisce questo argomento

— Efesto,

3

Sì, penso che questo, insieme al SEO, siano le cose più importanti per questa domanda.

— user2875289

Ho appena riscontrato questo problema durante l'utilizzo di .Net Uri.MakeRelativeUri. I risultati riflettono esattamente quello che hai detto. Ho risolto il problema aggiungendo la barra finale alla mia base Uri.

— julealgon,

61

Sono sempre sorpreso dall'ampio uso di barre finali su URL non di directory (WordPress tra gli altri). Questo in realtà non dovrebbe essere né uno né un dibattito perché mettere una barra dopo una risorsa è semanticamente sbagliato. 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 quel contesto:

Le barre indicano sempre le directory, mai i file.
I file possono essere nominati con qualsiasi nome (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.

— Yarin
fonte

50

"barra dopo directory, non dopo risorse": gli URL non fanno riferimento a due tipi di cose, "risorse" e "directory"; si riferiscono a un tipo di cosa: le risorse. L'indizio è nella R di URL.

— Raedwald,

31

E tutto in un file system * nix è un file, ma esistono ancora directory. Qual è il tuo punto?

— Yarin,

6

Che sia servito internamente da un file o da una directory, ciò che l'utente vede è solo una pagina web. E example.com/about potrebbe effettivamente leggere da example.com/about/index.html .

— musiphil,

1

@DavidRR: hai ragione. E il browser ha bisogno il redirect, perché la risoluzione del nome deve avvenire dall'interno directory(altrimenti, image.pngin http://hostname/directoryindicherebbe http://hostname/image.png). Stavo solo dicendo che la distinzione tra un file e una directory potrebbe non essere molto importante dal punto di vista dell'utente.

— musiphil,

2

Sono d'accordo con il tuo risultato, ma non sono sicuro che dovremmo progettare il nostro sistema URL per emulare file system in stile * nix. Ciò potrebbe aver originariamente servito a uno scopo, ma ora molto meno.

— speedplane il

27

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

Ora sei di nuovo nell'età della pietra 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 - nessuno script lato server o altro.

Un browser richiede /index.htm, esiste e viene consegnato al client. Più tardi avrai molti - diciamo - film in DVD recensiti e una pagina html per ognuno di essi nella /dvd/directory. Ora qualcuno richiede /dvd/adams_apples.htmed è consegnato perché è lì.

Un giorno qualcuno chiede solo /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à: Mostra all'utente il contenuto della directory (scommetto che l'hai già visto da qualche parte) o mostra 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 entriamo in esso:

Alle 5:34 hai sbagliato a caricare i tuoi file

(Il che è del tutto comprensibile.) Quindi, hai fatto qualcosa di completamente sbagliato e invece di caricare /dvd/the_big_lebowski.htmhai caricato quel file come dvd(senza estensione) in/ .

Qualcuno ha aggiunto un segnalibro alla tua /dvd/directory (ovviamente non volevi crearla e aggiornarla sempre index.htm) e sta visitando il tuo sito web. Il contenuto della directory viene consegnato - tutto bene.

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

Quindi, elimini quel file e dici al ragazzo di ricaricare la pagina. Il tuo server cerca il /dvdfile, ma non c'è più. La maggior parte dei server noterà quindi che esiste una directory con quel nome e dirà 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 tu pensi delle directory o dei file, il server può solo gestire tali cose e - se non diversamente indicato - decide per te sul significato di "barra o meno".

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

Va bene? No.

"Va bene" non è abbastanza buono per te

Hai qualche pagina dinamica in cui tutto viene passato /index.phpe viene elaborato. Fino ad ora tutto ha funzionato abbastanza bene, ma l'intera cosa inizia a sentirsi più lenta e indaghi.

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

Molto probabilmente anche qui hai un indice di directory predefinito: index.php?controller=dvdsenza actionsemplicemente caricamenti interni index.php?controller=dvd&action=list.

Sommario:

Se finisce con /esso non può mai essere un file. Nessun server indovinando.
Barra o nessuna barra sono significati completamente diversi. Esiste una differenza tecnico / di risorse tra "barra o nessuna barra" e dovresti esserne consapevole e utilizzarla di conseguenza. Solo perché il server molto probabilmente carica /dvd/index.htm- o carica la roba corretta dello script - quando dici /dvd: lo fa, ma non perché hai fatto la richiesta giusta. Quale sarebbe stato /dvd/.
Se si omette la barra anche se si intende effettivamente la versione con barra, si ottiene una penalità aggiuntiva per la richiesta HTTP. Il che è sempre negativo (pensa alla latenza mobile) e ha più peso di un "URL carino", soprattutto perché i crawler non sono così stupidi come credono o vogliono farti credere dai SEO;)

— nico gawenda
fonte

2

Quindi in una sintesi siete tutti per l'aggiunta della barra alla fine? :)

— Denis

2

Sono tutto per usarlo quando lo intendi;) Ad esempio parlando di controller e azioni sarebbe: i controller dovrebbero finire con la barra. Quando fai riferimento a un file o un'azione ometti la barra

— nico gawenda il

Aspetta, perché dovresti omettere la barra per un'azione? Come per il tuo esempio, non risulterà la richiesta reindirizzata extra? Voglio dire, presumibilmente il tuo server è abbastanza intelligente da riconoscere un'azione del controller e non reindirizzerà effettivamente alla ricerca di file o directory in quel caso, ma va comunque contro il tuo esempio, vero?

— Adam Goodwin,

7

Non capisco il tuo esempio. Quale filesystem consente una directory e un altro file normale con lo stesso nome ( dvd)?

— musiphil

19

Quando si effettua l'URL /about-us/(con la barra finale), è facile iniziare con un singolo file index.htmle poi espanderlo e aggiungere più file (ad esempio our-CEO-john-doe.jpg) o addirittura creare una gerarchia sotto di essa (ad esempio /about-us/company/, /about-us/products/e così via), se necessario, senza modifica dell'URL pubblicato . Questo ti dà una grande flessibilità.

— musiphil
fonte

9

Mi dispiace di non averlo capito. se inizio con /about-uso /about-us/devo ancora modificare l'URL pubblicato in entrambi i casi se ho espanso la directory. il nuovo file sarà /about-us/new-file.htmlin entrambi i casi !! cosa mi sto perdendo qui?

— Ragioniere م

2

@Accountant Penso che OP potrebbe pensare che se pubblichi "/ about-us" senza una barra finale non puoi successivamente aggiungere risorse secondarie usando percorsi relativi. Quando non hai la barra finale, il browser crederà che un riferimento a "ceo.jpg" nella pagina about risiederà nella radice del tuo dominio e richiederà example.com/ceo.jpg. Con la barra, il browser richiederà example.com/about-us/ceo.jpg e puoi espandere staticamente un intero albero di cartelle per il tuo sito mentre espandi.

— Daw

1

Cordiali saluti - Non credo che quanto sopra sia vero - Perché non ci può essere un /about-use /about-us/company? In termini di pubblicazione dei file, sia Apache che IIS possono gestirlo bene, quindi non sono d'accordo.

— sean2078,

1

@ sean2078 Sì, ma se, da /about-uste vuoi collegarti /about-us/company, devi usare href="https://stackoverflow.com/about-us/company"o href="./company"(non sei sicuro di quello, però). Se siete su /about-us/, però, è semplice: href="company".

— Adowrath,

11

Altre risposte qui sembrano favorire l'omissione della barra finale. C'è un caso in cui una barra finale aiuta con l'ottimizzazione dei motori di ricerca (SEO). Questo è il caso in cui il tuo documento ha quella che sembra essere un'estensione di file che non lo è .html. Questo diventa un problema con i siti che classificano 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' .comestensione è un'estensione per i file dei comandi eseguibili di Windows. I motori di ricerca e i controllori di virus spesso non amano gli URL che sembrano contenere malware distribuito attraverso tali meccanismi. La barra finale sembra mitigare qualsiasi preoccupazione, consentendo alla pagina di posizionarsi nei motori di ricerca e ottenere dai controllori dei virus.

Se i tuoi URL non sono presenti .nella parte del file, ti consiglio di omettere la barra finale per semplicità.

— Stephen Ostermiller
fonte

Nessun vero motore di ricerca è così stupido. Questa risposta è pura speculazione.

— Navin,

1

In realtà ho riscontrato questo problema con Google. È successo diversi anni fa, quindi non sono sicuro che sarebbe ancora così oggi.

— Stephen Ostermiller,

Eh, questo è un buon punto dati. Anche se non sappiamo ancora se sia stato causato da qualcos'altro.

— Navin,

10

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, nessuna barra finale.

— Aaron Gage
fonte

3

Dal punto di vista SEO, la scelta di includere o meno una barra finale alla fine di un URL è irrilevante. Al giorno d'oggi, è comune vedere esempi di entrambi sul Web. Un sito non sarà penalizzato in alcun modo, né questa scelta influenzerà il posizionamento del motore di ricerca del tuo sito Web o altre considerazioni SEO.

Scegli una convenzione di denominazione degli URL che preferisci e includi un meta tag canonico nel file <head> sezione di ogni pagina web.

I motori di ricerca possono considerare una singola pagina web come due URL duplicati separati quando la incontrano con e senza la barra finale, ovvero example.com/about-us/e example.com/about-us.

È consigliabile includere un meta tag canonico in ogni pagina perché non puoi controllare come altri siti si collegano ai tuoi URL.

Il tag canonica si presenta così: <link rel="canonical" href="https://example.com/about-us" />. L'uso di un meta tag canonico garantisce che i motori di ricerca contino ciascuno dei tuoi URL una sola volta, indipendentemente dal fatto che altri siti Web includano una barra finale quando si collegano al tuo sito.

— rivolta
fonte