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

url-rewriting seo (8)

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

¿Cuándo debería usarse una barra inclinada en una URL? Por ejemplo, ¿debería mi URL ser /about-us/ u like /about-us ?

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

Por ejemplo, mi colega piensa que una barra 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 forma adecuada de saber cuál usar?

Cuando crea su URL /about-us/ (con la barra diagonal final), es fácil comenzar con un solo archivo index.html y luego expandirlo y agregar más archivos (por ejemplo, our-CEO-john-doe.jpg ) o incluso cree una jerarquía debajo de ella (por ejemplo, /about-us/company/ , /about-us/products/ , etc.) según sea necesario, sin cambiar la URL publicada . Esto te da una gran flexibilidad.

Desde una perspectiva SEO, la elección de 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 la convención de nomenclatura de URL que prefiera e incluya una meta etiqueta canónica en la sección <head> de cada página web.

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

Es una buena práctica incluir una meta etiqueta canónica en cada página porque no puede controlar cómo se vinculan otros sitios a sus URL.

La etiqueta canónica se ve así: <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 oblicua al vincularse a su sitio.

En mi opinión personal, las barras inclinadas son mal utilizadas.

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

Una URL típica para este libro en un sistema operativo similar a 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 para decir, "en el mismo lugar que este, excepto con el siguiente relativo camino". Continuó diciendo que tales URL relativas dependen de la URL original que contiene una estructura jerárquica en la que se basa el enlace relativo, y que los esquemas de URL de ftp, http y archivo son ejemplos de algunos que pueden considerarse jerárquicos, con los componentes de la jerarquía están 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 diagonal al final para indicar un directorio, y aquellas sin una barra al final para denotar un archivo:
http://example.com/foo/ (con una barra diagonal final, convencionalmente un directorio)
http://example.com/foo (sin barra diagonal, convencionalmente un archivo)

Fuente: Blog de Google WebMaster Central - Para barra o no barra

Finalmente:

Una barra al final de la URL hace que la dirección se vea "bonita".
Una URL sin una barra al final y sin una extensión parece algo "extraña".
Nunca nombrarás tu archivo CSS (por ejemplo) http://www.sample.com/stylesheet/ ¿lo harías?

PERO soy un defensor de las mejores prácticas web, independientemente del entorno. Puede ser impreciso y confuso, tal como dijo sobre la URL sin ext.

Eso no es realmente una cuestión de estética, sino una diferencia técnica. El pensar en el directorio es totalmente correcto y explica todo bastante. Vamos a resolverlo:

Ya estás de vuelta en la edad de piedra o solo sirves páginas estáticas.

Tiene una estructura de directorios fija en su servidor web y solo archivos estáticos como imágenes, html, etc., sin scripts del lado del servidor ni nada de eso.

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

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

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

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

(Por cierto, es completamente comprensible). Entonces, hiciste algo totalmente incorrecto y, en lugar de cargar / /dvd/the_big_lebowski.htm / /dvd/the_big_lebowski.htm , subiste ese archivo como dvd (sin extensión) a / .

Alguien marcó tu lista de directorio /dvd/ (como es lógico, no quisiste crear y actualizar siempre ese ingenioso index.htm ) y está visitando tu sitio web. Se entrega el contenido del directorio - todo bien.

Alguien escuchó de tu lista y está escribiendo /dvd . Y ahora está atornillado. En lugar de su directorio de DVD, el servidor encuentra un archivo con ese nombre y le entrega su archivo de Big Lebowski.

Entonces, borras ese archivo y le dices al chico que recargue la página. Su servidor busca el archivo /dvd , pero se ha ido. La mayoría de los servidores notarán que hay un directorio con ese nombre y le dirán al cliente que lo que buscaba está en otro lugar. Lo más probable es que la respuesta sea:

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

Por lo tanto, ignorando totalmente lo que usted piensa acerca de los directorios o archivos, el servidor solo puede manejar tales cosas y, a menos que se le indique lo contrario, decide por usted el significado de "barra o no".

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

¿Está bien? No.

"Bien" no es suficiente para ti

Tiene alguna página dinámica donde todo se pasa a /index.php y se procesa. Todo funcionó bastante bien hasta ahora, pero todo eso empieza a sentirse más lento y tú investigas.

Pronto, notará que /dvd/list está haciendo exactamente lo mismo: redirigir a /dvd/list/ que luego se traduce internamente en index.php?controller=dvd&action=list . Una solicitud adicional, pero aún peor! Redirecciones de customer/login/ customer/login a customer/login/ que a su vez redirige a la URL HTTPS de customer/login/ . Usted termina teniendo toneladas de redirecciones HTTP innecesarias (= 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=dvd sin action simplemente carga internamente index.php?controller=dvd&action=list .

Resumen:

Si termina con / nunca puede ser un archivo. Sin adivinar el servidor.
Barra o no barra son significados completamente diferentes. Hay una diferencia técnica / de recursos entre "barra o no barra", y usted debe ser consciente de ello y utilizarlo en consecuencia. Solo porque el servidor probablemente carga /dvd/index.htm , o carga el 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 con barra diagonal le otorga una penalización de solicitud HTTP adicional. Lo que siempre es malo (piensa en la latencia móvil) y tiene más peso que una "URL bonita", especialmente porque los rastreadores no son tan tontos como los SEO creen o quieren que creas;)

No es una cuestión de preferencia. /base y /base/ tienen diferentes semánticas. En muchos casos, la diferencia no es importante. Pero es importante cuando hay URLs relativas.

child relativo a /base/ es /base/child .
child relativo a /base es (quizás sorprendentemente) /child .

Otras respuestas aquí parecen favorecer la omisión de la barra diagonal. Hay un caso en el que una barra inclinada ayudará con la optimización del motor de búsqueda (SEO). En ese caso, su documento tiene lo que parece ser una extensión de archivo que no es .html . Esto se convierte en un problema con los sitios que son sitios web de calificación. Podrían elegir entre estas dos urls:

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

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

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

Siempre me sorprende el uso extensivo de barras diagonales en direcciones URL que no son de directorio (WordPress, entre otras). Esto realmente no debería ser un debate, ya sea 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 sistemas de archivos de estilo * nix. En ese contexto:

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

Al usar estas pautas, es incorrecto colocar una barra diagonal después de un recurso que no es de directorio.