Quand dois-je utiliser une barre oblique de fin dans mon URL?

283

Quand faut-il utiliser une barre oblique de fin dans une URL? Par exemple - mon URL devrait-elle ressembler /about-us/ou ressembler /about-us?

Je suis pleinement conscient des problèmes liés au référencement - le contenu en double et la chose canonique; J'essaie de comprendre lequel je dois utiliser dans le contexte de la diffusion de pages correctement uniquement.

Par exemple, mon collègue pense qu'une barre oblique à la fin signifie que c'est un "dossier" - un "répertoire", donc ce n'est pas un style correct. Mais je pense que sans barre oblique à la fin - ce n'est pas tout à fait correct non plus, car il ressemble presque à un dossier, mais ce n'est pas le cas et ce n'est pas un fichier normal non plus, mais un nom de fichier sans extension.

Existe-t-il un moyen approprié de savoir lequel utiliser?

url url-rewriting seo trailing-slash url-design Denis
la source
Barre oblique, mais à mon avis, c'est principalement esthétique. Regarde et ressent.
Eric Herlitz
3
Même question sur les Webmasters Pro: cela fait-il une différence si votre chemin URL se termine par une barre oblique ou non?
Stephen Ostermiller
4
Cette question est posée comme une question de préférence , et semble donc être hors sujet car principalement basée sur l'opinion . Cependant, comme ma réponse le montre, en fait, poser cette question comme une question de préférence est une erreur: il s'agit d'un problème XY, et la "vraie" question sous-jacente a une réponse technique précise, et n'est donc pas principalement basée sur l'opinion .
Raedwald
Questions sur les types d'URL que Google aime ne sont pas liés à la programmation (comme mentionné dans le wiki wiki ) et sont hors sujet pour Stackoverflow.
Quentin
J'ai apporté quelques modifications à votre question, veuillez les vérifier lorsque vous en avez l'occasion. Merci :)
Tim Post

Réponses:

131

À mon avis, les barres obliques de fin sont utilisées à mauvais escient.

Fondamentalement, le format URL provenait du même format UNIX de fichiers et de dossiers, plus tard, sur les systèmes DOS, et enfin, adapté pour le Web.

Une URL typique pour ce livre sur un système d'exploitation de type Unix serait un chemin de fichier tel que file: ///home/username/RomeoAndJuliet.pdf, identifiant le livre électronique enregistré dans un fichier sur un disque dur local.

Source: Wikipedia: identifiant uniforme des ressources

Une autre bonne source à lire: Wikipedia: URI Scheme

Selon la RFC 1738, qui a défini les URL en 1994, lorsque les ressources contiennent des références à d'autres ressources, elles peuvent utiliser des liens relatifs pour définir l'emplacement de la deuxième ressource comme pour dire "au même endroit que celui-ci, sauf avec le parent suivant chemin". Il a poursuivi en disant que ces URL relatives dépendent de l'URL d'origine contenant une structure hiérarchique sur laquelle le lien relatif est basé, et que les schémas ftp, http et URL de fichier sont des exemples de certains qui peuvent être considérés comme hiérarchiques, avec le les composants de la hiérarchie étant séparés par "/".

Source: Wikipedia Uniform Resource Locator (URL)

Aussi:

C'est la question que nous entendons souvent. En route vers les réponses! Historiquement, il est courant que les URL avec une barre oblique de fin indiquent un répertoire et celles sans barre oblique de fin désignent un fichier:

http://example.com/foo/ (avec barre oblique de fin, classiquement un répertoire)

http://example.com/foo (sans barre oblique de fin, classiquement un fichier)

Source: Blog Google WebMaster Central - Pour réduire ou ne pas réduire

Finalement:

  1. Une barre oblique à la fin de l'URL rend l'adresse "jolie".

  2. Une URL sans barre oblique à la fin et sans extension semble quelque peu "bizarre".

  3. Vous ne nommerez jamais votre fichier CSS (par exemple) http://www.sample.com/stylesheet/, n'est-ce pas?

MAIS je suis un partisan des meilleures pratiques Web, quel que soit l'environnement. Cela peut être bancal et peu clair, comme vous l'avez dit à propos de l'URL sans extension.

