Dans l’épisode 115 du podcast Search Off the Record, publié en octobre 2026, Martin Splitt décrit ce que Google fait réellement d’un fichier PDF : un composant baptisé converter le transforme en page HTML, juste après le rendu et juste avant l’indexation. À partir de là, le reste de la chaîne ne voit plus qu’une page web.

Une règle pratique en découle : ce qui survit à cette conversion sert pour le référencement, c’est-à-dire le texte extractible, les liens et les métadonnées.

Ce qui n’y survit pas n’existe pas pour Google : les images, les pages scannées, la mise en page. Et comme un PDF ne peut porter aucune balise meta, presque tout le pilotage se fait dans l’en-tête HTTP que votre serveur envoie avec le fichier.

Un converter, et plus rien qui ressemble à un PDF

Martin Splitt explique ensuite pourquoi Google procède à cette conversion

Le PDF est un conteneur binaire : ouvert dans le même éditeur, il affiche une suite de caractères illisibles.

Google n’utilise pas de lecteur PDF. Il passe le fichier dans un converter, l’étape du pipeline d’indexation qui traduit un format de fichier en HTML. Il en existe pour le RTF, les documents Word, les feuilles Excel et même les documents Lotus Notes. Seules les images et les vidéos suivent un autre circuit.

Mueller l’avait déjà écrit sur Twitter en août 2018 : Google convertit les PDF et les formats voisins en HTML pour les indexer. Ce podcast récent précise l’emplacement de cette étape et ses conséquences.

L‘indexation et le classement sont donc gérés de la même façon que pour n’importe quel document. Martin Splitt résume en une phrase : « we don’t care if something was a PDF originally ». Un PDF peut donc apparaître dans les AI Overviews et dans l’AI Mode. Mueller ajoute qu’il en a vu cités par d’autres systèmes d’IA, qui s’en servent selon lui pour l’entraînement et pour le grounding, c’est-à-dire l’ancrage des réponses générées sur des documents récupérés au moment de la requête. Google indexe des PDF depuis 2001, et en comptait déjà des centaines de millions en 2011.

Le test du copier-coller

Par contre, pour que la conversion se passe bien, il faut que le PDF soit convertible.

Splitt désigne le pire cas : les pages rastérisées, où chaque page du PDF est stockée comme une image. Tout le texte est perdu pour Google. Le diagnostic qu’il propose prend dix secondes : ouvrir le PDF, tout sélectionner, copier, coller dans un éditeur de texte. Si le texte apparaît, Google peut le lire. S’il n’apparaît pas, le contenu est invisible.

Les PDF issus de numérisations posent le même problème. Sur ce point, les déclarations de Google ont glissé :

• En septembre 2011, Gary Illyes écrivait sur le blog Google que le moteur pouvait appliquer la reconnaissance optique de caractères (OCR) au texte intégré sous forme d’image.
• En 2026, Mueller dit que certains systèmes savent le faire, mais qu’on ne peut pas compter dessus.

Le test du copier-coller reste donc le seul contrôle fiable côté éditeur.

Deux autres cas aboutissent au même résultat :

• Un PDF protégé par mot de passe ou chiffré n’est pas indexé. Le blog de 2011 le disait, Splitt le répète.
• Les images intégrées ne vont pas dans Google Images. La recherche d’images travaille à partir d’URL d’images, et une image enfermée dans un PDF n’en a pas. Splitt pense que Google détecte leur présence sans pouvoir les traiter. La consigne de 2011 n’a pas changé : pour qu’une image soit indexée, elle doit figurer sur une page HTML.

Les liens sont bien conservés, mais pour leur « linkjuice » on ne sait pas

Les liens, eux, survivent à la conversion. Mueller le formule dans l’épisode : c’est...