L’intérêt des données structurées pour les FAQ et les articles de blog

Un client m'a envoyé un mail furieux l'an dernier : « Le bloc FAQ de mon site a disparu de Google. Vous m'avez vendu un truc qui coûte de l'argent et qui ne sert plus à rien. » Il avait raison sur un point, tort sur trois autres. Son balisage FAQ affichait effectivement un résultat enrichi depuis des années — sauf que depuis août 2023, Google a restreint ces rich results aux sites de santé et aux sites gouvernementaux. Son site de conseil en recrutement n'aurait jamais dû en bénéficier aussi longtemps ; c'était un reste de l'ancien monde.

Ce qui m'intéresse aujourd'hui avec les données structurées pour les FAQ et les articles de blog, ce n'est plus le petit bloc qui s'affiche sous le titre. C'est ce que le balisage fait quand personne ne le regarde : il décrit vos contenus à des machines qui, elles, n'ont plus seulement besoin du titre et de l'URL pour décider quoi citer. Et c'est là que la plupart des sites que j'audite se plantent, avec une conviction tranquille.

Données structurées pour les FAQ et articles de blog : ce qui se joue vraiment sous le capot

Prenons un article de 1 200 mots sur la mutuelle santé. Sans balisage, Google lit une page HTML et en déduit le sujet à partir du texte, des liens, du maillage. Avec un schéma Article correctement renseigné, il sait que la page est un article, qui l'a écrit, quand il a été publié, quelle est l'image principale, et de quoi parle l'article via son about et son mainEntity.

La différence n'est pas cosmétique. Elle porte sur la confiance accordée à la source et sur la capacité du moteur à extraire une réponse sans avoir à la reformuler lui-même. Sur un site d'information médicale que j'ai suivi pendant deux ans, l'ajout d'un balisage auteur complet (Person avec sameAs vers ses profils vérifiables) a coïncidé avec une hausse sensible des citations dans les réponses génératives — sur les requêtes où le nom du journaliste apparaissait dans la question. Corrélation, pas causalité absolue, mais le lien est logique : quand on demande « qu'est-ce que pense X de Y », le moteur a besoin d'une entité nommée.

FAQPage et Article : deux schémas sur une même page, est-ce permis ?

Oui. Et c'est même ce que je recommande sur un article de blog qui comporte une section questions-réponses en bas de page. La structure ressemble à ceci : un BlogPosting qui déclare un mainEntity de type FAQPage, lui-même contenant une liste de Question et de Answer. Google accepte cette imbrication ; il la valide sans rechigner, à condition que le contenu balisé soit réellement visible sur la page.

C'est là que j'ai vu le plus de dégâts. Une agence avait balisé 14 questions sur une page qui n'en affichait que 6. Le code était propre, le validateur souriait, la conformité aux règles était nulle. Aucune sanction visible à court terme, mais aucune chance non plus que ces données soient exploitées.

Ce que Google fait désormais des rich results FAQ

Depuis l'été 2023, les résultats enrichis FAQ sont réservés aux sites gouvernementaux et de santé faisant autorité. Point. Cela a changé beaucoup de choses dans mon quotidien de consultant, et notamment une conversation récurrente :

• « Mais alors à quoi bon baliser une FAQ ? » Parce que le balisage décrit du contenu, et que cette description sert à d'autres systèmes que le simple encadré dans les résultats.
• « Est-ce que je perds quelque chose à retirer le balisage ? » Sur un site marchand, probablement rien. Sur un site de contenu qui joue sa place dans les réponses IA, oui.
• « Est-ce que ça a un impact sur le référencement naturel classique ? » Marginal, mais réel sur la cohérence sémantique.
• Une erreur courante : croire que le balisage est un levier isolé. Il fonctionne en système avec le contenu, les liens internes, la qualité d'écriture.

Article : le balisage qui change vraiment la donne sur un blog

Le schéma BlogPosting (variante d'Article) est celui que je vois le plus souvent mal renseigné. Pas absent — mal renseigné. Et un balisage à moitié faux est parfois pire que pas de balisage du tout, parce qu'il envoie un signal contradictoire.

Les champs que je vérifie en priorité

Sur chaque audit, je passe en revue trois zones :

1. headline : souvent tronqué par un CMS mal configuré, avec un tiret et un suffixe de marque collés dedans.
2. datePublished et dateModified : le premier indique quand l'article a été écrit, le second quand il a été mis à jour. J'ai vu des sites qui renseignaient datePublished à chaque republication, ce qui donne l'impression d'un contenu tout neuf en permanence — un signal que Google peut interpréter comme un comportement spammy.
3. author : un nom en texte libre ne suffit pas. Je préfère un Person complet, avec url et sameAs vers les pages de profil externes. C'est ce qui construit l'entité auteur sur le long terme.
4. image : une image principale déclarée, avec dimensions cohérentes, et accessible. Une image cassée invalide tout le schéma.
5. mainEntityOfPage : le lien canonique de la page. Une omission fréquente, qui casse la cohérence sur les sites multi-domaines.

Un détail que j'ai mis deux ans à comprendre, à mes dépens : le balisage ne rattrape pas un mauvais contenu. J'ai travaillé avec un site qui avait investi plusieurs mois sur le sujet, avec un code exemplaire, mais dont les articles étaient générés à la chaîne et sans valeur ajoutée. Le résultat a été nul. C'est une évidence énoncée partout et vérifiée dans la vraie vie : les données structurées amplifient ce qui existe, elles ne créent rien.

Un exemple concret de balisage FAQ imbriqué dans un article

Voici la structure que je déploie sur les blogs clients qui proposent une vraie section FAQ en bas d'article. Elle est volontairement simplifiée et je l'utilise quasi telle quelle.

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "Titre réel de l'article",
  "datePublished": "2025-03-12",
  "dateModified": "2026-01-08",
  "author": { "@type": "Person", "name": "Prénom Nom", "url": "https://exemple.fr/auteur/prenom-nom" },
  "mainEntity": {
    "@type": "FAQPage",
    "mainEntity": [
      { "@type": "Question", "name": "Une question visible dans le texte ?", "acceptedAnswer": { "@type": "Answer", "text": "La réponse exacte affichée." } }
    ]
  }
}

