¿Debo usar una extensión de archivo o no?

Siempre me he preguntado sobre esto y nunca encontré una buena solución.

Pero esta pregunta me lo recordó.

Cuando tengo una URL en mi sitio web, se puede visualizar y acceder a cualquiera de las siguientes formas:

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 ...

Ahora, puedo entender los méritos de agregar palabras clave en la URL. Incluso la guía de SEO más básica mencionará hacer precisamente eso. ... pero en aras de la cordura, la claridad, la facilidad de lectura, la facilidad de uso, etc., incluido el cumplimiento web ...

¿Se prefiere tener una extensión de archivo o no?

Realmente, en el fondo mi lógica me dice: sí, debería. La razón es que esto se remonta a los días del pasado cuando Internet era principalmente USENET, FIDONET, FTP y GOPHER.

Vea, si una URL no tiene nombre de archivo , entonces normalmente se considera un directorio . Aquí es donde surgió index.htm, porque de forma predeterminada enumera el directorio si no se encuentra ningún archivo de índice. Sin embargo, muy pronto, los programadores web comenzaron a anular esto y usar index.htm para servir el contenido de ese directorio web como una página . La principal diferencia fue que se agregó lenguaje de marcado, y esto se analizó en el navegador. Con este lenguaje de marcado, la Content-Type:text/html;etiqueta en el encabezado de respuesta se convirtió en el indicador de qué tipo de archivo era para cualquier archivo . HTML parece ser el único "tipo de archivo" que simplemente no tiene extensiones con nombres consistentes, excepto cuando se guardan.

Desafortunadamente, una vez que las páginas web se convirtieron en lo principal, se convirtió en un error de seguridad mostrar realmente el contenido del directorio, por lo que todo quedó oculto con solo el contenido de la URL real que se muestra.

Sin mencionar las guerras de nombres de archivos multiplataforma. Windows basado requiere una extensión de 3 dígitos o menos, y Unix / Mac puede tener más. Entonces, ¿debería ser .HTMo .HTMLo NONEy dejar que la plataforma decida?

Entonces, en esencia, supongo que lo que estoy tratando de resolver está más allá del SEO y trata más con la estética y el cumplimiento web.

Utilice una extensión. Donde hay más de una representación o donde el software del cliente es absolutamente estúpido y se niega a aceptar solo el tipo de contenido (QuickTime, RealPlayer, Outlook, etc. Lo estoy mirando):

• http://www.somesite.com/subdirectory - esta puede ser su versión de negociación automática que utiliza etiquetas META canónicas para señalar la representación real

• http://www.somesite.com/subdirectory/ - siempre vale la pena admitir barras diagonales finales en cualquier URL, pero utilizando etiquetas META canónicas (no redirecciona, ya que esto es una ralentización innecesaria) para apuntar a la URL correcta

• http://www.somesite.com/subdirectory/index.htmy http://www.somesite.com/subdirectory/some-relevant-keywords.htm- el límite de extensión de tres caracteres no se aplica a HTTP (solo el FileSystem / OS subyacente), por lo que el cliente puede guardarlo como index.html o aa si lo desea, mientras aún puede acceder a él

• http://www.somesite.com/subdirectory/index.html - si sirve una versión .atom, .xml o similar, entonces tiene sentido honrar también la versión .html (y enlazarla canónicamente a través de etiquetas LINK en la versión negociada automáticamente) - use encabezados HTTP Content-Location para señalar sin embargo, a la versión de negociación automática, recuerde que también puede ir en varios idiomas (.en, .es, etc.) o en varios juegos de caracteres (.utf8, .utf16, etc.)

• http://www.somesite.com/subdirectory/index.phpy http://www.somesite.com/subdirectory/index.asp, a menos que esté sirviendo el código fuente, no tiene sentido admitir

• http://www.somesite.com/subdirectory/some-relevant-keywords - El SEO es un arte en constante cambio y si esto funciona para ti, entonces genial

• http://www.somesite.com/subdirectory/index.php?page=some-relevant-keywords, http://www.somesite.com/subdirectory/?page=some-relevant-keywordsY http://www.somesite.com/subdirectory/?page=some-relevant-keywords&even=more-keywords- si hay un número infinito de formas de manipular el contenido, entonces es genial - pero por lo general las páginas merecen su propia URL no están a evitar una cadena de consulta y este tipo de URL (intentar conseguir analfabeta alguien computadora para escribir una de los de)

Yo diría que no incluya la extensión del archivo si el software que está utilizando le permite omitirlo. Entonces, de su lista de ejemplos, mi preferencia sería:

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

A los navegadores no les importa si algo es un directorio o no en el sitio, o si es un archivo HTML, un archivo .asp o lo que sea, simplemente hacen una solicitud HTTP y obtienen una respuesta HTTP. Entonces, si la extensión es superflua, suéltela.

Esto también tiene el beneficio adicional de hacer que sus URL sean más concisas (y más fáciles de leer en el teléfono: "los productos de ejemplo de punto com slash" suenan mucho mejor que "los productos de ejemplo de punto com slash dot htm l") y lo hacen más fácil para cambiar la tecnología en el futuro (ya que no se requeriría un cambio de URL).

