Tapez « notice 2044 impots » dans Google. La notice de la déclaration des revenus fonciers est un document que l'administration fiscale publie elle-même, en PDF, gratuitement, à une URL publique. C'est la source de référence, et elle n'a pas de concurrente.
Google déclenche un Aperçu IA. Il explique ce que contient la notice, énumère les rubriques, cite le seuil de 15 000 euros et le plafond de déficit foncier de 10 700 euros. Il s'appuie sur huit références. Aucune n'est un PDF. Trois sont des vidéos YouTube. Les cinq autres sont des pages HTML tenues par service-public.gouv.fr, par la plateforme Services Publics +, et par trois sites commerciaux de conseil immobilier. Le domaine impots.gouv.fr n'apparaît nulle part dans la liste des références, seulement comme lien sortant au milieu d'un paragraphe.
Le document existe. Il est ouvert. Il est officiel. Et la réponse qui le décrit a été écrite à partir de huit sources qui parlent de lui.
Ce que j'ai mesuré le 30 août 2026. J'ai récupéré les documentations robots d'OpenAI, de Perplexity et d'Anthropic, la page de Google sur les fonctionnalités IA, sa page sur les types de fichiers indexables et sa page sur la balise meta robots, et j'y ai compté le vocabulaire du document, avec à chaque fois un contrôle positif pour vérifier que la page était bien chargée et que le comptage ne portait pas sur le menu. Puis j'ai constitué un corpus de 30 documents que Google indexe réellement, tirés de deux SERP françaises à l'opérateur filetype:pdf sur « livre blanc » et sur « étude de marché 2025 secteur ». J'ai demandé chacun avec l'agent utilisateur de PerplexityBot, puis avec celui d'un Chrome récent quand le premier échouait. Sur les fichiers reçus, j'ai relevé les métadonnées, le balisage structurel, les signets, la couche texte page par page, et l'en-tête HTTP. Enfin j'ai comparé le titre affiché par Google pour chaque document à ce que contient réellement le fichier.
Le seul format que Google décrit comme un conteneur à décoder
Google tient une page qui liste les types de fichiers qu'il sait indexer. Elle a été mise à jour le 3 février 2026. Elle range ces formats en trois familles, et les mots choisis pour la deuxième famille méritent d'être lus lentement :
Supported encoded file types
The following encoded file types are supported. These are binary files or complex containers that require a specific parser to extract the human-readable text.
Le PDF ouvre cette liste, sous son nom complet, Adobe Portable Document Format. Il y côtoie les formats Office, OpenOffice, PostScript, EPUB et le RTF.
La famille précédente, celle des « flat file types », contient le HTML, le CSV, le SVG, le XML, le TeX, le texte brut et le code source, pour lequel la page nomme six langages à titre d'exemple. Google la décrit en une ligne qui dit exactement l'inverse : ce sont des fichiers « where the content is stored in plain, unencoded text ». Le texte y est déjà du texte.
Sur cette page, qui est celle où Google énumère tout ce qu'il sait lire, la famille du PDF est la seule dont la définition mentionne un obstacle à franchir avant d'atteindre le contenu. Un fichier binaire, un conteneur complexe, un analyseur spécifique. Google y déclare posséder cet analyseur. La page ne dit nulle part que quelqu'un d'autre en possède un.
La même page ajoute une précision qui a des conséquences pratiques : le type d'un fichier est déterminé par l'en-tête HTTP Content-Type renvoyé lors de l'exploration, l'extension et une seconde tentative d'analyse ne servant que de recours quand cet en-tête est absent ou faux. Dans mon corpus, un serveur sur trente renvoie application/force-download au lieu de application/pdf. Le fichier est le même, sa carte d'identité déclarée ne l'est pas.
Quatre documentations robots, zéro occurrence
J'ai cherché le vocabulaire du document dans les quatre pages où les éditeurs de moteurs expliquent aux webmasters comment leurs robots se comportent.
documentation corps pdf document contrôle positif
Google, fonctionnalités IA 14 276 0 0 AI Overviews 14
OpenAI, docs bots 14 937 0 0 GPTBot 8
Perplexity, bots 5 817 0 0 PerplexityBot 11
Anthropic, support 20 537 0 1 ClaudeBot 5
Les quatre contrôles positifs se déclenchent, donc les pages étaient bien chargées et le comptage porte bien sur leur contenu. La colonne « corps » compte les caractères du texte visible après suppression des scripts, des styles et des balises.
Zéro sur les quatre. L'unique occurrence de « document » chez Anthropic ne parle pas de format de fichier.
Il faut lire ce tableau pour ce qu'il est : un relevé de silence, dont la portée est limitée et concrète. Dans les pages mêmes où ces trois éditeurs expliquent aux webmasters ce que font leurs robots, rien n'est dit d'un fichier binaire, ni de la façon dont son texte serait extrait, ni de ce qui en serait conservé. C'est là que vous iriez chercher la réponse, et elle n'y est pas. Que ces robots refusent ou acceptent les PDF, la documentation ne permet pas d'en décider.
Six documents sur trente ne sont jamais arrivés
Avant de savoir ce qu'un moteur comprend d'un PDF, il faut savoir s'il l'obtient. J'ai demandé les 30 URL avec l'agent utilisateur de PerplexityBot.
J'ai d'abord vérifié qu'aucune consigne ne l'écartait. Sur les 30 domaines du corpus, j'ai récupéré les robots.txt et cherché les onze robots IA les plus courants, de GPTBot à Google-Extended. Dix-huit fichiers sont lisibles et contiennent des directives. Aucun des dix-huit ne nomme un seul robot IA. Deux fichiers ne contiennent aucune directive, et dix ne sont pas récupérables parce qu'une protection anti-robot renvoie du HTML à leur place, ce qui est en soi un résultat. Le contrôle positif de ce comptage tombe juste : la même commande sur lemonde.fr ne trouve rien non plus, mais sur nytimes.com et lefigaro.fr elle trouve GPTBot, ClaudeBot et CCBot nommément.
Aucun de ces éditeurs n'a donc pris de décision explicite au sujet des robots génératifs. Retenez ce point pour la suite : ce qui va bloquer six documents n'est pas une consigne, c'est une couche d'infrastructure que personne n'a réglée pour ça.
résultat pour PerplexityBot documents
PDF reçu, en-tête application/pdf 24
403, alors qu'un Chrome récent reçoit le PDF 3
403 pour tout le monde, protection au niveau du serveur 1
mur anti-robot à preuve de travail, HTML servi à la place 2
Les trois refus sélectifs viennent de banque-france.fr, de bpifrance.fr et de cdr-copdl.fr. Le même fichier, à la même URL, à la même seconde : un navigateur reçoit un PDF, PerplexityBot reçoit une page d'erreur. La distinction se fait sur l'agent utilisateur déclaré, exactement comme la page Spotify relevée dans l'article sur la transcription de podcast.
Les deux derniers cas sont les plus instructifs, et ils viennent tous les deux de HAL, l'archive ouverte de la recherche française. Les URL en /document de shs.hal.science et de sciencespo.hal.science renvoient une page HTML de 10 404 octets, à un navigateur comme à un robot. Cette page est un mur Anubis, un défi à preuve de travail que le client doit résoudre en JavaScript avant d'obtenir le fichier. Elle porte cette ligne :
<meta name="robots" content="noindex,nofollow">
Un dépôt public d'articles scientifiques sert donc, à l'emplacement de ses PDF, une page qui demande explicitement à ne pas être indexée. Google conserve l'entrée dans son index parce qu'il l'a explorée avant que le mur ne soit posé, ou parce qu'il franchit le défi. Un robot génératif qui n'exécute pas de JavaScript n'a aucun moyen d'y arriver, pour la raison décrite dans l'article sur le rendu JavaScript et les crawlers IA.
Six documents sur trente, soit un cinquième du corpus, sont visibles dans les résultats de Google et inaccessibles à un robot génératif ordinaire.
Le titre : deux branches, et 24 documents sur 24 s'y rangent
Reste les 24 fichiers effectivement reçus. C'est là qu'apparaît le résultat le plus net du relevé, et le plus facile à corriger chez vous.
Une page HTML porte une balise title. Un PDF n'en a pas. Il a un champ de métadonnées nommé /Title, facultatif, que la plupart des logiciels d'export laissent vide ou remplissent avec le nom du fichier. Sur mes 24 documents, 10 portent une valeur dans ce champ et 14 n'en portent aucune.
J'ai comparé, pour chacun des 24, le titre que Google affiche dans sa SERP au contenu réel du fichier. Le résultat se range sans exception en deux branches.
cas documents titre affiché
/Title rédigé comme un titre 7 extrait exact
/Title rempli d'un nom de fichier 3 texte de couverture
aucun /Title 14 texte de couverture
Sept documents sur sept : quand le champ /Title contient une phrase qui ressemble à un titre, Google l'affiche mot pour mot, éventuellement tronquée. Le titre de l'OCDE dans la SERP, « Perspectives économiques de l'OCDE », est le début exact de « Perspectives économiques de l'OCDE, Volume 2025 Numéro 1 (FR) ». Celui de l'OMC, « Concilier commerce et IA dans l'intérêt de tous », est la fin exacte de « Rapport sur le commerce mondial 2025: Concilier commerce et IA dans l'intérêt de tous ».
La preuve la plus nette de cette reprise littérale est un accident. Le champ /Title du Livre Blanc sur la défense hébergé par vie-publique.fr contient une chaîne mal encodée, où le « é » s'est transformé en deux caractères parasites lors d'un export mal configuré. Google affiche dans sa SERP, caractère pour caractère :
Livre Blanc sur la Défense
Personne n'a relu ce titre depuis le jour de l'export. Il est en ligne, il est le nom sous lequel ce document existe pour Google, et il est illisible.
Quatorze documents sur quatorze, dans l'autre branche : quand le champ est vide, j'ai retrouvé le titre affiché par Google mot pour mot dans le texte de la première page du fichier. Sans exception. Les trois documents dont le /Title est un nom de fichier basculent dans la même branche. La valeur BPCE_BAROMETRE_2025_8 a été écartée au profit de « Entre contraintes et désirs », qui est le titre imprimé sur la couverture. Livre-Blanc-final-070324 et la valeur par défaut Présentation PowerPoint ont subi le même sort.
La mécanique est donc lisible et falsifiable. Google prend le champ /Title quand il ressemble à un titre, l'ignore quand il ressemble à un nom de fichier, et va dans les deux derniers cas chercher le plus gros texte de la couverture.
Ce que donnent les titres qui en résultent
Une page de couverture est un objet de graphiste. Elle est composée pour un lecteur qui tient déjà le document, qui sait de qui il vient, et qui vient de cliquer dessus en connaissance de cause. Elle n'a jamais été écrite pour servir d'identifiant dans un index.
Voici quatre titres réels, tels que Google les affiche aujourd'hui pour quatre documents de mon corpus :
T3 2025
Étude de marché
CHIFFRES CLÉS 2025
Livre Blanc
Le premier est une étude trimestrielle du marché de l'investissement immobilier d'entreprise en France, signée Immprove. Le deuxième est un modèle d'étude de marché remplissable édité par la Banque Populaire. Le troisième vient de l'U2P et porte sur les Pays de la Loire. Le quatrième est le livre blanc d'une association de la petite enfance.
Aucun de ces quatre titres ne nomme l'organisation qui publie. Aucun ne nomme le secteur traité. Deux ne nomment même pas le sujet. Ce sont exactement les marqueurs d'attribution dont l'article sur l'E-E-A-T et le GEO montre qu'ils sont les seuls à survivre à l'extraction d'un passage, et ils manquent tous à l'appel dès la première ligne.
Un moteur génératif qui découpe ce document en blocs, selon le mécanisme décrit dans l'article sur les balises Hn et le chunking, attachera à chaque bloc une métadonnée de titre qui vaut « T3 2025 ». Le passage sera peut-être excellent. Il ne portera le nom de personne.
Ce qu'un PDF ne contient pas
J'ai relevé sur les 24 fichiers ce qui pourrait tenir lieu de structure.
propriété relevée documents sur
PDF balisé, hiérarchie accessible 12 24
langue déclarée dans /Lang 16 24
signets de navigation 6 24
en-tête X-Robots-Tag 0 30
Le balisage d'un PDF, activé par le champ /MarkInfo, est la seule chose qui s'approche d'une hiérarchie de titres exploitable par une machine. La moitié du corpus en est dépourvue. Les signets, qui sont l'équivalent le plus proche d'un sommaire lisible, sont présents dans six fichiers sur vingt-quatre. Dans les dix-huit autres, un document de 44 pages en médiane, jusqu'à 310 pages pour le plus long, se présente à l'extracteur comme une suite de pages sans articulation déclarée.
J'ai aussi compté les pages sans couche texte, c'est-à-dire celles où l'extraction ne rend rien parce que le contenu est une image. Sur les 694 pages échantillonnées, 21 sont dans ce cas, soit 3 pour cent. C'est peu, et c'est un bon résultat pour le corpus. Il faut le nuancer dans les deux sens. Mon échantillon est constitué de documents que Google a déjà retenus, donc probablement déjà lisibles, ce qui est un biais de sélection assumé. Et une page sans texte extrait n'est pas toujours un scan : c'est souvent une page de séparation ou une infographie pleine page, c'est-à-dire précisément le cas décrit dans l'article sur la balise alt, où le fait ne vit que dans le visuel. Dans un PDF, ce cas est pire encore, puisqu'il n'existe aucun attribut où écrire l'alternative.
La dernière ligne du tableau est la plus parlante. Google documente un mécanisme de contrôle pour les fichiers non HTML, et il n'en documente qu'un :
To block indexing of non-HTML resources, such as PDF files, video files, or image files, use the X-Robots-Tag response header instead.
Toute la famille de directives décrite dans l'article sur le contrôle des extraits reste donc disponible pour un PDF, mais uniquement par l'en-tête HTTP. Une exception près, et elle compte : data-nosnippet est un attribut HTML, il n'a aucun équivalent dans un PDF. Vous pouvez retirer un document entier des Aperçus IA. Vous ne pouvez pas en protéger un paragraphe.
Sur les 30 URL testées, aucune ne renvoie d'en-tête X-Robots-Tag. Le seul levier existe et personne dans ce corpus ne s'en sert.
Le PDF qui perd contre la page HTML de son propre éditeur
Le SELL, syndicat des éditeurs de logiciels de loisirs, publie chaque année « L'Essentiel du jeu vidéo ». C'est un PDF, il est dans mon corpus, et c'est de lui que sortent les 5,8 milliards d'euros de chiffre d'affaires du marché français en 2025.
J'ai demandé à Google « chiffres du marché du jeu vidéo en France 2025 ». Le document n'apparaît pas dans les dix premiers résultats. Voici ce qui s'y trouve à sa place :
rang domaine nature
1 afjv.com article sur l'étude du SELL
2 sell.fr page HTML de l'éditeur du PDF
3 bigmedia.bpifrance.fr article
4 statistiques.com page de chiffres
5 facebook.com publication du Monde
6 yougov.com rapport concurrent
7 blogdumoderateur.com article
8 marketresearchfuture.com rapport payant
9 instagram.com publication
Le SELL est bien présent, en deuxième position, avec sa page /lindustrie. Une page HTML, qui reprend les chiffres de son propre PDF et les met en clair dans du texte que tout le monde sait lire. La position revient donc à la page de reprise, pendant que le document d'origine reste hors du classement.
Une recherche associée proposée par Google sur cette même SERP est « LEssentiel du jeu vidéo 2025 ». Les gens cherchent le document par son nom, et ce que Google leur donne, ce sont neuf pages qui le racontent.
Je précise le périmètre de cette observation : l'Aperçu IA était présent sur cette requête mais servi de façon asynchrone, donc mon relevé ne porte que sur les résultats organiques. Je ne peux pas dire ce que l'Aperçu citait.
Ce que ça change pour votre livre blanc
L'article sur le contenu fermé a déjà traité le PDF, mais sous un seul angle : celui de l'artefact placé derrière un formulaire, inatteignable par construction. Le présent relevé porte sur le cas inverse, celui du PDF parfaitement ouvert, correctement lié, exploré et indexé. La conclusion reste sévère, avec une différence qui compte : ici, tout dépend de vous.
Écrivez le champ /Title comme vous écririez une balise title. C'est la seule branche des deux où vous gardez la main, et sept documents sur sept montrent que Google la respecte à la lettre. Une phrase, pas un nom de fichier, avec le nom de l'organisation et l'année. Dans Word, c'est Fichier puis Informations puis Titre. Dans InDesign, c'est Fichier puis Informations sur le document. Dans un export automatisé, c'est le champ Title du dictionnaire d'information.
Relisez le titre que Google affiche déjà. Une recherche site:votredomaine.fr filetype:pdf vous donne en trente secondes la liste de vos documents indexés et le nom sous lequel ils existent. C'est là que se trouvent vos « T3 2025 » et vos « Livre Blanc », et c'est probablement le premier problème que ce relevé vous permet de régler.
Mettez la conclusion sur la couverture. Puisque la couverture sert de titre par défaut à quatorze documents sur quatorze, autant qu'elle porte une phrase utile. « Marché de l'investissement immobilier d'entreprise en France, troisième trimestre 2025, Immprove » aurait produit un titre correct sans rien changer d'autre au fichier.
Publiez la substance en HTML et gardez le PDF comme objet. C'est la décision que le SELL a prise, consciemment ou non, et elle lui rapporte la deuxième position. La version web ouverte porte les chiffres et le raisonnement, le PDF garde la mise en page, les annexes et la valeur d'usage. Cette recommandation existait déjà dans l'article sur le contenu fermé, où elle servait à contourner un formulaire. Le relevé du jour lui donne un second motif, indépendant du premier : même sans formulaire, même parfaitement ouvert, le document reste un conteneur que Google seul déclare savoir décoder.
Vérifiez que vos PDF arrivent vraiment. Six sur trente ne sont pas arrivés dans mon corpus, dont trois à cause d'une protection qui filtre sur l'agent utilisateur, souvent posée par un pare-feu applicatif que personne dans l'entreprise n'a réglé pour ça. Le contrôle se fait dans les journaux serveur, comme décrit dans l'article sur l'analyse des logs de crawlers IA.
Ce que ce relevé n'établit pas
Trente documents ne sont pas un échantillon représentatif du web français, et ils ne sont pas tirés au hasard. Ce sont des documents que Google a déjà retenus et classés, ce qui introduit un biais de sélection dans un sens précis : mon corpus est probablement plus lisible, mieux formé et mieux servi que la moyenne des PDF en ligne. Les 3 pour cent de pages sans couche texte sont donc un plancher, pas une moyenne.
Le relevé ne dit rien de ce que ChatGPT, Perplexity ou Claude font d'un PDF qu'ils obtiennent. J'ai mesuré l'accès au fichier et le contenu du fichier, pas le traitement en aval. Le silence des trois documentations est un fait sur les documentations, pas une preuve d'incapacité technique : les trois éditeurs savent manifestement lire un PDF que vous téléversez vous-même dans leur interface. La question ouverte, et je ne la tranche pas ici, est de savoir si leur robot d'exploration en fait autant.
Sur la requête du jeu vidéo, l'Aperçu IA était servi de façon asynchrone et son contenu ne m'a pas été renvoyé. Je n'ai donc relevé que les résultats organiques, et je ne peux pas dire ce que l'Aperçu citait. La seule liste de références d'Aperçu IA que j'ai lue en entier est celle de la requête sur la notice 2044.
Enfin, la mécanique du titre est établie sur 24 documents, tous francophones ou européens. Elle est nette, elle explique 24 cas sur 24, et elle demande à être rejouée sur un corpus plus large avant d'être tenue pour une règle générale de Google.
Le test à faire avant d'en discuter
Prenez le PDF le plus important que vous publiez. Trois commandes, dans cet ordre.
# 1. Est-ce qu'un robot génératif l'obtient ?
curl -sS -I -L -o /dev/null \
-w "%{http_code} %{content_type}\n" \
-A "PerplexityBot/1.0" \
https://votresite.fr/votre-document.pdf
# 2. Quel titre porte-t-il vraiment ?
python3 -c "from pypdf import PdfReader; \
m=PdfReader('votre-document.pdf').metadata; \
print(repr(m.get('/Title')))"
# 3. Sous quel nom Google le connaît-il ?
# site:votresite.fr filetype:pdf
Si la première commande ne renvoie pas 200 application/pdf, arrêtez tout : le reste ne sert à rien. Si la deuxième renvoie None ou un nom de fichier, ouvrez le document et lisez le plus gros texte de la couverture, parce que c'est votre titre. Si la troisième vous montre un titre que vous n'avez pas écrit, vous savez maintenant d'où il vient.
Ce qu'il faut retenir
Le PDF appartient à la seule famille de formats que Google, sur sa page des types de fichiers indexables, décrit comme des conteneurs binaires demandant un analyseur spécifique pour en extraire le texte lisible. C'est aussi, dans cette famille, le seul format que la plupart des entreprises publient vraiment. Les trois autres éditeurs de moteurs n'en parlent pas du tout dans leurs documentations robots.
Le titre sous lequel ce document existe dans un index ne vient presque jamais d'une décision. Sur 24 fichiers, il vient sept fois du champ /Title recopié à la lettre, mojibake compris, et dix-sept fois du texte imprimé sur la couverture. Cela donne des documents indexés sous le nom de « T3 2025 » ou « Étude de marché », sans organisation, sans secteur, parfois sans sujet.
Trois gestes en découlent, dans cet ordre d'importance. D'abord, publier la substance en HTML et laisser au PDF la mise en page et les annexes : c'est le seul des trois qui change ce qu'un moteur peut citer de vous, et c'est ce qui vaut au SELL la deuxième position sur les chiffres de son propre marché. Ensuite, écrire le champ /Title comme une balise title, puisque sept documents sur sept montrent que Google le respecte à la lettre. Enfin, vérifier que le fichier arrive vraiment, parce que six sur trente ne sont pas arrivés dans mon corpus, sans qu'un seul robots.txt l'ait demandé.
Ce dernier écart, entre ce qu'un site croit publier et ce qu'un robot génératif reçoit vraiment, ne se voit dans aucun outil de vérification de balises. C'est précisément ce que couvre notre audit GEO, et le vocabulaire de ces sujets est détaillé dans notre glossaire.