Démence
la source
1
C'est bizarre, vous ne pouvez pas nommer un fichier "stylesheet /" - et slash ou no slash sont des ressources entièrement différentes sur le serveur, peu importe à quoi ressemble l'URL
nico gawenda
10
@nicogawenda, .htaccess peut faire toutes sortes de magie;) votre CSS pourrait en fait être un fichier php!
rmorse
4
Les serveurs Web sont souvent configurés par défaut pour servir index.html(ou un fichier portant le même nom) lors de l'accès à un répertoire, tout /foo/comme /foo/index.htmlle désordre supplémentaire. De plus, dans le passé, les navigateurs s'ajoutaient /au nom de domaine, mais ils (Firefox, Chrome, Opera) ont depuis changé pour omettre le /lors de l'accès à la page d'accueil.
0b10011
4
Je suis d'accord avec @bfrohs. Les pages par défaut des répertoires contreviennent certainement à ce principe. Si nous devons appliquer 'slash = répertoire de fin', alors toutes les URL qui pointent vers un répertoire doivent sûrement retourner une liste de répertoires ou une réponse http 403 interdite.
Marvin
11
Je ne sais pas si les points # 1 et 2 de la section "Enfin" sont toujours exacts. Au fil des ans depuis que cela a été écrit à l'origine, les goûts ont changé. Je n'ai pas étudié cela en détail, mais il semble que sur les nouveaux sites Web, il est plus courant et "plus joli" d'omettre la barre oblique.
speedplane
172

Ce n'est pas une question de préférence. /baseet /base/ont une sémantique différente. Dans de nombreux cas, la différence est sans importance. Mais c'est important quand il y a des URL relatives.

  • childpar rapport à /base/is /base/child.
  • childpar rapport à /baseest (peut-être surprenant) /child.
Raedwald
la source
5
Article utile qui va dans le détail: cdivilly.wordpress.com/2014/03/11/…
Hephaestus
3
Oui, je pense que cela, avec le référencement, sont les choses les plus importantes à cette question.
user2875289
Je viens de traverser ce problème lors de l'utilisation de .Net Uri.MakeRelativeUri. Les résultats reflètent exactement ce que vous avez dit. J'ai résolu le problème en ajoutant la barre oblique de fin à ma base Uri.
julealgon
61

Je suis toujours surpris par l'utilisation extensive de barres obliques de fin sur les URL non-répertoires (WordPress entre autres). Cela ne devrait vraiment pas être un débat, car mettre une barre oblique après une ressource est sémantiquement incorrect. Le Web a été conçu pour fournir des ressources adressables, et ces adresses - URL - ont été conçues pour émuler une hiérarchie de système de fichiers de style * nix. Dans ce contexte:

  • Les barres obliques désignent toujours les répertoires, jamais les fichiers.
  • Les fichiers peuvent être nommés n'importe quoi (avec ou sans extensions), mais ne peuvent pas contenir ou se terminer par des barres obliques.

En utilisant ces directives, il est faux de mettre une barre oblique après une ressource non-répertoire.

Yarin
la source
50
"barres obliques après les répertoires, pas après les ressources": les URL ne font pas référence à deux types de choses, "ressources" et "répertoires"; ils se réfèrent à un genre de chose: les ressources. L'indice est dans le R de l'URL.
Raedwald
31
Et tout dans un système de fichiers * nix est un fichier, mais les répertoires existent toujours. À quoi veux-tu en venir?
Yarin
6
Qu'il soit servi par un fichier ou un répertoire en interne, ce que l'utilisateur voit n'est qu'une page Web. Et example.com/about pourrait en fait lire à partir d' exemple.com/about/index.html .
musiphil
1
@DavidRR: Vous avez raison. Et le navigateur a besoin de la redirection car la résolution de nom doit se passer de l' intérieur directory(sinon, image.pngen http://hostname/directoryindiquerait http://hostname/image.png). Je disais simplement que la distinction entre un fichier et un répertoire peut ne pas être très importante du point de vue de l'utilisateur.
musiphil
2
Je suis d'accord avec votre résultat, mais je ne suis pas sûr que nous devrions concevoir notre système d'URL pour émuler des systèmes de fichiers de style * nix. Cela a peut-être initialement servi un but, mais maintenant beaucoup moins.
speedplane
27

Ce n'est pas vraiment une question d'esthétique, mais bien une différence technique. Le répertoire qui y pense est totalement correct et explique à peu près tout. Voyons ça:

Vous êtes de retour à l'âge de pierre maintenant ou ne diffusez que des pages statiques

Vous avez une structure de répertoires fixe sur votre serveur Web et uniquement des fichiers statiques comme des images, du HTML, etc.

Un navigateur le demande /index.htm, il existe et est remis au client. Plus tard, vous avez beaucoup - disons - de films DVD examinés et une page html pour chacun d'eux dans le /dvd/répertoire. Maintenant, quelqu'un demande /dvd/adams_apples.htmet il est livré parce qu'il est là.

Un jour, quelqu'un demande simplement /dvd/- qui est un répertoire et le serveur essaie de comprendre quoi livrer. En plus des restrictions d'accès, etc. , il y a deux possibilités: montrer à l'utilisateur le contenu du répertoire (je parie que vous avez déjà vu ça quelque part) ou afficher un fichier par défaut (dans Apache est: DirectoryIndex: sets the file that Apache will serve if a directory is requested.)

