Pourquoi les service workers peuvent-ils rendre votre contenu invisible pour Googlebot ?

Qu'est-ce qu'un service worker et pourquoi pose-t-il problème à Googlebot ?

Un service worker est un script JavaScript qui s'exécute en arrière-plan du navigateur, séparé de la page web. Il permet notamment de gérer les requêtes réseau, de mettre en cache des ressources, et de créer des expériences offline performantes.

Le hic ? Googlebot ne peut pas bénéficier de ces fonctionnalités avancées. Si votre contenu n'est accessible que via l'interception d'une requête par le service worker — par exemple pour servir une version cachée ou modifier la réponse — Google ne verra tout simplement rien. Le robot reçoit une réponse vide ou incomplète, et votre page disparaît des résultats.

Dans quels cas cette interception bloque-t-elle réellement l'indexation ?

Le problème survient lorsque vous interceptez les requêtes normales (fetch events) uniquement pour des fonctionnalités offline, sans prévoir de fallback côté serveur. Concrètement : si le contenu n'existe que dans le cache du service worker et qu'aucune réponse HTTP classique n'est disponible, Googlebot est bloqué.

Les situations typiques : une application web progressive (PWA) qui sert tout le contenu depuis le cache, un site qui redirige toutes les requêtes vers un shell applicatif géré par le service worker, ou des pages dynamiques qui ne renvoient du HTML qu'après traitement côté client via le worker.

Comment Googlebot traite-t-il réellement les service workers ?

Google a confirmé que son robot peut charger et enregistrer un service worker, mais il ne l'exécute pas comme un navigateur moderne. Il ne peut pas attendre qu'un événement fetch soit intercepté, traité, puis retourné avec du contenu modifié.

En pratique, Googlebot effectue une requête HTTP classique et attend une réponse directe du serveur. Si cette réponse dépend d'une logique gérée uniquement par le service worker, elle n'arrivera jamais.

• Les service workers fonctionnent en arrière-plan dans les navigateurs, pas dans Googlebot
• L'interception de requêtes fetch peut bloquer l'accès au contenu si aucune réponse serveur n'est disponible
• Google peut enregistrer le service worker mais ne peut pas exécuter ses fonctionnalités avancées
• Le risque principal : rendre des pages invisibles pour le crawl sans diagnostic évident
• Une architecture PWA mal conçue peut créer un gouffre entre l'expérience utilisateur et l'accessibilité SEO

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

Oui, et c'est même un problème récurrent sur les PWA ambitieuses. J'ai vu des sites entiers perdre leur visibilité après une migration vers une architecture service worker mal calibrée. Le symptôme classique : des pages parfaitement fonctionnelles en navigation, mais un taux d'indexation qui s'effondre sans alerte évidente dans la Search Console.

Le souci, c'est que les outils de debug JavaScript (Lighthouse, DevTools) ne détectent pas ce type de blocage côté bot. Tout semble parfait en local, et pourtant Googlebot reçoit du vide. Il faut tester avec un user-agent Googlebot ou un crawler headless sans service worker actif pour identifier le problème.

Quelles nuances faut-il apporter à cette consigne ?

Google ne dit pas que les service workers sont interdits — il dit que l'interception des requêtes normales uniquement pour l'offline pose problème. Nuance importante : vous pouvez utiliser un service worker pour précharger des ressources, gérer des notifications push, ou optimiser la mise en cache, tant que le contenu reste accessible via une requête HTTP standard.

Le vrai enjeu, c'est l'architecture. Si votre service worker intercepte une requête mais renvoie quand même la réponse du réseau en cas de connexion (stratégie Network First ou Stale While Revalidate), aucun souci. Le problème surgit avec une stratégie Cache Only ou Cache First sans fallback réseau, où le contenu n'existe que localement.

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

Si votre service worker n'intercepte que des ressources statiques (CSS, JS, images) pour les mettre en cache, ou s'il gère uniquement des fonctionnalités annexes (notifications, sync en arrière-plan), aucun risque. Le contenu HTML reste servi normalement par le serveur.

De même, si vous utilisez une stratégie de progressive enhancement où le service worker améliore l'expérience sans jamais bloquer l'accès au contenu brut, vous êtes en sécurité. L'essentiel : que la requête HTTP initiale, sans service worker, retourne du contenu complet et indexable.

Que faut-il faire concrètement pour éviter ce piège ?

D'abord, auditer votre stratégie de service worker. Si vous interceptez des requêtes de contenu, vérifiez que la stratégie choisie prévoit un fallback réseau. Les stratégies Network First, Network Only, ou Stale While Revalidate sont sûres pour le SEO. Cache First ou Cache Only sont dangereuses si elles concernent le HTML des pages.

Ensuite, testez avec un user-agent Googlebot. Désactivez le service worker dans votre navigateur (DevTools > Application > Service Workers > Unregister) et rechargez la page. Si le contenu ne s'affiche plus ou si vous obtenez une erreur, Googlebot aura le même problème.

Comment vérifier que Googlebot accède bien à mon contenu ?

Utilisez l'outil d'inspection d'URL dans la Search Console. Demandez un test en direct et examinez le HTML renvoyé et la capture d'écran. Si le contenu n'apparaît pas alors qu'il est visible dans votre navigateur, le service worker est probablement en cause.

Autre méthode : un crawl avec un outil comme Screaming Frog en mode JavaScript désactivé, ou avec un user-agent Googlebot configuré pour ignorer les service workers. Comparez les résultats avec un crawl classique. Toute différence majeure révèle un problème d'accessibilité.

• Vérifier que la stratégie de mise en cache du service worker inclut un fallback réseau pour le HTML
• Tester le site avec le service worker désactivé pour s'assurer que le contenu reste accessible
• Utiliser l'outil d'inspection d'URL de la Search Console sur des pages critiques
• Comparer le rendu Googlebot avec le rendu utilisateur pour détecter les écarts
• Éviter les stratégies Cache Only ou Cache First sur les requêtes de pages HTML
• Privilégier Network First ou Stale While Revalidate pour garantir l'accès au contenu
• Documenter précisément la logique du service worker pour faciliter les audits futurs