Données structurées : Article, FAQPage et BreadcrumbList sur un site généré

Les données structurées ne font pas monter une page dans le classement. Elles rendent son contenu interprétable sans ambiguïté, ce qui conditionne l'affichage enrichi et, de plus en plus, la reprise du contenu par les systèmes de réponse automatique.

JSON-LD, et rien d'autre

Trois syntaxes existent — JSON-LD, Microdata, RDFa. Sur un site généré, seule la première est raisonnable : le balisage vit dans un bloc <script> séparé du HTML de présentation. Le gabarit visuel peut donc évoluer sans casser le balisage, et l'inverse.

Les trois types qui comptent sur un blog programmatique

BlogPosting (ou Article)

Décrit la page elle-même : titre, description, dates, auteur, éditeur, langue, image. Les deux champs les plus souvent mal renseignés sont dateModified — qui doit refléter une modification réelle du contenu — et author, qui sur un contenu généré doit être l'organisation, jamais une personne fictive.

BreadcrumbList

C'est le type le plus rentable sur un site programmatique, et le plus négligé. Il transmet la hiérarchie logique de la page indépendamment du chemin d'URL — ce qui rend viable la structure d'URL plate recommandée sur ces projets.

FAQPage

À réserver aux pages qui contiennent réellement une section de questions-réponses visible pour l'utilisateur. Le balisage doit décrire ce qui est affiché, jamais un contenu masqué ou absent.

Un graphe unique plutôt que trois blocs

Plutôt que d'empiler trois balises script indépendantes, un seul graphe relié est plus propre et plus facile à valider :

{
  "@context": "https://schema.org",
  "@graph": [
    { "@type": "BlogPosting", "@id": "…/blog/slug#article", … },
    { "@type": "BreadcrumbList", "itemListElement": [ … ] },
    { "@type": "FAQPage", "@id": "…/blog/slug#faq", "mainEntity": [ … ] }
  ]
}

Les @id permettent de référencer les entités entre elles sans duplication, ce qui devient utile dès qu'on ajoute une Organization partagée par tout le site.

Cinq pièges qui invalident un lot entier

1. Balisage sans correspondance visible. Une FAQ balisée mais absente de la page est une non-conformité franche.
2. Dates en format libre. Le format ISO 8601 est requis : 2026-08-19. Une date localisée casse le parsing silencieusement.
3. Caractères non échappés. Un guillemet droit ou une balise HTML dans un champ texte rend le JSON invalide — et un JSON invalide est ignoré en bloc, pas partiellement.
4. URLs relatives. Tous les champs url, @id et image doivent être absolus.
5. Champ manquant sur une partie du lot. Une variable vide dans le gabarit produit "headline": "", ce qui invalide l'entité sans erreur visible.

Valider à l'échelle, pas à l'unité

Tester trois pages dans un outil de validation en ligne ne dit rien d'un lot de 1 000. La validation doit être intégrée à la génération :

# à la génération, pour chaque page
assert json.loads(bloc_jsonld)              # JSON parsable
assert tous_champs_requis_non_vides(entite) # pas de valeur vide
assert toutes_urls_absolues(entite)         # pas de chemin relatif
assert faq_balisee == faq_affichee          # correspondance visible

Le quatrième contrôle est le plus important et le plus facile à oublier : il garantit que le balisage décrit bien ce que l'utilisateur voit. Le reste de la structure de page est traité dans l'article sur les balises Hn.