Quando devo usar uma barra final no meu URL?

Quando uma barra final deve ser usada em um URL? Por exemplo - meu URL deve ser parecido /about-us/ou não /about-us?

Estou plenamente ciente dos problemas relacionados ao SEO - conteúdo duplicado e coisa canônica; Estou tentando descobrir qual deles devo usar no contexto de veicular páginas corretamente sozinho.

Por exemplo, meu colega pensa que uma barra no final significa que é uma "pasta" - um "diretório", portanto esse não é o estilo correto. Mas acho que sem uma barra no final - também não está correta, porque quase parece uma pasta, mas não é e também não é um arquivo normal, mas um nome de arquivo sem extensão.

Existe uma maneira adequada de saber qual usar?

Na minha opinião pessoal, as barras finais são mal utilizadas.

Basicamente, o formato da URL veio do mesmo formato UNIX de arquivos e pastas, posteriormente, nos sistemas DOS e, finalmente, adaptado para a web.

Uma URL típica para este livro em um sistema operacional semelhante ao Unix seria um caminho de arquivo, como file: ///home/username/RomeoAndJuliet.pdf, identificando o livro eletrônico salvo em um arquivo em um disco rígido local.

Fonte: Wikipedia: Identificador Uniforme de Recursos

Outra boa fonte para ler: Wikipedia: Esquema URI

De acordo com a RFC 1738, que definiu URLs em 1994, quando os recursos contêm referências a outros recursos, eles podem usar links relativos para definir o local do segundo recurso como se dissesse "no mesmo local que este, exceto com o seguinte parente caminho". Continuou dizendo que essas URLs relativas dependem da URL original que contém uma estrutura hierárquica na qual o link relativo se baseia, e que os esquemas de FTP, HTTP e URL de arquivo são exemplos de alguns que podem ser considerados hierárquicos, com o componentes da hierarquia sendo separados por "/".

Fonte: Localizador Uniforme de Recursos (URL) da Wikipedia

Além disso:

Essa é a pergunta que ouvimos frequentemente. Avante para as respostas! Historicamente, é comum URLs com uma barra à direita indicar um diretório e aqueles sem uma barra à direita para indicar um arquivo:

http://example.com/foo/ (com barra à direita, convencionalmente um diretório)

http://example.com/foo (sem barra, normalmente um arquivo)

Fonte: Blog central do Google WebMaster - Para cortar ou não cortar

Finalmente:

1. Uma barra no final do URL faz o endereço parecer "bonito".

2. Um URL sem barra no final e sem extensão parece um pouco "estranho".

3. Você nunca nomeará seu arquivo CSS (por exemplo) http://www.sample.com/stylesheet/, não é?

MAS estou sendo um defensor das melhores práticas da Web, independentemente do ambiente. Pode ser instável e pouco claro, assim como você disse sobre o URL sem ext.

Não é uma questão de preferência. /basee /base/tem semântica diferente. Em muitos casos, a diferença não é importante. Mas é importante quando existem URLs relativos.

• childem relação a /base/é /base/child.
• childem relação a /baseé (talvez surpreendentemente) /child.

Sempre fico surpreso com o uso extensivo de barras finais em URLs que não são de diretório (WordPress entre outros). Isso realmente não deve ser um debate de um ou outro, porque colocar uma barra após um recurso é semanticamente errado. A web foi projetada para fornecer recursos endereçáveis, e esses endereços - URLs - foram projetados para emular uma hierarquia de sistemas de arquivos no estilo * nix. Nesse contexto:

• As barras sempre indicam diretórios, nunca arquivos.
• Os arquivos podem ter qualquer nome (com ou sem extensões), mas não podem conter ou terminar com barras.

Usando essas diretrizes, é errado colocar uma barra após um recurso que não seja de diretório.

Isso não é realmente uma questão de estética, mas de fato uma diferença técnica. O diretório pensando nisso é totalmente correto e praticamente explica tudo. Vamos resolver isso:

Você está de volta à idade da pedra agora ou veicula apenas páginas estáticas

Você tem uma estrutura de diretórios fixa no servidor da Web e apenas arquivos estáticos, como imagens, html e assim por diante - sem scripts do lado do servidor ou qualquer outro.

Um navegador solicita /index.htm, ele existe e é entregue ao cliente. Mais tarde, você terá muitos - digamos - filmes em DVD revisados ​​e uma página html para cada um deles no /dvd/diretório. Agora alguém solicita /dvd/adams_apples.htme é entregue porque está lá.

Em algum dia, alguém apenas solicita /dvd/- que é um diretório e o servidor está tentando descobrir o que entregar. Além de restrições de acesso e assim por diante, existem duas possibilidades: mostrar ao usuário o conteúdo do directório (Aposto que você já viu isso em algum lugar) ou mostrar um arquivo padrão (em Apache é: DirectoryIndex: sets the file that Apache will serve if a directory is requested.)

Até aqui tudo bem, este é o caso esperado. Ele já mostra a diferença no manuseio, então vamos entrar nele:

Às 5:34 da manhã, você cometeu um erro ao enviar seus arquivos

(O que é totalmente compreensível.) Então, você fez algo totalmente errado e, em vez de carregar, /dvd/the_big_lebowski.htmcarregou o arquivo como dvd(sem extensão) para /.

