topLeft lightmiddlePinkLightrightPurpleLight

La méthode Toe-Dip pour modifier la structure de l'URL

Paul Grieselhuber

Paul Grieselhuber

Apr 26, 2019

Si vous créez des sites web ou proposez des services de référencement, vous avez certainement été confronté à un moment ou à un autre à la question des avantages et des risques liés à la modification de la structure de l'URL d'un site web.

Par exemple, un site web peut avoir la structure URL suivante :

https://www.website.com/2019/04/26/the-post-title/

Alors que vous préféreriez avoir quelque chose de similaire à l'une ou l'autre de ces structures :

https://www.website.com/the-post-title/
https://www.website.com/articles/the-post-title/ 

Vous savez probablement aussi que de tels changements peuvent être incroyablement risqués. Si vous travaillez dans l'une ou l'autre des disciplines susmentionnées, vous ressentez probablement le poids de la responsabilité que vous portez soit à l'égard de votre propre entreprise, soit à l'égard de celle de vos clients.

Si ce n'est pas le cas, voici un bref résumé : votre contenu est classé là où il l'est (disons, première page de Google) parce que Google a trouvé son URL et qu'il est persuadé que si quelqu'un effectue une recherche pertinente, il peut l'envoyer à cette URL et qu'il y trouvera l'information qu'il cherche.

Si cette URL n'existe plus parce que vous avez modifié votre structure d'URL et que vous n'avez pas géré le changement correctement, votre trafic n'existe plus non plus.

Lectures conseillées pour se familiariser avec la structure des URL et les redirections

Il y a beaucoup de subtilité dans la gestion de ces questions et de nombreux ouvrages ont été consacrés à ce sujet. Ce post sur le forum Moz couvre la gamme générale des questions et des préoccupations.

Nous recommandons vivement ce billet d'Ahrefs sur le sujet. La version courte est la suivante : Si vous vous trompez, vous risquez de tuer leur entreprise - ou du moins de l'entraver gravement à court terme, ainsi que d'entacher votre réputation. Considérez cela comme notre déni de responsabilité pour la poursuite de ce projet.

Cependant, la méthode décrite dans ce billet ne couvre pas ce sujet et nous avons constaté qu'elle fonctionne incroyablement bien pour changer d'URL en toute sécurité.

Nous l'appelons la méthode Toe-Dip pour modifier la structure des URL.

Pourquoi faire une boule de canon quand vous pouvez simplement tremper vos orteils ?

Les boules de canon sont parfaites pour les fêtes au bord de la piscine en compagnie de gens bien habillés, mais lorsqu'il s'agit de conseiller les entreprises de nos clients, le changement de décor exige un peu plus de subtilité.

Ce billet explique comment apporter des modifications substantielles à la structure URL d'un site web, sans risquer de provoquer un raz-de-marée.

