Avez-vous déjà remarqué lors de la création d’une nouvelle page WordPress que créer des liens vers des images de librairie génère automatiquement des URL absolues? Le paramètre par défaut du CMS consiste à utiliser des URL absolues chaque fois que cela est possible. Même si cela peut faire du transfert d’un site WordPress d’un serveur à un autre un cauchemar, il y a de très bonnes raisons pour lesquelles les développeurs WordPress ont choisi cette route. Ces raisons sont expliquées ci-dessous.
Avant d’arriver à ces raisons, il convient d’abord de préciser que les développeurs WordPress n’essaient pas intentionnellement de faire de la vie les développeurs de sites web un enfer. Ils n’ont pas choisi le modèle d’URL absolu car ils apprécient que les développeurs web travaillent plus dur. Le modèle d’URL absolu est utilisé car il est, à long terme, meilleur pour le référencement et les performances du site web.
URL absolues et relatives
À des fins de clarification, une URL absolue est une URL qui inclut le chemin structurel complet d’un élément de conception sur le serveur. Disons que vous insérez un graphique nommé ‘Image.png’ dans un nouvel article WordPress. Choisir cette image après l’avoir téléchargée dans votre librairie de médias produira une URL absolue ressemblant à ceci :
http://votre_domaine.com/wp-content/uploads/2017/08/Image.png
Le chemin absolu de l’image comprend à la fois votre nom de domaine et le protocole approprié. Une URL relative ne le fait pas. Elle redirige vers l’élément en question en jouant sur l’URL de base. Voici un exemple d’URL relative pour le même fichier :
/wp-content/uploads/2017/08/Image.png
Il existe différentes manières de créer des URL relatives par rapport à son URL de base. D’un autre côté, il n’y a qu’une seule façon de construire des URL absolues. Cette différence est essentielle pour comprendre pourquoi WordPress utilise par défaut le modèle d’URL absolue.
Problèmes d’URL relatives
Avec une compréhension de base de la différence entre les URL absolues et relatives, nous pouvons commencer à comprendre pourquoi les URL relatives peuvent causer des problèmes. Un bon endroit pour commencer est ce qu’on appelle le « piège à araignée ».
Une araignée dans le monde SEO n’est rien de plus qu’un logiciel utilisé par les moteurs de recherche pour scanner et analyser des pages Web. Un piège à araignées se produit lorsque le logiciel confond une ou plusieurs URL relatives et les interprète comme redirigeant vers le même élément lorsque le concepteur web leur a demandé de rediriger vers des éléments différents. Une araignée capturée dans ce piège ne sait pas interpréter les URL relatives.
Un autre problème associé aux URL relatives est le contenu en doublons. Supposons, par exemple, qu’un développeur web utilise la même structure d’URL relative dans son environnement de test, qui s’applique également aux sites web qu’il a mis en ligne. Les robots des moteurs de recherche peuvent reconnaître un contenu distinct comme étant en doublon en raison des URL relatives. Le contenu en double ne nuirait évidemment pas à l’environnement de test, mais il pourrait endommager gravement les classements des moteurs de recherche des sites en ligne.
En résumé, on peut dire des URLs absolus qu’elles protègent les performances du site web en réduisant les erreurs qui pourraient causer des problèmes aux moteurs de recherche. Les développeurs de WordPress l’ont bien compris, même si les URL absolues peuvent représenter un surcroît de travail pour les développeurs de sites web.
C’est une excuse assez stupide de la part des développeurs wordpress. Beaucoup de CMS ou bien même lorsque l’on développe sous framework ont développé (dont moi même) des centaines de sites ou application avec une notion de référencement. Et très rarement sont les problèmes d’url en doublons sauf si le gestionnaire est un noob et provoquent des erreurs dans la gestion de son site.
Tout en sachant que les bots de recherche à moins d’être mal développés peuvent largement faire la différence et c’est très facile à programmer le fait de rajouter le nom de domaine à la base root du site et de l’indexation.
Cela peut devenir problématique lorsque l’on a une multi architecture applicative avec des CMS ou un mauvais développement des routes.
Les url absolues dans wordpress c’est une imminence connerie et bien d’autres cms ne fonctionnent pas comme ça et ça n’a jamais posé de problème.
Le seul et « chiant » ! problème de wordpress c’est lors d’une migration. C’est chiant, fastidieux et une perte de temps monumentale et peuvent être là pour le coup source d’erreurs lors d’un search and replace.
Bien dit.
Puisqu’il est évident que la compétence des développeurs de WP ne peut être mise en doute, il s’agit d’une stratégie délibérée : laisser de coté des fonctionnalités triviales, peut-être pour vendre des solutions payantes (ou de la formation…) qui vont y pallier. Le plus flagrant est le parcours de la médiathèque qui n’affiche pas les noms des fichiers, ce qui devient vite pénible lorsqu’on a plusieurs versions d’une même image en différentes résolutions ou différents formats. D’un point de vue programmation, afficher le nom des fichiers est totalement trivial, et pourtant les utilisateurs de WP sont toujours contraints de cliquer « au hasard » pour choisir une image quand ils en ont plusieurs versions. Je serais intéressé, dans la même veine de cet article, de lire ce que les développeurs de WP inventent comme justification pour ne pas afficher les noms des fichiers dans les listes de la médiathèque.