Devo usar uma extensão de arquivo ou não?

Eu sempre me perguntei sobre isso e nunca encontrei uma boa solução.

Mas essa pergunta me lembrou disso.

Quando tenho um URL no meu site, ele pode ser exibido e acessado de uma das seguintes maneiras:

http://www.somesite.com/subdirectory
http://www.somesite.com/subdirectory/
http://www.somesite.com/subdirectory/index.htm
http://www.somesite.com/subdirectory/index.html
http://www.somesite.com/subdirectory/index.php
http://www.somesite.com/subdirectory/index.asp
http://www.somesite.com/subdirectory/some-relevant-keywords
http://www.somesite.com/subdirectory/some-relevant-keywords.htm
http://www.somesite.com/subdirectory/index.php?page=some-relevant-keywords
http://www.somesite.com/subdirectory/?page=some-relevant-keywords
http://www.somesite.com/subdirectory/?page=some-relevant-keywords&even=more-keywords

etc ...

Agora, eu posso entender o mérito de adicionar palavras-chave no URL. Até o guia mais básico de SEO menciona isso. ... mas por uma questão de sanidade, clareza, facilidade de leitura, facilidade de uso e assim por diante, incluindo conformidade com a Web ...

É preferível ter uma extensão de arquivo ou não?

Realmente, no fundo minha lógica me diz: sim, deveria. A razão é que isso remonta aos dias do passado, quando a internet era principalmente USENET, FIDONET, FTP e GOPHER.

Veja, se um URL não tem nome de arquivo , normalmente é considerado um diretório . É aqui que surgiu o index.htm, porque, por padrão, lista o diretório se nenhum arquivo de índice for encontrado. No entanto, em breve, os programadores da Web começaram a substituir isso e usar o index.htm para realmente servir o conteúdo desse diretório da Web como uma página . A principal diferença foi que a linguagem de marcação foi adicionada e foi analisada no navegador. Com essa linguagem de marcação, a Content-Type:text/html;tag no cabeçalho da resposta se tornou o indicador do tipo de arquivo para qualquer arquivo . O HTML parece ser o único "tipo de arquivo" que simplesmente não possui extensões nomeadas de maneira consistente, exceto quando são salvas.

Infelizmente, uma vez que as páginas da Web se tornaram o principal, tornou-se um erro de segurança exibir o conteúdo do diretório, então tudo ficou oculto apenas com o conteúdo real da URL sendo exibido.

Sem mencionar as guerras de nomeação de arquivos de plataforma cruzada. O Windows baseado em janelas requer uma extensão de 3 ou menos dígitos e o unix / mac pode ter mais. Então deveria ser .HTMou .HTMLou NONEdeixar a plataforma decidir?

Então, em essência, acho que o que estou tentando descobrir está além do SEO e lida mais com estética e conformidade com a Web.

Use uma extensão. Onde houver mais de uma representação ou onde o software cliente seja absolutamente estúpido e se recuse a aceitar o Tipo de Conteúdo sozinho (QuickTime, RealPlayer, Outlook, etc., estou olhando para você):

• http://www.somesite.com/subdirectory - pode ser sua versão de negociação automática que usa tags META da Canonical para apontar para a representação real

• http://www.somesite.com/subdirectory/ - sempre vale a pena suportar barras à direita em qualquer URL, mas usando tags Canonical META (não redireciona, pois isso é uma desaceleração desnecessária) para apontar para o URL correto

• http://www.somesite.com/subdirectory/index.htme http://www.somesite.com/subdirectory/some-relevant-keywords.htm- o limite de extensão de três caracteres não se aplica ao HTTP (apenas o FileSystem / OS subjacente), para que o cliente possa salvá-lo como index.html ou aa, se desejar, enquanto ainda pode acessá-lo

• http://www.somesite.com/subdirectory/index.html - se você veicular uma versão .atom, .xml ou semelhante, também faz sentido honrar a versão .html (e vincular-se canonicamente a ela por meio de tags LINK na versão negociada automaticamente) - use os cabeçalhos de HTTP Content-Location para apontar para a versão de negociação automática - lembre-se de que você também pode usar vários idiomas (.en, .es, etc ...) ou vários caracteres (.utf8, .utf16, etc ...)

• http://www.somesite.com/subdirectory/index.phpe http://www.somesite.com/subdirectory/index.asp- a menos que você esteja servindo o código fonte, eles não fazem sentido oferecer suporte

• http://www.somesite.com/subdirectory/some-relevant-keywords - SEO é uma arte em constante mudança e, se isso funcionar para você, é ótimo

• http://www.somesite.com/subdirectory/index.php?page=some-relevant-keywords, http://www.somesite.com/subdirectory/?page=some-relevant-keywordse http://www.somesite.com/subdirectory/?page=some-relevant-keywords&even=more-keywords- se houver um número infinito de maneiras de manipular o conteúdo, isso é ótimo - mas geralmente as páginas merecem seu próprio URL, não uma string de consulta, e esse tipo de URL deve ser evitado (tente fazer com que alguém analfabeto do computador digite um dos aqueles em)

Eu diria que não inclua a extensão do arquivo se o software que você está usando permitir que você o omita. Portanto, na sua lista de exemplos, minha preferência seria:

http://www.somesite.com/subdirectory/some-relevant-keywords

Os navegadores não se importam se algo é um diretório ou não no site, se é um arquivo HTML, um arquivo .asp ou o que quer que seja - eles simplesmente fazem uma solicitação HTTP e obtêm uma resposta HTTP. Portanto, se a extensão for supérflua, solte-a.

