Guide

Structured data avancé pour SaaS B2B : la stack qui ranke en 2026

11 min de lecture

Les données structurées en JSON-LD permettent à Google et aux moteurs IA d'extraire et de citer ton contenu avec précision ; pour un SaaS B2B 2026, empiler 4-6 schémas par page (Article + FAQPage + HowTo + DefinedTerm selon le type) corrèle avec ~3,2× plus de citations IA.

Le structured data n'est pas un nice-to-have en 2026 — c'est ce qui distingue les pages qui sont citées par ChatGPT de celles qui restent invisibles. Ce guide te livre la stack exacte à empiler par type de page, avec le code TypeScript prêt à copier.

Pourquoi JSON-LD et pas microdata ou RDFa

Google a tranché en 2015 : JSON-LD est le format recommandé pour les structured data. Trois raisons :

1. Séparation HTML / metadata. JSON-LD se place dans une balise <script type="application/ld+json"> dédiée. Pas de pollution des attributes HTML. Plus simple à maintenir.

2. Composabilité. Tu peux empiler plusieurs blocs JSON-LD dans une même page (jusqu'à 6 sur les pages produit-vedette de référence). Chaque bloc = un schéma indépendant. Microdata force tout dans la même hiérarchie HTML.

3. Cross-référencement via @id. L'attribut @id permet de référencer une entité depuis plusieurs schémas (ex. ton Organization sur le layout référencée depuis le publisher de chaque Article). Réduit la duplication.

Microdata reste valide (Google le lit) mais l'écosystème converge vers JSON-LD. RDFa est quasiment abandonné côté SaaS.

La baseline universelle : Organization + WebSite + SoftwareApplication

Trois schémas à mettre dans le layout root, chargés sur chaque page :

Organization identifie l'entreprise éditrice. À mettre une fois avec un @id (https://tonsite.com/#organization). Champs : name, url, logo, description, sameAs (réseaux sociaux), foundingDate, founder, parentOrganization si applicable.

WebSite identifie le site lui-même. publisher → l'Organization via @id. Permet à Google d'afficher le sitelinks search box.

SoftwareApplication identifie le produit avec ses Offers (les tarifs en EUR/USD avec billingDuration P1M pour mensuel). applicationCategory: "BusinessApplication", applicationSubCategory selon ton verticale.

Ces 3 schémas dans le layout = présent sur chaque page = signal global de marque. Permet à Google + IA d'avoir un contexte stable.

Stack par type de page programmatique

Pages comparer (X vs Y) : BreadcrumbList + Article + FAQPage - Article : headline = metaTitle, datePublished + dateModified critiques pour la freshness - FAQPage : éligible aux Google rich results (FAQs expandables dans les SERPs)

Pages cas d'usage (how-to) : BreadcrumbList + Article + HowTo + FAQPage - HowTo : steps de la procédure (HowToStep position + name + text) - Google peut afficher les steps directement dans la SERP

Pages glossaire (définitions) : BreadcrumbList + DefinedTerm + Article + FAQPage - DefinedTerm : name + description + inDefinedTermSet pointant vers le hub /glossaire - AlternateName pour les variations d'orthographe / acronymes - Signal d'autorité topique très fort

Pages templates (prompts) : BreadcrumbList + Article + HowTo + FAQPage - Même stack que les cas d'usage, framing différent

Pages experts (profils) : BreadcrumbList + Person + Article + FAQPage - Person : name + jobTitle + url + sameAs (LinkedIn officiel) + knowsAbout - Capture les requêtes "qui est X"

Champs critiques pour l'AEO : dates et author

Trois champs sous-utilisés mais critiques pour la rétention de citation IA :

datePublished + dateModified. Sur le schéma Article. dateModified bumpé trimestriellement maintient ta page en haut de la pile de fraîcheur. Pages non rafraîchies trimestriellement = 3× plus susceptibles de perdre leur citation au profit d'un concurrent plus frais (AirOps 2026).

author. Type "Organization" ou "Person". Pour B2B SaaS, "Organization" avec le nom de ta marque suffit (vs un éditeur média qui voudra un author Person). Cross-référence avec ton Organization du layout via @id.

publisher. Pointe vers ton Organization ({"@id": "https://tonsite.com/#organization"}). Permet à Google + IA de relier l'article à l'entité éditrice.

Combinaison datePublished + dateModified + author + publisher = signal Article complet. Active la rich SERP card et améliore la citabilité.

Outils de validation

Google Rich Results Test (https://search.google.com/test/rich-results) — vérifie que tes pages sont éligibles aux rich results. Test page par page.

Schema Markup Validator (https://validator.schema.org/) — valide la conformité schema.org. Plus strict que Google, utile pour catch les erreurs subtiles.

Search Console > Rich Results report — voit quelles pages sont effectivement indexées avec rich results en prod. À surveiller hebdomadairement.

Audit interne en bash : ``bash curl -sS https://tonsite.com/ta-page | grep -oE '"@type":"[^"]+"' | sort -u `` Liste tous les types de schémas présents sur une page. Utile pour audit rapide multi-pages.

Brandyze brand_radar / seo_audit_citation_worthiness — score la "citation-worthiness" d'une URL en croisant la qualité du structured data + la fraîcheur + la sourcing du contenu. Disponible dans le plan Pro chatsocial.fr.

Questions fréquentes

  • Trop de schémas par page peut-il nuire ?

    Non — Google et les moteurs IA gèrent jusqu'à 8+ schémas par page sans problème, à condition qu'ils soient COHÉRENTS (ex. ne pas mettre HowTo sur une page qui n'a pas de steps). La règle : chaque schéma doit décrire un aspect réel du contenu de la page.

  • Comment gérer dateModified sans le bumper manuellement à chaque déploiement ?

    Deux options : (1) constante en haut du fichier de page mise à jour à chaque vraie refresh du contenu (recommandé) ; (2) lecture du git log de la page à la build pour dériver automatiquement. Éviter de mettre `now()` qui casse le signal (chaque rebuild = 'fraîcheur instantanée' = signal pourri).

  • FAQPage limite-t-elle vraiment à 3-5 questions ?

    Pas de limite imposée par schema.org, mais Google n'affiche que les 4-6 premières dans les rich results. Au-delà, c'est cosmétique pour les LLMs (qui lisent tout). Recommandation : 3-8 questions de qualité.

  • BreadcrumbList est-il utile si la page n'a pas de breadcrumb visuel ?

    Oui — BreadcrumbList JSON-LD est utile même sans breadcrumb HTML visuel. Google l'utilise pour comprendre la hiérarchie du site et l'affiche dans certaines SERPs sous l'URL.

Mettre ce guide en pratique

chatsocial.fr embarque les outils nécessaires (AEO brand_radar, SEO 8 outils, programmatic SEO via topic clusters) pour appliquer la méthodologie en une conversation.

Commencer