PrestaShop 9.2 : changements des données structurées et des routes multilingues

Une mise à jour du thème et une mise à jour du cœur peuvent chacune produire des données structurées apparemment valides alors que la page résultante décrit deux fois le même produit avec des valeurs contradictoires. C’est le type de problème d’intégration à rechercher dans PrestaShop 9.2.

Les changements de la version 9.2 comprennent des travaux sur les données structurées côté cœur, une prise en charge complémentaire des URL de produits et catégories non valides et la configuration multilingue des routes d’entités. Ce sont des changements concrets de rendu et de routage. Ils ne prouvent pas une amélioration du classement, et cet article ne reprend pas une liste générale de vérifications SEO. Modification des données structurées dans le cœur, amélioration complémentaire, routes multilingues.

Effectuez les vérifications ci-dessous sur la version candidate 9.2 RC1 disponible au 26 septembre 2026, en consignant les versions exactes du thème et des modules SEO.

Dans un déploiement multiboutique, combinez cet audit du rendu avec les vérifications multiboutiques de PrestaShop 9.2 afin qu’une URL correcte soit également évaluée dans le contexte de la bonne boutique.

Déplacez le périmètre d’audit des fragments de modèles vers la sortie finale

L’orientation des données structurées côté cœur permet de préparer les données dans le code de l’application et de les rendre par l’intermédiaire du thème. Cela modifie les points auxquels une extension peut contribuer et auxquels des responsabilités en double peuvent apparaître. L’exemple officiel demoseo constitue une référence source utile pour cette nouvelle orientation d’intégration. Exemple officiel de données structurées.

Commencez par répertorier chaque composant susceptible de produire des données de produit ou d’organisation : le cœur, le thème, les surcharges du thème enfant et les modules. Identifiez le responsable de chaque champ ou représentation d’entité. Ne supposez pas qu’un module a cessé de produire du balisage simplement parce que le cœur a acquis une nouvelle capacité.

Examinez ensuite la page rendue. Une revue du code source ne suffit pas à prouver le résultat final, car plusieurs hooks et modèles peuvent y contribuer. Inversement, le résultat d’un validateur ne permet pas toujours d’expliquer quel composant a produit une valeur incorrecte.

Choisissez d’abord un produit ordinaire comme jeu de données de test. Capturez la réponse de la page et analysez chaque bloc JSON-LD. Comparez les identifiants, noms, URL et valeurs commerciales à la page visible. Utilisez le résultat rendu comme pièce d’acceptation et l’inventaire des sources pour expliquer la responsabilité de chaque donnée.

Détectez les descriptions contradictoires avant d’ajouter du balisage

La présence de plusieurs blocs de données structurées n’est pas mauvaise en soi. Le problème réside dans des descriptions contradictoires ou déconnectées de la même entité. Un thème et un module peuvent chacun produire un produit avec des prix, disponibilités ou identifiants différents.

Pour chaque représentation de produit, déterminez si elle désigne la même entité et si ses valeurs concordent. Si deux composants sont responsables du même fait, décidez lequel doit faire autorité. Ne supprimez pas un bloc entier uniquement parce qu’il y a plusieurs éléments script ; il peut décrire une autre entité légitime.

Soyez attentif aux valeurs ajoutées par les modules, telles que les avis ou les politiques. Leur présence doit être étayée par le contenu réel de la boutique et le contrat de données prévu par le module. N’inventez pas de notes ni d’informations de politique pour donner l’impression qu’un rapport de validation est plus complet.

Pour un thème enfant, comparez les modèles hérités aux surcharges locales. Une ancienne surcharge peut conserver une sortie héritée alors que le thème parent adopte le parcours côté cœur. La correction doit résoudre le conflit de responsabilité plutôt qu’appliquer un remplacement textuel général à tous les scripts de la page.

Traitez séparément toute affirmation relative aux résultats de recherche externes. Un balisage correct est un résultat d’implémentation. L’affichage d’un enrichissement particulier par un moteur de recherche est une autre question, qui n’est pas garanti par ce changement de version.

Utilisez des jeux de données révélant les erreurs de transformation

Un nom de produit simple et une courte description peuvent masquer les problèmes de conversion de texte. Ajoutez une description fictive avec des paragraphes adjacents, des mises en valeur et des caractères non ASCII. Examinez le texte des données structurées et comparez-le au contenu lisible prévu.

