Pourquoi Googlebot ignore-t-il vos images WebP servies par Service Worker ?

Qu'est-ce qu'un Service Worker et pourquoi Googlebot ne l'exécute-t-il pas ?

Un Service Worker est un script JavaScript qui s'exécute en arrière-plan du navigateur, indépendamment de la page web. Il intercepte les requêtes réseau et peut modifier les réponses — y compris servir des formats d'image optimisés comme WebP à la place de JPEG ou PNG lorsque le navigateur le supporte.

Googlebot, dans sa phase de rendering, n'exécute pas les Service Workers. Cela signifie que toute logique de remplacement d'image basée sur cette technologie reste invisible pour le bot. Il voit uniquement ce qui est déclaré dans le HTML source initial, avant toute intervention JavaScript post-chargement. Les outils de test tiers comme PageSpeed Insights ou WebPageTest, eux, simulent un navigateur complet et voient donc les WebP — d'où une confusion fréquente entre ce que l'outil rapporte et ce que Google indexe réellement.

Quelle est la différence entre ce que voit Googlebot et ce que voient les utilisateurs ?

Les utilisateurs réels naviguent avec des navigateurs modernes qui exécutent les Service Workers. Ils reçoivent donc bien les images WebP optimisées, bénéficiant d'un temps de chargement réduit et d'une meilleure expérience. Les Core Web Vitals mesurés côté utilisateur reflètent cette optimisation.

Googlebot, en revanche, récupère le HTML brut, parse les balises <img>, et indexe les URLs déclarées dans les attributs src ou srcset. Si ces attributs pointent vers des JPEG ou PNG, c'est ce que Google stocke dans son index images. Le Service Worker qui aurait transformé la réponse en WebP ne s'exécute jamais pour le bot. Cette asymétrie crée un décalage entre l'expérience utilisateur mesurée et ce que Google voit techniquement.

Pourquoi cela n'empêche-t-il pas le ranking dans Google Images ?

Google affirme que l'absence de WebP indexé n'impacte pas le classement des images. Le ranking dans Google Images dépend de nombreux facteurs : pertinence contextuelle, qualité perçue, données structurées, texte alternatif, légendes, et signaux d'engagement utilisateur.

Le format d'image en lui-même n'est pas un critère de ranking direct. Ce qui compte, c'est que l'image soit accessible, indexable, et pertinente. Les JPEG et PNG sont parfaitement indexables. Le WebP apporte un avantage performance côté utilisateur, mais Google n'a jamais confirmé qu'un format moderne confère un bonus de ranking images. Tant que vos images originales sont de bonne qualité et correctement balisées, elles peuvent se classer normalement.

• Googlebot n'exécute pas les Service Workers, donc ignore toute logique de remplacement d'image basée sur cette technologie.
• Les outils de test tiers (PageSpeed Insights, WebPageTest) simulent un navigateur complet et voient les WebP, créant une fausse impression que Google les indexe.
• L'indexation porte sur les formats déclarés dans le HTML source (JPEG/PNG), pas sur les versions servies dynamiquement.
• Le ranking Google Images ne dépend pas du format (WebP vs JPEG), mais de la pertinence, qualité, et contexte.
• Les utilisateurs réels bénéficient toujours du WebP (performance, Core Web Vitals), même si Google ne l'indexe pas.

Cette déclaration est-elle cohérente avec les observations terrain ?

Oui, totalement. Sur le terrain, on observe depuis des années que Googlebot se comporte comme un navigateur partiel : il parse le HTML, exécute du JavaScript pour le rendering, mais ignore certaines API avancées comme les Service Workers, les notifications push, ou la synchronisation en arrière-plan. Martin Splitt a déjà confirmé à plusieurs reprises que Googlebot ne joue pas le rôle d'un PWA complet.

Les tests montrent que les images déclarées en JPEG dans le HTML source restent indexées en JPEG, même si un Service Worker intercepte la requête côté client pour servir du WebP. Google n'a jamais eu de mécanisme pour « rejouer » les Service Workers lors du crawl. Cette limitation est documentée dans les ressources officielles Google Search Central, bien que rarement mise en avant. Aucune contradiction avec les pratiques observées — c'est une règle stable depuis l'introduction des Service Workers en SEO.

Quelles nuances faut-il apporter à cette affirmation ?

La nuance principale concerne la méthode de détection et de service du WebP. Si vous servez du WebP via une balise <picture> avec <source type="image/webp">, Googlebot voit et indexe le WebP — car cette logique est dans le HTML source, pas dans un script post-chargement. De même, une réécriture serveur (Apache mod_rewrite, Nginx, CDN header-based) qui sert du WebP en fonction de l'en-tête Accept: image/webp fonctionne pour Googlebot, car Googlebot envoie cet en-tête depuis 2019. [À vérifier] : Google n'a jamais publié de statistiques sur le taux d'indexation WebP vs JPEG/PNG dans son index images global.

