Comment déterminer si un prestataire de création de sites web prend en charge les données structurées ?

Lors de l’évaluation d’un fournisseur de créateur de sites web avec données structurées, il ne suffit pas que le prestataire affirme « prendre en charge les données structurées ». Il faut surtout vérifier quelles pages peuvent être balisées, d’où proviennent les données, si elles sont synchronisées après une modification et qui se charge de leur validation et de leur maintenance une fois le site en ligne. Pour les entreprises exportatrices disposant d’un catalogue de produits multilingue, la possibilité d’insérer un extrait de code sur une page donnée et celle de gérer durablement les balisages de l’ensemble du site sont deux capacités très différentes.

Commencez par distinguer l’insertion de code de la mise en correspondance des données métier

Les données structurées sont des informations qui décrivent le contenu d’une page selon un format convenu. Elles sont généralement mises en œuvre à l’aide du vocabulaire Schema.org et du format JSON-LD afin d’indiquer aux moteurs de recherche que la page concerne une entreprise, un produit ou une autre entité. Il ne s’agit pas de balises de mots-clés et elles ne remplacent pas le contenu de la page. Même si un moteur de recherche reconnaît le balisage, cela ne garantit ni l’indexation, ni une amélioration du classement, ni l’affichage de résultats enrichis.

Lors du choix d’un prestataire, demandez-lui de présenter une opération concrète : après avoir modifié le nom ou l’image d’un produit dans l’interface d’administration, publiez la page et vérifiez si les données structurées sont mises à jour en conséquence. Si le code doit être saisi manuellement page par page, cela peut suffire pour quelques pages statiques. En revanche, lorsque le catalogue comprend de nombreux produits ou est fréquemment mis à jour, cette maintenance répétitive risque de créer des incohérences entre le contenu de la page et son balisage.

Demandez également à quel niveau le code peut être ajouté : dans les paramètres généraux du site, dans un modèle de page ou dans le code personnalisé d’une page individuelle. Le code global convient aux informations communes à l’entreprise, mais pas à la duplication des mêmes informations produit sur toutes les pages produits. L’essentiel n’est pas de savoir si le code peut être collé, mais s’il est possible de générer les données appropriées sur les bonnes pages.

Vérifiez le balisage selon le type de page, sans chercher à multiplier les types

Un site d’entreprise peut généralement utiliser des types tels que Organization, BreadcrumbList et Product. Une page d’article peut, par exemple, utiliser Article. Le choix doit dépendre du contenu réel de la page et des exigences du moteur de recherche visé. Schema.org définit les vocabulaires disponibles, mais l’existence d’un type ne signifie pas que Google ou d’autres moteurs de recherche lui associeront nécessairement une fonctionnalité d’affichage.

Les pages produits B2B exigent une attention particulière à l’exactitude des champs. Le site d’un fabricant peut présenter des spécifications, des applications et un formulaire de demande de renseignements, sans afficher publiquement les prix ni les stocks. Dans ce cas, il ne faut pas inventer un prix, une devise ou un état de disponibilité pour remplir les champs. Si la page affiche effectivement une offre commerciale, vérifiez que le prix, la devise et les conditions applicables dans le balisage correspondent à ceux de la page.

Pour la « liste des fonctionnalités prises en charge » présentée par le prestataire, posez aussi des questions précises sur chaque champ : le modèle du produit peut-il être associé à un champ de l’interface d’administration ? Le fil d’Ariane s’adapte-t-il aux changements de hiérarchie des rubriques ? Les anciennes données sont-elles supprimées lorsque le nom de l’entreprise, son URL ou son logo sont mis à jour ? La prise en charge d’un type ne signifie pas que tous les champs requis pour ce type peuvent être configurés.

Évaluez les capacités de configuration et de publication au moyen d’une démonstration complète

Plutôt que de vous fier à une présentation des fonctionnalités, demandez au prestataire d’effectuer tout le processus dans un environnement de test : « configuration, publication, modification et nouvelle vérification ». Choisissez une page de détail produit et une page de liste ou de rubrique. Vérifiez s’il est possible de configurer les balisages séparément, si la modification d’un modèle affecte d’autres pages et ce qui est réellement généré à l’URL publiée.