Nous utilisons Wordpress dans ce billet (puisque il y a de fortes chances que vous l'utilisiez), mais le même concept s'appliquerait également à d'autres systèmes de gestion de contenu populaires.

Plongeons donc dans l'aventure. ...euh, testons les eaux.

Un peu d'histoire

L'un de nos clients, qui compte plus de 10 000 articles sur son site web, utilise depuis la création du site la structure basée sur la date mentionnée ci-dessus (site.com/yyyy/mm/dd/post-title). Cela signifie qu'un grand nombre de leurs articles de haute qualité apparaissent dans les résultats de recherche de la manière suivante :

changing-url-structure-cover-update.png

Les choses ressemblent probablement à ceci en ce moment.

Le pire, c'est que le secteur d'activité de ce client est l'un de ceux où, à tort ou à raison, la fraîcheur du contenu est considérée comme une marque exclusive de pertinence. Ainsi, même si les moteurs de recherche classent bien le contenu, leurs CTR organiques sont incontestablement quelque peu réduits par l'ancienneté du contenu.

En raison de la compétitivité de l'espace, il est devenu presque impératif de modifier la structure de l'URL, afin de s'assurer qu'ils donnent le meilleur d'eux-mêmes à tous les égards.

Une fois la nouvelle structure d'URL décidée, nous avons eu l'idée de la meilleure façon d'optimiser le rapport risque/récompense :

https://www.website.com/articles/post-title

Considérez ceci : si vous êtes un utilisateur chevronné de Wordpress, la première chose qui vous vient à l'esprit lorsque vous réfléchissez à la structure des URL est la page Permalink Settings dans WP Admin :

current-permalinks-screenshot.png

Si vous n'êtes pas familier avec cet écran, c'est l'endroit où vous indiquez à Wordpress comment structurer les URL des articles de votre site. Il s'agit d'un outil simple pour gérer quelque chose qui a un impact énorme. Nous reviendrons sur cet écran plus tard dans ce billet pour finaliser nos changements après avoir effectué de nombreux tests.

Mais le problème, lorsqu'on cherche une solution sur cette page, c'est que les modifications apportées à la structure des URL sont all-or-nothing : si l'on modifie le paramètre sur cet écran, chaque message est immédiatement modifié, sur l'ensemble du site.

Comme le plugin Yoast SEO nous en avertit en haut de cet écran :

Modifier les paramètres de vos permaliens peut avoir un impact sérieux sur la visibilité de votre site dans les moteurs de recherche. Cette opération ne devrait presque jamais être effectuée sur un site web en activité.

Yoast SEO Plugin

Comment pourrions-nous tester cette nouvelle structure d'URL sur un sous-ensemble d'articles, disons une vingtaine, et évaluer les résultats ? Les moteurs de recherche trouveraient-ils la nouvelle adresse du contenu sans que cela n'ait d'effet dévastateur sur le classement ?

Voici comment nous avons procédé.

La méthode Toe-Dip, expliquée

Nous commençons par créer un nouveau type d'article personnalisé appelé "Articles" (qui aura pour nom "articles"). La meilleure façon de créer et de gérer les types de posts personnalisés est le plugin Wordpress appelé CPT UI, ou Custom Post Type UI.

Installez ce plugin, puis créez votre nouveau type d'article personnalisé appelé "Articles". Si vous avez besoin d'instructions pour configurer un nouveau CPT, consultez la documentation.

La meilleure façon de déterminer les articles avec lesquels tester les changements d'URL est d'aller sur Google Analytics (ou un outil similaire) et de trouver des articles qui ont un trafic important, mais qui ne sont peut-être pas vos articles principaux (encore une fois, pour atténuer les risques). Faites une liste des articles que vous souhaitez tester, enregistrez leur nom et leur URL dans un endroit pratique, car vous voudrez revenir sur votre système d'analyse plusieurs fois au cours des semaines à venir pour évaluer les performances.

Pour modifier le type d'article en question, vous devez procéder de l'une des deux manières suivantes.

Vous devez soit

  • Avoir un accès à la base de données et du savoir-faire, afin de trouver l'ID du message en question, et changer manuellement la valeur de post_type field from post to article, si vous vous sentez à l'aise pour le faire. Cette méthode sera de loin la plus rapide lorsque vous commencerez à inclure de nombreux messages dans le test. Si vous ne vous sentez pas à l'aise pour faire ce changement, assurez-vous de hire un développeur, et bien sûr, sauvegardez d'abord votre site web ! Ou bien..,

  • Installez Post Type Switcher, et effectuez le changement à partir de l'écran d'édition de l'article. Voici un article qui explique comment effectuer le changement avec cette méthode. Remarque : cette méthode deviendra fastidieuse au fur et à mesure que vous inclurez de plus en plus de messages dans votre test.

Utilisez la méthode choisie pour chaque article que vous souhaitez tester, et c'est alors que la magie opère. Comme Wordpress traite les requêtes en fonction du type d'article, vous n'avez même pas besoin de créer manuellement des redirections ! Dès que vous demanderez à nouveau l'ancienne URL, Wordpress vous redirigera automatiquement vers la nouvelle à l'adresse :

Utilisez la méthode choisie pour chaque article que vous souhaitez tester, et c'est alors que la magie opère. Comme Wordpress traite les demandes en fonction du type d'article, vous n'avez même pas besoin de créer manuellement des redirections ! Dès que vous demanderez à nouveau l'ancienne URL, Wordpress vous redirigera automatiquement vers la nouvelle à l'adresse :

https://www.website.com/articles/post-title

De cette manière, le travail est en fait extrêmement minime pour obtenir le résultat souhaité. Nos articles de test utilisent maintenant notre nouvelle structure URL finale, le reste de notre contenu ne sait pas que quelque chose a changé, et nous pouvons nous asseoir et attendre de recueillir de nouvelles données d'analyse pour voir comment les changements se déroulent.

Avant de continuer, assurez-vous que chaque URL est redirigée correctement et que tout fonctionne comme prévu. Il serait dommage que votre test échoue à cause d'une erreur honnête.

Établir des intervalles de performance pour les tests

Maintenant que votre test est en place, nous vous recommandons de surveiller de près les performances de ces URL au cours des jours et des semaines à venir. Nous avons utilisé le calendrier suivant pour nous assurer que nous gardions un œil attentif sur les choses :

  • Un jour après
  • Trois jours après
  • Une semaine après
  • Deux semaines après
  • Trois semaines après

Pourquoi attendre trois semaines ? Les choses changent beaucoup en matière de référencement et de performances des sites web, parfois rapidement, parfois lentement. Notre décision d'effectuer ces tests pendant une période aussi longue était fondée sur le fait que nous disposions d'un moyen de réduire les risques liés à ce changement et qu'il n'y avait pas d'urgence substantielle, alors pourquoi précipiter les choses et ajouter des risques en allant trop vite ? Vous pouvez, bien entendu, adapter votre calendrier de tests aux besoins de votre organisation.

Comme nous l'avons déjà mentionné, nous avons commencé avec seulement 20 messages à impact moyen pour notre premier lot de tests. Après avoir obtenu de bons résultats (voir "Nos résultats" ci-dessous), nous sommes passés à un lot plus important de 100 messages, puis de 500 messages, de 1 000 messages, puis des milliers de messages restants. Là encore, il était essentiel pour nous de réduire les risques d'un changement aussi massif.

Il convient toutefois de noter qu'au fur et à mesure que nous établissions la confiance avec chaque test ultérieur, nous avons utilisé des intervalles de confiance de plus en plus courts.

Évaluation des performances : création d'un rapport rapide

La méthode que nous avons utilisée ici est relativement simple mais extrêmement puissante et, une fois qu'elle est mise en place, très facile à utiliser.

Nous allons créer un rapport personnalisé dans Google Analytics, qui filtre les URL qui nous intéressent. Ouvrez votre Google Analytics et cliquez sur Personnalisation->Rapports personnalisés en haut de la barre latérale :

create-a-google-analytics-custom-report.png

Ensuite, configurez votre rapport pour qu'il corresponde aux paramètres présentés ici :

create-a-ga-custom-report.png

N'hésitez pas à ajouter toutes les mesures que vous jugez pertinentes, mais dans cet exemple, nous avons simplement ajouté "Entrées / Pages vues", car ce qui nous intéresse avant tout ici, c'est l'impact de cette modification de la structure de l'URL sur le trafic.

La petite touche de "magie" ici est que sous Filters nous avons inclus un filtre Regex sur "articles". C'est là qu'intervient la puissance de ce rapport : lorsque nous ajouterons de nouveaux articles au test, ils seront automatiquement inclus ici.

Note : lorsque vous inclurez de nouvelles URL dans le test, votre trafic dans ce rapport augmentera également. Veillez donc à créer Notations dans votre rapport pour garder une trace de l'ajout de nouvelles URL, sinon vous aurez l'impression que les performances ont skyrocketed (ce qui est possible, d'où l'utilité de la notation).

Avec notre rapport filtré configuré, nous pouvons maintenant évaluer notre test de changement de structure d'URL à faible risque, et voir s'il s'agit d'un changement que nous devrions déployer sur l'ensemble du site.

Il est temps de faire des vagues : Effectuer le changement final

Vous avez effectué les tests décrits ci-dessus et les performances du trafic sont (espérons-le) stables ou se sont améliorées dans une certaine mesure, comme le montre votre rapport Google Analytics personnalisé. Vous avez acquis la certitude qu'il s'agit de la bonne direction à prendre sans risquer de mettre en péril votre entreprise (ou celle de votre client).

Rendons les choses officielles.

Avant de commencer, veillez à sauvegarder votre site web (y compris votre base de données) au cas où vous feriez des erreurs ou auriez besoin de revenir sur vos modifications pour quelque raison que ce soit.

Les dernières étapes de ce processus sont un peu nuancées, mais tout à fait réalisables si vous (ou votre développeur) avez un peu de "technicité". Pourquoi ?

Il peut sembler qu'il ne reste plus qu'à se rendre à nouveau sur Settings->Permalinks et à attribuer une structure personnalisée qui commence par /articles/, comme vous le voyez ci-dessous :

changing-permalinks-old.png

NE PAS FAIRE CELA - sauf si vous n'avez (et n'aurez toujours) qu'un seul type d'article sur votre site. sur votre site. Dans ce cas, tout devrait bien se passer. Mais TESTEZ !

