¿Cuándo debo usar una barra inclinada final en mi URL?

¿Cuándo se debe usar una barra inclinada final en una URL? Por ejemplo, ¿mi URL debería ser similar /about-us/o similar /about-us?

Soy plenamente consciente de los problemas relacionados con el SEO: contenido duplicado y lo canónico; Estoy tratando de averiguar cuál debo usar en el contexto de servir páginas correctamente solo.

Por ejemplo, mi colega está pensando que una barra diagonal al final significa que es una "carpeta", un "directorio", por lo que este no es un estilo correcto. Pero creo que sin una barra al final, tampoco es del todo correcto, porque casi parece una carpeta, pero no lo es y tampoco es un archivo normal, sino un nombre de archivo sin extensión.

¿Hay una manera adecuada de saber cuál usar?

En mi opinión personal, las barras diagonales finales se usan incorrectamente.

Básicamente, el formato URL provino del mismo formato UNIX de archivos y carpetas, más tarde, en sistemas DOS, y finalmente, adaptado para la web.

Una URL típica para este libro en un sistema operativo tipo Unix sería una ruta de archivo como file: ///home/username/RomeoAndJuliet.pdf, que identifica el libro electrónico guardado en un archivo en un disco duro local.

Fuente: Wikipedia: Identificador uniforme de recursos

Otra buena fuente para leer: Wikipedia: Esquema URI

De acuerdo con RFC 1738, que definió las URL en 1994, cuando los recursos contienen referencias a otros recursos, pueden usar enlaces relativos para definir la ubicación del segundo recurso como si dijera "en el mismo lugar que este, excepto con el siguiente pariente camino". Continuó diciendo que tales URL relativas dependen de la URL original que contiene una estructura jerárquica contra la cual se basa el enlace relativo, y que los esquemas de URL ftp, http y archivo son ejemplos de algunos que pueden considerarse jerárquicos, con el componentes de la jerarquía separados por "/".

Fuente: Wikipedia Uniform Resource Locator (URL)

También:

Esa es la pregunta que escuchamos a menudo. ¡Adelante a las respuestas! Históricamente, es común que las URL con una barra inclinada final indiquen un directorio, y aquellas sin una barra inclinada final denoten un archivo:

http://example.com/foo/ (con barra diagonal, convencionalmente un directorio)

http://example.com/foo (sin barra diagonal, convencionalmente un archivo)

Fuente: Blog de Google WebMaster Central: recortar o no recortar

Finalmente:

1. Una barra diagonal al final de la URL hace que la dirección se vea "bonita".

2. Una URL sin barra oblicua al final y sin extensión parece algo "extraña".

3. Nunca nombrará su archivo CSS (por ejemplo) http://www.sample.com/stylesheet/, ¿verdad?

PERO soy un defensor de las mejores prácticas web independientemente del entorno. Puede ser inestable y poco claro, tal como dijiste sobre la URL sin ext.

No es una cuestión de preferencia. /basey /base/tienen una semántica diferente. En muchos casos, la diferencia no es importante. Pero es importante cuando hay URL relativas.

• childrelativo a /base/es /base/child.
• childrelativo a /basees (quizás sorprendentemente) /child.

Siempre me sorprende el uso extensivo de barras diagonales finales en URL que no son de directorio (WordPress, entre otros). Esto realmente no debería ser un debate de uno u otro porque poner una barra después de un recurso es semánticamente incorrecto. La web fue diseñada para entregar recursos direccionables, y esas direcciones - URL - fueron diseñadas para emular una jerarquía de sistema de archivos estilo * nix. En ese contexto:

• Las barras siempre denotan directorios, nunca archivos.
• Los archivos pueden tener cualquier nombre (con o sin extensiones), pero no pueden contener ni terminar con barras inclinadas.

Usando estas pautas, es incorrecto poner una barra diagonal después de un recurso que no sea de directorio.

Eso no es realmente una cuestión de estética, sino una diferencia técnica. El directorio que lo piensa es totalmente correcto y prácticamente explica todo. Vamos a resolverlo:

Ahora está de vuelta en la edad de piedra o solo sirve páginas estáticas.

Tiene una estructura de directorio fija en su servidor web y solo archivos estáticos como imágenes, html, etc.

Un navegador solicita /index.htm, existe y se entrega al cliente. Más tarde, tendrá muchas, digamos, películas en DVD revisadas y una página html para cada una de ellas en el /dvd/directorio. Ahora alguien solicita /dvd/adams_apples.htmy se entrega porque está allí.

Algún día, alguien simplemente solicita /dvd/, que es un directorio y el servidor está tratando de averiguar qué entregar. Además de las restricciones de acceso y así sucesivamente, hay dos posibilidades: mostrar al usuario el contenido del directorio (apuesto a que ya ha visto esto en alguna parte) o mostrar un archivo por defecto (en Apache es: DirectoryIndex: sets the file that Apache will serve if a directory is requested.)

Hasta ahora todo bien, este es el caso esperado. Ya muestra la diferencia en el manejo, así que vamos a entrar:

A las 5:34 am cometiste un error al subir tus archivos

(Lo cual, por cierto, es completamente comprensible). Entonces, hizo algo completamente incorrecto y, en lugar de cargarlo /dvd/the_big_lebowski.htm, cargó ese archivo como dvd(sin extensión) /.

