Googlebot ignore-t-il vraiment vos images WebP servies via Service Workers ?

Qu'est-ce qu'un Service Worker et pourquoi certains sites l'utilisent-ils pour les images ?

Un Service Worker est un script JavaScript qui s'exécute en arrière-plan du navigateur, indépendamment de la page web. Il permet notamment d'intercepter les requêtes réseau et de manipuler les réponses avant qu'elles n'atteignent le navigateur.

Certains développeurs l'utilisent pour servir dynamiquement des images WebP aux navigateurs compatibles, tout en conservant des JPEG/PNG pour les anciens navigateurs. C'est une forme de progressive enhancement côté client, élégante techniquement, mais invisible pour un bot qui n'exécute pas JavaScript au même niveau qu'un navigateur moderne.

Pourquoi Googlebot n'exécute-t-il pas les Service Workers ?

Googlebot exécute JavaScript depuis des années, mais pas tous les types de scripts. Les Service Workers fonctionnent en dehors du thread principal de la page et nécessitent une gestion d'état persistante entre les requêtes — quelque chose que Googlebot n'implémente pas.

Le bot traite chaque URL comme une requête isolée, sans contexte de session ni cache de Service Worker. Résultat : toute logique de substitution d'images côté Service Worker est tout simplement court-circuitée. Googlebot voit ce que le HTML renvoie directement, point.

Quelle différence entre ce que voit l'utilisateur et ce que voit Google ?

L'utilisateur avec un navigateur moderne bénéficie de la version optimisée WebP, avec un gain substantiel en poids et en vitesse de chargement. Googlebot, lui, récupère les formats d'origine définis dans le HTML ou les balises <picture> sans la couche Service Worker.

Ça signifie que vos Core Web Vitals côté utilisateur peuvent être excellents, mais que Google indexe des images plus lourdes que celles réellement servies. Le crawl n'est pas bloqué — les images JPEG/PNG sont bien découvertes — mais vous ne profitez pas du label WebP dans l'index Image de Google.

• Googlebot ignore complètement les Service Workers, quelle que soit leur sophistication.
• Les images servies uniquement via Service Worker ne seront pas indexées en WebP, même si l'utilisateur final les reçoit bien dans ce format.
• Le crawl des images continue normalement sur les formats originaux définis dans le HTML source.
• Les performances utilisateur restent intactes, mais l'impact SEO du WebP est perdu pour l'indexation d'images.
• Cette limitation s'applique à toutes les ressources servies exclusivement via Service Worker, pas seulement les images.

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

Complètement. Les tests avec Google Search Console et les outils de rendu montrent depuis longtemps que Googlebot ne gère pas les Service Workers. L'URL Inspection Tool ne les exécute pas non plus. Aucune surprise ici.

Ce qui est plus intéressant, c'est que Martin Splitt prend la peine de le clarifier publiquement. Ça montre que suffisamment de sites ont adopté cette stratégie pour que Google juge nécessaire de poser les limites explicitement. Les implémentations purement JavaScript côté client restent un angle mort partiel pour le crawl.

Quelles nuances faut-il apporter à cette règle ?

Le problème ne concerne que les sites où le Service Worker est la seule méthode de diffusion du WebP. Si vous utilisez des balises <picture> avec des sources WebP déclarées côté serveur, Googlebot les verra parfaitement — Service Worker ou pas.

Autrement dit, la déclaration de Martin Splitt vise les architectures où le HTML source contient uniquement du JPEG/PNG, et où un Service Worker fait de la substitution transparente côté client. Dans ce cas précis, oui, Google indexe les formats d'origine. [A vérifier] : on ne sait pas si Google prévoit un jour d'exécuter les Service Workers — rien n'indique que ce soit sur la roadmap.

Quels risques si on ignore cette limitation ?

Le risque principal ? Vous croyez diffuser du WebP à Google alors que ce n'est pas le cas. Ça fausse vos hypothèses SEO, notamment pour la recherche d'images où le format et le poids comptent.

Autre effet pervers : si vous désactivez complètement les JPEG/PNG côté serveur en pensant que le Service Worker suffit, vous risquez de casser l'indexation des images ou de rendre certaines ressources inaccessibles au bot. Soyons honnêtes, c'est rare — mais ça arrive sur des stacks trop optimisées côté client sans fallback serveur.

Que faut-il faire concrètement pour que Google indexe vos images WebP ?

La solution la plus robuste est de servir le WebP côté serveur, via des balises <picture> ou <img> avec attributs srcset et types déclarés. Googlebot comprend parfaitement cette syntaxe et indexera les versions WebP sans problème.

Si vous utilisez un CDN moderne (Cloudflare, Fastly, Akamai), activez la conversion automatique WebP avec négociation de contenu via l'en-tête Accept. Le bot envoie cet en-tête, reçoit le WebP si disponible, et l'indexe correctement. Pas besoin de JavaScript.

Quelles erreurs éviter dans l'implémentation WebP ?

Ne comptez jamais sur du JavaScript côté client — Service Worker ou autre — comme unique méthode de diffusion d'un format d'image. C'est une couche d'amélioration, pas une base d'architecture pour le SEO.

Évitez aussi les redirects JavaScript conditionnels qui chargent des URLs différentes selon le support WebP détecté côté navigateur. Googlebot suivra la version par défaut, souvent le JPEG, et ignorera la branche WebP. Privilégiez toujours une logique serveur ou des balises HTML natives.

Comment vérifier que votre implémentation WebP est compatible crawl ?

Utilisez l'URL Inspection Tool dans Google Search Console pour tester une page contenant vos images. Regardez la version HTML rendue : si les balises <img> ou <picture> pointent vers des .webp, c'est bon. Si vous ne voyez que du .jpg/.png, c'est que votre Service Worker fait le boulot — et Google ne le voit pas.

Testez aussi avec curl -A "Googlebot" -H "Accept: image/webp" sur vos URLs d'images. Si le serveur renvoie du WebP avec un Content-Type correct, vous êtes tranquille. Si ça renvoie du JPEG quoi qu'il arrive, il faut revoir la config serveur.

• Implémenter les images WebP côté serveur via balises <picture> ou négociation de contenu HTTP.
• Ne jamais s'appuyer uniquement sur un Service Worker pour diffuser des formats optimisés destinés à l'indexation.
• Vérifier le rendu Googlebot avec l'URL Inspection Tool et confirmer que les .webp apparaissent dans le HTML.
• Tester les réponses serveur avec curl en simulant un user-agent Googlebot et un en-tête Accept: image/webp.
• Conserver un fallback JPEG/PNG déclaré explicitement pour les bots et navigateurs non compatibles.
• Monitorer les logs serveur pour vérifier que Googlebot reçoit bien les bonnes ressources lors du crawl.