Sur une boutique WordPress, le choix de l'extension de référencement se joue moins sur les fonctionnalités annoncées que sur ce qu'elle produit réellement dans le code de la fiche produit. Comparer Yoast SEO et Rank Math sur le balisage produit demande donc de regarder la sortie plutôt que la page de présentation : quels champs sont réellement générés, comment ils se relient au reste de la page, ce qu'il faut écrire pour les compléter, et ce que coûterait un changement d'avis deux ans plus tard. Les deux extensions font correctement le travail de base, et il faut le dire d'emblée ; leurs différences apparaissent sur les catalogues à variantes, sur l'extensibilité et sur la manière dont elles cohabitent avec les autres sources de balisage.

Deux approches du balisage

La différence la plus structurante entre les deux outils n'est pas une liste de champs mais une conception différente de ce qu'est le balisage d'une page. Elle explique la plupart des écarts constatés ensuite, et elle prolonge ce que nous décrivons dans notre article sur la manière de comprendre et étendre le graphe JSON-LD de Yoast.

Le graphe relié

La première approche, celle retenue par Yoast, produit un ensemble unique de nœuds reliés par identifiants, décrivant simultanément le site, la page, l'organisation, l'auteur et le produit. Le produit y est explicitement désigné comme entité principale de la page, ce qui lève l'ambiguïté entre la page et son sujet, distinction que beaucoup de balisages manquent. Cette structure est nettement plus verbeuse et bien plus riche en relations, ce qui est précisément l'intérêt recherché par un moteur qui cherche à rattacher une offre à un vendeur identifié et à une organisation connue par ailleurs.

Le balisage par blocs

La seconde approche, plus proche de ce que produit Rank Math, produit plusieurs blocs, chacun décrivant un type, avec moins de relations entre eux. Elle est plus lisible à l'œil nu, plus facile à comprendre pour qui découvre le sujet, et suffit très largement à l'éligibilité aux affichages enrichis des moteurs. Elle relie en revanche moins les entités entre elles, ce qui compte peu sur une boutique isolée et davantage sur un site où la même organisation apparaît dans plusieurs contextes, un groupe avec plusieurs enseignes par exemple.

Ce que les deux font également bien

Sur une fiche produit simple, un article avec un prix, une disponibilité et une référence, les deux extensions produisent un balisage valide, complet et accepté sans réserve par les outils de test des moteurs. La différence est strictement nulle sur ce cas de figure, qui représente pourtant la majorité des fiches d'une boutique ordinaire. Il serait malhonnête de laisser entendre que l'une échoue là où l'autre réussit sur le cas courant, et les comparatifs qui le suggèrent méritent d'être lus avec méfiance.

Où les écarts apparaissent

Les différences réelles se manifestent sur trois terrains bien identifiés : les produits à variantes, où la manière de décrire plusieurs offres pour une même fiche n'est pas la même ; les champs propres au commerce, gestion des identifiants normalisés, des marques, des conditions de retour et de livraison ; et l'extensibilité, c'est à dire ce qu'il faut écrire pour ajouter ou corriger un champ. Ces trois points doivent être évalués sur la boutique concernée, avec son catalogue et ses extensions, et non dans l'absolu.

Le rôle de l'extension de commerce

Un point souvent oublié : le logiciel de commerce produit lui même un balisage produit, et les deux extensions de référencement s'appuient dessus ou le remplacent selon les cas. La question n'est donc pas seulement de comparer deux extensions mais de savoir laquelle des trois sources fait autorité sur la page. Une configuration où les trois s'expriment produit un balisage contradictoire, situation que l'on rencontre très régulièrement et qui est bien plus dommageable que le choix de l'une ou l'autre extension. Le réglage consiste à désactiver le balisage natif du logiciel de commerce dès qu'une extension de référencement s'en charge, option prévue par les deux.

Les champs récents que les moteurs attendent

Le vocabulaire du commerce s'est enrichi ces dernières années de propriétés que les moteurs exploitent réellement et que beaucoup de balisages ignorent encore. Les conditions de retour, avec leur délai, leur pays d'application et la question de savoir qui paie les frais, sont désormais affichées dans certains résultats. Les informations de livraison, avec les frais et les délais par destination, le sont également. Le prix unitaire rapporté à une quantité de référence est attendu sur les produits vendus au poids ou au volume. L'état du produit, neuf ou reconditionné, distingue les offres sur les catalogues concernés. Aucune extension ne renseigne ces champs toute seule, puisqu'ils dépendent de règles commerciales que seul le marchand connaît : ils doivent donc être ajoutés par configuration ou par code, et leur présence pèse aujourd'hui plus lourd, dans la qualité de l'affichage, que le choix entre deux extensions.

Deux structures de données produit générées par des extensions différentes

Le cas des variantes

C'est le terrain qui départage réellement les deux outils sur une boutique à catalogue, et il mérite d'être examiné en détail plutôt que survolé, dans le prolongement de notre article sur la manière de gérer les variantes sans démultiplier les fiches produit.

