Is it true that Googlebot overlooks your WebP images served by Service Worker?

What exactly is a Service Worker and why doesn't Googlebot execute it?

A Service Worker is a JavaScript script that runs in the background of the browser, independently of the web page. It intercepts network requests and can modify responses — including serving optimized image formats like WebP instead of JPEG or PNG when the browser supports it.

In its rendering phase, Googlebot does not execute Service Workers. This means that any image replacement logic based on this technology remains invisible to the bot. It only sees what is declared in the initial source HTML, before any post-loading JavaScript intervention. Third-party testing tools like PageSpeed Insights or WebPageTest simulate a complete browser, therefore they can see the WebP — which often leads to confusion between what the tool reports and what Google actually indexes.

What is the difference between what Googlebot sees and what users see?

Real users browse with modern browsers that execute Service Workers. Therefore, they receive the optimized WebP images, benefiting from reduced load times and an improved experience. The Core Web Vitals measured from the user's side reflect this optimization.

Googlebot, on the other hand, retrieves raw HTML, parses <img> tags, and indexes the URLs declared in src or srcset attributes. If these attributes point to JPEG or PNG, that’s what Google stores in its image index. The Service Worker that would have transformed the response into WebP never executes for the bot. This asymmetry creates a disconnect between the measured user experience and what Google technically sees.

Why doesn't this prevent ranking in Google Images?

Google asserts that the absence of indexed WebP does not impact image ranking. Ranking in Google Images depends on many factors: contextual relevance, perceived quality, structured data, alt text, captions, and user engagement signals.

The image format itself is not a direct ranking criterion. What matters is that the image is accessible, indexable, and relevant. JPEG and PNG formats are perfectly indexable. WebP provides a performance advantage on the user side, but Google has never confirmed that a modern format gives an image ranking bonus. As long as your original images are of good quality and correctly marked, they can rank normally.

• Googlebot does not execute Service Workers, so it ignores any image replacement logic based on this technology.
• Third-party testing tools (PageSpeed Insights, WebPageTest) simulate a complete browser and see WebP, creating a false impression that Google indexes them.
• Indexing only applies to formats declared in the source HTML (JPEG/PNG), not to dynamically served versions.
• Google Images ranking does not depend on the format (WebP vs JPEG), but on relevance, quality, and context.
• Real users still benefit from WebP (performance, Core Web Vitals), even if Google does not index it.

Is this statement consistent with field observations?

Yes, absolutely. In practice, we have observed for years that Googlebot behaves like a partial browser: it parses HTML, executes JavaScript for rendering, but ignores certain advanced APIs like Service Workers, push notifications, or background sync. Martin Splitt has repeatedly confirmed that Googlebot does not play the role of a complete PWA.

Tests show that images declared as JPEG in the source HTML remain indexed as JPEG, even if a Service Worker intercepts the request on the client side to serve WebP. Google has never had a mechanism to

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