L'autre nuance : Martin Splitt dit que cela « n'empêche pas le ranking images », mais il ne dit pas que cela n'a aucun impact indirect. Si vos Core Web Vitals côté utilisateur sont excellents grâce au WebP, cela peut influencer positivement les signaux d'engagement (taux de rebond, temps sur page), qui eux influencent le ranking global. Le format indexé n'est pas un facteur direct, mais la performance perçue par les vrais utilisateurs compte dans l'écosystème ranking. Soyons honnêtes : Google ne dit jamais toute la chaîne causale.

Dans quels cas cette règle ne s'applique-t-elle pas ?

Cette règle ne s'applique que si vous utilisez un Service Worker pour servir le WebP. Si vous passez par une implémentation HTML native (<picture>, srcset avec types MIME), ou par une négociation de contenu serveur, Googlebot verra le WebP sans problème. De même, certains CDN (Cloudflare, Fastly, Akamai) réécrivent les images à la volée en fonction de l'en-tête Accept, et Googlebot reçoit alors directement du WebP — tant que le HTML pointe vers une URL capable de cette négociation.

Autre cas : si vous n'utilisez pas de Service Worker mais un lazy-loading JavaScript qui remplace l'attribut src après le chargement, Googlebot peut voir le WebP si le script s'exécute dans la fenêtre de rendering (généralement quelques secondes). Cependant, cela dépend du timing d'exécution et reste moins fiable qu'une déclaration HTML source. La règle de Martin Splitt cible spécifiquement les Service Workers, pas toutes les formes de service dynamique d'images.

Que faut-il faire concrètement si vous servez du WebP via Service Worker ?

Si vous utilisez actuellement un Service Worker pour servir des images WebP, vous devez migrer vers une méthode que Googlebot comprend. La solution la plus simple et la plus robuste est d'implémenter une balise <picture> avec des <source> pour chaque format. Cela garantit que Googlebot indexe le WebP tout en offrant un fallback JPEG/PNG pour les navigateurs anciens. Concrètement : remplacez vos <img src="image.jpg"> par <picture><source type="image/webp" srcset="image.webp"><img src="image.jpg"></picture>.

Autre option : configurer votre serveur ou CDN pour faire de la négociation de contenu automatique. Cela signifie que l'URL reste inchangée (image.jpg), mais le serveur renvoie du WebP si l'en-tête Accept: image/webp est présent dans la requête. Googlebot envoie cet en-tête depuis 2019, donc il recevra du WebP sans modification HTML. Cette approche est plus élégante et évite de dupliquer le markup, mais elle nécessite un accès à la configuration serveur ou une fonctionnalité CDN compatible.

Quelles erreurs éviter lors de la migration ?

Ne supprimez pas brutalement le Service Worker sans tester l'impact sur les Core Web Vitals réels. Le Service Worker peut gérer bien plus que les images (cache API, stratégies de fetch, offline fallback). Si vous le désactivez, vérifiez que votre performance utilisateur reste stable. Utilisez les rapports CrUX (Chrome User Experience Report) dans Search Console pour valider que LCP et CLS ne se dégradent pas après la migration.

Deuxième erreur fréquente : croire qu'il suffit de changer le src de image.jpg vers image.webp pour que tout fonctionne. Cela casse l'expérience pour les navigateurs qui ne supportent pas WebP (Safari < 14, IE11). Utilisez toujours un fallback via <picture> ou négociation serveur. Et c'est là que ça coince : si vous imposez du WebP sans fallback, vous risquez des images cassées pour une partie de votre audience, et potentiellement un impact SEO indirect via des signaux d'engagement dégradés.

Comment vérifier que Googlebot indexe bien vos images WebP après migration ?

Utilisez l'outil d'inspection d'URL dans Google Search Console. Demandez une inspection en direct d'une page contenant vos images. Cliquez sur « Afficher la page explorée », puis « Plus d'infos » > « Capture d'écran » et « HTML rendu ». Inspectez le code HTML rendu : si vous voyez des URLs .webp dans les balises <img> ou <source>, c'est bon signe. Comparez avec le HTML source pour vérifier que Googlebot n'a pas fait de réécriture inattendue.

Complétez avec un test via l'API PageSpeed Insights en mode mobile et desktop, mais ne vous fiez pas uniquement à cela — comme dit plus haut, PSI simule un navigateur complet, pas Googlebot. Enfin, surveillez vos rapports Google Images dans Search Console : si vous constatez une chute d'impressions après migration, c'est un signal d'alerte que quelque chose ne s'est pas bien passé. Donnez quelques semaines à Google pour ré-indexer vos images avant de tirer des conclusions.

• Migrer du Service Worker vers <picture> avec <source type="image/webp"> ou négociation serveur
• Tester l'implémentation avec l'outil d'inspection d'URL Search Console (HTML rendu)
• Vérifier que Googlebot reçoit bien l'en-tête Accept: image/webp si vous utilisez la négociation serveur
• Conserver un fallback JPEG/PNG pour les navigateurs anciens (Safari < 14, IE11)
• Surveiller les Core Web Vitals CrUX après migration pour détecter toute régression performance
• Monitorer les impressions Google Images dans Search Console sur 4-6 semaines post-migration