Le problème qui se pose est que si vous avez d'autres types d'articles sur votre site, cette modification ajoutera /articles/ aux URL de ces types d'articles.

Nous allons donc procéder à cette modification en ** quatre étapes** : en utilisant les paramètres Permalinks et une logique simple dans votre functions.php. Préparez votre éditeur de code et ouvrez ce fichier, car vous voudrez effectuer ces changements très rapidement (ou vous risquez d'avoir un impact sur les utilisateurs). Bien entendu, réfléchissez aux modifications avant de les enregistrer, mais lorsque vous êtes prêt à passer à l'action, passez à l'action !

Étape 1 : Modifier les paramètres du permalien

Retournez dans l'administration de Wordpress et allez sur Settings->Permalinks une fois de plus, et faites le changement que vous voyez ici (regardez dans la zone Post name) :

updated-permalinks-structure.png

Si vous avez plusieurs types d'articles sur votre site, c'est ce paramètre qu'il vous faut, combiné avec le reste des étapes ci-dessous

Enregistrez vos modifications. Mais nous n'avons pas encore tout à fait terminé !

Étape 2 : Ajouter une logique pour dire à Wordpress de faire précéder /articles/ uniquement pour les articles

Ajoutez ce qui suit à votre functions.php file, editing the articles bit si nécessaire, si vous n'utilisez pas exactement cette chaîne pour vos nouvelles URLs.

Prenez l'extrait de code pour cette fonction sur cette Gist

L'action (voir add_action) rewrites the URLs for our posts. The filter (see add_filter) modifie les liens de publication que Wordpress génère à différents endroits dans le backend et le frontend de votre site.

Étape 3 : Réaffectation articles as posts

Nous devons encore réaffecter le post-type de tous les articles que nous avons assignés au post-type Articles plus tôt. Utilisez la méthode que vous avez sélectionnée ci-dessus pour changer le type de message de ces messages (ce sera beaucoup plus rapide si vous avez choisi l'option de la base de données). Assurez-vous de faire appel à hire un développeur pour effectuer ce changement si vous ne vous sentez pas capable de le faire vous-même).

Ensuite, supprimez le type d'article de votre site à l'aide du plugin CPT UI.

Étape 4 et un "gotcha" : Redirections Regex à partir de votre serveur web

Vous vous souvenez de l'époque où Wordpress gérait facilement le changement de /yyyy/mm/dd/post-title to /articles/post-title ? Eh bien, ce ne sera plus le cas maintenant, parce qu'en changeant la structure permalienne, nous avons effectivement interrompu le mécanisme qui était en jeu auparavant (Wordpress nous donnait le bénéfice du doute en se basant sur le type de message).

Puisque nous sommes maintenant en dehors des mécanismes de Wordpress pour gérer les redirections, nous devrons donner à notre serveur web des instructions spécifiques sur ce qu'il doit faire lorsqu'il reçoit des requêtes pour des URL basées sur la date (/yyyy/mm/dd/post). Nous utilisons Nginx, et voici le petit extrait que nous avons créé pour gérer cette dernière étape :

location ~ "/([0-9]{4})/([0-9]{2})/([0-9]{2})/(.*)" {
  return 301 https://www.website.com/articles/$4;
}

Nous créons ici un bloc de localisation dans notre serveur Nginx en utilisant une expression régulière qui répondra à toutes les routes au format /yyyy/mm/dd/, and redirect the request to whatever we set inside the block. The $4 part of the snippet means basically "the fourth part of the regex above", which in this case is the slug for the URL, absent the date (which is composed of parts $1, $2, and $3 (non utilisé ici).

Si vous utilisez Apache au lieu de Nginx, consultez ce post sur Stack Overflow, qui semble avoir la solution.

Testez minutieusement !

Maintenant, vérifiez votre site pour vous assurer que tout fonctionne toujours correctement. Si vous avez suivi les instructions ci-dessus, tous vos posts devraient maintenant être débarrassés de l'ancienne structure d'URL basée sur la date (ou ce que vous aviez auparavant) et utiliser la nouvelle structure /articles/ (ou ce que vous avez choisi).

Veillez à continuer à surveiller le trafic de votre site web au cours des semaines et des mois à venir. Mais sachez que vous avez adopté l'approche la moins risquée pour modifier la structure de votre URL.

Et si vous constatiez une baisse des performances ?

La première chose à vérifier est que vous avez correctement configuré le test. Ouvrez quelques-unes de vos URL de test et assurez-vous que votre contenu est accessible à son nouvel emplacement.

Tout est clair ? Bien, passons à la suite. Non ? Relisez cet article, vous avez manqué quelque chose.

Vérifiez l'URL précédente de ce contenu (la version qui, dans notre exemple, aurait eu la structure /yyyy/mm/dd). Lorsque vous naviguez vers cette URL, êtes-vous redirigé vers la nouvelle URL de test ?

Oui ? Bien, nous continuons. Non ? Relisez ce billet, vous avez probablement oublié une étape.

Assurez-vous également que vous exécutez ces tests en tant qu'utilisateur déconnecté et anonyme, sans cache de navigateur, car cela peut affecter les résultats (les redirections de cache des navigateurs).

Si ces deux vérifications aboutissent à une redirection réussie, consultez les journaux 404 de votre serveur pour voir s'il n'y a pas eu d'interruption dans la disponibilité des ressources. C'est peu probable, mais cela vaut la peine de vérifier.

Bien qu'il existe d'autres possibilités, celles-ci sont les plus probables. Si vous avez exclu ces options et que les performances de ces URL de test ont chuté, il vous reste quelques options principales :

  • attendre quelques semaines, la situation pourrait s'améliorer
  • Attendre la prochaine mise à jour majeure de l'algorithme de Google. Ces mises à jour sont généralement espacées de 6 à 8 mois, nous ne le recommandons donc pas, mais Google devrait être en mesure de trouver ce contenu et de comprendre la redirection. Il est donc possible qu'un re-crawl complet de votre site en prévision d'une mise à jour majeure de l'algorithme puisse entraîner un changement de performance, mais considérez cela comme un cas particulier.
  • Revenez sur vos modifications et partez en sachant que vous avez testé ce changement de structure d'URL et qu'il aurait été catastrophique si vous l'aviez fait globalement. Vous venez de vous épargner, à vous ou à votre client (ou aux deux), beaucoup de chagrin, ce qui vous rend fantastique et vous donne une longueur d'avance.

Nos résultats : Une très grande victoire

results.png

D'après notre expérience, cette méthode a incroyablement bien fonctionné, et le client a non seulement maintenu son trafic pour les articles testés, mais l'a considérablement amélioré pour presque tous les articles testés.

Le plus beau, c'est qu'à aucun moment de ce test, le client n'a été exposé à un risque massif pour son trafic. Et le trafic a considérablement augmenté en conséquence.

Nous pensons que cette recette est le "secret" manquant pour effectuer en toute sécurité des changements de structure d'URL à l'échelle du site.

Vous avez besoin d'aide pour réaliser ce test ou vous souhaitez que nous le fassions pour vous ?

Pas de problème, nous serons ravis de vous aider. Entrez en contact avec nous avec quelques détails de base sur votre site web et nous vous contacterons.

Paul Grieselhuber

Paul Grieselhuber

Founder, President

Paul has extensive background in software development and product design. Currently he runs rendr.

Commentaires

    Réservez un appel de découverte avec nos experts produits.

    Notre équipe d'experts en applications web et mobiles est impatiente de discuter avec vous de votre prochain projet.

    Réservez un appel avec nous 👋