Google convertit les PDF en HTML avant de les indexer, puis les classe comme des pages web, jusque dans AI Overviews et AI Mode. Martin Splitt et John Mueller, de l’équipe Search Relations, l’ont détaillé le 13 octobre dans l’épisode 115 du podcast « Search Off the Record », consacré à l’indexation des PDF. Contrepartie : ces fichiers sont réexplorés bien moins souvent que les pages, ce qui oblige les marques qui publient catalogues, lookbooks, fiches techniques ou menus à faire le tri.
Ce que Google fait d’un PDF, de la conversion au classement
Un PDF n’est pas du texte brut mais un conteneur binaire. Pendant l’indexation, un convertisseur le transforme en représentation HTML, pour que le reste du pipeline le traite comme une page ordinaire. Les liens texte du document sont conservés et explorés. Qu’ils transmettent du PageRank était déjà connu.
Une fois converti, le fichier suit le même chemin qu’une page. « L’indexation et le classement sont à peu près les mêmes que pour n’importe quel autre document », résume Martin Splitt, cité par Search Engine Journal. Selon le même média, John Mueller ajoute que ces PDF « peuvent aussi apparaître dans AI Overviews, AI Mode, et tout le reste ». Google indique aussi qu’ils sont accessibles aux modèles d’IA pour l’entraînement et l’ancrage des réponses (le « grounding »).
Il faut garder la mesure. Barry Schwartz, de Search Engine Roundtable, rappelle que presque tout ce contenu avait déjà été traité et que Google s’est peu étendu sur la recherche IA. Rien n’indique qu’un PDF soit favorisé ou pénalisé face au HTML comme source d’une réponse générée, et Mueller estime que le HTML classique reste probablement meilleur pour le classement. Il s’agit du fonctionnement général de l’indexation, sans différence signalée selon les pays. L’épisode, en anglais, est disponible sur la page officielle du podcast.
Taille, images, mises à jour : les limites qui pénalisent l’indexation des PDF
La documentation de Google fixe un plafond. Googlebot explore les 64 premiers Mo d’un PDF, contre 2 Mo pour une URL HTML ou un autre type de fichier pris en charge. Au-delà, l’exploration s’arrête et seule la partie téléchargée part en indexation, la limite portant sur les données décompressées. Le chiffre est rappelé sur le blog Google Search Central de mars 2026.
Dans l’épisode, les deux intervenants n’ont pourtant cité aucun seuil, ce que PPC Land a relevé. L’un d’eux évoque même une possible limite distincte pour la version HTML convertie. Rien n’est confirmé, mais un très gros catalogue pourrait n’être lu qu’en partie, même sous les 64 Mo.
Les images posent un autre problème. Celles qui sont intégrées dans un PDF n’ont pas d’URL propre et ne rejoignent généralement pas Google Images, selon la synthèse de Search Engine Roundtable. Un PDF fait de pages scannées ou rastérisées n’est, lui, pas lisible sans OCR. Le test proposé est simple : sélectionnez le texte, copiez-le, collez-le dans un éditeur. Si rien ne vient, le document est probablement difficile à indexer. Un PDF protégé par mot de passe n’est pas lu du tout.
Reste la fraîcheur. Google traite les PDF comme des fichiers plutôt statiques, au même titre que les images, et les réexplore beaucoup moins souvent que le HTML, sans fournir de chiffre. Les versions « imprimables » générées automatiquement par certains CMS deviennent alors un piège : elles peuvent concurrencer la page d’origine dans les résultats tout en restant périmées. Côté lecteur, un PDF doit être téléchargé en entier sur mobile, ne se réorganise pas au zoom et peut gêner les lecteurs d’écran s’il n’est pas structuré pour l’accessibilité.
Garder, corriger ou refaire en HTML : la décision se prend document par document
La recommandation de Google est nette : le HTML par défaut, le PDF quand la mise en page imprimée doit rester fixe, pour un formulaire hors ligne ou une documentation papier. Pour un restaurant, un menu en PDF vaut mieux que pas de menu, mais une page responsive fait mieux. Chez Snazzy, on juge pourtant le réflexe « tout en HTML » aussi risqué que l’immobilisme. Un PDF bien classé est indexé comme une page, et le remplacer revient à changer d’URL, avec redirection et suivi à la clé. Avant de trancher, passez chaque fichier au crible de cinq questions :
- Reçoit-il déjà des impressions et des clics dans la Search Console ?
- Son texte se copie-t-il, ou s’agit-il d’images ?
- Son contenu change-t-il souvent (prix, collection, carte saisonnière) ?
- La mise en page fixe est-elle indispensable à son usage ?
- Une page HTML équivalente existe-t-elle déjà sur le site ?
Un livre blanc qui se classe bien, au texte sélectionnable, se garde et s’optimise. Un lookbook composé d’images gagne à devenir une page HTML : son texte est quasi invisible et ses visuels n’atteignent pas Google Images. Un menu ou un catalogue aux prix mouvants souffre d’un autre mal, la réexploration lente, qui laisse traîner des informations périmées dans les résultats. Les versions imprimables produites par le CMS sont à désactiver ou à exclure de l’index, puisqu’elles concurrencent vos vraies pages.
Entre les deux, une voie prudente existe. Google a déjà indiqué que publier le même contenu en PDF et en HTML ne pose pas de problème. Vous pouvez donc créer la page HTML sans supprimer un PDF qui performe, et relier les deux.
Les réglages qui rendent un PDF lisible pour Google et les IA
Pour les fichiers que vous conservez, tout se joue à l’export. Un catalogue exporté avec son texte sélectionnable se lit, alors que la même maquette aplatie en images reste muette. Visez un poids très en dessous des 64 Mo, ne serait-ce que pour les lecteurs sur mobile qui doivent tout télécharger avant de voir la première page. Et remplissez les métadonnées du document.
Placez des liens bien visibles vers votre site dans l’en-tête du document : ils sont explorés et ramènent le lecteur vers vos pages produits. Si vos fiches techniques circulent chez des distributeurs, sachez que deux copies identiques d’un PDF sont des « binary blobs » (fichiers binaires) identiques, difficiles à rattacher à un domaine. Google cite trois parades : un en-tête HTTP rel= »canonical », des métadonnées PDF bien remplies et ces liens placés en tête de document.
Pour une mise à jour, ne remplacez plus le fichier sous la même adresse. Google conseille de publier la nouvelle version sous un nouveau nom de fichier ou une nouvelle URL, par exemple en datant le nom du catalogue. Pensez ensuite à faire pointer vos liens internes vers la nouvelle version. Si vous préparez un fichier llms.txt pour les moteurs IA, gardez-le en texte brut : Google juge l’enregistrer en PDF comme une mauvaise idée.
Par où commencer d’ici la fin du mois
Cette semaine, filtrez dans la Search Console les URL qui se terminent par « .pdf » et notez celles qui génèrent des impressions. Ce sont les documents à ne pas convertir à la légère. Passez ensuite chaque PDF au test du copier-coller, puis recensez les versions imprimables créées par votre CMS. Avant la saison des catalogues de fin d’année, fixez une règle de nommage pour les mises à jour, afin que Google découvre vite les nouvelles éditions.
Plusieurs points restent flous : la limite éventuelle sur la version convertie n’est pas documentée, Google ne chiffre pas la fréquence de réexploration et le poids réel des PDF dans les réponses IA reste inconnu. Pour un inventaire de vos PDF et une décision argumentée sur chacun, notre équipe peut s’en charger dans le cadre d’un audit SEO de votre site.