Los URI geniales no cambian . (Vaya a la sección titulada "Entonces, ¿qué debo hacer? Diseño de URI")

¿Se prefiere tener una extensión de archivo o no?

No hay nada en los RFC que ordene tener extensiones de archivo, ni tampoco hay nada que requiera que los omita. Es una elección que haces.

Los URI HTTP conformes no necesitan extensiones de archivo para nada. Hay un amplio conjunto de encabezados HTTP (especialmente el tipo MIME) para manejar todo lo que las extensiones de archivo se usan de otra manera.

Dicho esto, la mayoría de los navegadores de hoy confían en una combinación de tipo MIME, extensión y 'huella digital' binaria de los primeros bytes para determinar el tipo de contenido. Esto a veces puede dar resultados sorprendentes , por lo que es importante que los webmasters establezcamos los encabezados correctos (y posiblemente desactivemos la detección de tipos de contenido si estamos 101% seguros de que nuestros encabezados son correctos).

Hay una situación en la que las extensiones de archivo son útiles: si el usuario final guarda el contenido de su sitio en su computadora local para su uso posterior. Teóricamente, un navegador 'inteligente' debería garantizar que el contenido guardado funcione para el tipo de computadora local; pero en la práctica, puede ayudar a todos al ofrecer contenido con extensiones estándar de la industria como .jpg, .mp4, .css, etc. En mi experiencia, todos los navegadores manejan el tipo HTML correctamente. No necesita agregar una extensión .htm / .html en HTML, el navegador manejará este tipo de contenido específico correctamente.

Seguridad: se podría argumentar que existe un beneficio de seguridad al ocultar qué plataforma está utilizando (.php / .asp, etc.). Es verdad. En la práctica, creo que cualquier buen hacker descubrirá esto de inmediato, así que no creo que valga la pena ocultar estas extensiones solo por seguridad.

Consideración especial: si planea usar una CDN en el futuro, y su CDN es del tipo "push" (el contenido se carga previamente en la CDN fx a través de SFTP), entonces es posible que desee conservar las extensiones de archivo. La mayoría de los sistemas de terceros examinan las extensiones de archivo para descubrir con qué tipo MIME servir el contenido.

Mi elección personal se ha convertido en:

• Cuando mi aplicación web genera dinámicamente HTML, no agrego una extensión 'falsa' .html para imitar un directorio y una estructura de archivos que en realidad no existe. Normalizo las URL y estandarizo el formato de URL utilizado por razones de SEO. Personalmente prefiero tener una barra diagonal en la última hoja de la URL, es decir http://example.org/first/second/, pero eso es cuestión de gustos.

• Cuando de hecho estamos hablando de archivos reales que se cargan en un disco duro en algún lugar, entonces mantengo la extensión de archivo 'normal' para el tipo. Por lo tanto, .css / .js / .exe / .mp4, etc. están en uso para este tipo de contenido.

He hecho un poco de experimentación informal, y lo que descubrí me sorprendió pero tiene algo de sentido.

Desde el punto de vista del contenido que se entrega al usuario, así como el raspado de pantalla, el tipo de contenido rige el día.

Sin embargo, la presencia o ausencia de una extensión, así como lo que es esa extensión, parece influir en las visitas al motor de búsqueda.

Cuando omití cualquier extensión, obtuve relativamente pocos resultados, como si la URL fuera una ubicación o contenido dinámico y, por lo tanto, no valiera mucho la indexación.

Cuando cambié los mismos enlaces para usar una extensión .xml, debido a que las páginas fueron realmente generadas por XSLT (en el lado del servidor), la indexación se redujo aún más, tal vez porque pensaba que eran meramente datos o el resultado de alguna solicitud programática .

Cuando cambié los mismos enlaces para usar .html, los motores de búsqueda se volvieron locos con el sitio.

Por el momento, mi sitio maneja los tres de forma transparente, pero cuando proporciona un enlace en el que se puede hacer clic, devuelvo la versión .html de la URL.

Me gustaría pensar que los motores de búsqueda eran un poco más inteligentes o menos sesgados, pero eso es lo que he observado que sucede con mis páginas.

No, no debe usar una extensión de archivo para los tipos de página normales a menos que lo necesite por una razón técnica. ¿Cómo mejora la experiencia del usuario? Es más para escribir, pero no les dice nada útil. ¿Qué podrán hacer sabiendo que su sitio es PHP, ASP, etc.? Una URL es más simple, más limpia, más utilizable y más memorable sin una extensión de archivo.

Vea, si una URL no tiene nombre de archivo, entonces normalmente se considera un directorio.

No creo estar de acuerdo. En general, una URL es un directorio solo cuando tiene una barra inclinada final. Sin una barra inclinada final, se considera un archivo.

Solo debe agregar una extensión de archivo, si el contenido detrás del URI es en realidad un archivo. Pero incluso entonces, podría soltarlo, si solo hay una representación de él (JPG, PDF, ...).

Si hay varias representaciones, la forma HTTP sería tener el formato negociado a través del Acceptencabezado. Pero si desea que sus usuarios puedan opinar, es probable que desee tener una extensión para que puedan elegir qué representación desean (JPG, PNG, ...) solicitando uno u otro URI.