Le problème à résoudre

Une fiche regroupant douze déclinaisons contient en réalité douze offres distinctes, chacune avec son prix, sa disponibilité et son identifiant propre, et le balisage doit rendre compte de cette réalité. Le vocabulaire employé par les moteurs prévoit deux manières distinctes de décrire cette situation : une offre unique portant une fourchette de prix, ou une liste d'offres détaillées. La première est plus simple à produire et beaucoup moins informative, la seconde permet un affichage enrichi précis, un rattachement fiable aux flux marchands et une disponibilité juste par déclinaison.

La fourchette de prix

Déclarer une fourchette de prix est parfaitement accepté par les moteurs et convient aux fiches dont les variantes ne diffèrent que légèrement en prix, quelques euros d'écart sur une gamme de tailles par exemple. Elle devient trompeuse dès que l'écart est important, le moteur affichant alors une valeur qui ne correspond à presque aucune vente réelle. Sur les catalogues où le prix varie fortement selon la contenance ou la taille, cette solution dégrade la qualité de l'affichage et le taux de clic, le visiteur découvrant en arrivant que le prix annoncé correspondait à la plus petite déclinaison.

La liste d'offres

Décrire chaque combinaison vendable comme une offre distincte, avec son identifiant, son prix et sa disponibilité, est la représentation fidèle. Elle demande que le balisage soit alimenté par les données réelles de chaque variante, ce que les deux extensions savent faire à des degrés divers, parfois nativement et parfois moyennant un module complémentaire ou quelques lignes de code. C'est de loin le point à vérifier en priorité sur un catalogue à déclinaisons, en lisant le balisage produit sur une fiche à variantes plutôt qu'en se fiant à une case cochée.

La cohérence avec le flux marchand

Le balisage de la page et le flux envoyé aux régies décrivent les mêmes offres et doivent employer les mêmes identifiants. Une incohérence entre les deux empêche tout rapprochement et prive la boutique des affichages qui en dépendent, sans qu'aucun message d'erreur ne le signale. Ce contrôle est indépendant du choix de l'extension et il est presque toujours le vrai sujet, bien avant la comparaison des outils. Il se vérifie en prenant trois références au hasard dans le flux et en cherchant leurs identifiants dans le balisage de la page correspondante.

Les adresses de variantes

Quand la boutique expose une adresse par variante, le balisage de chacune doit décrire l'offre correspondante et non la fourchette du produit parent. Très peu de configurations le font correctement d'origine, et c'est un point d'extension à prévoir quel que soit l'outil retenu, en s'appuyant sur les filtres que celui ci expose. Le contrôle est immédiat : ouvrir deux adresses de variantes différentes et vérifier que le prix balisé n'est pas le même sur les deux.

Critère Ce qu'il faut vérifier Comment
Structure générale Nœuds reliés ou blocs séparés Lire le code source d'une fiche
Variantes Fourchette ou liste d'offres Tester une fiche à déclinaisons
Identifiants normalisés Présence et exactitude Comparer avec le flux marchand
Extensibilité Filtres disponibles et documentés Écrire un ajout de test
Cohabitation Une seule source de balisage Compter les blocs sur la page
Coût de sortie Champs récupérables à la migration Exporter avant de décider

Extensibilité et maintenance

Sur une boutique un peu construite, aucune extension ne couvre l'intégralité des besoins réels, et ce qui compte devient la facilité à compléter ce qu'elle produit sans casser le reste. C'est le même raisonnement que celui appliqué aux données structurées d'une fiche produit e-commerce en général.

Les points d'accroche disponibles

Les deux outils exposent des filtres permettant d'intervenir sur le balisage juste avant sa sortie, mais leur granularité et leur philosophie diffèrent nettement : intervenir sur un ensemble complet de nœuds reliés n'est pas la même opération qu'intervenir sur un bloc isolé. Le premier cas demande de comprendre la structure, le second est plus immédiat mais offre moins de prise sur les relations entre entités. Le critère de choix est donc ici le profil de l'équipe qui interviendra dans la durée, plus que la qualité intrinsèque du mécanisme, les deux étant de toute façon suffisants pour un usage courant.

La qualité de la documentation

C'est un critère largement sous estimé et pourtant décisif au moment précis où il faut écrire une extension. Une documentation qui donne des exemples complets et fonctionnels de modification de balisage fait gagner une journée entière par rapport à une documentation qui se limite à lister des noms de filtres sans montrer ce qu'ils reçoivent. Ce point s'évalue en une demi heure avant même de choisir, en cherchant simplement comment ajouter un champ donné et en mesurant le temps qu'il faut pour trouver la réponse.

La stabilité des interfaces

Tout code écrit contre les filtres d'une extension dépend entièrement de leur stabilité dans le temps, et cette dépendance ne se voit qu'au moment où elle casse. Une extension qui modifie régulièrement la structure de son balisage impose de revérifier toutes les personnalisations à chaque mise à jour majeure, travail invisible et récurrent. Ce risque se mesure très simplement en parcourant l'historique des changements publié pour les deux dernières années, information publique, accessible en quelques minutes et pourtant presque jamais consultée avant un choix.

