Injecter du JSON-LD dans l’App Router de Next.js avec un Server Component

La méthode la plus fiable pour injecter du JSON-LD avec l’App Router consiste à générer directement une balise `<script type="application/ld+json">` dans un Server Component. Les données structurées figurent alors dans le HTML initial renvoyé par le serveur, ce qui permet aux robots d’exploration des IA de les lire sans exécuter JavaScript. À l’inverse, le JSON-LD ajouté après coup avec useEffect ou Google Tag Manager est pratiquement invisible pour les moteurs de réponse : la plupart terminent leur exploration et quittent la page sans attendre son hydratation.

Pourquoi faut-il générer le JSON-LD côté serveur ?

Tout est une question de timing. Dès la requête, le Server Component inscrit le JSON-LD dans la chaîne HTML. Le premier fichier récupéré par des robots comme GPTBot, ClaudeBot, PerplexityBot ou Google-Extended contient donc le schéma complet. Une injection côté client suppose en revanche que le navigateur télécharge puis exécute votre bundle, une étape que la plupart des robots d’exploration des IA n’effectuent pas. Un piège peut fausser le diagnostic : le test des résultats enrichis de Google exécute JavaScript. Les données injectées côté client y semblent donc parfaitement normales et vous pouvez croire la validation acquise. Pourtant, lorsqu’un moteur de réponse consulte réellement la page, il récupère souvent le HTML source non rendu, dépourvu de tout schéma. Dans les audits techniques que nous réalisons pour nos clients, c’est l’un des défauts les plus fréquents et les plus faciles à manquer.

Exemple minimal viable : une seule page page.tsx

L’implémentation tient en peu de code. Aucun package supplémentaire ni aucune route API ne sont nécessaires : tout se passe dans le Server Component qui affiche l’article. Trois opérations suffisent : récupérer les données, regrouper les objets et générer la balise script.

1. Dans `app/blog/[slug]/page.tsx`, qui est un Server Component par défaut, utilisez d’abord `await` pour récupérer les données de l’article.
2. Construisez un objet JavaScript simple nommé `jsonLd`. Commencez par `"@context": "https://schema.org"` et `"@type": "Article"`, puis renseignez dynamiquement les autres propriétés — headline, datePublished, author et image — à partir des données de l’article.
3. Placez au début du JSX renvoyé : `<script type="application/ld+json" dangerouslySetInnerHTML={{ __html: JSON.stringify(jsonLd).replace(/</g, "\\u003c") }} />`.
4. N’importez aucune bibliothèque côté client et n’ajoutez pas `"use client"` en tête du fichier. Dans ce dernier cas, le composant devient un Client Component et tout le bénéfice de cette mise en œuvre disparaît.

Relier plusieurs entités avec @graph

Une page a généralement besoin de plusieurs schémas : Organization pour la marque, Article pour le contenu, BreadcrumbList pour le fil d’Ariane et FAQPage pour la foire aux questions. Plutôt que de générer quatre balises script indépendantes, il est plus propre de réunir ces entités dans le tableau `@graph` d’un même objet JSON-LD, puis de les relier au moyen de `@id`. Vous pouvez, par exemple, faire pointer la propriété `publisher` d’Article vers le `@id` d’Organization, et le dernier élément de BreadcrumbList vers le `@id` de la page courante. Le moteur de réponse obtient ainsi, en une seule analyse, une représentation complète des relations entre les entités, avec moins de risques de rencontrer des nœuds contradictoires ou dupliqués.

• Organization et WebSite : placez-les dans `app/layout.tsx` afin de les partager une seule fois sur l’ensemble du site. Ne les redéclarez pas sur chaque page.
• Article ou BlogPosting : placez-le dans le fichier `page.tsx` de l’article et renseignez dynamiquement ses propriétés avec les données de la page courante.
• BreadcrumbList : construisez-le selon la hiérarchie des routes. Il aide tout particulièrement les IA à comprendre l’architecture du site.
• FAQPage : ne l’ajoutez que si la page comporte réellement une section de questions-réponses. Le texte de `acceptedAnswer` doit correspondre au contenu visible. Ne créez pas une fausse FAQ uniquement pour disposer de ce schéma.

Rendre le JSON-LD facile à maintenir

Si les objets de schéma sont dispersés dans toutes les pages, plus personne n’osera les modifier trois mois plus tard. Notre approche consiste à les centraliser dans `lib/schema.ts` et à utiliser les types de `schema-dts` (`import type { Article, WithContext } from "schema-dts"`) pour contraindre la valeur renvoyée par chaque fonction de génération. En cas de nom de propriété ou de type incorrect, TypeScript signale l’erreur dès la compilation. La page se contente d’appeler `buildArticleSchema(post)`, de récupérer un objet typé de manière sûre, puis de le générer. Toute modification s’applique ainsi à l’ensemble du site. Les URL sont toujours absolues et centralisées dans une constante `SITE_URL`, afin d’éviter que les `@id` ne divergent entre le site officiel et le domaine de prévisualisation.

Erreurs fréquentes et vérifications avant la mise en ligne

• Les valeurs `url`, `image` ou `datePublished` du JSON-LD ne correspondent pas au contenu réellement affiché. Le moteur de réponse repère cette incohérence, ce qui réduit la fiabilité perçue de toute la page.
• L’utilisation de chemins relatifs dans `@id` ou `url` peut les faire pointer vers le mauvais emplacement dès que vous passez sur le domaine de prévisualisation.
• Vous avez oublié d’échapper `<` ou ajouté par inadvertance `"use client"` en tête de la page, ce qui repousse la génération de la balise script côté client.
• Avant la mise en ligne, vérifiez la syntaxe avec le test des résultats enrichis de Google, puis récupérez directement le HTML source de la page avec `curl`. Vous pourrez ainsi confirmer que la balise script figure bien dans la réponse initiale et pas uniquement dans les DevTools du navigateur. Cette vérification est décisive, car elle reproduit exactement ce que voit le robot d’exploration de l’IA.

Sur les sites que nous avons audités, le principal problème ne vient généralement pas d’un schéma mal rédigé, mais d’un JSON-LD uniquement présent côté client. S’il n’apparaît pas dans le HTML renvoyé par le serveur, l’IA le considère comme inexistant.— Tenten GEO Technical Audit

De l’implémentation à la citation comme source

Déplacer le JSON-LD dans un Server Component constitue le minimum requis pour rendre un contenu « lisible par les machines ». Il faut ensuite harmoniser la dénomination des entités, le maillage interne et les informations publiées d’une page à l’autre, afin que les IA puissent vous citer durablement comme une source fiable. Si vous ignorez si les données structurées de votre site figurent bien dans le HTML consulté par les robots, vous pouvez prendre rendez-vous pour un diagnostic GEO de 30 minutes. Nous analyserons le code source réellement récupéré afin d’identifier les lacunes, au lieu de nous limiter à la page rendue à l’écran.