La PR complémentaire de la version 9.2 mentionne un nouveau parcours de conversion HTML vers texte pour les descriptions et le traitement des URL de produits et catégories incohérentes. Ces détails justifient des cas de régression ciblés sans laisser entendre que tous les comportements SEO ont changé. Amélioration des données structurées #42016.

Vérifiez un produit avec déclinaisons si la boutique en utilise. Sélectionnez une autre déclinaison par l’interface prise en charge et examinez la représentation structurée produite par la page. La représentation attendue doit correspondre au contrat du thème et du cœur, et non à une hypothèse copiée d’une autre boutique.

En cas de données facultatives manquantes, confirmez que la sortie reste cohérente. L’absence d’image ou de description ne doit pas provoquer d’erreur de syntaxe dans un script ni la réutilisation de la valeur d’un autre produit. Utilisez des jeux de données laissant volontairement le contenu facultatif non renseigné.

Il s’agit de propositions de tests d’intégration. Elles n’affirment pas que la version candidate présente chacun des échecs décrits.

Les caractéristiques produit et les coordonnées de la boutique font l’objet d’un changement concret dans RC

La version RC1 comprend également un changement ajoutant les caractéristiques produit via additionalProperty et les coordonnées configurées de la boutique aux données d’organisation. Il s’agit d’un ajout précis à la sortie, distinct de l’orientation antérieure vers le rendu côté cœur. Modification des caractéristiques produit et des coordonnées #42571.

Attribuez deux valeurs de caractéristiques reconnaissables au produit de test et comparez-les aux propriétés produites. Pour un thème multiboutique, examinez les coordonnées dans chaque contexte de boutique et confirmez que la sortie décrit la boutique sélectionnée. Si un autre module produit déjà les mêmes informations, examinez les responsabilités avant de conserver les deux représentations. N’ajoutez pas de coordonnées inventées uniquement pour remplir un champ facultatif.

Examinez les entités manquantes comme une catégorie de pages distincte

Demandez en préproduction une URL contrôlée de produit ou de catégorie inexistante. Capturez le résultat HTTP, la page visible et les éventuelles données structurées. La page ne doit pas décrire de manière trompeuse une offre produit valide pour une entité qui n’existe pas.

Ne testez pas uniquement en changeant le slug d’un identifiant existant. Selon le comportement documenté du routeur, cela peut aboutir à une entité réelle ou rediriger vers elle. Utilisez un jeu de données dont l’identité n’existe réellement pas et distinguez-le d’un produit inactif ou indisponible.

Si un module de page d’erreur personnalisé ou une surcharge de thème intervient, incluez-le dans l’inventaire des responsabilités. Une correction du cœur ne peut pas établir l’exactitude du balisage ajouté ensuite par une extension.

Conservez la réponse avant d’appliquer des modifications côté navigateur. Si un script change la page après son chargement, consignez-le séparément pour que l’équipe distingue la sortie du serveur du comportement du client.

Un cas de page manquante a sa place dans cet audit de version, car l’amélioration citée de la version 9.2 le concerne. Il ne doit pas devenir un guide sans rapport sur toutes les politiques de redirection ou d’indexation de la boutique.

La configuration des routes multilingues va au-delà des slugs traduits

Le changement des routes multilingues permet aux modèles de routes des entités de varier selon la langue. La PR présente comme exemple motivant une formulation du chemin propre à chaque langue. Cela se distingue de la traduction du nom réécrit d’un produit individuel. Modification des routes d’entités #41405.

Dans un jeu de données à deux langues, consignez le modèle de route et une URL d’entité réellement générée dans chaque langue. Suivez ces liens générés et vérifiez qu’ils aboutissent à l’entité et à la langue attendues. Évitez de construire manuellement une URL que l’application ne générerait jamais.

Changez ensuite de langue dans la boutique et examinez la destination. Vérifiez l’URL produite par un module qui pointe vers la même entité. Un module concaténant un segment de chemin fixe peut ignorer le nouveau modèle de langue configurable.

Une correction RC distincte et vérifiée préserve la pagination dans les URL hreflang des listes de produits. Auparavant, les variantes linguistiques pouvaient pointer vers la première page alors que l’URL canonique représentait une page ultérieure. Il s’agit d’une correction limitée de pagination, et non d’une affirmation selon laquelle tous les problèmes d’annotation linguistique seraient résolus. Correction de la pagination hreflang #42725.