Le coût de la migration

Passer d'une extension à l'autre suppose de transférer l'ensemble des données stockées contenu par contenu, titres, méta descriptions, directives d'indexation, canoniques et réglages sociaux, tous enregistrés sous des clés de métadonnées différentes selon l'outil. Des outils d'import existent des deux côtés et fonctionnent correctement sur les champs standards, nettement moins bien sur les champs spécifiques et sur les réglages propres au commerce. La règle de prudence, sans exception, est d'exporter l'intégralité des métadonnées avant toute migration et de vérifier un échantillon d'une vingtaine de contenus après l'opération, plutôt que de faire confiance à un message de réussite affiché en fin d'import. La migration gagne aussi à être menée en période creuse et à conserver l'ancienne extension désactivée quelques semaines, le temps de vérifier que rien n'a été perdu, plutôt que de la supprimer immédiatement.

Vérifier plutôt que croire

La seule méthode d'évaluation qui vaut quelque chose consiste à installer les deux extensions sur une copie de la boutique, l'une après l'autre, et à comparer le balisage produit sur trois fiches choisies : un produit simple, un produit à variantes, et un produit en rupture. Cette manipulation prend une demi journée et remplace avantageusement tous les comparatifs disponibles, parce qu'elle porte sur le catalogue réel, avec ses particularités, ses champs personnalisés et ses extensions installées. Les résultats se lisent dans les outils de test des moteurs, mais aussi et surtout à l'œil : un balisage dont on ne comprend pas la structure sera difficile à maintenir, quel que soit son verdict de validation. Il faut également profiter de cet essai pour mesurer le temps de génération des pages avec chaque extension, écart rarement décisif mais qui peut compter sur une boutique déjà chargée.

Ce qui détermine réellement la qualité du balisage produit d'une boutique
Complétude des données du catalogue
38 %
Unicité de la source de balisage
27 %
Traitement correct des variantes
19 %
Extensions écrites pour le projet
11 %
Choix de l'extension de référencement
5 %

Poids relatif des facteurs constatés sur des audits de boutiques. Le choix de l'extension, qui occupe l'essentiel des discussions, arrive en dernière position.

Choisir sans se tromper de question

La comparaison des deux extensions occupe beaucoup de discussions, de comparatifs et de fils de forum, et elle pèse en réalité bien moins lourd que trois autres décisions que personne ne prend explicitement. Les hiérarchiser correctement fait gagner du temps et de l'argent.

La question qui compte le plus

Avant même de choisir un outil, il faut décider quelle source produit le balisage de la fiche produit, et désactiver explicitement toutes les autres. Une boutique disposant d'une seule source cohérente, quelle qu'elle soit, obtient systématiquement de meilleurs résultats qu'une boutique équipée de la meilleure extension du marché mais qui laisse en parallèle le thème et le logiciel de commerce produire leur propre balisage. Ce point se règle en une heure de travail et produit plus d'effet que n'importe quel changement d'extension mené sur plusieurs jours.

La qualité des données du catalogue

Aucune extension, quelle qu'elle soit, ne peut baliser un identifiant normalisé qui n'existe pas dans la fiche, ni une marque qui n'est renseignée nulle part dans le catalogue. Sur la très grande majorité des boutiques que nous auditons, le facteur limitant n'est pas l'outil de référencement mais la complétude du catalogue lui même. Renseigner les identifiants normalisés, les marques et les références fabricant produit un gain immédiat et mesurable, quel que soit l'outil retenu, et ce travail se retrouve intégralement dans les flux marchands, ce qui en double le rendement.

Ce que l'équipe sait faire

Une extension parfaitement adaptée sur le papier mais que personne dans l'entreprise ne sait paramétrer produit moins de valeur qu'un outil plus modeste et bien maîtrisé par celui qui l'utilise tous les jours. Ce critère est parfaitement légitime et pourtant rarement assumé dans les comparatifs, qui raisonnent comme si l'équipe qui exploite le site était interchangeable et disponible sans limite. Il vaut particulièrement pour une petite structure où une seule personne administre le site et n'a pas de temps à consacrer à l'apprentissage d'un nouvel outil.

Refaire le choix quand le contexte change

Un choix fait il y a quatre ans, sur un catalogue de deux cents produits simples et sans variantes, n'engage évidemment pas une boutique qui en compte aujourd'hui huit mille avec des déclinaisons et trois canaux de vente. La question se repose donc légitimement lors d'un changement d'échelle, d'une ouverture à l'international ou de l'ajout de nouveaux canaux de vente. Elle ne se repose pas parce qu'un comparatif publié quelque part a changé de conclusion, ni parce qu'une extension a refait sa page de présentation. Cette révision se fait sur la base des besoins effectivement rencontrés dans l'année écoulée, liste bien plus courte et bien plus fiable que celle des fonctionnalités annoncées de part et d'autre.