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?
Réponses:
À 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.
Source: Wikipedia: identifiant uniforme des ressources
Une autre bonne source à lire: Wikipedia: URI Scheme
Source: Wikipedia Uniform Resource Locator (URL)
Aussi:
Source: Blog Google WebMaster Central - Pour réduire ou ne pas réduire
Finalement:
Une barre oblique à la fin de l'URL rend l'adresse "jolie".
Une URL sans barre oblique à la fin et sans extension semble quelque peu "bizarre".
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.
la source
index.html
(ou un fichier portant le même nom) lors de l'accès à un répertoire, tout/foo/
comme/foo/index.html
le 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.Ce n'est pas une question de préférence.
/base
et/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.child
par rapport à/base/
is/base/child
.child
par rapport à/base
est (peut-être surprenant)/child
.la source
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 baseUri
.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:
En utilisant ces directives, il est faux de mettre une barre oblique après une ressource non-répertoire.
la source
directory
(sinon,image.png
enhttp://hostname/directory
indiqueraithttp://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.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.htm
et 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.htm
vous avez téléchargé ce fichier sousdvd
(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 astucieuseindex.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
/dvd
fichier, 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
avecLocation: 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.php
et 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/list
fait exactement la même chose: la redirection vers/dvd/list/
laquelle est ensuite traduite en interneindex.php?controller=dvd&action=list
. Une demande supplémentaire - mais pire encore!customer/login
redirige verscustomer/login/
qui à son tour redirige vers l'URL HTTPS decustomer/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=dvd
sansaction
simplement charger en interneindex.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;)
la source
dvd
)?Lorsque vous effectuez votre URL
/about-us/
(avec le slash), il est facile de commencer par un seul fichierindex.html
, puis plus tard développer et ajouter d' autres fichiers (par exempleour-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é.la source
/about-us
ou/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.html
dans les deux cas !! Qu'est-ce que j'oublie ici?/about-us
et/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./about-us
votre part, vous voulez créer un lien/about-us/company
, vous devez utiliserhref="https://stackoverflow.com/about-us/company"
ouhref="./company"
(cependant, pas sûr de celui-là). Si vous êtes/about-us/
, cependant, il est simple:href="company"
.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'
.com
extension 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é.la source
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.
la source
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 etexample.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.la source