Google et les PDF : conversion en HTML, classement normal et six pièges

L’essentiel

• Google convertit chaque PDF en HTML pendant l’indexation, juste après le rendu.
• Les liens d’un PDF sont repris, mais ses images ne seraient probablement pas traitées par Google Images.
• Selon Martin Splitt, un PDF est indexé et classé comme un autre document, AI Overviews et Mode IA compris.
• La documentation de Googlebot fixe à 64 Mo la part d’un PDF explorée ; le llms.txt en PDF reçoit un « non » net.

Conversion : le PDF devient une page HTML avant l’index

Martin Splitt rappelle qu’un PDF est un format binaire, une sorte de « conteneur », et non du texte brut. Google ne l’ouvre pas avec une visionneuse. Un composant appelé convertisseur intervient pendant l’indexation, « juste après le rendu et juste avant que quelque chose n’entre éventuellement dans l’index » (traduction). Google dispose de convertisseurs pour plusieurs formats (fichiers texte enrichi, documents bureautiques, feuilles Excel et même documents Lotus Notes), dont un pour les PDF.

Objectif : produire une version HTML du fichier, parce que le reste de la chaîne de traitement « ne fonctionne pratiquement qu’avec du HTML » (traduction). Images et vidéos suivent des circuits distincts. Les échanges sont consultables sur la page de l’épisode et dans sa transcription.

Liens suivis, images probablement ignorées par Google Images

La conversion a une conséquence directe : les liens d’un PDF se retrouvent dans sa représentation HTML, et les systèmes de Google les traitent comme ceux d’une page web. Sur les images, Martin Splitt se montre bien moins affirmatif. Google comprend qu’une image est présente, mais la recherche d’images travaille à partir de l’URL de chaque fichier, et une image intégrée à un PDF n’en a pas. « Je ne pense pas que nous puissions la traiter comme une image normale pour la recherche d’images. Mais cela pourrait changer, ou avoir déjà changé » (traduction), précise-t-il, en parlant de sa « compréhension actuelle ».

Taille : 64 Mo documentés pour l’exploration, le reste à l’état d’hypothèse

Interrogé par John Mueller, Martin Splitt dit ne pas connaître le seuil propre aux PDF. Il suppose que leur récupération obéit à une limite plus large que celle des pages web, comme pour les images et les vidéos, puis qu’une seconde limite s’applique à la version HTML issue de la conversion. Il ne se souvient même plus du chiffre retenu pour le HTML (« deux mégaoctets ? », traduction).

Pour rappel, la documentation de Googlebot, mise à jour le 3 février 2026, chiffre déjà le premier seuil. Pour la recherche Google, Googlebot explore les 2 premiers Mo d’un type de fichier pris en charge et les 64 premiers Mo d’un PDF, mesurés sur les données non compressées. La limite qui s’appliquerait ensuite à la version HTML n’y figure pas.

Google ne tient pas à graver ces seuils dans le marbre, explique Martin Splitt, parce qu’ils peuvent bouger et qu’un chiffre publié circule pendant des années. Si les PDF de 100 Mo devenaient courants, la limite pourrait être relevée. John Mueller invite les SEO à la mesurer eux-mêmes, par exemple en prenant un PDF du Projet Gutenberg et en cherchant la phrase où l’indexation s’arrête.

Classement et recherche IA : aucun traitement à part

Une fois converti, un PDF est indexé et classé « à peu près comme n’importe quel autre document » (traduction), selon Martin Splitt. Il peut apparaître dans les AI Overviews et le Mode IA, puisqu’il s’agit en interne d’une page HTML ordinaire. Google ne se soucie pas qu’un contenu ait d’abord été un PDF, pas plus qu’il ne garde trace d’un contenu généré en JavaScript. John Mueller pointe une limite : un livre entier dans un seul PDF pose la même difficulté qu’un livre sur une seule page HTML, celle de savoir quel passage justifie le classement.

Le GEO n’occupe qu’une minute environ, en fin d’épisode. Pour John Mueller, les PDF fonctionnent, « au moins chez Google » (traduction), et il dit en avoir vu cités par d’autres systèmes d’IA. Il suppose que ces systèmes veulent s’entraîner sur ces contenus et s’en servent probablement aussi pour ancrer leurs réponses (grounding). Publier en PDF n’est donc pas « une façon de détruire votre GEO » (traduction). Martin Splitt enchaîne : « un bon SEO, c’est un bon GEO » (traduction), en ajoutant « au moins sur les nôtres », à propos des systèmes d’IA de Google.

Le llms.txt enregistré en PDF avait ouvert l’épisode. Réponse de Martin Splitt : non. Ce fichier est censé offrir aux LLM le contenu sous la forme la plus simple possible, « et le PDF n’est pas la forme de contenu la plus simple du web » (traduction).

Six pièges relevés par les deux Googlers

• Pages rastérisées (texte enregistré comme image) : le pire cas pour Martin Splitt. Son test : tout sélectionner, copier, puis coller dans un fichier texte ou un Google Doc. Si rien n’apparaît, Google ne voit pas le contenu non plus. Certains systèmes savent faire de l’OCR, mais on ne peut pas compter dessus, ajoute John Mueller.
• Copies à l’identique : un PDF repris sur un autre site reste exactement le même fichier, ce qui complique la canonicalisation. John Mueller évoque l’en-tête HTTP Link avec rel="canonical", peu utilisé car fastidieux, et un lien vers le site placé en haut du document, que Google conserve lors de la conversion.
• Métadonnées : Martin Splitt conseille de renseigner l’auteur, une description, voire un lien vers la source d’origine.
• Mot de passe : il empêche les moteurs de lire le contenu. Bloquer le fichier dans le robots.txt empêche aussi Google de l’examiner.
• Recrawl : selon John Mueller, Google revisite les PDF moins souvent que le HTML. Pour une mise à jour, changer de nom de fichier permet à Google de repérer une nouvelle URL à explorer.
• PDF générés par le CMS (bouton « version PDF ») : ils peuvent concurrencer la page HTML et rester indexés avec un contenu périmé.

Sur le menu de restaurant en PDF, John Mueller se dit pragmatique. Un menu en PDF vaut mieux que pas de menu du tout. Mais si une page HTML est facile à tenir à jour, elle reste préférable : on y zoome mieux, elle s’adapte au mobile et se charge un peu plus vite.

Ce que j’en retiens

L’épisode ne bouscule rien. Il confirme qu’un PDF n’est pas désavantagé tant que son texte se sélectionne, et le test du copier-coller est le premier à faire sur les fichiers qui comptent. Viennent ensuite deux réflexes simples à adopter : un lien vers le site en tête de document, et une nouvelle URL à chaque version plutôt que d’attendre un recrawl. Pour un fichier destiné aux machines comme le llms.txt, le texte brut reste la seule option sensée.

Je sépare nettement le documenté de l’avis personnel. Le plafond de 64 Mo figure dans la documentation de Googlebot. Le sort des images et la limite appliquée à la version HTML sont des suppositions de Martin Splitt, qu’il présente d’ailleurs comme telles. Côté suivi, le rapport Performance de la Search Console filtré sur les URL contenant « .pdf » montre la part de trafic qui passe par ces fichiers et aide à repérer les PDF qui concurrencent une page HTML.

Quand un PDF occupe la place qu’une page devrait tenir, le sujet n’est plus le fichier mais la conception du site : quel format répond à quelle recherche.