Jusqu'ici tout va bien, c'est le cas attendu. Cela montre déjà la différence de manipulation, alors allons-y:

À 5 h 34, vous avez fait une erreur lors du téléchargement de vos fichiers

(Ce qui est d'ailleurs complètement compréhensible.) Donc, vous avez fait quelque chose de complètement faux et au lieu de télécharger, /dvd/the_big_lebowski.htmvous avez téléchargé ce fichier sous dvd(sans extension) vers /.

Quelqu'un a mis en signet votre /dvd/liste de répertoires (bien sûr, vous ne vouliez pas créer et toujours mettre à jour cette astucieuse index.htm) et visite votre site Web. Le contenu du répertoire est livré - tout va bien.

Quelqu'un a entendu parler de votre liste et tape /dvd. Et maintenant c'est foutu. Au lieu de la liste de votre répertoire DVD, le serveur trouve un fichier avec ce nom et fournit votre fichier Big Lebowski.

Donc, vous supprimez ce fichier et dites au gars de recharger la page. Votre serveur recherche le /dvdfichier, mais il a disparu. La plupart des serveurs remarqueront alors qu'il existe un répertoire avec ce nom et diront au client que ce qu'il cherchait est bien ailleurs. La réponse sera très probablement:

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

Donc, ignorant totalement ce que vous pensez des répertoires ou des fichiers, le serveur ne peut gérer que de telles choses et - sauf indication contraire - décide pour vous de la signification de "slash or not".

Enfin après avoir reçu cette réponse, le client se charge /dvd/et tout va bien.

Ça va? Non.

"Très bien" ne vous suffit pas

Vous avez une page dynamique où tout est transmis /index.phpet traité. Tout fonctionnait assez bien jusqu'à présent, mais tout cela commence à se sentir plus lentement et vous étudiez.

Bientôt, vous remarquerez que cela /dvd/listfait exactement la même chose: la redirection vers /dvd/list/laquelle est ensuite traduite en interne index.php?controller=dvd&action=list. Une demande supplémentaire - mais pire encore! customer/loginredirige vers customer/login/qui à son tour redirige vers l'URL HTTPS de customer/login/. Vous finissez par avoir des tonnes de redirections HTTP inutiles (= demandes supplémentaires) qui rendent l'expérience utilisateur plus lente.

Très probablement, vous avez également un index de répertoire par défaut: index.php?controller=dvdsans actionsimplement charger en interne index.php?controller=dvd&action=list.

Résumé:

  • S'il se termine par, /il ne peut jamais s'agir d'un fichier. Aucun serveur ne devine.

  • Slash ou pas de slash sont des significations entièrement différentes. Il existe une différence technique / de ressources entre "barre oblique ou pas de barre oblique", et vous devez en être conscient et l'utiliser en conséquence. Tout simplement parce que le serveur charge probablement /dvd/index.htm- ou charge les éléments de script corrects - lorsque vous dites /dvd: il le fait, mais pas parce que vous avez fait la bonne demande. Ce qui aurait été /dvd/.

  • L'omission de la barre oblique même si vous voulez dire que la version barrée vous donne une pénalité de requête HTTP supplémentaire. Ce qui est toujours mauvais (pensez à la latence mobile) et a plus de poids qu'une "jolie URL" - d'autant plus que les robots d'exploration ne sont pas aussi stupides que les SEO le croient ou veulent le faire croire;)

nico gawenda
la source
2
Donc, dans un résumé, êtes-vous tous d'accord pour ajouter la barre oblique à la fin? :)
Denis
2
Je suis tout à fait d'accord pour l'utiliser quand vous le pensez;) Par exemple, en parlant de contrôleurs et d'actions, ce serait: les contrôleurs devraient se terminer par une barre oblique. Lorsque vous référencez un fichier ou une action, omettez la barre oblique
nico gawenda
Attendez, pourquoi voudriez-vous omettre la barre oblique pour une action? Selon votre exemple, cela n'entraînera-t-il pas une demande redirigée supplémentaire? Je veux dire, votre serveur est probablement assez intelligent pour reconnaître une action de contrôleur et ne redirigera pas réellement pour rechercher des fichiers ou des répertoires dans ce cas, mais cela va toujours à l'encontre de votre exemple, n'est-ce pas?
Adam Goodwin
7
Je ne comprends pas ton exemple. Quel système de fichiers autorise un répertoire et un autre fichier ordinaire du même nom ( dvd)?
musiphil
19

