Vous avez peut-être passé des semaines à baliser vos FAQ en Schema.org pour gagner ces fameuses questions repliables dans Google. Mauvaise nouvelle : depuis le 7 mai 2026, Google ne les affiche plus du tout, pour personne, hors sites gouvernementaux et santé. Bonne nouvelle : il reste sept ou huit types de données structurées Schema.org qui font vraiment grimper le taux de clic, et la plupart des TPE et PME passent à côté faute de savoir où regarder.
Cet article fait le tri entre ce qui rapporte encore en 2026, ce qui est mort, ce qui est en train de mourir et comment implémenter les balises sans tomber dans les pièges classiques.
Votre site est invisible pour Google si vous ne lui dites pas ce qu'il regarde
Google lit votre HTML, mais il ne comprend pas le sens. Un prix de 49 €, pour lui, c'est juste du texte qui ressemble à un montant. Le nom de votre entreprise, pour lui, c'est juste une suite de mots. Le titre d'un article, pour lui, c'est juste une balise h1 parmi d'autres signaux.
Schema.org sert exactement à ça : ajouter une couche d'informations machine-readable qui dit explicitement à Google « ceci est le prix d'un produit », « ceci est une entreprise locale située à cette adresse », « ceci est un article publié à telle date par tel auteur ». C'est un vocabulaire co-développé par Google, Microsoft, Yahoo et Yandex depuis 2011, désormais standard de facto pour décrire n'importe quel contenu web. La référence vit sur schema.org et compte plus de 800 types d'objets.
Une fois Google capable de comprendre votre contenu, deux choses se passent. La première : il peut afficher des résultats enrichis (rich snippets) avec étoiles, prix, horaires, image, breadcrumb. La seconde, plus discrète mais plus durable : il intègre mieux votre site dans son knowledge graph, ce qui aide aussi pour les AI Overviews et les réponses générées par Gemini.
Ce qui est mort en 2026 : les FAQ rich results, et probablement HowTo
Le coup de massue : Google a définitivement supprimé l'affichage des FAQ dans les résultats de recherche le 7 mai 2026, et retire le rapport correspondant de la Search Console en juin. Les rich results FAQ ne reviendront plus, sauf pour une poignée de sites gouvernementaux et santé jugés autoritaires. Cette décision avait été préparée dès août 2023, comme l'a annoncé Google sur son blog Search Central, et confirmée mi-2026 par Search Engine Land.
Concrètement, si vous avez balisé vos pages avec FAQPage pour faire apparaître des questions repliables sous votre résultat, c'est fini. Le code reste valide, Google continue de l'utiliser pour comprendre le contenu (notamment pour ses AI Overviews), mais l'affichage visuel disparaît. Inutile de retirer le balisage existant, inutile aussi d'en mettre en place dans le seul espoir d'occuper plus d'espace dans la SERP.
Le balisage HowTo a connu le même sort dès août 2023 sur mobile, puis a été complètement retiré du desktop. Si vous écrivez du contenu type « tutoriel pas à pas », le balisage n'apporte plus de rich result. Restez sur du contenu propre et structuré, c'est ce qui paie.
Les 7 balises Schema.org qui rapportent vraiment en 2026
Voici la liste courte des types qui produisent encore des rich results visibles dans Google. Si vous n'en mettez en place qu'une partie, mettez celles-là.
- LocalBusiness : la priorité absolue pour toute entreprise avec une adresse physique ou une zone de service. Alimente le Knowledge Panel et le Local Pack. Documentée par Google sur Search Central.
- Organization : version générique pour les entreprises sans présence locale, ou complément de LocalBusiness. Logo, nom légal, profils sociaux, coordonnées. Détails sur Search Central Organization.
- Product : indispensable pour tout site e-commerce. Affiche le prix, la disponibilité, l'image et la note moyenne dans les résultats. Combine avec Offer et AggregateRating.
- AggregateRating et Review : les étoiles jaunes sous le titre du résultat. Le levier numéro un pour le CTR. À utiliser uniquement avec des avis réels que vous affichez visiblement sur la page.
- Article ou BlogPosting : pour le contenu éditorial. Donne accès au carrousel d'actualités et aide l'identification de l'auteur (E-E-A-T).
- BreadcrumbList : remplace l'URL technique par votre arborescence lisible dans la SERP. Petit gain visuel, gros gain de clarté.
- Event : pour les pages d'événements (concert, salon, atelier, formation). Date, lieu, prix, format en ligne ou présentiel, le tout affiché directement.
Pour les sites de réservation, ajoutez Service et Reservation. Pour les restaurants, Menu et Restaurant (sous-type de LocalBusiness). Pour les sites de location, LodgingBusiness. Le principe reste le même : utiliser toujours le sous-type le plus spécifique disponible.
JSON-LD : pourquoi c'est le seul format à utiliser en 2026
Schema.org peut s'écrire de trois façons : JSON-LD, Microdata, RDFa. Google a une préférence claire et la répète depuis 2015 : JSON-LD. Trois raisons concrètes.
La première, maintenabilité. JSON-LD tient dans une balise <script type="application/ld+json"> placée dans le <head> de la page. Tout est centralisé, séparé du HTML visible. Quand vous redesign votre site, vous ne cassez pas le balisage. Microdata, à l'inverse, mélange des attributs dans vos balises HTML : un changement de structure et vous perdez des balises sans vous en rendre compte.
La deuxième, compatibilité avec le rendering moderne. Si votre site utilise React, Vue, Next.js ou tout autre framework JavaScript, JSON-LD s'intègre sans friction dans le head généré. Microdata force à instrumenter chaque composant visible, ce qui devient vite ingérable.
La troisième, lisibilité. Un développeur qui prend votre site peut lire le bloc JSON-LD en 30 secondes et corriger. Avec du Microdata éparpillé, il faut traquer les attributs itemtype et itemprop dans tout le DOM.
Voici à quoi ressemble un bloc JSON-LD minimal pour une entreprise locale :
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "LocalBusiness",
"name": "Boulangerie Martin",
"address": {
"@type": "PostalAddress",
"streetAddress": "12 rue de la République",
"addressLocality": "Aix-en-Provence",
"postalCode": "13100"
},
"telephone": "+33 4 42 00 00 00",
"openingHours": "Mo-Sa 07:00-19:30"
}
</script>
Une dizaine de lignes, et vous donnez à Google les fondamentaux pour vous afficher dans le Local Pack.
Implémenter les données structurées Schema.org sans tout casser : la méthode en 4 étapes
L'erreur classique : copier un bloc JSON-LD trouvé sur un blog, le coller dans le site, et oublier d'aligner les données avec ce qui s'affiche réellement. Google considère ça comme une tentative de manipulation et peut sanctionner manuellement la page. Les directives officielles de Google sont claires sur ce point : les données structurées doivent refléter le contenu visible.
Étape 1 : Inventorier les pages éligibles
Faites la liste de vos types de pages : page d'accueil, fiches produit, fiches service, articles de blog, pages localisation, page contact, pages événement. À chaque type correspond une balise Schema.org adaptée. Pas la peine de baliser tout : une page « Mentions légales » n'a rien à dire à Google en données structurées.
Étape 2 : Choisir le bon type pour chaque page
Une page d'accueil de TPE locale = LocalBusiness + Organization. Une fiche produit = Product + Offer + AggregateRating. Un article = Article + Person (auteur). Une page d'événement = Event. Un breadcrumb sur toutes les pages internes = BreadcrumbList. Toujours utiliser le sous-type le plus précis : Restaurant, Dentist, HairSalon, AutoRepair plutôt que LocalBusiness générique.
Étape 3 : Renseigner les propriétés requises et recommandées
Chaque type a une liste de propriétés required (sans elles, pas de rich result) et recommended (sans elles, rich result possible mais limité). Lisez la doc Google par type. Un Product sans price ou priceCurrency dans son Offer ne déclenchera jamais d'affichage enrichi. Un LocalBusiness sans address ne servira à rien.
Étape 4 : Valider avant de pousser en production
Utilisez le Rich Results Test de Google sur votre URL de staging ou directement sur le code. L'outil parse votre page, exécute le JavaScript et liste les rich results éligibles, avec les erreurs et avertissements. Tant que la page n'est pas verte, ne mettez pas en production.
Tester et suivre vos balises avec les outils Google
Trois outils suffisent pour tout le cycle.
- Rich Results Test : la validation avant déploiement. Pointez une URL ou collez un snippet. Vous voyez immédiatement les types détectés et les erreurs.
- Schema Markup Validator (schema.org/validator) : plus permissif, il valide la conformité au standard Schema.org global, même pour les types non supportés par Google.
- Search Console, section Améliorations : une fois la page indexée, Google y affiche les rich results valides, les erreurs et les avertissements par type. Le rapport est documenté sur l'aide officielle Search Console.
Comptez 1 à 4 semaines entre la mise en production et l'apparition des rich snippets dans les résultats, le temps que Google recrawl et décide d'afficher. Vous pouvez accélérer en soumettant l'URL via l'outil « Inspection d'URL » de Search Console. L'éligibilité ne garantit jamais l'affichage : Google choisit selon la pertinence de la requête, le contexte mobile/desktop et la concurrence.
Ce que les données structurées ne feront jamais
Trois illusions à dissiper avant de commencer.
Schema.org n'est pas un facteur de classement direct. Google le répète depuis dix ans : le balisage aide à la compréhension et à l'affichage, pas au ranking. Si votre page est en 8e position, du Schema.org ne la fera pas passer en 2e. Si elle est en 2e position avec un mauvais snippet, du Schema.org peut multiplier vos clics. La nuance est essentielle.
Les rich snippets ne sont jamais garantis. Même avec un balisage parfaitement valide, Google peut décider de ne pas afficher l'enrichissement. Sa décision dépend de la requête, du device, de votre autorité et de la concurrence. Sur une recherche très concurrentielle, seul le résultat numéro un héritera parfois des étoiles.
Mettre des avis fictifs ou des notes inventées dans Schema.org est interdit. Google sait croiser le balisage avec ce qui s'affiche sur la page. AggregateRating sans avis visibles sur la page = pénalité manuelle. Plusieurs sites se sont vu rétrograder pour ce motif. Si vous n'avez pas encore d'avis clients, n'inventez rien : commencez par en collecter via Google Business Profile, et c'est l'objet d'un autre chantier traité dans mon article sur le référencement local pour TPE.
Sur un site vitrine récent, ce que j'ai constaté avec et sans Schema.org
Sur un projet de site vitrine livré récemment pour une activité locale en région PACA, j'ai mis en place LocalBusiness + Organization + BreadcrumbList dès le lancement. La page d'accueil et la page contact ont été reconnues comme entreprise locale par Google en moins de trois semaines, alimentant directement le Knowledge Panel sur les recherches de marque. Sans ce balisage, Google reconstruit l'information à partir d'indices (titre, footer, mentions légales), ce qui prend plus de temps et donne des panels moins complets.
Le Schema.org n'a rien fait pour le ranking. Mais l'affichage enrichi a clairement donné de la crédibilité au résultat dans la SERP, et le client a vu remonter ses appels téléphoniques entrants.
Le bon ordre de bataille pour une TPE qui démarre
Si vous partez de zéro, voici la priorité utile.
- Balisez d'abord LocalBusiness (ou son sous-type le plus précis) sur la page d'accueil et la page contact. C'est ce qui rapporte le plus vite.
- Ajoutez Organization avec logo, sameAs (vos profils LinkedIn, Instagram, etc.) pour consolider votre identité.
- Mettez du BreadcrumbList sur toutes les pages internes. Coût quasi nul, gain visuel immédiat.
- Si vous vendez en ligne, Product + Offer + AggregateRating sur chaque fiche.
- Sur le blog, Article ou BlogPosting avec auteur identifié.
- Le reste (Event, Service, Recipe, JobPosting) selon votre activité.
Ne perdez pas de temps avec FAQPage et HowTo : Google ne les affiche plus. Ne perdez pas non plus de temps à baliser tout votre site la première semaine. Visez les pages qui reçoivent du trafic ou qui ciblent des requêtes commerciales fortes.
Si votre site est sur WordPress, des plugins comme Yoast SEO ou Rank Math génèrent automatiquement la majorité du balisage. Si votre site est sur mesure (Next.js, Astro, Remix), JSON-LD se génère côté serveur en quelques composants. Dans les deux cas, validez toujours avec le Rich Results Test avant de considérer le travail fini.
Un site mal balisé reste lisible par Google, mais il joue avec une main attachée dans le dos. Si vous voulez auditer ce qui existe sur votre site et savoir quelles balises mettre en priorité, parlons-en sur la page contact.