Une étude récente analysée par Search Engine Land révèle qu'à peine 15% des pages récupérées par ChatGPT lors de sa phase de recherche finissent effectivement citées dans la réponse finale. Autrement dit, 85% des pages que le modèle va chercher, lit, évalue — et rejette. La course à la "visibilité IA" que mènent la plupart des marques vise la mauvaise cible : être crawlé par un LLM n'est pas être cité par un LLM.
Le pipeline retrieval-to-citation : anatomie d'un filtre brutal
Pour comprendre pourquoi 85% des pages disparaissent entre la récupération et la citation, il faut modéliser le pipeline que ChatGPT (et les systèmes RAG en général) exécutent à chaque requête.
Étape 1 : Query decomposition
Quand un utilisateur pose une question complexe, ChatGPT la décompose en sous-requêtes. Une question comme "quel est le meilleur framework JavaScript pour le SEO d'un e-commerce en 2026" génère potentiellement 3 à 5 sous-requêtes distinctes : frameworks JS populaires, comparaison SSR/CSR, spécificités SEO e-commerce, benchmarks performance, etc.
Étape 2 : Retrieval (la récupération)
Chaque sous-requête déclenche une recherche via Bing (ou un index interne). Le système récupère typiquement 5 à 20 URLs par sous-requête. Pour une question décomposée en 4 sous-requêtes, on peut avoir 40 à 80 pages récupérées au total.
Étape 3 : Extraction et chunking
Le contenu de chaque page est extrait, nettoyé du markup non-sémantique, et découpé en chunks. C'est ici que le premier filtre opère : si votre page est un SPA dont le contenu dépend de JavaScript côté client, le système de retrieval peut ne récupérer qu'une coquille vide.
Étape 4 : Reranking et scoring
Les chunks extraits sont passés dans un modèle de reranking qui évalue leur pertinence par rapport à la requête originale. C'est le filtre le plus sévère. Un chunk peut être thématiquement pertinent mais jugé redondant avec un autre chunk de meilleure qualité, trop générique, ou insuffisamment factuel.
Étape 5 : Synthesis et citation
Le LLM synthétise les chunks retenus en une réponse cohérente. Seules les sources qui ont directement contribué à une affirmation dans la réponse reçoivent une citation. Résultat : sur 50 pages récupérées, 7 ou 8 sont citées.
Ce pipeline explique pourquoi les stratégies "optimisons pour être dans l'index de l'IA" passent à côté du problème. Le goulot d'étranglement n'est pas le retrieval — c'est le reranking et la synthesis.
Pourquoi votre page est récupérée mais rejetée : les 5 causes techniques
1. Contenu dupliqué sémantique
Vous publiez un article sur les balises canonical. Trois autres sites font de même, en reformulant la documentation Google. Le modèle de reranking va sélectionner le chunk le plus dense en information unique et éliminer les reformulations. Si votre article n'apporte aucun insight original — un cas d'usage non documenté, une analyse de edge case, des données propriétaires — il sera systématiquement rejeté au profit de la source primaire.
2. Signal structurel faible
Les systèmes RAG ne se contentent pas d'analyser le texte brut. Ils exploitent les signaux structurels du HTML pour évaluer la qualité et la hiérarchie de l'information. Un document dont le balisage sémantique est pauvre — des <div> partout, pas de <article>, pas de hiérarchie <h2>/<h3> cohérente — envoie un signal de qualité inférieure.
Voici un exemple de structure que les systèmes RAG extraient efficacement :
<article itemscope itemtype="https://schema.org/TechArticle">
<header>
<h1 itemprop="headline">Configurer le pre-rendering pour un SPA Next.js</h1>
<div itemprop="author" itemscope itemtype="https://schema.org/Person">
<span itemprop="name">Marie Dupont</span>
<meta itemprop="jobTitle" content="Lead SEO, Fnac.com" />
</div>
<time itemprop="datePublished" datetime="2026-02-15">15 février 2026</time>
<time itemprop="dateModified" datetime="2026-03-10">10 mars 2026</time>
</header>
<section>
<h2>Pourquoi le SSR seul ne suffit pas pour les pages produit</h2>
<p>Sur un catalogue de 22 000 SKUs, le temps de génération SSR
dépasse 800ms par page sous charge, ce qui...</p>
<h3>Benchmark : SSR vs ISR vs Pre-rendering statique</h3>
<table>
<thead>
<tr><th>Stratégie</th><th>TTFB moyen</th><th>Taux de crawl Googlebot</th></tr>
</thead>
<tbody>
<tr><td>SSR pur</td><td>847ms</td><td>62%</td></tr>
<tr><td>ISR (revalidate: 3600)</td><td>124ms</td><td>94%</td></tr>
<tr><td>Pre-rendering statique</td><td>43ms</td><td>99%</td></tr>
</tbody>
</table>
</section>
</article>Comparez avec une page qui sert le même contenu dans un <div id="root"> rempli par JavaScript côté client. Le système RAG extrait le HTML, pas le DOM rendu. La différence de signal est massive.
3. Fraîcheur insuffisante
ChatGPT accorde un poids significatif à la fraîcheur du contenu lorsque la requête porte sur un sujet évolutif. Si votre article sur les Core Web Vitals date de 2023 et n'a pas été mis à jour, il sera récupéré (parce qu'il ranke dans Bing) mais écarté au profit d'un article de 2026 couvrant INP et les dernières évolutions.
La balise dateModified dans vos données structurées n'est pas décorative. Elle participe au signal de fraîcheur exploité par les systèmes RAG.
4. Absence de réponses directes extractibles
Les LLM cherchent des chunks qui répondent directement à la sous-requête. Un paragraphe qui tourne autour du sujet pendant 200 mots avant de donner la réponse sera reranké en dessous d'un paragraphe qui commence par la réponse.
C'est l'équivalent IA du format "inverted pyramid" en journalisme. Sauf qu'ici, la pénalité pour verbosité n'est pas une baisse de position — c'est l'exclusion totale de la citation.
5. Accessibilité technique défaillante
Si le crawler de ChatGPT (qui s'identifie comme ChatGPT-User dans le user-agent) est bloqué par votre robots.txt, ou si votre page retourne un 200 avec un body vide parce que le SSR est cassé, la page peut être dans l'index de retrieval (via un cache ancien) mais le contenu extrait sera tronqué ou vide — garanti d'être rejeté au reranking.
Scénario concret : un média tech de 8 000 articles face au filtre ChatGPT
Prenons le cas d'un média tech français publiant environ 8 000 articles, avec un trafic organique de 1,2 million de visites/mois. Leur monitoring montre que le crawler ChatGPT-User visite environ 3 200 URLs par mois — 40% du corpus. L'équipe SEO constate dans ses analytics que le referral "chatgpt.com" génère 14 000 visites/mois, en croissance.
Le problème
En analysant les logs serveur, l'équipe identifie que sur les 3 200 pages visitées par le crawler, seules 480 (15%) apparaissent effectivement comme citations dans les réponses ChatGPT (vérification manuelle sur un échantillon + analyse des referrals). Les 2 720 pages restantes sont récupérées mais ne génèrent aucun trafic de citation.
L'analyse
L'équipe classe les 2 720 pages rejetées en catégories :
- 1 100 pages (40%) : articles de news datant de plus de 6 mois, sans mise à jour. Sujet couvert par des sources plus récentes.
- 720 pages (26%) : tutoriels dont le contenu est quasi-identique à la documentation officielle. Aucune valeur ajoutée identifiable par le reranker.
- 540 pages (20%) : pages avec un rendu JavaScript problématique. Le contenu principal est injecté via un composant React hydraté côté client, et le HTML initial servi au crawler ne contient que le header, le footer, et un placeholder.
- 360 pages (13%) : articles pertinents et uniques, mais dont la structure éditoriale enfouit la réponse après 500+ mots d'introduction contextuelle.
Le plan d'action
L'équipe déploie un script d'audit qui croise les logs du crawler ChatGPT-User avec les données de referral pour identifier les pages à fort potentiel de citation mais actuellement rejetées :
#!/usr/bin/env python3
"""
Analyse croisée : pages crawlées par ChatGPT-User vs pages effectivement citées.
Identifie les pages "récupérées mais rejetées" à fort potentiel.
"""
import json
from collections import defaultdict
from datetime import datetime, timedelta
def parse_access_log(log_path: str) -> dict[str, list[str]]:
"""Extrait les URLs visitées par ChatGPT-User depuis les access logs."""
chatgpt_visits: dict[str, list[str]] = defaultdict(list)
with open(log_path) as f:
for line in f:
if "ChatGPT-User" not in line:
continue
# Format combiné Apache/Nginx
parts = line.split('"')
if len(parts) < 2:
continue
request = parts[1] # GET /path HTTP/1.1
method, path, _ = request.split()
timestamp = line.split("[")[1].split("]")[0]
chatgpt_visits[path].append(timestamp)
return chatgpt_visits
def load_referral_data(analytics_export: str) -> set[str]:
"""Charge les pages ayant reçu du trafic referral chatgpt.com."""
cited_pages: set[str] = set()
with open(analytics_export) as f:
data = json.load(f)
for row in data["rows"]:
if "chatgpt.com" in row.get("source", ""):
cited_pages.add(row["landing_page"])
return cited_pages
def identify_rejected_high_potential(
crawled: dict[str, list[str]],
cited: set[str],
min_crawl_frequency: int = 3
) -> list[dict]:
"""
Pages crawlées fréquemment par ChatGPT mais jamais citées.
Fréquence élevée = le retrieval les sélectionne souvent,
mais le reranker les rejette systématiquement.
"""
rejected = []
for path, visits in crawled.items():
if path in cited:
continue
if len(visits) >= min_crawl_frequency:
rejected.append({
"path": path,
"crawl_count": len(visits),
"last_crawl": max(visits),
"priority": "high" if len(visits) >= 8 else "medium"
})
rejected.sort(key=lambda x: x["crawl_count"], reverse=True)
return rejected
# Exécution
crawled = parse_access_log("/var/log/nginx/access.log")
cited = load_referral_data("ga4_export_chatgpt_referrals.json")
rejected = identify_rejected_high_potential(crawled, cited)
print(f"Pages crawlées par ChatGPT-User: {len(crawled)}")
print(f"Pages effectivement citées: {len(cited)}")
print(f"Pages rejetées à fort potentiel: {len(rejected)}")
print(f"\nTaux de citation: {len(cited)/len(crawled)*100:.1f}%")
print(f"\nTop 20 pages rejetées (les plus crawlées):")
for page in rejected[:20]:
print(f" [{page['priority']}] {page['path']} — {page['crawl_count']} crawls")Ce script permet de passer de l'intuition ("on devrait optimiser pour l'IA") à un diagnostic quantifié. Les 360 pages rejetées malgré un contenu unique deviennent la priorité absolue.
Les résultats à 8 semaines
Après restructuration des 360 articles à contenu unique (réponse factuelle en premier paragraphe, balisage sémantique enrichi, mise à jour des dates) et correction du SSR sur les 540 pages avec rendu JS problématique, le taux de citation passe de 15% à 23%. Le trafic referral ChatGPT augmente de 14 000 à 21 500 visites/mois.
C'est exactement le type de régression invisible — un SSR qui casse silencieusement sur un sous-ensemble de pages — qu'un outil de monitoring comme SEOGard détecte en continu, avant que le taux de citation ne s'effondre.
Optimiser pour le reranking, pas pour le retrieval
La plupart des guides "GEO" (Generative Engine Optimization) se concentrent sur le retrieval : être présent dans l'index, être crawlé. C'est nécessaire mais insuffisant. Le vrai levier est l'optimisation pour l'étape de reranking.
Le format "assertion-evidence"
Les modèles de reranking évaluent la densité informationnelle d'un chunk. Un format qui performe : commencer chaque section par une assertion factuelle, immédiatement suivie de la preuve.
Mauvais pattern :
"Il existe de nombreuses façons de configurer le pre-rendering. Le pre-rendering peut être utile dans certains cas. Voyons les différentes options disponibles..."
Bon pattern :
"Le pre-rendering statique réduit le TTFB de 847ms à 43ms sur un catalogue de 22 000 SKUs, contre 124ms pour l'ISR avec
revalidate: 3600."
Le second chunk a 4x plus de chances de survivre au reranking. Il contient une assertion spécifique, des chiffres, un contexte de taille, et une comparaison avec une alternative nommée.
Les données structurées comme signal de confiance
Les systèmes RAG exploitent le schema.org comme signal de confiance additionnel. Un article avec TechArticle schema, un auteur identifié avec jobTitle, des ClaimReview ou des HowTo structurés envoie un signal de fiabilité que le reranker peut exploiter pour départager deux chunks de qualité textuelle similaire.
Le FAQ schema est particulièrement intéressant dans ce contexte : il pré-structure le contenu dans un format question-réponse qui correspond directement au pattern de retrieval des LLM.
La spécificité comme avantage compétitif
Si votre page couvre le même sujet que 50 autres avec le même niveau de généralité, vous êtes interchangeable au reranking. La page qui sera citée est celle qui apporte un angle que les autres n'ont pas.
Pour un e-commerce, ça peut être des données propriétaires : "Sur notre catalogue de 15 000 produits, le passage au pre-rendering a augmenté le taux de crawl Googlebot de 62% à 94%." Aucun autre site ne peut fournir cette donnée.
Auditer votre surface d'exposition aux crawlers IA
Avant d'optimiser le contenu, vérifiez que vos pages sont techniquement accessibles aux crawlers IA. Voici la procédure d'audit.
Identifier les crawlers IA dans vos logs
Les principaux user-agents à traquer :
# Configuration Nginx : log séparé pour les crawlers IA
# À ajouter dans le bloc http {} de nginx.conf
map $http_user_agent $is_ai_crawler {
default 0;
"~*ChatGPT-User" 1;
"~*GPTBot" 1;
"~*Google-Extended" 1;
"~*CCBot" 1;
"~*anthropic-ai" 1;
"~*Claude-Web" 1;
"~*PerplexityBot" 1;
"~*Bytespider" 1;
"~*cohere-ai" 1;
}
# Log dédié crawlers IA
access_log /var/log/nginx/ai_crawlers.log combined if=$is_ai_crawler;
# Optionnel : headers de debug pour identifier le rendu servi
add_header X-Served-To $http_user_agent always;Cette configuration crée un fichier de log séparé qui ne contient que les requêtes des crawlers IA. Beaucoup plus exploitable que de grep dans un access log de 50 Go.
Vérifier ce que le crawler reçoit réellement
Le piège classique : votre page retourne un 200, mais le body contenu est un shell HTML vide en attente d'hydratation JavaScript. Pour vérifier ce que ChatGPT-User reçoit :
# Simuler la requête du crawler ChatGPT
curl -s -A "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; ChatGPT-User/1.0; +https://openai.com/bot" \
-H "Accept: text/html" \
"https://votresite.fr/guides/nextjs-ssr-ecommerce" \
| pup 'article text{}' \
| wc -w
# Comparer avec le rendu complet (via un headless browser)
node -e "
const puppeteer = require('puppeteer');
(async () => {
const browser = await puppeteer.launch();
const page = await browser.newPage();
await page.goto('https://votresite.fr/guides/nextjs-ssr-ecommerce', {
waitUntil: 'networkidle0'
});
const text = await page.evaluate(() =>
document.querySelector('article')?.innerText || 'NO ARTICLE ELEMENT'
);
console.log('Words (rendered):', text.split(/\s+/).length);
await browser.close();
})();
"Si le curl retourne 50 mots et le Puppeteer 1 500 mots, votre page a un problème de rendu pour les crawlers IA. C'est le même problème que pour Googlebot, documenté en détail dans notre article sur pourquoi Google voit une page blanche sur votre SPA.
Vérifier votre robots.txt
Beaucoup de sites ont bloqué GPTBot en 2023-2024 par réflexe (craintes sur l'entraînement des modèles) sans distinguer GPTBot (crawl pour l'entraînement) de ChatGPT-User (crawl pour la recherche en temps réel). Bloquer ChatGPT-User vous exclut des citations dans les réponses ChatGPT Search.
Vérifiez :
# robots.txt - Configuration recommandée
# Bloquer l'entraînement, autoriser la recherche
User-agent: GPTBot
Disallow: /
User-agent: ChatGPT-User
Allow: /
# Bloquer les sections sans valeur pour les citations
Disallow: /compte/
Disallow: /panier/
Disallow: /admin/
Cette distinction est critique. Consultez notre guide complet robots.txt pour les subtilités de configuration multi-agents.
Au-delà de ChatGPT : le pattern se généralise
Le ratio 15% de citation n'est pas spécifique à ChatGPT. Les systèmes Perplexity, Google AI Overviews, et les futures intégrations Copilot de Microsoft suivent tous une architecture RAG similaire avec un pipeline retrieval → reranking → synthesis.
La convergence avec les AI Overviews de Google
L'étude rejoint ce que nous avions analysé dans notre article sur la divergence entre citations AIO et rankings : les pages qui rankent en position 1 dans les résultats classiques ne sont pas nécessairement celles que l'IA cite. Le reranking des systèmes RAG utilise des critères différents du ranking traditionnel :
- Density informationnelle plutôt que popularité (backlinks)
- Extractabilité des assertions factuelles plutôt que qualité globale de la page
- Complémentarité avec les autres sources sélectionnées plutôt que pertinence absolue
Ce dernier point est rarement discuté. Un système RAG ne sélectionne pas les N meilleures sources individuellement — il optimise un ensemble de sources qui, combinées, couvrent la requête de manière complète. Votre page peut être excellente mais redondante avec une source déjà sélectionnée.
Implications pour la stratégie de contenu
L'approche SEO traditionnelle orientée "surface" — publier massivement sur des variations de mots-clés — est contre-productive dans un monde RAG. Plus vous publiez d'articles similaires sur le même sujet, plus vous diluez la densité informationnelle de chacun, et plus le reranker a de raisons de tous les rejeter au profit d'une source concurrente plus concentrée.
La stratégie gagnante est l'inverse : moins de pages, plus denses, avec des données et des angles uniques. Un article de 3 000 mots qui couvre exhaustivement un sujet avec des données propriétaires bat systématiquement 10 articles de 500 mots qui survolent le même terrain.
Préparer l'infrastructure pour le monitoring LLM
L'émergence du trafic IA comme canal d'acquisition crée un nouveau besoin de monitoring. Vous devez traquer non seulement ce que les crawlers IA récupèrent, mais aussi ce qui est effectivement cité.
Les métriques à suivre
Le trafic referral chatgpt.com, perplexity.ai, et les autres plateformes IA est le proxy le plus fiable pour mesurer les citations. Mais ce proxy a ses limites : beaucoup d'utilisateurs ne cliquent pas sur les liens sources. La citation sans clic est invisible dans vos analytics.
Pour une vision complète, croisez trois sources de données :
- Logs serveur : volume et fréquence de crawl par user-agent IA
- Referral analytics : trafic effectif depuis les plateformes IA
- Monitoring de citations : vérification manuelle ou automatisée de la présence de votre domaine dans les réponses à des requêtes cibles
C'est un domaine où la recherche de prompts devient un outil stratégique : identifier les prompts pour lesquels vous devriez être cité, vérifier si vous l'êtes, et diagnostiquer pourquoi si ce n'est pas le cas.
L'enjeu de la détection de régressions
Le scénario le plus dangereux n'est pas l'absence initiale de citations — c'est la perte silencieuse. Un déploiement qui casse le SSR sur une section du site, une mise à jour de robots.txt qui bloque accidentellement ChatGPT-User, une chaîne de redirections qui s'allonge après une migration — autant de régressions techniques qui font disparaître vos pages du pipeline de citation sans aucune alerte.
Les five infrastructure gates qui conditionnent le crawl, le rendu et l'indexation Google s'appliquent aussi aux crawlers IA, avec une tolérance souvent inférieure : là où Googlebot a un rendering service sophistiqué capable d'exécuter du JavaScript, ChatGPT-User se comporte davantage comme un crawler statique.
Le 15% n'est pas un plafond — c'est un filtre de qualité
Le ratio de 15% de citation révèle quelque chose de fondamental sur l'architecture des réponses LLM : ces systèmes sont conçus pour être sélectifs. Contrairement à une SERP qui affiche 10 résultats par défaut, un LLM ne cite que ce qui a directement contribué à sa réponse. Le nombre de citations est proportionnel à la complexité de la requête, pas au nombre de sources disponibles.
Cela signifie que le levier n'est pas d'augmenter le nombre de pages crawlées, mais d'augmenter la probabilité de survie au reranking pour chaque page crawlée. En d'autres termes : moins de pages mieux faites, techniquement irréprochables dans leur rendu, structurellement optimisées pour l'extraction, et porteuses d'information que personne d'autre ne possède.
Les marques qui l'ont compris investissent dans la densité informationnelle et l'infrastructure technique. Les autres continueront à célébrer le crawl de leurs pages par GPTBot sans réaliser que 85% de cet effort finit dans un /dev/null algorithmique. Pour éviter de découvrir ces rejets silencieux après coup, un monitoring continu de l'accessibilité technique — comme celui que propose SEOGard sur les régressions SSR, les erreurs de rendu et les blocages robots.txt — transforme un problème invisible en alerte actionable.