Structured content
core/paragraph
ChatGPT ne “lit” pas le web comme un moteur de recherche classique. Son stack de retrieval combine un index propriétaire très minimal, un cache de lecture partagé à l’échelle mondiale, et un petit lot de pages consultées en live quand le contexte l’exige. Une étude RESONEO (1 200 réponses, 88 000 résultats, 26 900 pages) a cartographié ces trois étages, jusqu’à identifier les pipelines internes après la disparition soudaine du champ “result_source”. Le tableau qui en ressort est net : efficacité maximale, coût minimal, et des règles de récupération de données qui n’ont rien d’ésotérique une fois posées à plat.
core/paragraph
Le cœur du routage est économique. En mode rapide, l’assistant sert presque uniquement l’index maison (“labrador”) et répond avec des titles complets et des snippets figés d’environ 200 caractères. En mode avancé, il paie pour des résultats Google via des prestataires, ouvre de vraies URLs, et s’autorise plus de sources. Côté performance, ce choix explique des écarts massifs de citations, de fraîcheur et de profondeur de lecture. Pour le SEO, la conséquence est directe : optimiser ce que l’assistant voit vraiment, dès les 200 premiers caractères après le H1, tout en restant sous 4 Mo et lisible sans JavaScript.
core/list
En bref — les points à retenirTrois étages : un index propriétaire, un cache partagé, quelques pages consultées en live.Routage éco : gratuit = “instant” (index interne) ; payant = “thinking” (Google scrapé + ouvertures d’URLs).Snippet figé ~200c : ancré sur le H1, indépendant de la requête, meta description ignorée par l’index interne.Cache mondial : copies en markdown, fraîcheur ~30 min, no-store/noindex ignorés, recrawl dicté par la demande.Limites du fetch : pas de JS exécuté, 4 Mo max sinon rejet total, alt image conservés, texte masqué extrait.Trafic invisible : l’utm_source manque sur les pages ouvertes en thinking ; suivez le user-agent ChatGPT-User.Optimisation : title phrase complète, message clé dans les 200 premiers caractères, pages légères et lisibles sans JS.
core/heading
Stack de retrieval de ChatGPT : l’index, le cache et les pages réellement consultées
core/paragraph
Premier étage : un index web propriétaire, distinct de Bing. Les recoupements montrent des URLs, titles et snippets qui ne correspondent pas aux normes Bing (titles non tronqués, parfois jusqu’à 289 caractères). Chaque résultat livre trois éléments : l’URL, le title complet, un snippet d’environ 200 caractères, figé à l’indexation et identique quelle que soit la requête.
core/paragraph
Deuxième étage : un cache de lecture partagé par tous. Les pages déjà lues sont stockées en markdown et servies pendant ~30 minutes en stale‑while‑revalidate. Troisième étage : un petit volume de pages consultées en direct par le robot ChatGPT-User, surtout en mode avancé, pour des réponses qui le justifient.
core/heading
Index propriétaire, pas Bing : ce que cela change pour le moteur de recherche de ChatGPT
core/paragraph
Dans les logs observés, “labrador” orchestre l’index interne (web, news, arXiv, Reddit, YouTube, dépôts ouverts, presse). “bright” et “oxylabs” renvoient des classements Google achetés en live. Côté verticales, P1/P2/P3 adressent le shopping via des feeds dédiés ; B1/B3 servent le local via Yelp/Tripadvisor, avec des liens affichés qui redirigent vers Google Maps.
core/paragraph
Concrètement, l’index interne pilote la visibilité en mode rapide. Les résultats “bright” ressemblent à des SERP Google classiques (titles coupés, meta descriptions reprises une fois sur trois). Résultat : une optimisation qui diffère selon le pipeline routé, surtout sur le snippet et le title.
core/paragraph
Pourquoi ce choix hybride ? Pour la performance perçue et le coût. L’index maison répond vite et presque sans dépense externe ; le scraping Google est réservé aux requêtes qui exigent fraîcheur et profondeur. L’essentiel, pour vous : adapter la page au pipeline dominant sur votre audience.
core/heading
Modes instant et thinking : routage économique, performance et récupération de données
core/paragraph
Le mode instant sert majoritairement l’index interne. Dans les captures étudiées, 93 % des réponses rapides n’ouvrent aucune page. Le modèle compose avec le title et un snippet figé de ~200 caractères, rien d’autre. En face, le mode thinking appelle surtout des résultats Google via bright, et déclenche des pages consultées en vrai.
core/paragraph
Les chiffres ancrent l’enjeu. Sur un corpus large, 61 332 URLs apparaissent en sources, 5 032 deviennent sources principales, 759 sont réellement ouvertes (toutes en thinking). Une page ouverte est citée dans 74 % des cas, une page seulement “remontée” l’est dans 7 %. Le routage paie d’abord ce qui coûte… quand l’utilisateur paie aussi.
core/list
Signaux à surveillerLogs serveur pour le user-agent ChatGPT-User (vraies pages consultées).Paramètre API renvoyant la date de crawl d’une copie stockée pour vos URLs.Présence ou absence d’utm_source=chatgpt.com sur les clics sortants (attention : absent sur les ouvertures thinking).Poids des pages (< 4 Mo) et rendu sans JavaScript.
core/paragraph
Conséquence stratégique : le mode gratuit concentre l’audience et dépend de l’index interne. Gagner l’instant, c’est optimiser ce que l’assistant voit sans ouvrir la page.
core/heading
Le cache de lecture partagé : markdown, 30 minutes, et limites 4 Mo
core/paragraph
Le cache stocke des pages complètes en markdown, partagées entre tous les utilisateurs. Pendant ~30 minutes, la copie est servie directement ; au-delà, une version périmée part tout de suite et un rafraîchissement s’exécute en arrière-plan. Le rythme de recrawl dépend donc du volume de requêtes posées à propos de votre page.
core/paragraph
Spécificités notables : no-store et noindex sont ignorés sur ce chemin. JS non exécuté. 4 Mo stricts : au‑delà, rejet complet (HTTP 400), rien n’est lu. Les alt d’images survivent, le texte masqué par CSS est extrait, et le JSON‑LD disparaît. Une API permet de récupérer la date de dernière lecture d’une URL côté cache, un indicateur d’exposition trop peu exploité.
core/paragraph
Traduction SEO : rester léger, lisible sans JS, et soigner le haut de page. Un cache mondial impose une hygiène de contenu universelle.
core/heading
Citations, mémoire et sources “fantômes” : ce que ChatGPT montre vraiment
core/paragraph
Paradoxe observé : des URLs sans snippet (hors Reddit, YouTube, arXiv) sont citées plus souvent en mode instant que celles dotées d’un snippet. Hypothèse de travail : la “mémoire” interne du modèle propose parfois des racines de domaines déjà connues, suffixées proprement en utm, sans passer par un résultat de recherche visible.
core/paragraph
Autre bizarrerie : arXiv et Reddit sont massivement récupérés pour “réfléchir”, mais rarement cités en sortie. Être récupéré et être cité sont deux marchés différents. Pour mesurer l’impact réel, ne vous fiez pas qu’au paramètre utm_source ; les ouvertures en thinking, elles, n’en laissent souvent aucune trace.
core/paragraph
Conclusion opérationnelle implicite : l’attribution est partielle, la lecture peut être invisible, et seule une observation serveur + API donne l’image complète.
core/heading
Optimisation SEO pour cette stack : titles, H1, contenu utile et poids de page
core/paragraph
Ce que le modèle voit d’abord en instant : le title complet et ~200 caractères après le H1. Placez l’info vitale ici. Écrivez un title “phrase” autonome plutôt qu’un libellé tronqué. Repoussez labels, dates et widgets après la première phrase utile.
core/paragraph
Gardez la meta description (utile sur les pipelines Google). Restez sous 4 Mo. Rendez la page lisible sans JavaScript. Préservez un alt d’image informatif en haut de page. L’optimisation vise d’abord ce que l’assistant lit sans ouvrir la page, puis ce qu’il lira via le cache.
core/list
Checklist expressTitle = phrase complète avec bénéfice clair.200 premiers caractères après H1 = réponse condensée.Poids page < 4 Mo, CSS/HTML propres, pas de rendu critique au JS.Alt image descriptif au-dessus de la ligne de flottaison.Surveillez ChatGPT-User et la date de crawl côté API.
core/paragraph
But final : maximiser le grounding utile, au moindre coût de crawl pour l’assistant… et pour vous.
core/heading
Cas d’usage concret : aligner le contenu sur les vraies questions des utilisateurs
core/paragraph
Exemple fil rouge : une marque de poussettes vise “châssis 49 cm”. Les requêtes adressées à ChatGPT disent autre chose : “passe les portiques du métro”. En reformulant le title en phrase claire et en plaçant la réponse pratique dans les 200 premiers caractères, la page devient immédiatement plus pertinente pour le stack de retrieval interne.
core/paragraph
Même logique pour l’audio : peu de gens demandent la dureté de la mousse d’un casque. Ils cherchent “casque confortable avec lunettes”. En adoptant la langue des clients (avis, SAV, forums) et en la rendant crawlable, la page gagne à la fois en performance IA et en conversions humaines. Pourquoi se priver d’un double bénéfice ?
core/paragraph
Insight clé : posséder les réponses concrètes dans les mots du public aligne SEO, RAG et expérience utilisateur.
core/heading
Zones encore floues en 2026 : observe, teste, recoupe
core/paragraph
Des angles restent ouverts : quel robot nourrit précisément l’index interne quand OAI‑SearchBot reste discret ? Comment YouTube est‑il agrégé sans empreinte publique claire ? Pourquoi la sur‑citation d’URLs sans snippet ? Le système bouge vite : champs masqués, providers anonymisés, routage en évolution.
core/paragraph
Pour avancer, exploitez le trio observation serveur + API crawl date + replays multi‑comptes/pays. Et recoupez avec vos gains de visibilité dans les conversations. Les données consolidées, la méthode et les exemples sont publiés ici : think.resoneo.com/chatgpt-retrieval.
core/paragraph
Ligne directrice : l’exploration continue paie. Les fondamentaux, eux, paient toujours.