Lors de la recette, vérifiez notamment les points suivants :

• Consultez le code source de la page ou la page après rendu pour confirmer que le JSON-LD est bien présent et que l’URL, le nom, l’image et les autres champs correspondent au contenu actuel.
• Utilisez l’outil de validation du balisage de Schema.org pour vérifier la syntaxe et le vocabulaire. Pour les types de résultats enrichis pris en charge par Google, utilisez également son outil de test des résultats enrichis afin de vérifier les problèmes applicables.
• Examinez à la fois le balisage généré automatiquement par le système et celui ajouté manuellement pour éviter que la même entité comporte des noms, des URL ou des prix contradictoires.
• Modifiez un champ réel et republiez la page pour vérifier que l’ancienne valeur ne subsiste pas. Si nécessaire, videz le cache avant de refaire le test.

L’absence d’erreur dans un outil de validation indique uniquement qu’aucun problème relevant de son périmètre de vérification n’a été détecté. Elle ne garantit pas l’exactitude des données métier. L’outil ne remplace pas non plus une vérification manuelle du contenu de la page et ne peut garantir l’affichage d’un résultat enrichi dans les résultats de recherche. Si le balisage du site est généré par des scripts, vérifiez également que les moteurs de recherche peuvent accéder aux ressources des pages concernées et les traiter.

Pour les sites multilingues, le défi réside dans les relations entre les données et les responsabilités de maintenance

Sur les pages en différentes langues, le nom, la description et l’URL d’un même produit varient généralement, tandis que son modèle peut rester identique. Lors de l’évaluation, vérifiez quelques pages dans chaque langue : le balisage utilise-t-il la langue et l’URL de la page concernée ? Les images sont-elles accessibles ? La devise ou l’offre s’applique-t-elle à cette page ? La vérification de la langue par défaut ne suffit pas à confirmer que l’ensemble du site multilingue est correctement configuré.

Déterminez également quelles informations sont générées automatiquement par le système et lesquelles sont saisies par les éditeurs. Par exemple, si les coordonnées de l’entreprise changent, mais que le pied de page et les données structurées conservent les anciennes informations alors que le contenu de la page a été mis à jour, il sera difficile d’identifier le problème par la suite. Une approche plus fiable consiste à définir clairement la source des champs essentiels et à convenir d’une procédure de vérification après chaque mise à jour du contenu.

Les équipes qui proposent des services intégrant site web et marketing interviennent souvent aussi dans la gestion du contenu, du référencement et des pages promotionnelles. Les activités de 易营宝 couvrent notamment la création de sites web intelligents, les sites multilingues et le SEO. Lors de l’évaluation de ce type de solution, ajoutez à votre liste de questions la coordination entre les équipes : qui configure les champs, qui vérifie les traductions et les informations métier, et qui effectue une nouvelle validation après la mise à niveau des modèles ? Les capacités réelles en matière de données structurées doivent être confirmées lors d’une démonstration du projet et dans les conditions de livraison convenues.

Incluez les critères de recette dans le périmètre de livraison

Avant l’achat, demandez au prestataire de préciser les pages concernées, les types de balisage, la provenance des champs, les autorisations de configuration et les méthodes de validation. Faites-lui également indiquer si l’ajout de langues ou la modification des modèles produits nécessite un développement supplémentaire. Pour le code personnalisé, vérifiez si votre entreprise peut le consulter, le modifier ou le supprimer, et comment il sera transféré lors d’un changement de modèle.

Il n’est pas nécessaire de vérifier toutes les pages lors de la recette, mais il faut sélectionner des pages utilisant différents modèles et différentes versions linguistiques, et conserver les URL de test ainsi que les résultats. Un critère fiable consiste à vérifier si, après la mise à jour du contenu par les équipes métier, le système génère des informations cohérentes, si les équipes techniques peuvent effectuer les contrôles de manière autonome et si, en cas de problème, un responsable clairement identifié peut être contacté. Lorsque ces conditions sont réunies, les données structurées font véritablement partie du processus de maintenance quotidien du site.