Comment implémenter les données structurées pour les FAQ et les articles

La semaine dernière, un client m'appelle, paniqué. Son trafic a chuté de 40 % en trois semaines sur ses pages FAQ. Il a tout vérifié : contenu, maillage, vitesse de chargement. Rien. Il ne comprend pas. Je regarde le code source de sa page FAQ, je vois un balisage FAQPage impeccable, JSON-LD propre, validation sans erreur. Et je lui dis la phrase qu'il ne veut pas entendre : « Ton balisage est parfait. C'est justement ça le problème. »

Depuis le 7 mai 2026, Google a retiré les résultats enrichis FAQ. Le déploiement est complet depuis juin. Des milliers de sites qui avaient mis mille lignes de code pour choper ces accordéons dans les résultats se retrouvent avec... rien. Pas de pénalité, pas de déclassement, juste un retour à la normale. Et une grosse remise en question sur ce qu'on fait vraiment quand on parle de données structurées.

Cet article n'est pas un nième tuto « colle ce code et prie ». Je veux vous montrer ce qui marche encore, ce qui ne marche plus, et surtout pourquoi baliser une FAQ reste utile même quand les résultats enrichis ont disparu.

Pourquoi baliser sa FAQ et ses articles en 2026 (quand les règles ont changé)

Avouons-le : pendant des années, on a balisé des FAQ pour une seule raison. Choper ces accordéons dans les SERP. Un CTR qui grimpe de 15-20 %, une position 0 facile, le jackpot. J'en ai installé sur au moins quarante sites. Sur certains, ça a doublé le trafic organique en deux mois.

Puis mai 2026 est arrivé. Google a annoncé la dépréciation complète des résultats enrichis FAQ. Mon premier réflexe a été : « ok, on déballe tout ». Mauvaise idée. Voilà pourquoi.

Ce qui a changé concrètement

Google n'affiche plus les accordéons FAQ dans les résultats de recherche classiques. Point. Deux exceptions à ma connaissance : certains sites gouvernementaux et de santé, qui gardent un affichage résiduel. Pour les autres, le balisage FAQPage est devenu invisible dans l'interface de recherche.

Est-ce que ça veut dire qu'il faut tout retirer ? Non, et voilà mon raisonnement. Un contenu balisé proprement reste plus facile à ingérer pour les moteurs de réponse IA. ChatGPT, Perplexity, Gemini, ces outils s'appuient sur du texte structuré pour citer leurs sources. Une FAQ balisée en Question/Réponse est exactement ce qu'ils cherchent : une question formulée, une réponse autonome, une relation sémantique claire.

Le balisage Article, lui, n'a pas bougé

Point important que personne ne dit assez fort : Article schema fonctionne toujours. Résultats enrichis avec image, auteur, date de publication, tout reste actif. Si vous ne devez baliser qu'une seule chose sur votre blog, c'est celle-là.

J'ai comparé deux articles identiques sur un même site. Un balisé, l'autre non. En trois mois, l'article balisé a récupéré environ 30 % de clics en plus sur les mêmes positions. Anecdotique ? Peut-être. Mais ça coûte quinze minutes de mise en place, alors bon.

Comment implémenter le balisage FAQPage en JSON-LD

La première fois que j'ai collé du JSON-LD, j'ai oublié une virgule. Le validateur m'a craché une erreur qui m'a pris quarante minutes à comprendre. Donc on va faire simple.

La structure minimale d'un FAQPage

Un FAQPage contient une propriété mainEntity, qui est un tableau de Questions. Chaque Question a un name (le texte de la question) et une acceptedAnswer (la réponse). Voilà ce que ça donne :

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Combien de temps faut-il pour voir des résultats ?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Comptez généralement deux à quatre semaines après indexation."
      }
    },
    {
      "@type": "Question",
      "name": "Le balisage remplace-t-il le contenu visible ?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Non. Le balisage décrit un contenu qui doit être visible sur la page."
      }
    }
  ]
}

Trois règles non négociables : le contenu balisé doit être visible sur la page, vous ne pouvez pas baliser une réponse que vous avez cachée en accordéon JavaScript et qui ne s'affiche jamais, et chaque réponse doit être autonome (compréhensible hors contexte).

Questions qu'on me pose souvent sur le balisage FAQ

Où placer le script JSON-LD ? Dans le <head> si possible. Dans le <body> juste avant la section FAQ si votre CMS ne permet pas de toucher au head. Google lit les deux.

Faut-il baliser toutes les questions d'une page ? Non. Trois à huit questions bien choisies valent mieux que vingt questions fourre-tout. Si une question n'a pas de réponse sérieuse, ne la balisez pas.

Peut-on mettre plusieurs types de schémas sur une même page ? Oui, et c'est même recommandé. Une page article avec une section FAQ en bas peut parfaitement avoir un Article + un FAQPage + un BreadcrumbList. En JSON-LD, vous utilisez soit un tableau avec plusieurs objets, soit un objet unique avec un tableau @graph.

Implémenter le balisage Article (celui qui rapporte encore)

Le balisage Article est plus technique qu'il n'y paraît. Pas dans la syntaxe, dans les détails. Une date de publication mal formatée, un auteur en texte brut au lieu d'un objet Person, une image manquante : le validateur passe parfois, mais Google ignore le balisage.

Les propriétés qui comptent vraiment

Vous n'avez pas besoin des trente propriétés disponibles. Voici celles qui font la différence :

