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

283

¿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?

url url-rewriting seo trailing-slash url-design Denis
fuente
Slash final, pero en mi opinión es principalmente estética. Mira y siente.
Eric Herlitz
3
La misma pregunta en Pro Webmasters: ¿Hay alguna diferencia si su ruta URL termina en una barra inclinada final o no?
Stephen Ostermiller
44
Esta pregunta se plantea como una de preferencia y, por lo tanto, parece estar fuera de tema, principalmente basada en la opinión . Sin embargo, como muestra mi respuesta , de hecho plantear esta pregunta como una cuestión de preferencia es un error: este es un problema XY, y la pregunta "real" subyacente tiene una respuesta técnica precisa y, por lo tanto, no se basa principalmente en la opinión .
Raedwald
Las preguntas sobre qué tipos de URL le gustan a Google no están relacionadas con la programación (como se menciona en la etiqueta wiki ) y están fuera de tema para Stackoverflow.
Quentin
He hecho algunas ediciones a su pregunta, revíselas cuando tenga la oportunidad de hacerlo. Gracias :)
Tim Post

Respuestas:

131

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.

Demencial
fuente
1
Esto es extraño, no puede nombrar un archivo "hoja de estilo /" - y la barra oblicua o ninguna barra son recursos completamente diferentes en el servidor, sin importar cómo se vea la URL
nico gawenda
10
@nicogawenda, .htaccess puede hacer todo tipo de magia;) ¡tu CSS en realidad podría ser un archivo php!
rmorse
44
Los servidores web a menudo se configuran de manera predeterminada para servir index.html(o un archivo con un nombre similar) cuando se accede a un directorio, por lo que /foo/es /foo/index.htmlsin el desorden adicional. Además, en el pasado, los navegadores agregaban /el nombre de dominio, pero ellos (Firefox, Chrome, Opera) han cambiado para omitir el /acceso a la página de inicio.
0b10011
44
Estoy de acuerdo con @bfrohs. Seguramente las páginas predeterminadas para directorios contravienen este principio. Si vamos a aplicar 'trailing slash = directory', entonces seguramente todas las direcciones URL que apuntan a un directorio deben devolver una lista de directorios o una respuesta http 403 prohibida.
Marvin
11
No estoy seguro de si los puntos 1 y 2 en la sección "Finalmente" siguen siendo precisos. Con los años desde que esto se escribió originalmente, los gustos han cambiado. No he estudiado esto en detalle, pero parece que en los sitios web más nuevos, es más común y "más bonito" omitir la barra.
Speedplane
172

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.
Raedwald
fuente
55
Artículo útil que profundiza en esto: cdivilly.wordpress.com/2014/03/11/…
Hephaestus
3
Sí, creo que esto, junto con el SEO, son las cosas más importantes para esta pregunta.
user2875289
Acabo de pasar por este problema al usar .Net's Uri.MakeRelativeUri. Los resultados reflejan exactamente lo que dijiste. Solucioné el problema agregando la barra diagonal a mi base Uri.
julealgon
61

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.

Yarin
fuente
50
"barras diagonales después de directorios, no después de recursos": las URL no se refieren a dos tipos de cosas, "recursos" y "directorios"; se refieren a un tipo de cosa: recursos. La pista está en la R de la URL.
Raedwald
31
Y todo en un sistema de archivos * nix es un archivo, pero todavía existen directorios. ¿Cual es tu punto?
Yarin
66
Ya sea que sea servido por un archivo o un directorio internamente, lo que el usuario ve es solo una página web. Y example.com/about en realidad podría estar leyendo de example.com/about/index.html .
musiphil
1
@DavidRR: Tienes razón. Y el navegador necesita la redirección porque la resolución del nombre tiene que ocurrir desde adentro directory(de lo contrario, image.pngen http://hostname/directoryapuntaría a http://hostname/image.png). Solo decía que la distinción entre un archivo y un directorio puede no ser muy importante desde el punto de vista del usuario.
musiphil
2
Estoy de acuerdo con su resultado, pero no estoy seguro de que debamos diseñar nuestro sistema de URL para emular sistemas de archivos * nix-style. Eso pudo haber servido originalmente para un propósito, pero ahora mucho menos.
Speedplane
27

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;)

nico gawenda
fuente
2
Entonces, en resumen, ¿están todos a favor de agregar la barra al final? :)
Denis
2
Estoy a favor de usarlo cuando lo dices en serio;) Por ejemplo, hablar de controladores y acciones sería: Los controladores deberían terminar con una barra diagonal. Cuando hace referencia a un archivo o una acción, omita la barra diagonal
nico gawenda
Espera, ¿por qué omitirías la barra para una acción? Según su ejemplo, ¿eso no va a resultar en una solicitud redirigida adicional? Quiero decir, presumiblemente su servidor es lo suficientemente inteligente como para reconocer una acción del controlador y en realidad no redirigirá para buscar archivos o directorios en ese caso, pero todavía va en contra de su ejemplo, ¿no?
Adam Goodwin
77
No entiendo tu ejemplo. ¿Qué sistema de archivos permite un directorio y otro archivo normal con el mismo nombre ( dvd)?
musiphil
19

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.

musiphil
fuente
9
Lo siento, no lo entendí. si empiezo /about-uso /about-us/todavía necesito cambiar la URL publicada en ambos casos si amplié el directorio. ¡el nuevo archivo estará /about-us/new-file.htmlen ambos casos! ¿que me estoy perdiendo aqui?
Contador م
2
@ Contable Creo que OP puede estar pensando que si publicas "/ about-us" sin una barra inclinada final, entonces no puedes agregar recursos secundarios usando rutas relativas. Cuando no tenga la barra inclinada final, el navegador creerá que una referencia a "ceo.jpg" en la página acerca se ubicará en la raíz de su dominio y solicitará example.com/ceo.jpg. Con la barra oblicua, el navegador solicitará example.com/about-us/ceo.jpg y puede enrutar estáticamente un árbol completo de carpetas para su sitio a medida que se expande.
amanece el
1
FYI - No creo que nada de lo anterior sea cierto - ¿Por qué no puede haber un /about-usy /about-us/company? En términos de servir los archivos, tanto Apache como IIS pueden manejar esto bien, así que no estoy de acuerdo.
sean2078
1
@ sean2078 Sí, pero si, desde el /about-usque quieres vincular /about-us/company, tienes que usar href="https://stackoverflow.com/about-us/company"o href="./company"(aunque no estoy seguro de eso). Si usted está en /about-us/, sin embargo, es muy sencillo: href="company".
Adowrath
11

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.

Stephen Ostermiller
fuente
No hay motores de búsqueda reales que sean tan estúpidos. Esta respuesta es pura especulación.
Navin
1
De hecho, he visto este problema con Google. Eso fue hace varios años, así que no estoy seguro si ese sería el caso hoy.
Stephen Ostermiller
Eh, ese es un buen punto de datos. Aunque todavía no sabemos si fue causado por algo más.
Navin
10

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

Aaron Gage
fuente
3

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.

alboroto
fuente