Utilisez une catégorie comportant assez de produits pour plusieurs pages et examinez une page ultérieure dans deux langues. Suivez les liens de langue alternative et confirmez qu’ils conservent la position de page prévue. Incluez la première page comme cas distinct et examinez les alternatives réciproques. Distinguez ce test de la traduction des modèles de routes : l’un porte sur l’état de pagination, l’autre sur le modèle de chemin propre à la langue.

Vérifiez les valeurs par défaut avant d’enregistrer le formulaire des routes

Une correction complémentaire concerne les valeurs de route par défaut qui ne s’affichent pas correctement pour toutes les langues dans le formulaire SEO et URL lorsque la configuration est absente ou encore représentée dans une forme antérieure. La PR fournit une reproduction précise sur une configuration neuve. Correction des valeurs par défaut par langue #42241.

Testez une installation neuve de la version candidate avant de personnaliser les modèles. Ouvrez le formulaire et vérifiez que chaque langue concernée affiche une valeur par défaut valide. Enregistrez sans changement intentionnel, rouvrez et confirmez que les valeurs restent valides.

Configurez ensuite une différence linguistique volontaire au moyen du formulaire pris en charge et répétez les vérifications des liens générés. Cela distingue le renseignement des valeurs par défaut de la persistance des modèles personnalisés.

N’effacez pas des lignes de configuration sur une boutique en production pour recréer le cas du projet amont. Une base de test neuve fournit la condition nécessaire sans risquer les URL publiées. Si une configuration existante nécessite une investigation, utilisez une copie contrôlée et conservez ses valeurs d’origine.

Comparez un thème neuf au thème personnalisé

Lorsqu’un balisage contradictoire apparaît, reproduisez le jeu de données sur la révision prise en charge du thème non modifié, dans une instance de test distincte. Conservez des versions équivalentes du cœur et des modules. Introduisez ensuite une à une les surcharges du thème enfant et les modules SEO concernés.

Cette comparaison peut identifier la couche qui ajoute l’entité contradictoire ou la valeur périmée. Elle ne prouve pas que toute personnalisation est erronée ; un module peut fournir intentionnellement des données absentes du thème de base. La question est de savoir si la représentation combinée reste cohérente.

Enregistrez les objets analysés avec l’index du script d’origine et, lorsque votre examen permet de l’établir, le composant responsable. Évitez de supprimer une sortie uniquement selon l’ordre des scripts, car cet ordre peut changer sans que les responsabilités changent.

Une fois la couche responsable identifiée, retestez le produit ordinaire, l’entité manquante et les routes des deux langues. Une correction de modèle peut affecter d’autres pages que celle où l’écart a été remarqué initialement.

Gardez la comparaison de sortie finale assez concise pour qu’un responsable de thème puisse l’examiner sans reconstruire toute la boutique.

Conservez une comparaison de sortie concise et facile à examiner

Pour chaque jeu de données, enregistrez l’URL sélectionnée, la langue, le statut de réponse, les objets de données structurées analysés et les valeurs visibles pertinentes. L’extrait ci-dessous, destiné à la console du navigateur, inventorie uniquement les blocs JSON-LD de la page actuellement ouverte ; il ne valide pas l’admissibilité aux résultats de recherche :

const results = [...document.querySelectorAll('script[type="application/ld+json"]')]
  .map((node, index) => {
    try {
      return { index, validJson: true, value: JSON.parse(node.textContent) };
    } catch (error) {
      return { index, validJson: false, error: String(error) };
    }
  });
console.table(results.map(({ index, validJson }) => ({ index, validJson })));

Utilisez un validateur spécialisé et une revue sémantique manuelle à l’étape suivante. Un JSON valide est nécessaire pour un script JSON-LD, mais ne prouve pas que ses faits décrivent correctement la page.

L’audit de la version 9.2 doit aboutir à une responsabilité claire des données produites et à un comportement vérifié des routes linguistiques. Corrigez les contradictions et les valeurs par défaut défaillantes à leur source, puis conservez les jeux de données pour vérifier une mise à jour ultérieure du thème ou des modules avec les mêmes éléments de preuve.

Pour le contexte de la plateforme sous-jacente, consultez notre guide SEO de PrestaShop 9 et appliquez les vérifications propres à la version décrites ci-dessus à l’installation que vous évaluez.