• headline : le titre de l'article. Maximum 110 caractères, sinon il est tronqué.
• author : un objet Person avec name et, si possible, url vers une page auteur.
• datePublished : au format ISO 8601, avec le fuseau horaire. Pas « 12 mars 2026 ».
• dateModified : la date de dernière modification réelle. Si vous la bidouillez tous les jours sans rien changer, ça finit par se voir.
• image : une URL absolue, dimensions 1200px minimum en largeur pour les gros résultats enrichis.
• publisher : un objet Organization avec name et logo.
• mainEntityOfPage : l'URL canonique de l'article.

Un client avait mis son datePublished au format « 15/03/2026 ». Le balisage était syntaxiquement valide, mais Google ne l'affichait pas. Trois semaines perdues à chercher pourquoi. Format ISO, toujours.

Combiner Article et FAQ sur une même page

Quand vous mettez une FAQ en bas d'un article (ce qui est une excellente pratique éditoriale, indépendamment du SEO), vous voulez baliser les deux. Voilà une structure qui fonctionne, avec @graph :

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Article",
      "headline": "Votre titre",
      "author": { "@type": "Person", "name": "Prénom Nom" },
      "datePublished": "2026-03-15T10:00:00+01:00",
      "image": "https://exemple.com/image.jpg",
      "publisher": {
        "@type": "Organization",
        "name": "Votre site",
        "logo": { "@type": "ImageObject", "url": "https://exemple.com/logo.png" }
      }
    },
    {
      "@type": "FAQPage",
      "mainEntity": [
        {
          "@type": "Question",
          "name": "Votre question ?",
          "acceptedAnswer": { "@type": "Answer", "text": "Votre réponse." }
        }
      ]
    }
  ]
}

Un détail qui change tout : le FAQPage doit décrire des questions qui existent réellement et visuellement sur la page. Si vous balisez une FAQ que vous n'avez pas affichée, ça s'appelle du balisage trompeur. Google n'aime pas. Et il le détecte.

Les erreurs qui annulent tous les bénéfices

Je les ai toutes faites. Une par une. Voici la liste, pour que vous ne perdiez pas les mêmes soirées que moi.

• Contenu masqué non visible — vous balisez une réponse que l'utilisateur ne peut voir qu'après trois clics. Non.
• Balisage qui ne correspond pas au contenu — le title du JSON-LD ne matche pas le H1. Google ignore.
• Duplication — deux blocs FAQPage sur la même page, ou un FAQPage en plus d'un QAPage sur la même question.
• Dates incohérentes — dateModified antérieure à datePublished. Erreur bête, éliminatoire.
• URLs relatives — les propriétés image, url, logo doivent être absolues (https://…).
• Balises dans du texte balisé — mettre <strong> dans la valeur de text d'une réponse. À éviter, préférez du texte brut.
• Oublier de valider après chaque modif — un CMS mal configuré peut casser un JSON-LD fonctionnel en une mise à jour.

Comparatif rapide des schémas utiles en 2026

Schéma	Résultats enrichis actifs ?	Utilité résiduelle
FAQPage	Non (sauf exceptions santé/gouvernement)	Moteurs de réponse IA, structuration sémantique
QAPage	Partiel	Forums, pages de questions communautaires
Article	Oui	Image, auteur, date dans les résultats
BreadcrumbList	Oui	Fil d'Ariane dans l'URL affichée
HowTo	Très limité	Structuration de tutoriels pour ingestion IA

Valider, puis mesurer (la partie que tout le monde saute)

Vous avez collé le code. Il valide. Bravo. Maintenant, est-ce que ça sert à quelque chose ?

Les outils de validation

Deux obligatoires : le test des résultats enrichis de Google, et le validateur Schema.org. Le premier vous dit si Google peut extraire quelque chose, le second valide la syntaxe structurée. Utilisez les deux, toujours. Ils ne disent pas la même chose.

Ajoutez la Search Console. La section « Améliorations » liste les schémas détectés et les éventuelles erreurs. C'est là que vous voyez, sur plusieurs semaines, si un balisage est réellement exploité ou juste ingéré passivement.

Comment mesurer l'impact réel

Franchement, c'est là que la plupart des articles s'arrêtent. Moi-même j'ai longtemps balisé puis oublié. Ce qui m'a fait changer : segmenter le CTR des pages balisées vs non balisées sur des requêtes comparables. Sur un blog tech que je suis, les pages avec Article correct ont environ 12 % de CTR en plus sur les mêmes positions. Pas fou. Mais gratuit.

Pour le FAQPage post-mai 2026, la mesure pertinente n'est plus le CTR Google. C'est le trafic référent depuis les IA conversationnelles. Regardez vos logs serveur : les user-agents ChatGPT, Perplexity, Claude apparaissent de plus en plus. Si vos FAQ balisées sont citées, vous le verrez là. Pas dans la Search Console.

Ce qu'il faut vraiment retenir

Baliser une FAQ en 2026, c'est préparer le terrain pour les moteurs de réponse, pas pour Google. C'est un investissement sur la prochaine vague, pas sur la précédente. Ça ne coûte presque rien, ça reste sémantiquement propre, et le jour où les règles bougent à nouveau (elles bougeront), vous serez déjà structuré.

Quant au balisage Article, il n'a jamais été aussi rentable. Faites-le correctement une fois, et n'y touchez plus, sauf pour mettre à jour les dates réelles.

La vraie question que je me pose aujourd'hui, et que je vous laisse : si les moteurs de réponse IA deviennent la principale porte d'entrée vers votre contenu, est-ce que votre balisage parle leur langue, ou est-ce qu'il parle encore celle de 2019 ?