Le contexte : une suppression annoncée, un impact sous-estimé
En août 2023, Google a commencé à restreindre les FAQ rich results aux sites dits « à forte autorité » (sites gouvernementaux, santé). Depuis, le déploiement s'est élargi : les FAQ rich results ne s'affichent plus pour la majorité des sites dans les résultats de recherche, et les rapports associés dans Search Console sont en cours de suppression.
Ce n'est pas un ajustement mineur. Les FAQ rich results ont été, pendant quatre ans, l'un des leviers les plus exploités pour augmenter la surface SERP occupée par un résultat organique — parfois doublant ou triplant la hauteur d'un snippet. Pour certains sites, c'était la principale source de CTR différentiel entre eux et leurs concurrents directs.
La question n'est plus « est-ce que ça va arriver » mais « qu'est-ce que vous faites du balisage FAQPage qui traîne sur des milliers de pages, et comment vous récupérez le CTR perdu ».
Pourquoi Google a tué les FAQ rich results
Le problème de l'abus à l'échelle
Le schéma FAQPage a été massivement détourné. L'intention initiale — permettre aux pages qui contiennent réellement une FAQ éditoriale de l'afficher enrichie — a été noyée sous les implémentations opportunistes. Des sites e-commerce collaient du balisage FAQ sur chaque page catégorie avec des questions générées automatiquement du type « Quel est le meilleur [produit] en 2024 ? ». Des blogs ajoutaient des FAQ de 10 questions pour des articles de 500 mots.
Google a constaté que la qualité perçue des SERP se dégradait. Les FAQ rich results prenaient un espace disproportionné sans fournir de valeur informationnelle réelle. Le ratio signal/bruit était devenu intenable.
L'alignement avec la stratégie AI Overviews
L'autre facteur, rarement discuté : les FAQ rich results entraient en conflit direct avec les AI Overviews. Quand Google génère une réponse synthétique en haut de SERP, afficher en dessous une FAQ dépliable avec des réponses fragmentées crée une redondance visuelle et informationnelle. La suppression des FAQ rich results libère de l'espace SERP pour les fonctionnalités IA que Google pousse activement.
C'est un pattern récurrent : Google retire les features structured data qui concurrencent ses propres formats de réponse. Les évolutions récentes des liens dans les AI Overviews confirment cette direction — Google veut contrôler la couche de présentation, pas la déléguer au balisage des webmasters.
Audit technique : identifier et quantifier l'impact sur votre site
Avant de toucher quoi que ce soit, vous devez mesurer l'étendue du problème.
Étape 1 : Lister toutes les pages avec balisage FAQPage
Avec Screaming Frog, lancez un crawl avec l'extraction de données structurées activée :
# Configuration Screaming Frog CLI (si vous utilisez la version en ligne de commande)
screamingfrog --crawl https://www.votresite.fr \
--headless \
--save-crawl \
--export-tabs "Structured Data:All" \
--output-folder /tmp/audit-faq/
# Filtrez ensuite les résultats pour le type FAQPage
cat /tmp/audit-faq/structured_data_all.csv | \
grep "FAQPage" | \
awk -F',' '{print $1}' | \
sort -u > /tmp/audit-faq/pages_with_faq.txt
wc -l /tmp/audit-faq/pages_with_faq.txt
Si vous n'avez pas Screaming Frog CLI, l'interface graphique fait le même travail : Configuration > Spider > Extraction > cochez « Structured Data ». Après le crawl, allez dans l'onglet « Structured Data » et filtrez sur FAQPage.
Étape 2 : Croiser avec les données Search Console
L'objectif est d'identifier les pages qui bénéficiaient réellement d'impressions FAQ rich results — pas juste celles qui avaient le balisage.
Dans Search Console, le rapport « Améliorations > FAQ » est en cours de suppression, mais tant qu'il est disponible, exportez-le. Sinon, utilisez l'API Search Console pour extraire les données historiques de performance par page :
# Extraction via l'API Search Console (Python + google-api-python-client)
from googleapiclient.discovery import build
from google.oauth2.service_account import Credentials
import csv
from datetime import datetime, timedelta
SCOPES = ['https://www.googleapis.com/auth/webmasters.readonly']
SERVICE_ACCOUNT_FILE = 'service-account.json'
credentials = Credentials.from_service_account_file(
SERVICE_ACCOUNT_FILE, scopes=SCOPES
)
service = build('searchconsole', 'v1', credentials=credentials)
SITE_URL = 'https://www.votresite.fr'
# Période AVANT la suppression des FAQ rich results
# Ajustez selon la date effective pour votre site
start_date = '2023-06-01'
end_date = '2023-08-01'
# Charger les URLs avec balisage FAQ
with open('/tmp/audit-faq/pages_with_faq.txt') as f:
faq_urls = [line.strip() for line in f.readlines()]
results = []
# L'API limite à 25 000 lignes par requête
# Pour un gros site, paginez avec startRow
request_body = {
'startDate': start_date,
'endDate': end_date,
'dimensions': ['page'],
'rowLimit': 25000,
'dimensionFilterGroups': [{
'filters': [{
'dimension': 'searchAppearance',
'expression': 'FAQ_RICH_RESULT'
}]
}]
}
response = service.searchanalytics().query(
siteUrl=SITE_URL,
body=request_body
).execute()
with open('/tmp/audit-faq/faq_performance.csv', 'w', newline='') as csvfile:
writer = csv.writer(csvfile)
writer.writerow(['url', 'clicks', 'impressions', 'ctr', 'position'])
for row in response.get('rows', []):
writer.writerow([
row['keys'][0],
row['clicks'],
row['impressions'],
round(row['ctr'], 4),
round(row['position'], 1)
])
print(f"Pages avec FAQ rich results actifs : {len(response.get('rows', []))}")
Le filtre searchAppearance: FAQ_RICH_RESULT est la clé. Il vous donne uniquement les pages qui ont effectivement généré des impressions avec le rich result FAQ affiché — pas celles qui avaient le balisage mais sans affichage.
Étape 3 : Quantifier le delta CTR
Comparez le CTR des mêmes pages avant et après la suppression. Si la suppression est déjà effective pour votre site, prenez la période actuelle comme « après ». Le delta typique se situe entre 8% et 30% de CTR perdu, selon la proportion de l'espace SERP que la FAQ occupait et le niveau de concurrence.
Scénario concret : un site e-commerce de 12 000 pages
Prenons un cas réaliste. Un e-commerce spécialisé en équipement outdoor, 12 000 pages indexées (800 pages catégories, 10 500 fiches produits, 700 articles de blog). L'équipe SEO avait déployé du balisage FAQPage sur :
- Les 800 pages catégories : 3-5 questions générées par template (« Quelle est la meilleure tente 2 places ? », « Comment choisir ses chaussures de randonnée ? »)
- 350 articles de blog : FAQ reprenant les sous-titres de l'article sous forme de questions
Données avant suppression (moyenne mensuelle, période janvier-juillet 2023) :
- Pages catégories avec FAQ rich result affiché : 420 sur 800 (53%)
- CTR moyen des pages catégories avec FAQ : 4.8%
- CTR moyen des pages catégories sans FAQ : 3.1%
- Trafic mensuel attribuable au différentiel CTR FAQ : ~2 800 visites
Données après suppression (octobre 2023 - mars 2024) :
- CTR moyen des pages catégories (toutes) : 3.3%
- Perte de trafic mensuel estimée : ~2 200 visites
Soit une perte annuelle de ~26 000 visites qualifiées sur les pages catégories seules. Pour un site avec un revenu par visite organique de 1,80€, c'est ~47 000€/an de manque à gagner.
Ce scénario n'a rien d'exceptionnel. Il illustre pourquoi la réaction « c'est juste un affichage en moins » est dangereusement naïve.
Faut-il supprimer le balisage FAQPage ?
La réponse courte : oui, dans la majorité des cas. Mais pas pour les raisons que vous croyez.
Le balisage orphelin n'est pas neutre
Un balisage FAQPage qui ne génère plus de rich result n'est pas techniquement « nocif » au sens d'une pénalité. Google ne va pas déclasser votre page parce qu'elle contient un schéma valide mais non affiché. Cependant :
-
Il alourdit le DOM — chaque bloc JSON-LD ajoute du poids au HTML initial. Sur des pages catégories déjà lourdes, avec des fiches produits lazy-loaded et du balisage
Product,BreadcrumbList,Organization, le JSON-LD FAQ ajoute typiquement 2-5 Ko de données inutiles. -
Il brouille le signal de données structurées — Googlebot parse tous les blocs de données structurées. Un balisage FAQ de qualité médiocre (questions auto-générées, réponses vagues) envoie un signal de qualité négatif sur la page, même sans affichage rich result.
-
Il crée de la dette technique — du code que personne ne maintient mais que tout le monde hérite. Quand un développeur modifie le template de page catégorie, il doit comprendre et maintenir un bloc JSON-LD qui ne sert plus à rien.
L'exception : les sites « à forte autorité »
Google continue d'afficher les FAQ rich results pour les sites gouvernementaux et les sources de santé faisant autorité. Si vous êtes dans cette catégorie (sites .gouv.fr, établissements de santé référencés, organismes publics), conservez le balisage et assurez-vous qu'il reste valide.
Pour tous les autres, procédez au nettoyage.
Plan de suppression technique
Voici un exemple de script qui nettoie les blocs FAQPage du JSON-LD sans toucher aux autres types de données structurées. Adapté pour un site Next.js qui génère le JSON-LD côté serveur :
// utils/cleanStructuredData.ts
// Supprime les blocs FAQPage du JSON-LD avant injection dans le <head>
interface StructuredDataBlock {
'@type': string | string[];
'@context'?: string;
[key: string]: unknown;
}
type StructuredData = StructuredDataBlock | StructuredDataBlock[];
export function removeFaqSchema(jsonLd: StructuredData): StructuredData | null {
// Cas 1 : un seul objet
if (!Array.isArray(jsonLd)) {
const types = Array.isArray(jsonLd['@type'])
? jsonLd['@type']
: [jsonLd['@type']];
if (types.includes('FAQPage')) {
return null; // Suppression complète
}
// Vérifier les sous-objets @graph
if (jsonLd['@graph'] && Array.isArray(jsonLd['@graph'])) {
const filtered = (jsonLd['@graph'] as StructuredDataBlock[]).filter(
(item) => {
const itemTypes = Array.isArray(item['@type'])
? item['@type']
: [item['@type']];
return !itemTypes.includes('FAQPage');
}
);
if (filtered.length === 0) return null;
return { ...jsonLd, '@graph': filtered };
}
return jsonLd;
}
// Cas 2 : tableau de blocs
const filtered = jsonLd.filter((block) => {
const types = Array.isArray(block['@type'])
? block['@type']
: [block['@type']];
return !types.includes('FAQPage');
});
if (filtered.length === 0) return null;
if (filtered.length === 1) return filtered[0];
return filtered;
}
// Utilisation dans un composant Next.js (App Router)
// app/category/[slug]/page.tsx
//
// const cleanedJsonLd = removeFaqSchema(originalJsonLd);
// if (cleanedJsonLd) {
// return (
// <script
// type="application/ld+json"
// dangerouslySetInnerHTML={{ __html: JSON.stringify(cleanedJsonLd) }}
// />
// );
// }
Ce script gère les trois cas courants : un bloc JSON-LD unique de type FAQPage, un @graph contenant un mélange de types, et un tableau de blocs autonomes. Testez-le sur votre staging avant déploiement — et validez avec le test de résultats enrichis de Google que vos autres types de données structurées restent intacts.
Récupérer le CTR perdu : stratégies de remplacement
Supprimer le balisage FAQ ne résout que la moitié du problème. L'autre moitié, c'est compenser la perte de surface SERP.
Miser sur les données structurées qui fonctionnent encore
Plusieurs types de rich results restent pleinement supportés et offrent un gain de CTR mesurable :
HowTo — pour les contenus éditoriaux qui décrivent un processus. Attention : Google a aussi restreint HowTo en août 2023, mais il reste affiché pour les requêtes informationnelles légitimes sur mobile. À tester au cas par cas.
Product et Review — pour l'e-commerce, le balisage produit avec agrégation d'avis reste le levier rich result le plus stable. Si vos pages catégories n'ont pas d'AggregateRating, c'est la première chose à implémenter.
Article avec speakable — pour les sites médias, le balisage speakable permet à Google Assistant de lire des extraits. Niche, mais différenciant.
BreadcrumbList — souvent négligé, le fil d'Ariane structuré améliore l'affichage de l'URL dans les SERPs. C'est un petit gain, mais il est systématique et fiable.
Optimiser pour les « People Also Ask »
Les FAQ rich results sont morts, mais les « People Also Ask » (PAA) sont bien vivants. La différence fondamentale : vous ne contrôlez pas l'affichage PAA via du balisage. Google sélectionne les contenus qui répondent aux questions connexes en se basant sur la pertinence sémantique de votre contenu.
La stratégie : conservez le contenu de vos FAQ (les questions-réponses elles-mêmes) dans le corps de la page, mais supprimez le balisage JSON-LD. Structurez les Q&A avec des H3 et des paragraphes de réponse concis (40-60 mots). Ce format est celui que Google extrait le plus facilement pour les PAA.
C'est aussi le format que les modèles de langage ingèrent le mieux pour les AI Overviews. Les signaux qui définissent la visibilité en AI search reposent en grande partie sur la capacité de votre contenu à fournir des réponses extractibles et attribuables.
Travailler les meta descriptions pour le CTR
Sans rich result, votre snippet se réduit au title + meta description + URL. Chaque caractère compte davantage. Passez en revue les meta descriptions de vos pages les plus impactées. Une meta description qui reprend la question principale à laquelle la page répond performe systématiquement mieux qu'une description générique.
Vérifiez aussi que vos meta descriptions ne sont pas tronquées ou absentes sur les pages critiques. C'est le type de régression silencieuse qu'un outil de monitoring comme Seogard détecte automatiquement — une meta description qui disparaît après un déploiement peut passer inaperçue pendant des semaines si personne ne surveille.
Implications pour la stratégie de contenu SEO
La fin du contenu FAQ comme levier de scaling
Beaucoup de sites avaient industrialisé la production de contenu FAQ : un script qui génère 3 à 5 questions par page à partir des données de Search Console (requêtes liées), un template qui injecte le balisage FAQPage automatiquement. Cette approche perd son ROI principal.
Cela rejoint un mouvement plus large. Google resserre les critères de qualité sur le contenu scalé. Les seuils de qualité appliqués au contenu IA généré à grande échelle montrent que la quantité sans profondeur éditoriale est de moins en moins viable. La fin des FAQ rich results est un symptôme de cette tendance, pas un événement isolé.
Rediriger l'effort vers la profondeur thématique
Les ressources que vous consacriez à créer et maintenir du contenu FAQ doivent être réallouées. Deux pistes à fort ROI :
-
Enrichir les pages existantes avec du contenu expert qui répond aux questions que le FAQ couvrait, mais de manière intégrée et contextualisée plutôt que sous forme de liste Q&A. Un paragraphe de 150 mots qui traite une objection client dans le flux naturel de la page a plus de valeur SEO qu'une FAQ collée en bas de page.
-
Créer des contenus hub qui centralisent l'expertise sur un sujet. Au lieu de 800 pages catégories avec chacune 5 questions FAQ, créez 20 guides approfondis qui couvrent les questions transversales et qui maillent vers les pages catégories. Le SEO programmatique sémantique offre un cadre méthodologique pour ce type de restructuration.
Monitoring post-migration : ce qu'il faut surveiller
La suppression du balisage FAQ est un changement à déployer proprement, pas un hotfix à pousser un vendredi soir.
Checklist de validation
- Validation des données structurées restantes : après suppression du FAQ JSON-LD, vérifiez que les autres blocs (Product, BreadcrumbList, Organization) sont toujours syntaxiquement valides. Un JSON-LD malformé peut casser silencieusement tous les rich results de la page.
- Monitoring du CTR par segment : dans Search Console, créez des expressions régulières pour isoler les pages qui avaient du FAQ. Suivez le CTR hebdomadaire pendant 8 semaines minimum.
- Vérification du rendu SSR : si votre balisage FAQ était injecté côté serveur et que vous modifiez le pipeline de rendu, assurez-vous que le SSR n'est pas cassé. Les leçons JavaScript SEO des sites e-commerce détaillent les pièges courants.
- Suivi des impressions « FAQ » dans Search Console : tant que le rapport existe, vérifiez qu'il tombe bien à zéro après votre déploiement. Si des impressions FAQ persistent, vous avez probablement un cache CDN qui sert encore l'ancien HTML, ou un composant client-side qui réinjecte le balisage.
Automatiser la détection de régression
Le risque réel n'est pas le déploiement initial — c'est le déploiement suivant. Un développeur qui ne connaît pas le contexte pourrait réintroduire le balisage FAQ en important un ancien template, ou un plugin CMS pourrait le générer automatiquement après une mise à jour.
C'est précisément le type de régression que Seogard surveille en continu : un balisage structuré qui réapparaît ou disparaît de manière inattendue déclenche une alerte avant que l'impact ne se propage sur des milliers de pages.
Le signal plus large : Google reprend le contrôle de la SERP
La suppression des FAQ rich results n'est pas un événement technique isolé. C'est un mouvement stratégique dans la même direction que les AI Overviews, les featured snippets étendus, et la réduction progressive de l'espace accordé aux résultats organiques classiques.
Google ne veut plus que les webmasters contrôlent la présentation des résultats via le balisage structuré. Il veut extraire les données, les reformuler, et les présenter dans ses propres formats. Le balisage structuré reste utile — pas comme levier d'affichage, mais comme signal de compréhension sémantique. Google l'utilise pour mieux comprendre vos données, pas pour vous laisser décider comment elles s'affichent.
Cette distinction change fondamentalement la manière dont vous devez penser les données structurées. Implémentez-les pour la précision sémantique (un produit est un produit, un prix est un prix, une organisation est une organisation), pas pour « obtenir un rich result ». Les rich results sont un bonus que Google accorde quand ça l'arrange — et qu'il retire quand ça ne l'arrange plus.
Les FAQ rich results viennent de nous le rappeler. Nettoyez votre balisage, réallouez vos efforts vers la profondeur de contenu et les formats que Google favorise aujourd'hui, et mettez en place un monitoring qui vous préviendra la prochaine fois qu'une feature disparaît sous vos pieds.