Les données structurées peuvent aider les systèmes de recherche à interpréter les pages éligibles et soutenir des éléments comme les étoiles d'évaluation, les fils d'Ariane ou les cartes d'articles. Elles donnent aussi aux systèmes d'IA un contexte lisible par machine, sans garantir de citation. Dans l'App Router, rendez le JSON-LD sous forme de balise script depuis un composant serveur (typé par schema-dts) :
import type { WithContext, BlogPosting } from "schema-dts";
export default async function PostPage({ params }) {
const post = await getPost(params.slug);
const jsonLd: WithContext<BlogPosting> = {
"@context": "https://schema.org",
"@type": "BlogPosting",
headline: post.title,
description: post.excerpt,
datePublished: post.publishedAt,
dateModified: post.updatedAt,
author: {
"@type": "Person",
name: "Vlad Sedenko",
url: "https://example.com/about",
},
image: post.ogImage,
};
return (
<>
<script
type="application/ld+json"
dangerouslySetInnerHTML={{ __html: JSON.stringify(jsonLd) }}
/>
<article>{/* ... */}</article>
</>
);
}
Les types courants à envisager, selon la page :
Organization/Person: pour tout le site, dans le layout racine. Alimente le Knowledge Panel.BlogPosting/Article: chaque article.BreadcrumbList: remplace l'URL dans les résultats par un chemin lisible.FAQPage: pour les pages avec de vraies questions et réponses.Product+Offer+AggregateRating: e-commerce ; c'est de là que viennent les étoiles.Service+LocalBusiness: agences et entreprises locales.
Validez avec le Rich Results Test de Google : le validateur schema.org vérifie la syntaxe, mais seul l'outil de Google dit si vous êtes éligible aux résultats enrichis.
Checklist :
- JSON-LD rendu côté serveur (jamais injecté côté client après le chargement)
- Article/BlogPosting sur tous les articles avec de vraies dates
- BreadcrumbList sur tout le site
- Les données du balisage correspondent à la page visible (les écarts exposent à une action manuelle)