Alguém marcou a sua /dvd/listagem de diretórios (é claro que você não queria criar e sempre atualizava essa aparência bacana index.htm) e está visitando seu site. O conteúdo do diretório é entregue - tudo bem.

Alguém ouviu falar da sua lista e está digitando /dvd. E agora está ferrado. Em vez de listar o diretório de DVD, o servidor encontra um arquivo com esse nome e está entregando o arquivo Big Lebowski.

Então, você exclui esse arquivo e diz ao cara para recarregar a página. Seu servidor procura o /dvdarquivo, mas ele se foi. A maioria dos servidores notará que existe um diretório com esse nome e informará ao cliente que o que ele estava procurando realmente está em outro lugar. A resposta provavelmente será:

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

Portanto, ignorando totalmente o que você pensa sobre diretórios ou arquivos, o servidor só pode lidar com essas coisas e - a menos que seja dito de outra maneira - decide por você sobre o significado de "barra ou não".

Finalmente, depois de receber essa resposta, o cliente carrega /dvd/e está tudo bem.

Está bom? Não.

"Muito bem" não é bom o suficiente para você

Você tem alguma página dinâmica na qual tudo é passado /index.phpe processado. Tudo funcionou muito bem até agora, mas tudo começa a parecer mais lento e você investiga.

Em breve, você perceberá que /dvd/listestá fazendo exatamente o mesmo: redirecionar para o /dvd/list/qual é traduzido internamente index.php?controller=dvd&action=list. Um pedido adicional - mas ainda pior! customer/loginredireciona para o customer/login/qual, por sua vez, redireciona para o URL HTTPS de customer/login/. Você acaba tendo toneladas de redirecionamentos desnecessários HTTP (= pedidos adicionais) que tornam a experiência do usuário mais lento.

Provavelmente você também tem um índice de diretório padrão aqui: index.php?controller=dvdsem actionsimplesmente carregar internamente index.php?controller=dvd&action=list.

Resumo:

• Se terminar /, nunca poderá ser um arquivo. Nenhum servidor adivinhando.

• Barra ou nenhuma barra são significados completamente diferentes. Há uma diferença técnica / de recursos entre "barra ou nenhuma barra", e você deve estar ciente disso e usá-lo de acordo. Só porque o servidor provavelmente carrega /dvd/index.htm- ou carrega o material de script correto - quando você diz /dvd: Faz, mas não porque você fez a solicitação correta. O que teria sido /dvd/.

• Omitir a barra, mesmo que você queira dizer que a versão com barra oferece uma penalidade adicional de solicitação HTTP. O que é sempre ruim (pense na latência móvel) e tem mais peso do que um "URL bonito" - especialmente porque os rastreadores não são tão burros quanto os SEOs acreditam ou querem que você acredite;)

Quando você faz o seu URL /about-us/(com a barra final), é fácil começar com um único arquivo index.htmle depois expandi-lo e adicionar mais arquivos (por exemplo our-CEO-john-doe.jpg) ou até mesmo construir uma hierarquia sob ele (por exemplo /about-us/company/, /about-us/products/, etc.), conforme necessário, sem alterando o URL publicado . Isso oferece uma ótima flexibilidade.

Outras respostas aqui parecem favorecer a omissão da barra final. Há um caso em que uma barra final ajudará na otimização do mecanismo de busca (SEO). É esse o caso do seu documento que parece ser uma extensão de arquivo que não é .html. Isso se torna um problema com sites que classificam sites. Eles podem escolher entre esses dois URLs:

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

Nesse caso, eu escolheria aquele com a barra à direita . Isso ocorre porque a .comextensão é uma extensão para os arquivos de comando executável do Windows. Os mecanismos de pesquisa e os antivírus frequentemente não gostam de URLs que parecem conter malware distribuído por esses mecanismos. A barra final parece atenuar qualquer preocupação, permitindo que a página seja classificada nos mecanismos de pesquisa e seja verificada por vírus.

Se seus URLs não tiverem .parte do arquivo, recomendo que você omita a barra final por simplicidade.

Quem disse que um nome de arquivo precisa de uma extensão? dê uma olhada em uma máquina * nix em algum momento ...
Eu concordo com seu amigo, sem barra.

De uma perspectiva de SEO, a escolha de incluir ou não uma barra final no final de um URL é irrelevante. Hoje em dia, é comum ver exemplos de ambos na web. Um site não será penalizado de qualquer maneira, nem esta escolha afetará a classificação do mecanismo de pesquisa do seu site ou outras considerações de SEO.

Escolha uma convenção de nomenclatura de URL de sua preferência e inclua uma metatag canônica na <head> seção de cada página da web.

Os mecanismos de pesquisa podem considerar uma única página da Web como dois URLs duplicados separados quando a encontrarem com e sem a barra final, ou seja, example.com/about-us/e example.com/about-us.

É uma prática recomendada incluir uma metatag canônica em cada página, porque você não pode controlar como outros sites apontam para seus URLs.

A tag canônica parece com isso: <link rel="canonical" href="https://example.com/about-us" />. O uso de uma metatag canônica garante que os mecanismos de pesquisa contabilizem apenas cada um dos seus URLs apenas uma vez, independentemente de outros sites incluírem uma barra final no link para o seu site.