Alguien marcó como favorito su /dvd/directorio (por supuesto, no desea crear y actualizar siempre ese ingeniosoindex.htm ) y está visitando su sitio web. El contenido del directorio se entrega, todo bien.

Alguien se enteró de tu lista y está escribiendo /dvd. Y ahora está jodido. En lugar de que su directorio de DVD enumere el servidor encuentra un archivo con ese nombre y está entregando su archivo Big Lebowski.

Entonces, eliminas ese archivo y le dices al chico que vuelva a cargar la página. Su servidor busca el /dvdarchivo, pero ya no está. La mayoría de los servidores se darán cuenta de que hay un directorio con ese nombre y le dirán al cliente que lo que estaba buscando está en otro lugar. La respuesta probablemente será:

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

Entonces, ignorando por completo lo que piensa sobre directorios o archivos, el servidor solo puede manejar tales cosas y, a menos que se le diga lo contrario, decide por usted sobre el significado de "barra oblicua o no".

Finalmente, después de recibir esta respuesta, el cliente carga /dvd/y todo está bien.

¿Está bien? No.

"Simplemente bien" no es lo suficientemente bueno para ti

Tienes una página dinámica donde todo se pasa /index.phpy se procesa. Todo funcionó bastante bien hasta ahora, pero todo eso comienza a sentirse más lento e investigas.

Pronto, notará que /dvd/listestá haciendo exactamente lo mismo: redireccionar a lo /dvd/list/que luego se traduce internamente index.php?controller=dvd&action=list. Una solicitud adicional, ¡pero aún peor! customer/loginredirecciona a la customer/login/que a su vez redirige a la URL HTTPS de customer/login/. Termina teniendo toneladas de redireccionamientos HTTP innecesarios (= solicitudes adicionales) que hacen que la experiencia del usuario sea más lenta.

Lo más probable es que también tenga un índice de directorio predeterminado aquí: index.php?controller=dvdsin actionsimplemente cargas internas index.php?controller=dvd&action=list.

Resumen:

• Si termina con /esto, nunca puede ser un archivo. Ningún servidor adivinando.

• Slash o no slash son significados completamente diferentes. Existe una diferencia técnica / de recursos entre "barra oblicua o sin barra oblicua", y debe ser consciente de ello y utilizarlo en consecuencia. Solo porque el servidor probablemente carga /dvd/index.htm, o carga el material de script correcto, cuando dice /dvd: Lo hace, pero no porque haya hecho la solicitud correcta. Que habría sido /dvd/.

• Omitir la barra oblicua incluso si realmente quiere decir que la versión recortada le otorga una penalización de solicitud HTTP adicional. Lo que siempre es malo (piense en la latencia móvil) y tiene más peso que una "URL bonita", especialmente porque los rastreadores no son tan tontos como creen o quieren que creas los SEO;)

Cuando haga su URL /about-us/(con la barra final), es fácil comenzar con un solo archivo index.htmly luego expandirlo y añadir más archivos (por ejemplo our-CEO-john-doe.jpg) o incluso construir una jerarquía en virtud del mismo (por ejemplo /about-us/company/, /about-us/products/, etc.) según sea necesario, sin cambiando la URL publicada . Esto te da una gran flexibilidad.

Otras respuestas aquí parecen favorecer la omisión de la barra diagonal final. Hay un caso en el que una barra diagonal final ayudará con la optimización de motores de búsqueda (SEO). Es el caso de que su documento tenga lo que parece ser una extensión de archivo que no lo es .html. Esto se convierte en un problema con los sitios que son sitios web de calificación. Pueden elegir entre estas dos URL:

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

En tal caso, elegiría el que tiene la barra inclinada final . Esto se debe a que la .comextensión es una extensión para los archivos de comandos ejecutables de Windows. Los motores de búsqueda y los verificadores de virus a menudo no les gustan las URL que parecen contener malware distribuido a través de dichos mecanismos. La barra inclinada final parece mitigar cualquier inquietud, permitiendo que la página se clasifique en los motores de búsqueda y evite los controles de virus.

Si sus URL no tienen .en la parte del archivo, entonces recomendaría omitir la barra diagonal para simplificar.

¿Quién dice que un nombre de archivo necesita una extensión? eche un vistazo a una máquina * nix en algún momento ...
Estoy de acuerdo con su amigo, no hay barra diagonal.

Desde una perspectiva de SEO, elegir si incluir o no una barra diagonal al final de una URL es irrelevante. En estos días, es común ver ejemplos de ambos en la web. Un sitio no será penalizado de ninguna manera, ni esta elección afectará el ranking del motor de búsqueda de su sitio web u otras consideraciones de SEO.

Simplemente elija una convención de nomenclatura de URL que prefiera e incluya una metaetiqueta canónica en la <head>sección de cada página web.

Los motores de búsqueda pueden considerar una sola página web como dos URL duplicadas separadas cuando la encuentran con y sin la barra inclinada final, es decir, example.com/about-us/y example.com/about-us.

Se recomienda incluir una metaetiqueta canónica en cada página porque no puede controlar cómo otros sitios se vinculan a sus URL.

La etiqueta canónica se parece a esto: <link rel="canonical" href="https://example.com/about-us" />. El uso de una metaetiqueta canónica garantiza que los motores de búsqueda solo cuenten cada una de sus URL una vez, independientemente de si otros sitios web incluyen una barra diagonal final cuando se vinculan a su sitio.