Faut-il vraiment compter sur les service workers pour le SEO ?

Pourquoi Google insiste sur le caractère optionnel des service workers ?

Les service workers sont des scripts qui tournent en arrière-plan du navigateur et interceptent les requêtes réseau. Ils permettent de mettre en cache des ressources, de servir du contenu hors ligne, et d'améliorer les performances.

Le problème : leur enregistrement n'est jamais garanti. Un navigateur peut refuser de les activer pour des raisons de sécurité, de politique de confidentialité, ou simplement parce que l'utilisateur a désactivé JavaScript. Googlebot lui-même peut rencontrer des échecs d'enregistrement lors du crawl.

Qu'est-ce que cela change pour le crawl et l'indexation ?

Si votre site compte sur un service worker pour servir le contenu principal ou gérer la navigation, vous prenez un risque majeur. Googlebot doit pouvoir accéder au contenu même si le service worker échoue.

Concrètement, cela concerne surtout les Progressive Web Apps (PWA) qui utilisent intensivement les service workers. Si le contenu n'est accessible que via le service worker, et que celui-ci ne s'enregistre pas, Googlebot verra une page vide ou cassée.

Quelles sont les implications techniques concrètes ?

• Un site doit toujours avoir une version HTML classique accessible sans service worker
• Le contenu critique ne doit jamais dépendre uniquement d'un script interceptant les requêtes
• Les stratégies de cache doivent être pensées comme une amélioration progressive, pas comme une dépendance
• Les tests de crawlabilité doivent simuler des scénarios où le service worker échoue
• La navigation interne doit rester fonctionnelle même si le service worker ne charge pas

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

Oui, complètement. J'ai vu plusieurs PWA perdre des positions parce que leur contenu n'était accessible que via un service worker mal implémenté. Googlebot est capricieux avec ces scripts — parfois il les exécute, parfois non.

Le vrai souci, c'est que beaucoup de devs pensent que si leur service worker fonctionne en local, il fonctionnera partout. Faux. Les conditions de crawl sont différentes : timeouts plus courts, environnement JavaScript plus strict, gestion du cache différente.

Quelles nuances faut-il apporter à ce conseil ?

Google ne dit pas que les service workers sont mauvais pour le SEO. Il dit qu'ils ne doivent jamais être un point de défaillance unique. Utilisés correctement, ils améliorent les Core Web Vitals et l'expérience utilisateur.

La nuance importante : les service workers peuvent servir du contenu en cache pour accélérer la navigation, mais ce contenu doit aussi être accessible directement via le serveur. C'est le principe de l'amélioration progressive appliqué au niveau réseau.

[À vérifier] : Google reste vague sur la fréquence à laquelle Googlebot échoue à enregistrer un service worker. Aucune métrique officielle n'est disponible, ce qui rend difficile l'évaluation du risque réel.

Dans quels cas cette règle devient-elle critique ?

Trois scénarios à surveiller de près :

D'abord, les Single Page Applications (SPA) qui routent tout via un service worker. Si le worker plante, la navigation interne devient invisible pour Googlebot. Ensuite, les sites qui servent du contenu dynamique uniquement via des requêtes interceptées — si l'interception échoue, le contenu disparaît.

Enfin, les stratégies de cache-first mal configurées peuvent servir du contenu obsolète à Googlebot pendant des semaines. Si le service worker ne se met pas à jour, le bot crawle une version périmée du site.

Que faut-il vérifier en priorité sur son site ?

Commencez par désactiver complètement les service workers dans votre navigateur et naviguez sur votre site. Tout doit fonctionner normalement : navigation, chargement du contenu, formulaires. Si quelque chose casse, vous avez un problème SEO.

Ensuite, utilisez la Search Console pour inspecter vos URL en live. Regardez le code source rendu — si le contenu principal manque, c'est probablement lié à un échec du service worker côté Googlebot.

Quelles erreurs éviter lors de l'implémentation ?

L'erreur la plus courante : router toutes les requêtes via le service worker sans fallback serveur. Si le worker échoue, l'utilisateur (ou Googlebot) se retrouve face à une erreur réseau.

Autre piège fréquent : mettre en cache des ressources critiques pour le SEO (comme les balises title, meta description, ou le contenu principal) sans servir aussi ces éléments directement depuis le HTML initial. Le service worker doit améliorer la performance, pas remplacer le rendu serveur.

Enfin, ne configurez jamais une stratégie cache-only pour le contenu indexable. Toujours prévoir un mode dégradé qui récupère les données depuis le serveur si le cache est vide ou invalide.

Comment tester la résilience de son architecture ?

• Désactiver JavaScript et vérifier que le contenu principal s'affiche
• Bloquer l'enregistrement des service workers dans les DevTools et tester la navigation
• Simuler une panne réseau pour voir comment le site se comporte sans cache
• Inspecter les URLs via la Search Console en mode live pour vérifier le rendu Googlebot
• Vérifier que les balises meta, title, canonical sont présentes dans le HTML source, pas seulement injectées par JavaScript
• Tester les redirections et les codes HTTP — ils doivent être gérés côté serveur, jamais via le service worker
• Auditer les stratégies de cache pour éviter de servir du contenu obsolète à Googlebot