Google ne garantit aucun affichage particulier pour les données structurées : voyez-les comme un étiquetage, pas comme une tactique de croissance. Cet étiquetage mérite pourtant une heure sur un petit site. Un seul bloc dans un gabarit indique ce qu’est chaque page, qui la publie et où elle se situe dans le site, sous une forme qu’une machine lit sans avoir à deviner.
Ce qu’un petit site de contenu doit baliser
Google recommande le JSON-LD, un bloc de JSON placé dans un élément <script type="application/ld+json">, plutôt qu’un balisage mêlé au HTML. Ses consignes générales ajoutent trois limites qui conditionnent tout ce qui suit : le balisage doit décrire un contenu que les visiteurs peuvent réellement voir sur la page, rien ne garantit qu’un balisage produise un résultat enrichi, et une violation peut entraîner une action manuelle, qui retire à la page son éligibilité aux résultats enrichis.
Dans ces limites, un petit éditeur de site a besoin de peu de types. Nous recommandons un Organization et un WebSite une seule fois par site, un Person pour le rédacteur si une vraie personne se tient derrière le site, un Article sur chaque guide ou billet, et un BreadcrumbList partout où la page affiche un fil d’Ariane. Relier les nœuds par des références @id au lieu de répéter leur contenu garde une seule définition de chaque entité dans un unique @graph : le nom de l’éditeur ne peut donc jamais différer d’un nœud à l’autre.
Voici ce que portent nos propres pages. Chaque page livre des nœuds WebSite, Organization et Person. Les guides ajoutent Article et BreadcrumbList, ainsi qu’un FAQPage quand le guide affiche un bloc FAQ visible. Les pages d’outils ajoutent un nœud WebApplication avec un nom, une URL, une catégorie et une Offer au prix de 0, puisque les outils sont gratuits. Nous n’y ajoutons aucune note, faute d’avis à afficher. Le tout tient dans un seul élément script généré par le gabarit de page, personne n’a donc à penser à le coller.
Un graphe à copier
Le bloc ci-dessous est le modèle, avec des valeurs d’exemple. Remplacez example.com, les noms, les dates et la langue. Toutes les URL sont absolues, les dates suivent la norme ISO 8601, et les valeurs @id sont des URL avec un fragment, pour ne jamais entrer en collision avec une vraie page.
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "WebSite",
"@id": "https://example.com/#website",
"url": "https://example.com/",
"name": "Site d'exemple",
"inLanguage": "fr",
"publisher": { "@id": "https://example.com/#org" }
},
{
"@type": "Organization",
"@id": "https://example.com/#org",
"name": "Site d'exemple",
"url": "https://example.com/",
"logo": {
"@type": "ImageObject",
"url": "https://example.com/logo-512.png",
"width": 512,
"height": 512
},
"founder": { "@id": "https://example.com/#editor" }
},
{
"@type": "Person",
"@id": "https://example.com/#editor",
"name": "Camille Martin",
"jobTitle": "Ingénieur réseaux",
"sameAs": ["https://www.linkedin.com/in/example-editor/"],
"worksFor": { "@id": "https://example.com/#org" }
},
{
"@type": "Article",
"@id": "https://example.com/guides/my-guide/#article",
"headline": "Titre de mon guide",
"description": "Une phrase qui correspond à la méta-description.",
"image": ["https://example.com/og/my-guide-fr.jpg"],
"datePublished": "2026-10-30T00:00:00.000Z",
"dateModified": "2026-10-30T00:00:00.000Z",
"inLanguage": "fr",
"author": { "@id": "https://example.com/#editor" },
"publisher": { "@id": "https://example.com/#org" },
"mainEntityOfPage": { "@id": "https://example.com/guides/my-guide/" }
},
{
"@type": "BreadcrumbList",
"itemListElement": [
{ "@type": "ListItem", "position": 1, "name": "Accueil", "item": "https://example.com/" },
{ "@type": "ListItem", "position": 2, "name": "Guides", "item": "https://example.com/guides/" },
{ "@type": "ListItem", "position": 3, "name": "SEO technique", "item": "https://example.com/guides/category/technical/" },
{ "@type": "ListItem", "position": 4, "name": "Titre de mon guide", "item": "https://example.com/guides/my-guide/" }
]
}
]
}Quelques remarques sur les champs qui tournent le plus souvent mal. headline doit correspondre au H1 visible (la structure des titres explique pourquoi cette ligne compte deux fois). image est l’URL absolue d’un vrai fichier ; nos images de partage font 1200 par 630 pixels, et le guide SEO des images traite le reste du volet image. Faites pointer author vers une personne qui signe réellement la page : les consignes de Google sur le contenu utile demandent des informations d’auteur claires, sans qualifications ni profils inventés, et le guide E-E-A-T détaille ce que cela veut dire en pratique. Supprimez sameAs si vous n’avez aucun profil public à lier. Ne modifiez dateModified que lorsque le contenu a changé.
Balisage FAQ : ce qu’il fait aujourd’hui
Depuis 2023, Google n’affiche les résultats enrichis FAQ que pour des sites gouvernementaux et de santé bien connus. Il a retiré sa documentation sur les données structurées FAQ en 2025. Sur un site comme le vôtre ou le nôtre, un balisage FAQPage ne produira pas de questions dépliables sous le résultat de recherche, et les conseils qui les promettent aux sites ordinaires datent d’avant ce changement.
Le balisage reste valide et d’autres systèmes peuvent encore le lire, ce qui est la seule raison pour laquelle nous l’émettons sur les guides qui affichent un bloc FAQ. Si vous le gardez ou l’ajoutez, les règles qui comptent n’ont pas changé : les questions et les réponses doivent être visibles sur la page, avec les mêmes mots que dans le balisage, et écrites d’abord pour les lecteurs.
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "Le vérificateur est-il gratuit ?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Oui. Il est gratuit et ne demande aucun compte."
}
}
]
}Notre recommandation : ne passez pas de temps sur ce type. Si la FAQ aide les lecteurs, mettez-la sur la page pour eux et laissez le balisage découler du gabarit. Si vous hésitez entre une heure sur le balisage FAQ et une heure sur la justesse d’Article et de BreadcrumbList, prenez la seconde.
Ce qu’il ne faut pas baliser
La consigne de Google est que le balisage doit refléter ce qui se trouve sur la page, et les fautes en découlent. Ne balisez pas un texte que les visiteurs ne voient pas, comme du contenu masqué par CSS ou placé uniquement dans le balisage. Ne balisez pas des questions que la page n’affiche pas. Ne publiez pas un auteur qui n’existe pas, ni des diplômes que personne ne détient. N’ajoutez pas de notes ou d’avis que vous n’affichez pas, et n’ajoutez pas de balisage Product à une page qui ne vend rien. Ne copiez pas un modèle d’un autre site sans remplacer chaque URL et chaque date : un graphe qui pointe vers les pages d’un autre est pire que pas de graphe du tout.
La politique de Google décrit la sanction comme une action manuelle, qui coûte à la page son éligibilité aux résultats enrichis. Quel que soit le type, le risque ne vaut pas la peine pour un balisage qui n’ajoute rien de ce qu’un lecteur peut voir.
Le générer à partir des données qui produisent la page
Le moyen le plus fiable de garder le balisage et la page d’accord est de construire les deux à partir de la même source. Sur ce site, le titre, la description et la date de publication d’un guide viennent de l’en-tête (le frontmatter) du fichier Markdown, et le gabarit lit ces mêmes champs pour afficher le titre visible et remplir headline, description et datePublished. Les éléments du fil d’Ariane viennent des mêmes fonctions de chemin que le fil d’Ariane visible. Personne ne modifie le JSON-LD à la main : il ne peut donc pas décrire une ancienne version de la page.
Si votre site tourne sur un CMS, cherchez le réglage ou le gabarit qui produit le graphe, et vérifiez ce qu’il fait quand vous changez un titre. Si vous écrivez du HTML statique, placez l’élément script dans la mise en page commune et alimentez-le avec des variables. L’échec à éviter est le bloc collé à la main qui était juste en janvier et décrit une page renommée depuis.
Le tester avant et après la mise en ligne
Collez l’URL de la page ou le code dans le test des résultats enrichis de Google (Rich Results Test). Il indique les types qu’il reconnaît comme éligibles et signale les propriétés obligatoires manquantes. Les types non éligibles à un résultat enrichi peuvent simplement ne pas apparaître : le test seul ne prouve donc pas que chaque nœud de votre graphe est correct.
Pour cela, contrôlez deux choses vous-même. D’abord, que le JSON se lit sans erreur : enregistrez le bloc sous schema.json et passez-le dans la commande d’une ligne ci-dessous, qui n’affiche un message que si le JSON est valide. Ensuite, que le balisage est bien arrivé dans la page déployée : affichez le code source de l’URL en ligne et cherchez ld+json, car il arrive qu’un gabarit abandonne le bloc sur un type de page. Notre vérificateur SEO fait les deux sur une URL en ligne : son contrôle JSON-LD récupère la page, analyse chaque bloc, indique combien sont valides ou cassés, et liste les types trouvés.
node -e "JSON.parse(require('fs').readFileSync('schema.json','utf8')); console.log('valid JSON')"Réponses rapides
Dois-je retirer le balisage FAQPage que j'ai déjà ?
Rien ne presse. Le balisage reste lisible par d'autres systèmes, et tant que les questions et les réponses sont visibles sur la page et identiques au balisage, il ne fait pas de mal. Ce que nous cesserions de faire, c'est de l'ajouter dans l'espoir d'obtenir un résultat enrichi.
Où placer le JSON-LD : dans le head ou dans le body ?
Les deux fonctionnent. Nous mettons un seul élément script dans le head, généré par le gabarit de la page, pour que le balisage parte toujours avec la page qu'il décrit.
Faut-il un type plus précis qu'Article pour un guide ?
Article suffit pour un guide ou un tutoriel. Des types plus précis existent, mais nous utilisons le type simple : la précision supplémentaire n'apporte aucun affichage que nous puissions vérifier, et un graphe plus simple est plus facile à garder juste.
