Recherche Google sur les PDF : conversion, liens, HTML, classement, limites, exploration...

Martin Splitt et John Mueller de Google viennent de publier un podcast Search Off the Record sur le thème des PDF, intitulé PDFs in Search: Indexing, AI & Pitfalls. Il explique comment les PDF sont convertis pour l'exploration et l'indexation, comment Google traite les liens, les images, quelles sont les limites des fichiers et leur classement dans la recherche et la recherche IA.

Le podcast est divisé en chapitres :

00:50 – Pouvez-vous enregistrer un fichier LLMs.txt au format PDF ?
01:56 – Texte brut ou conteneur binaire : qu'est-ce qui différencie les PDF du HTML ?
03:08 – Dans le pipeline de conversion de Google : transformation de PDF en HTML pour l'indexation.
05:08 – Extraction d'images et de liens à partir de fichiers PDF.
06h04 – Limites d'exploration, tailles de fichiers et seuils de coupure de test.
08h35 – Quand est-il judicieux de publier un PDF ?
09h33 – Les PDF sont-ils classés dans la recherche, les aperçus de l'IA et le mode IA ?
11h22 – Pièges techniques : pages rastérisées, images numérisées et accessibilité.
12h53 – Retards de connexion mobile, verrouillage de la mise en page et problèmes de zoom.
14h12 – Défis de canonisation avec des « blobs binaires » en double.
15h57 – Métadonnées, protection par mot de passe et mise à jour des fichiers PDF.
18h59 – Le problème avec la génération dynamique de PDF CMS.
21h08 – Le débat sur le menu du restaurant : pages Web PDF ou HTML.
23h00 – PDF pour la mise à la terre GEO (Generative Engine Optimization) et AI.

La vérité est que nous avons couvert la plupart de ces choses, peut-être en dehors de l'aspect de recherche GEO/IA, dont Google n'a pas beaucoup parlé.

Voici notre ancienne couverture de ce que Google a dit sur les PDF, je suis sûr qu'il me manque des choses :

Voici comment je le résumerais après l’avoir écouté deux fois et lu la transcription :

Comment Google traite et classe les PDF :

Conversion HTML : les PDF sont des fichiers conteneurs binaires plutôt que du texte brut. Au cours du pipeline d'indexation, Google utilise un composant de conversion pour transformer les PDF en une représentation HTML, permettant ainsi aux systèmes de recherche internes de les traiter comme des pages Web classiques.
Liens et médias intégrés : étant donné que les PDF sont convertis en HTML, les liens texte intégrés sont conservés et explorés normalement. Cependant, les images intégrées dans les PDF ne disposent pas d'URL autonomes. Elles ne peuvent donc généralement pas être traitées dans Google Image Search de la même manière que les images Web standard.
Recherche et visibilité de l'IA : les fichiers PDF convertis sont classés et indexés en utilisant les mêmes systèmes fondamentaux que les documents HTML standard. Ils peuvent apparaître dans les aperçus de l’IA et sont accessibles aux modèles d’IA à des fins de formation et de mise à la terre.
Limites de taille d'exploration : la limite d'exploration des fichiers PDF est supérieure à la limite des pages HTML standard. Google ne documente délibérément pas de seuil exact, car les seuils d'exploration sont ajustés au fil du temps à mesure que les normes de taille de fichier évoluent. Bien que Google le documente.

Pièges techniques et défis UX :

Documents pixellisés et numérisés : si un PDF est composé d'images numérisées ou de pages pixellisées plutôt que de texte, les moteurs de recherche ne peuvent pas lire le contenu sans OCR. Les propriétaires de sites peuvent tester cela en mettant en surbrillance, en copiant et en collant le texte du PDF dans un éditeur de texte.
Problèmes de mobile et d'accessibilité : les fichiers PDF doivent être entièrement téléchargés avant d'être rendus sur des appareils mobiles et avoir des mises en page d'impression fixes qui ne redistribuent pas le texte lors d'un zoom. Ils peuvent également constituer des obstacles pour les lecteurs d’écran s’ils ne sont pas structurés de manière accessible.
Canonicalisation et duplication : étant donné que les fichiers PDF identiques sont des doublons binaires exacts, la canonisation inter-domaines est difficile. Les éditeurs peuvent atténuer les problèmes de contenu en double en utilisant les en-têtes HTTP rel=canonical, en remplissant les champs de métadonnées PDF et en plaçant des liens visibles vers leur site Web dans l'en-tête du document.
Restrictions d'accès : la protection par mot de passe empêche les robots des moteurs de recherche de lire ou d'indexer le contenu PDF.

Fréquence d'exploration et mises à jour :

Taux de réexploration plus lents : Google traite les fichiers PDF comme des fichiers binaires relativement statiques (semblables aux images) et les réexplore beaucoup moins fréquemment que le HTML.
Modification des noms de fichiers pour les mises à jour : étant donné que les réanalyses prennent plus de temps, les éditeurs ayant besoin d'indexer rapidement un PDF mis à jour doivent le publier sous une nouvelle URL ou un nouveau nom de fichier plutôt que d'écraser le fichier existant.
Éviter les PDF « à imprimer » générés automatiquement : les outils CMS automatisés qui génèrent des doublons PDF de pages Web en direct peuvent entraîner une concurrence entre les deux versions dans les résultats de recherche, laissant la version PDF obsolète car elle est réexplorée moins souvent.

Recommandations SEO :

HTML par défaut : le HTML est plus facile à modifier, réactif sur les écrans mobiles et plus rapide à indexer.
Utiliser les PDF de manière sélective : les PDF sont appropriés lorsque le contenu nécessite un format d'impression rigide, des formulaires téléchargeables hors ligne ou une documentation papier. Pour les petites entreprises comme les restaurants, un menu PDF est acceptable si la création d'un équivalent HTML n'est pas pratique.
Conserver le texte brut llms.txt : les fichiers destinés à la consommation automatique (comme llms.txt) ne doivent jamais être formatés au format PDF, car l'objectif principal du format est de fournir un texte brut simple et léger.

Discussion sur le forum X.