Lorsque vous effectuez votre URL /about-us/(avec le slash), il est facile de commencer par un seul fichier index.html, puis plus tard développer et ajouter d' autres fichiers (par exemple our-CEO-john-doe.jpg) ou même construire une hiérarchie en dessous (par exemple /about-us/company/, /about-us/products/etc.) selon les besoins, sans changer l'URL publiée . Cela vous donne une grande flexibilité.

musiphil
la source
9
Je suis désolé de ne pas l'avoir compris. si je commence par /about-usou /about-us/je dois encore changer l'URL publiée dans les deux cas si j'ai développé le répertoire. le nouveau fichier sera /about-us/new-file.htmldans les deux cas !! Qu'est-ce que j'oublie ici?
Comptable du
2
@Accountant Je pense que OP peut penser que si vous publiez "/ about-us" sans barre oblique, vous ne pourrez pas ajouter plus tard des sous-ressources en utilisant des chemins relatifs. Lorsque vous ne disposez pas de la barre oblique de fin, le navigateur pensera qu'une référence à "ceo.jpg" sur la page à propos vivra à la racine de votre domaine et demandera example.com/ceo.jpg. Avec la barre oblique, le navigateur demandera example.com/about-us/ceo.jpg et vous pouvez acheminer statiquement une arborescence entière de dossiers pour votre site au fur et à mesure que vous développez.
daw
1
FYI - Je ne crois pas que ce qui précède soit vrai - Pourquoi ne peut-il y avoir un /about-uset /about-us/company? En termes de service des fichiers, Apache et IIS peuvent gérer cela très bien, donc je ne suis pas d'accord.
sean2078
1
@ sean2078 Oui, mais si, de /about-usvotre part, vous voulez créer un lien /about-us/company, vous devez utiliser href="https://stackoverflow.com/about-us/company"ou href="./company"(cependant, pas sûr de celui-là). Si vous êtes /about-us/, cependant, il est simple: href="company".
Adowrath
11

D'autres réponses semblent favoriser l'omission de la barre oblique de fin. Il y a un cas dans lequel une barre oblique de fin aidera à l'optimisation des moteurs de recherche (SEO). C'est le cas que votre document a ce qui semble être une extension de fichier qui ne l'est pas .html. Cela devient un problème avec les sites qui évaluent les sites Web. Ils pourraient choisir entre ces deux URL:

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

Dans un tel cas, je choisirais celui avec la barre oblique de fin . En effet, l' .comextension est une extension pour les fichiers de commandes exécutables Windows. Les moteurs de recherche et les antivirus détestent souvent les URL qui semblent contenir des logiciels malveillants distribués via de tels mécanismes. La barre oblique de fin semble atténuer toutes les préoccupations, permettant à la page de se classer dans les moteurs de recherche et d'obtenir des vérificateurs de virus.

Si vos URL n'ont pas .dans la partie fichier, je recommanderais d'omettre la barre oblique de fin pour plus de simplicité.

Stephen Ostermiller
la source
Aucun moteur de recherche réel n'est aussi stupide. Cette réponse est pure spéculation.
Navin
1
J'ai effectivement vu ce problème avec Google. C'était il y a plusieurs années, donc je ne sais pas si ce serait encore le cas aujourd'hui.
Stephen Ostermiller
Huh, c'est un bon point de données. Bien que nous ne sachions toujours pas si cela a été causé par autre chose.
Navin
10

Qui a dit qu'un nom de fichier avait besoin d'une extension ?? jetez un oeil sur une machine * nix un jour ...
Je suis d'accord avec votre ami, pas de barre oblique.

Aaron Gage
la source
3

Du point de vue du référencement, il n'est pas pertinent de choisir d'inclure ou non une barre oblique de fin à la fin d'une URL. De nos jours, il est courant de voir des exemples des deux sur le Web. Un site ne sera pas pénalisé de toute façon, et ce choix n'affectera pas le classement des moteurs de recherche de votre site Web ou d'autres considérations de référencement.

Choisissez simplement une convention de dénomination d'URL que vous préférez et incluez une balise META canonique dans la <head>section de chaque page Web.

Les moteurs de recherche peuvent considérer une seule page Web comme deux URL distinctes en double lorsqu'ils la rencontrent avec et sans la barre oblique de fin, c'est example.com/about-us/-à- dire et example.com/about-us.

Il est recommandé d'inclure une balise META canonique sur chaque page, car vous ne pouvez pas contrôler la façon dont les autres sites sont liés à vos URL.

La balise canonique ressemble à ceci: <link rel="canonical" href="https://example.com/about-us" />. L'utilisation d'une balise META canonique garantit que les moteurs de recherche ne comptent qu'une seule fois chacune de vos URL, que les autres sites Web incluent une barre oblique de fin lorsqu'ils établissent un lien vers votre site.

émeute
la source