Deux règles d'hygiène. Première : chaque question balisée doit apparaître à l'identique dans le HTML visible. Deuxième : ne remplissez jamais dateModified si vous n'avez rien modifié de fond — le mettre à jour pour dater le crawl est une pratique qui finit par se retourner contre vous.

Balisage manuel ou générateur ?

Critère	Balisage manuel (JSON-LD écrit à la main)	Extension / plugin générateur	Génération automatique par le CMS
Contrôle de la précision	Total	Partiel, selon le plugin	Faible à moyen
Risque d'incohérence (auteur, dates)	Faible si discipline	Moyen	Élevé
Effort de mise en place	Élevé au départ, faible ensuite	Faible	Nul
Capacité à imbriquer un FAQPage dans un BlogPosting	Immédiate	Souvent limitée	Rarement supportée nativement
Maintenance dans le temps	Manuelle, mais lisible	Dépend du mainteneur du plugin	Dépend de la roadmap de l'éditeur

Pour un blog individuel, je recommande généralement le balisage manuel sur les articles à fort enjeu (5 à 10 par an), et un plugin pour le reste. C'est un compromis pragmatique, pas une position idéologique.

Les erreurs de balisage que je vois le plus souvent

Un audit rapide sur une vingtaine de sites, c'est le même constat chaque fois : environ trois quarts des schémas inspectés comportent au moins une erreur détectable. Et les erreurs sont presque toutes les mêmes.

• Une FAQ balisée qui n'apparaît pas dans le texte visible (ou dont le texte balisé diffère du texte affiché).
• Un author qui pointe vers une page qui renvoie une 404.
• Des dates incohérentes : dateModified antérieur à datePublished.
• Un Article déclaré sur une page de liste, sans contenu éditorial.
• Un même schéma répété deux fois sur la même page (souvent : CMS + plugin).

Le problème n'est pas que ces erreurs soient graves prises isolément. C'est qu'elles s'accumulent sans alerte. Le site continue de fonctionner, les visiteurs arrivent, et l'on ne voit pas ce qu'on perd.

Données structurées et IA générative : le vrai enjeu de 2026

Le basculement, je l'ai vu sur mes propres sites. Depuis un an environ, une part non négligeable des visites provient de moteurs conversationnels qui répondent directement à la question sans passer par la page. Sur un blog technique que je gère, c'est passé de quelque chose comme 2 % des sessions à plus du double en dix-huit mois. Et cette part continue de croître.

Ce que ces moteurs cherchent, c'est de la matière fiable, structurée, attribuable. Une page qui déclare clairement son auteur, ses dates, son sujet, ses sous-questions, a un avantage mécanique : elle est plus facile à extraire, à citer, à relier à d'autres entités. Une page qui ne déclare rien repose sur la seule qualité du texte brut — ce qui marche parfois, mais qui est bien plus fragile.

Autrement dit : le balisage FAQ et Article n'est plus un levier pour obtenir un joli bloc dans les résultats Google. C'est devenu une infrastructure de lisibilité pour un ensemble de systèmes qui ne sont plus seulement Google.

Faut-il baliser toutes les questions d'une FAQ ?

Non. Balisez uniquement les questions qui ont une vraie valeur informative et une réponse complète et autonome sur la page. Une question dont la réponse tient en cinq mots vagues n'apporte rien, et une accumulation de micro-questions dégrade la qualité perçue du balisage. Je limite généralement à cinq ou six questions par article, sur les points qui reviennent le plus souvent dans les mails clients.

Quel impact sur le référencement naturel classique ?

Marginal mais réel, sur trois points : la cohérence sémantique (le balisage force à nommer clairement le sujet), la qualité des métadonnées affichées dans les résultats (dates, auteur), et la robustesse face aux évolutions des moteurs. En revanche, un balisage seul ne fera pas remonter un article de la dixième à la première position. Il ne compense ni une intention de recherche mal ciblée, ni un contenu faible.

Ce que je dis souvent à mes clients : le balisage est un multiplicateur. Il multiplie une bonne base. Il ne crée pas de base à partir de rien.

Reste une question que je n'arrive pas encore à trancher, et que je pose à quiconque prétend avoir la réponse : dans deux ans, la part des contenus structurés et attribuables dans les réponses génératives sera-t-elle si déterminante que les sites non balisés seront simplement invisibles sur ces canaux ? Je n'en sais rien. Mais je vois de plus en plus de sites où le trafic direct baisse pendant que les citations augmentent, et où personne ne sait mesurer ce basculement. C'est peut-être là que se joue la vraie question : non pas comment apparaître dans un bloc FAQ, mais comment rester une source que les machines savent citer.