Ajouter du JSON-LD dans Next.js : schémas d’article, de produit, de logiciel et de fil d’Ariane

Demandez-vous ce que la page représente principalement. Un article d’actualité ou de blog peut être un Article. Un article à acheter peut être un Product avec une Offer. Une page de présentation logicielle peut décrire une SoftwareApplication. BreadcrumbList décrit la hiérarchie de navigation et peut accompagner une autre entité principale.

Ne choisissez pas un type parce que son apparence dans la recherche vous attire. Les fonctionnalités de recherche ont des règles d’éligibilité qui dépassent la validité JSON, et publier du balisage ne garantit pas un résultat enrichi. Le premier objectif est une description exacte, lisible par machine et cohérente avec la page visible.

Construisez l’objet dans un Server Component à partir du même enregistrement que la page. Sérialisez-le dans un script de type application/ld+json. Remplacez les caractères inférieur à dans la valeur sérialisée afin que les chaînes contrôlées par l’utilisateur ne puissent pas fermer l’élément script et injecter du balisage.

Gardez la fonction utilitaire petite. Elle doit sérialiser les données sans risque, pas décider des faits métier. Construisez les objets Article, Product ou SoftwareApplication dans des fonctions typées qui valident les champs requis et omettent les valeurs facultatives inconnues.

Utilisez le titre canonique, la description, les dates de publication et de modification, l’auteur, l’éditeur, l’image principale et l’URL principale. Ne mettez dateModified à jour que pour un changement substantiel de l’article. Une recompilation globale du site n’est pas une révision éditoriale.

L’auteur doit correspondre à la signature visible. Si la page crédite une organisation, décrivez cette organisation ; si elle crédite une personne, utilisez cette personne. Ajoutez des liens vers les pages stables de l’auteur ou de l’éditeur si elles existent et gardez l’URL du logo absolue.

Les données Product peuvent inclure le nom, la description, les images, le SKU, la marque et les offres. Les valeurs Offer, comme le prix, la devise, l’URL, l’état et la disponibilité, doivent correspondre à ce que l’acheteur peut voir et acheter. Générez-les depuis le même enregistrement commercial que la page.

Les variantes nécessitent un modèle clair. N’émettez pas plusieurs prix contradictoires comme une offre unique sans expliquer la plage, et n’affirmez pas InStock si le paiement rejette l’article. Les avis et notes agrégées doivent provenir de véritables avis visibles et respecter les règles de recherche applicables.

SoftwareApplication peut indiquer le nom, la catégorie, le système d’exploitation, l’URL et la description de l’application. N’ajoutez une Offer que si le prix et les conditions correspondent à une option visible. Si le prix varie ou nécessite un contact, représentez-le fidèlement plutôt que d’imposer une offre trompeuse à prix nul.

Les données structurées ne remplacent pas une page produit claire. Celle-ci doit encore expliquer l’usage, le public, les fonctionnalités, les contraintes, le parcours tarifaire et l’action suivante. Écartez les affirmations de notes ou de récompenses si la page et les preuves ne les justifient pas.

BreadcrumbList décrit le parcours que l’utilisateur peut suivre dans l’architecture du site. Chaque élément a une position, un nom et une URL canonique. Le fil d’Ariane visible et le JSON-LD doivent correspondre. N’incluez pas chaque segment de route si la hiérarchie présentée à l’utilisateur utilise un libellé plus simple.

Générez le fil d’Ariane depuis les données de la route plutôt qu’en analysant des URL arbitraires. Un produit peut appartenir à plusieurs catégories, mais la page doit choisir la hiérarchie canonique que sa navigation visible et ses liens internes renforcent.

Validez la syntaxe JSON, la structure du schéma et les exigences de la fonctionnalité de recherche, puis comparez chaque valeur importante au contenu visible. Testez les guillemets, chevrons, caractères Unicode, images manquantes, prix absents, produits en rupture, articles non publiés et URL canoniques modifiées.

Lorsqu’un champ facultatif manque, omettez généralement la propriété. L’absence d’une information métier obligatoire peut signifier que la page n’est pas prête pour ce schéma. Journalisez les échecs de validation pendant le développement et l’import du contenu plutôt que de servir des valeurs par défaut inventées.

Adios permet à une même version Next.js de servir la page visible et le JSON-LD depuis un environnement d’exécution persistant. Déployez la candidate, récupérez la route générée et validez le script dans le HTML réel. Les journaux de compilation révèlent les erreurs de sérialisation ou de type ; ceux d’exécution aident à suivre les enregistrements qui échouent seulement avec les données de production.

Après la réussite du contrôle de santé, gardez le domaine personnalisé et le TLS géré associés à la version promue. Relancez la validation sur l’URL canonique : l’hôte, les redirections, les valeurs d’environnement et les URL d’images peuvent différer d’un test local.