Deux adresses qui se ressemblent, deux URL pour Google
Commençons par le fait brut : une URL est une chaîne de caractères, et un caractère de différence suffit à en faire une autre. https://exemple.fr/blog et https://exemple.fr/blog/ ne sont pas la même adresse. Ni pour votre serveur, ni pour Googlebot.
Cette distinction vient de loin. Historiquement, le slash final désignait un dossier (dans lequel le serveur allait chercher un fichier index), et son absence désignait un fichier. Sur un site piloté par un CMS, cette logique n'a plus grand sens, mais la règle technique est restée.
Google l'a écrit noir sur blanc dans un billet ancien mais toujours valable de son blog pour les webmasters, « To slash or not to slash » : chaque URL est traitée séparément, avec ou sans barre oblique finale. Si les deux renvoient le même contenu, vous avez donc, pour le moteur, deux pages identiques à deux adresses.
L'exception : la racine du domaine
Un seul cas échappe à la règle. https://exemple.fr et https://exemple.fr/ sont strictement la même URL. Le navigateur (et Googlebot) envoie de toute façon une requête vers /, car un chemin vide n'existe pas dans le protocole HTTP. Inutile de chercher à rediriger l'une vers l'autre.
Tout ce qui vient après le nom de domaine, en revanche, est concerné : /services, /blog/mon-article, /categorie/chaussures.
Est-ce un problème chez vous ? Le test qui prend deux minutes
Tout dépend de ce que répond votre serveur quand on lui demande la version que vous n'utilisez pas. Prenez une page de votre site, ouvrez un terminal et interrogez les deux variantes :
curl -I https://exemple.fr/ma-page
curl -I https://exemple.fr/ma-page/Pas de terminal sous la main ? L'onglet Réseau des outils de développement de votre navigateur fait le même travail. Regardez uniquement le code de statut de chaque réponse. Trois scénarios possibles.
Premier scénario : l'une répond 200 et l'autre répond 301 vers la première. C'est la configuration saine. Votre site a une version officielle, l'autre y renvoie proprement, Google consolide tout au bon endroit. Vérifiez quand même vos liens internes, j'y reviens plus bas.
Deuxième scénario : les deux répondent 200 avec le même contenu. C'est le cas qui vous a probablement amené ici. Rien de dramatique, Google gère ce genre de doublon tous les jours et choisit lui-même une version à indexer. Sauf que vous lui laissez la main. Il peut retenir celle que vous ne vouliez pas, changer d'avis selon les pages, et les liens que vous recevez se répartissent entre deux adresses au lieu d'une. Dans la Search Console, ça se traduit par des lignes du type « Page en double sans URL canonique sélectionnée par l'utilisateur » dans le rapport d'indexation. Pour traiter le sujet à l'échelle du site, j'ai détaillé la méthode pour détecter un contenu dupliqué et le corriger.
Troisième scénario : l'une répond 200 et l'autre 404. Pas de doublon ici, mais le jour où quelqu'un fait un lien vers la mauvaise variante (ça arrive, les gens recopient les URL à la main), ce lien tombe dans le vide. Une redirection règle ça une fois pour toutes.
Sur les gros catalogues, il y a un effet secondaire : Googlebot explore les deux séries d'URL et gaspille des visites sur des pages qu'il connaît déjà. Sur un site vitrine, vous ne le sentirez jamais.
Avec ou sans slash : laquelle garder ?
Google n'a aucune préférence. Aucun des deux formats ne se positionne mieux que l'autre. La seule chose que le moteur attend, c'est de la cohérence. Le choix se fait donc sur des critères pratiques, que je prends dans cet ordre.
D'abord, ce que fait votre CMS nativement. WordPress suit la structure de permaliens définie dans les réglages : si elle se termine par un slash, toutes les URL en portent un, et WordPress redirige de lui-même la variante sans. Beaucoup de frameworks ont aussi un comportement par défaut. Aller contre l'outil, c'est s'offrir des bugs à chaque mise à jour.
Ensuite, l'historique. Si rien n'est imposé par la technique, gardez la version qui a déjà de l'ancienneté : celle que Google indexe majoritairement (l'inspection d'URL de la Search Console vous donne l'« URL canonique sélectionnée par Google »), celle qui reçoit vos backlinks, celle qu'utilisent vos liens internes. Moins vous déplacez de signaux, mieux c'est.
Dernier point, une convention plus qu'une règle : les URL qui désignent un fichier avec extension (.html, .pdf, .php) s'écrivent sans slash final. /guide.pdf/ n'a aucun sens et certains serveurs le refusent.
La mise au propre, dans l'ordre
Une fois la version choisie, quatre réglages à aligner. Le premier est une instruction, les autres des confirmations.
La redirection 301, d'abord. Toute requête vers la mauvaise variante doit renvoyer vers la bonne, de façon permanente. Sur un serveur Apache, pour imposer le slash final, la règle classique du .htaccess ressemble à ceci :
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*[^/])$ /$1/ [L,R=301]La condition exclut les vrais fichiers (images, PDF, CSS), sinon vous leur colleriez un slash aussi. Testez sur une préproduction avant, une règle mal placée crée vite une boucle. Et n'empilez pas les sauts : une URL en http, sans www et sans slash doit rejoindre l'adresse finale en un seul bond, pas en trois. Si le sujet est nouveau pour vous, mon guide explique ce qu'est une redirection 301 et comment la configurer selon votre serveur.
La balise canonical, ensuite. Chaque page doit déclarer sa propre adresse, au bon format, slash compris. C'est un filet de sécurité pour les variantes qui passent entre les mailles de la redirection. Attention à l'erreur que je croise le plus souvent : une 301 vers la version avec slash, et un canonical généré par le thème qui pointe vers la version sans. Deux signaux contradictoires, et Google tranche à votre place. Voyez mon article sur le rôle de la balise canonical et son bon usage. Google liste lui-même ces méthodes dans sa documentation sur la consolidation des URL en double.
Troisième étape, les liens internes. Un crawl de votre site (Screaming Frog en version gratuite suffit pour un petit site) fait ressortir tous les liens qui passent par une 301. Menu, pied de page, liens dans les articles : corrigez-les pour qu'ils pointent directement vers la bonne version.
Enfin le sitemap XML, qui ne doit contenir que les URL au format retenu. Même chose pour les balises hreflang si votre site est multilingue.
Ce qu'il ne faut pas en attendre
Unifier vos slashs ne fera pas bondir vos positions. C'est de l'hygiène technique : vous retirez une ambiguïté, vous concentrez vos liens sur une seule adresse, vous rendez vos rapports Search Console lisibles. L'effet est le plus souvent discret, et c'est normal.
Comptez quelques semaines pour que Google recrawle l'ensemble et que les doublons disparaissent des rapports, davantage sur un gros site peu visité par le robot. Ne changez surtout pas de format sur un site qui a déjà une version propre et cohérente : passer de « avec » à « sans » par goût personnel, c'est une mini-migration d'URL sans aucun bénéfice à la clé.