JSON-LD
Définition
JSON Linked Data. Format recommandé par Google pour intégrer du balisage Schema.org dans une page sous forme de script JSON. Plus simple à maintenir que les microdonnées HTML.
Ce qu'est JSON-LD
JSON-LD (JSON for Linked Data) est un format de sérialisation pour le Linked Data, recommandé par le W3C en 2014. Dans le contexte SEO, c'est la méthode préférée par Google pour intégrer du balisage Schema.org dans une page web : un bloc script type application/ld+json contenant un objet JSON décrivant le contenu (auteur, date, image, prix, avis, FAQ, etc.). Le format respecte la syntaxe JSON standard plus une convention @context qui pointe vers schema.org, et @type qui précise le type décrit. Le tout est lisible par les moteurs sans interférer avec le HTML rendu à l'utilisateur.
Pourquoi JSON-LD plutôt que Microdata
Trois formats coexistent : JSON-LD, Microdata, RDFa. Microdata utilise des attributs HTML (itemscope, itemtype, itemprop) imbriqués dans le markup visible. RDFa fait pareil avec d'autres attributs. JSON-LD est totalement séparé du HTML : un bloc script à part. Cette séparation a trois avantages majeurs. Premièrement, on n'alourdit pas le markup visible avec des attributs sémantiques. Deuxièmement, on peut générer le JSON-LD dynamiquement sans toucher au design. Troisièmement, on évite les conflits avec les frameworks frontend qui réécrivent le DOM. Google a clairement indiqué que JSON-LD est sa méthode préférée.
Anatomie d'un bloc JSON-LD
Un bloc minimal pour un article : @context: https://schema.org, @type: Article, headline, image, datePublished, author. Pour aller plus loin : description, dateModified, publisher avec son logo, mainEntityOfPage. Les champs obligatoires varient selon le type Rich Result visé. Pour Product, il faut au minimum name, image, et offers avec price/priceCurrency/availability. Pour FAQPage : mainEntity avec un tableau de Question, chacune avec acceptedAnswer. Le vocabulaire complet vit sur schema.org, mais Google ne reconnaît qu'un sous-ensemble pour les Rich Results, documenté sur developers.google.com/search.
Génération côté Next.js
Dans Next.js, on génère le JSON-LD dans un Server Component à partir des données déjà disponibles. On définit un objet TypeScript typé, on le sérialise avec JSON.stringify, et on l'injecte via une balise script avec dangerouslySetInnerHTML. Pour la sécurité, on échappe les caractères spéciaux : remplacer < par \u003c, > par \u003e, & par \u0026. La metadata API de Next.js ne gère pas nativement le JSON-LD, donc on l'ajoute manuellement dans le composant de page ou de layout. Sur un site avec beaucoup de pages, on factorise une fonction generateArticleJsonLd ou generateProductJsonLd réutilisable.
Plusieurs blocs par page
Une page peut contenir plusieurs blocs JSON-LD, chacun pour un type différent. Sur une page produit e-commerce, on peut avoir : un Product avec son AggregateRating et ses Reviews, un BreadcrumbList pour le fil d'Ariane, et une Organization sur le footer. Sur une page article : Article, BreadcrumbList, et une FAQPage si l'article contient des questions/réponses structurées. Google lit chaque bloc indépendamment. On évite les blocs redondants ou contradictoires (deux Organization avec des infos différentes), qui peuvent dérouter les moteurs.
Les pièges à éviter
Premier piège : injecter des données qui n'apparaissent pas sur la page visible. Google détecte les balisages trompeurs et peut désindexer la page ou ignorer définitivement le balisage du site. Deuxième piège : les caractères mal échappés (guillemets, retours à la ligne dans une description) qui cassent le JSON et invalident tout le bloc silencieusement. Troisième piège : les valeurs nulles ou undefined non filtrées qui rendent le JSON invalide. Quatrième piège : un balisage qui se met à jour côté client après l'hydratation : Google peut ne pas le voir au premier crawl, on génère donc toujours en SSR ou SSG.
Tester et déployer
Avant chaque mise en production, on valide chaque page type (article, produit, catégorie) avec le Rich Results Test de Google. L'outil indique quels Rich Results sont éligibles et quels champs manquent ou sont invalides. On surveille ensuite dans Search Console le rapport "Améliorations" qui liste les pages avec des balisages cassés en production. Sur un gros site, on automatise la validation en CI : pour chaque PR, on extrait le JSON-LD des pages modifiées et on le passe au validateur. C'est l'assurance qu'une refactorisation ne casse pas silencieusement le SEO enrichi.