Isso também tem o benefício adicional de tornar seus URLs mais concisos (e mais fáceis de ler no telefone - "exemplo de produtos com barra pontilhada" é muito mais agradável do que "exemplo de produtos com barra pontilhada dot htm l") e facilita para mudar de tecnologia no futuro (já que nenhuma alteração de URL seria necessária).

URIs legais não mudam . (Vá para a seção intitulada "Então, o que devo fazer? Criando URIs")

É preferível ter uma extensão de arquivo ou não?

Não há nada nas RFCs que exija extensões de arquivo, nem há algo que exija que você as deixe de fora. É uma escolha que você faz.

Os URIs HTTP compatíveis não precisam de extensões de arquivo para nada. Há um rico conjunto de cabeçalhos HTTP (especialmente o tipo MIME) para lidar com tudo para o qual as extensões de arquivo são usadas.

Dito isto, a maioria dos navegadores atualmente depende de uma combinação de tipo MIME, extensão e 'impressão digital' binária dos primeiros bytes para determinar o tipo de conteúdo. Às vezes, isso pode dar resultados surpreendentes e, portanto, é importante que os webmasters definam os cabeçalhos corretos (e possivelmente desabilitemos o sniffing do tipo de conteúdo se tivermos 101% de certeza de que nossos cabeçalhos estão corretos).

Há uma situação em que as extensões de arquivo são úteis: se o usuário final salvar o conteúdo do seu site no computador local para uso posterior. Teoricamente, um navegador 'inteligente' deve garantir que o conteúdo salvo funcione para o tipo de computador local; mas, na prática, você pode ajudar a todos exibindo conteúdo com extensões padrão do setor, como .jpg, .mp4, .css etc. Na minha experiência, todos os navegadores lidam com o tipo HTML corretamente. Você não precisa adicionar uma extensão .htm / .html ao HTML, o navegador manipulará esse tipo de conteúdo específico corretamente.

Segurança: Pode-se argumentar que há um benefício de segurança em ocultar qual plataforma você está usando (.php / .asp etc). Isso é verdade. Na prática, acho que qualquer bom hacker descobrirá isso imediatamente, então não acho que ocultar essas extensões apenas por segurança vale a pena.

Consideração especial: se você planeja usar uma CDN no futuro, e sua CDN é do tipo "push" (o conteúdo é enviado para a CDN anteriormente através do SFTP), convém manter as extensões de arquivo. A maioria dos sistemas de terceiros analisa as extensões de arquivo para descobrir com qual tipo MIME servir o conteúdo.

Minha escolha pessoal tornou-se:

• Quando o HTML é gerado dinamicamente pelo meu aplicativo da web, não adiciono uma extensão .html 'falsa' para imitar uma estrutura de diretório e arquivo que não está realmente lá. Normalizo os URLs e padronizo o formato do URL usado por razões de SEO. Pessoalmente, prefiro ter uma barra na última folha da URL http://example.org/first/second/, mas é uma questão de gosto.

• Quando na verdade estamos falando sobre arquivos reais que são carregados em um disco rígido em algum lugar, eu mantenho a extensão de arquivo 'normal' para o tipo. Portanto, .css / .js / .exe / .mp4 etc estão em uso para esses tipos de conteúdo.

Fiz algumas experiências informais e o que descobri me surpreendeu, mas faz algum sentido.

Do ponto de vista do conteúdo sendo entregue ao usuário, bem como da captura de tela, o Tipo de Conteúdo rege o dia.

No entanto, a presença ou ausência de uma extensão, bem como o que é essa extensão, parece influenciar as visitas aos mecanismos de pesquisa.

Quando omiti qualquer extensão, recebi relativamente poucos acessos - como se o URL fosse um local ou conteúdo dinâmico e, portanto, não valesse muito a pena indexar.

Quando alterei os mesmos links para usar uma extensão .xml, porque as páginas foram realmente geradas pelo XSLT (no lado do servidor), a indexação caiu mais ainda - talvez porque pensasse que eram apenas dados ou o resultado de alguma solicitação programática .

Quando mudei os mesmos links para usar .html, os mecanismos de pesquisa foram à loucura com o site.

No momento, meu site lida com os três de forma transparente, mas quando ele fornece um link clicável, eu retorno a versão .html do URL.

Eu gostaria de pensar que os mecanismos de pesquisa eram um pouco mais inteligentes ou menos tendenciosos, mas é o que eu observei acontecer com minhas páginas.

Não, você não deve usar uma extensão de arquivo para tipos de página normais, a menos que seja absolutamente necessário por um motivo técnico. Como isso melhora a experiência do usuário? É mais para digitar, mas não lhes diz nada de útil. O que eles poderão fazer sabendo que seu site é PHP, ASP, etc? Um URL é mais simples, mais limpo, mais utilizável e mais memorável sem uma extensão de arquivo.

Veja, se um URL não tem nome de arquivo, normalmente é considerado um diretório.

Acho que não concordo. Geralmente, um URL é um diretório apenas quando possui uma barra final. Sem uma barra final, é considerado um arquivo.

Você só deve adicionar uma extensão de arquivo, se o conteúdo por trás do URI for realmente um arquivo. Mas, mesmo assim, você pode descartá-lo, se houver apenas uma representação (JPG, PDF, ...).

Se houver várias representações, a maneira HTTP seria ter o formato negociado através do Acceptcabeçalho. Porém, se você quiser que seus usuários tenham uma opinião, provavelmente precisará de uma extensão para que eles possam escolher qual representação desejam (JPG, PNG, ...) solicitando um ou outro URI.