Je suis Mathieu Ponton, Co-Founder & ingénieur logiciel chez Apogée Consult à Lyon. Ingénieur diplômé de Polytech Lyon (Informatique), j'ai fait trois ans en apprentissage, partagés entre la Métropole de Lyon (inclusion numérique avec Res'in et sobriété énergétique avec Écolyo) et Superwyze, une startup medtech (POCs, dont certains aujourd'hui industrialisés, et travail sur des codebases existantes). J'ai livré plus de 10 projets en production (web, mobile et IA / RAG) pour des PME, startups et organisations publiques.
Schema.org pour cabinets de conseil : notre template pour faire remonter les bons rich results
- seo-tech
Les rich results ne sont pas réservés aux e-commerçants et aux recettes de cuisine. Voici le balisage Schema.org que nous utilisons pour les cabinets de conseil B2B, avec les types qui fonctionnent réellement.
Schema.org pour cabinets de conseil : notre template pour faire remonter les bons rich results
Les rich results, ces blocs enrichis qui apparaissent dans les SERPs avec des étoiles, des FAQ dépliables, ou des informations structurées, sont souvent associés au e-commerce et aux médias. Pour un cabinet de conseil B2B, les opportunités existent, mais elles sont différentes. Le bon balisage Schema.org ne garantit pas un rich result, mais il pose les conditions pour que Google considère l'affichage enrichi. Sans lui, c'est impossible.
Ce que Google peut afficher pour un cabinet de conseil
Google ne génère pas de rich results pour tous les types Schema.org. La liste des types éligibles est documentée dans Google Search Central et mise à jour régulièrement. Pour un cabinet de conseil, les types pertinents et éligibles aux rich results sont :
- FAQPage : questions-réponses dépliables dans la SERP (éligibilité confirmée)
- LocalBusiness / ProfessionalService : panneau Knowledge Graph avec adresse, horaires, note
- BreadcrumbList : fil d'Ariane dans l'URL affichée
- Person : pour les profils de consultants (peut apparaître dans les résultats de recherche personnelle)
- Organization : pas directement un rich result, mais alimente le Knowledge Graph et les sitelinks
Les types comme Service, Offer, ou Event peuvent enrichir la compréhension sémantique par Google sans nécessairement produire un affichage enrichi visible.
Le template Organization de base
Chaque page du site doit référencer l'entité Organization principale. Nous l'incluons dans le layout racine pour qu'elle soit présente sur toutes les pages.
// app/layout.tsx
export default function RootLayout({ children }: { children: React.ReactNode }) {
const organizationSchema = {
"@context": "https://schema.org",
"@type": "ProfessionalService",
"@id": "https://exemple-conseil.fr/#organization",
name: "Apogée Consult",
url: "https://exemple-conseil.fr",
logo: {
"@type": "ImageObject",
url: "https://exemple-conseil.fr/logo.png",
width: 400,
height: 120,
},
description:
"Cabinet conseil en développement web et IA générative basé à Lyon.",
address: {
"@type": "PostalAddress",
streetAddress: "12 rue de la République",
addressLocality: "Lyon",
postalCode: "69001",
addressRegion: "Auvergne-Rhône-Alpes",
addressCountry: "FR",
},
contactPoint: {
"@type": "ContactPoint",
email: "[email protected]",
contactType: "customer service",
availableLanguage: "French",
},
sameAs: [
"https://www.linkedin.com/company/exemple-conseil",
],
areaServed: {
"@type": "City",
name: "Lyon",
},
};
return (
<html lang="fr">
<head>
<script
type="application/ld+json"
dangerouslySetInnerHTML={{
__html: JSON.stringify(organizationSchema),
}}
/>
</head>
<body>{children}</body>
</html>
);
}Le @id avec un fragment #organization est important. Il permet à d'autres éléments Schema.org de la page de référencer cette entité via { "@id": "https://exemple-conseil.fr/#organization" } sans redéclarer toutes ses propriétés.
Le balisage de page service
Chaque page décrivant une offre de service doit avoir son propre balisage Service lié à l'organisation principale.
// app/services/[slug]/page.tsx
const serviceSchema = {
"@context": "https://schema.org",
"@type": "Service",
"@id": `https://exemple-conseil.fr/services/${service.slug}/#service`,
name: service.name,
description: service.description,
provider: {
"@id": "https://exemple-conseil.fr/#organization",
},
serviceType: service.category, // ex: "Développement web", "Conseil IA"
areaServed: {
"@type": "City",
name: "Lyon",
},
offers: {
"@type": "Offer",
availability: "https://schema.org/InStock",
priceSpecification: {
"@type": "PriceSpecification",
priceCurrency: "EUR",
description: service.pricingModel, // ex: "Sur devis"
},
},
};Le balisage FAQPage
C'est le type le plus actionnable pour un cabinet de conseil car il produit des rich results visibles directement dans la SERP. La condition : avoir une section FAQ réelle dans la page, avec des questions et réponses substantielles.
// Composant FAQ
const faqSchema = {
"@context": "https://schema.org",
"@type": "FAQPage",
mainEntity: faqs.map((faq) => ({
"@type": "Question",
name: faq.question,
acceptedAnswer: {
"@type": "Answer",
text: faq.answer,
},
})),
};La règle de Google pour FAQPage : les questions et réponses doivent être visibles sur la page pour l'utilisateur. Un balisage FAQ pointant vers un contenu masqué (accordéon non déplié, tab non actif) peut ne pas être éligible. Avec un accordéon, le contenu doit être dans le DOM même si visuellement replié, ce qui est généralement le cas avec les implémentations CSS standards.
Le balisage Person pour les consultants
Pour un cabinet avec des consultants identifiables publiquement, le balisage Person sur les pages de présentation améliore la visibilité dans les recherches nominatives et alimente le Knowledge Graph Google pour les entités personnelles.
const personSchema = {
"@context": "https://schema.org",
"@type": "Person",
"@id": `https://exemple-conseil.fr/equipe/${consultant.slug}/#person`,
name: consultant.fullName,
jobTitle: consultant.title,
description: consultant.bio,
url: `https://exemple-conseil.fr/equipe/${consultant.slug}`,
image: {
"@type": "ImageObject",
url: consultant.photoUrl,
},
worksFor: {
"@id": "https://exemple-conseil.fr/#organization",
},
sameAs: [
consultant.linkedinUrl,
consultant.websiteUrl,
].filter(Boolean),
};Le champ sameAs avec l'URL LinkedIn est particulièrement important. Google utilise ces liens pour réconcilier les entités entre sources et alimenter le Knowledge Graph. Une entité Person avec un sameAs vers LinkedIn a plus de chances d'apparaître dans les résultats de recherche pour le nom du consultant.
Comment tester le balisage
Google fournit deux outils :
- Rich Results Test (search.google.com/test/rich-results) : vérifie si une page est éligible aux rich results avec le balisage détecté
- Schema Markup Validator (validator.schema.org) : vérifie la validité syntaxique du Schema.org sans jugement sur l'éligibilité Google
Le processus que nous suivons :
- Déployer le balisage en staging
- Tester via Rich Results Test, corriger les erreurs et avertissements
- Déployer en production
- Soumettre les URLs modifiées à l'inspection via Search Console
- Attendre 2 à 6 semaines pour l'apparition éventuelle des rich results
La limite principale : Google ne garantit pas l'affichage des rich results même avec un balisage valide. Les facteurs qui influencent l'affichage incluent l'autorité du domaine, la qualité du contenu de la page, et les filtres éditoriaux que Google applique discrétionnairement. Un balisage FAQPage validé à 100% peut ne jamais produire de rich result visible si Google considère la page ou le domaine insuffisamment autoritatifs.
Ce qu'on ne sait pas encore : dans quelle mesure Google utilise le Schema.org pour nourrir ses réponses AI Overviews. Les premières analyses suggèrent une corrélation entre balisage structuré et apparition dans les réponses générées, mais Google n'a pas confirmé de lien direct.