web-dev-qa-db-pt.com

Quando devo usar uma barra no meu URL?

Quando deve ser usada uma barra final em um URL? Por exemplo, meu URL deve ser parecido com /about-us/ ou como /about-us?

Tenho plena consciência das questões relacionadas ao SEO - conteúdo duplicado e a coisa canônica; Estou tentando descobrir qual deles devo usar no contexto de páginas de exibição corretamente sozinho.

Por exemplo, meu colega está pensando que uma barra no final significa que é uma "pasta" - um "diretório", portanto, esse não é um estilo correto. Mas eu acho que sem uma barra no final - não é muito correto também, 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?

252
Denis

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

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

Um URL típico 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: URI Scheme

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 a localização do segundo recurso como se dissessem "no mesmo local que este, exceto com o seguinte relativo caminho". Ele passou a dizer que tais URLs relativos são dependentes da URL original contendo uma estrutura hierárquica contra a qual o link relativo é baseado, e que os esquemas de FTP, http e file URL são exemplos de alguns que podem ser considerados hierárquicos, com os componentes da hierarquia separados por "/".

Fonte: Localizador Uniforme de Recursos da Wikipédia (URL)

Além disso:

Essa é a pergunta que ouvimos com frequência. Avante para as respostas! Historicamente, é comum que os URLs com uma barra final indiquem um diretório e aqueles sem uma barra final para denotar um arquivo:

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

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

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

Finalmente:

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

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

  3. Você nunca vai nomear seu arquivo CSS (por exemplo) http://www.sample.com/stylesheet/ você faria?

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

125
Dementic

Não é uma questão de preferência. /base e /base/ têm semânticas diferentes. Em muitos casos, a diferença não é importante. Mas é importante quando existem URLs relativos.

  • child relativo a /base/ é /base/child.
  • child relativo a /base é (talvez surpreendentemente) /child.
147
Raedwald

Eu sempre me surpreendo com o uso extensivo de barras à direita em URLs que não são de diretório (WordPress, entre outros). Isso realmente não deveria ser um ou outro debate, 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 sistema de arquivos no estilo * nix. Nesse contexto:

  • Barras sempre denotam 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.

57
Yarin

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

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

Você tem uma estrutura de diretório fixa em seu servidor web e apenas arquivos estáticos como imagens, html e assim por diante - nenhum script 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 diretório /dvd/. Agora alguém solicita /dvd/adams_apples.htm e ele é 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 diretório (aposto que você já viu isso em algum lugar) ou mostrar um arquivo padrão (no Apache é: DirectoryIndex: sets the file that Apache will serve if a directory is requested.)

Até aí tudo bem, este é o caso esperado. Já mostra a diferença no manuseio, então vamos entrar nisso:

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

(Que é completamente compreensível.) Então, você fez algo totalmente errado e, em vez de fazer o upload de /dvd/the_big_lebowski.htm, carregou esse arquivo como dvd (sem extensão) para /.

Alguém marcou sua listagem de diretórios /dvd/ (é claro que você não queria criar e atualizar sempre esse 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 seu arquivo Big Lebowski.

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

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

Então, 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 forma diferente - 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 uma página dinâmica em que tudo é passado para /index.php e processado. Tudo funcionou muito bem até agora, mas a coisa toda começa a parecer mais lenta e você investiga.

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

O mais provável é que você também tenha um índice de diretório padrão aqui: index.php?controller=dvd sem action simplesmente carrega internamente index.php?controller=dvd&action=list.

Resumo:

  • Se terminar com / pode nunca ser um arquivo. Nenhuma adivinhação do servidor.

  • Barra ou nenhuma barra são significados totalmente diferentes. Existe uma diferença técnica/recurso entre "barra ou não barra", e você deve estar ciente disso e usá-la de acordo. Só porque o servidor provavelmente carrega /dvd/index.htm - ou carrega o material correto do script - quando você diz /dvd: ele faz isso, mas não porque você fez o pedido correto. Qual teria sido /dvd/.

  • Omitindo a barra mesmo que você realmente signifique a versão slashed lhe dá uma penalidade de requisição HTTP adicional. Que é sempre ruim (pense de latência móvel) e tem mais peso do que uma "URL bonita" - especialmente porque os rastreadores não são tão burros quanto os SEOs acreditam ou querem que você acredite;)

24
nico gawenda

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

18
musiphil

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 de seu documento ter o 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 o com a barra final. Isso ocorre porque a extensão .com é uma extensão dos arquivos de comando executáveis ​​do Windows. Mecanismos de pesquisa e verificadores de vírus geralmente não gostam de URLs que parecem conter malwares distribuídos por esses mecanismos. A barra à direita parece atenuar quaisquer preocupações, permitindo que a página seja classificada nos mecanismos de pesquisa e obtida pelos verificadores de vírus.

Se seus URLs não tiverem . na parte do arquivo, recomendamos a omissão da barra final para simplificar.

10
Stephen Ostermiller

Quem diz 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 nenhuma barra.

9
Aaron Gage

Do ponto de vista do SEO, escolher se deve ou não incluir uma barra no final de um URL é irrelevante. Hoje em dia, é comum ver exemplos de ambos na web. Um site não será penalizado de nenhuma maneira, nem essa escolha afetará o ranking do mecanismo de pesquisa do seu site ou outras considerações de SEO.

Basta escolher uma convenção de nomenclatura de URL de sua preferência e incluir uma meta tag canônica na seção <head> 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 meta tag canônica em cada página, pois você não pode controlar como outros sites vinculam seus URLs.

A tag canônica se 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 contem uma vez cada um de seus URLs, independentemente de outros websites incluírem uma barra ao se vincularem ao seu site.

2
riot