Service Workers et SEO : cache offline vs crawlabilité

Un site e-commerce de 22 000 fiches produit déploie un service worker avec une stratégie cache-first agressive. Six semaines plus tard, 40% des pages produit affichent du contenu obsolète dans le cache navigateur des utilisateurs — prix erronés, stock épuisé affiché comme disponible — tandis que Googlebot, lui, n'a jamais exécuté ce service worker et continue de crawler le HTML brut. Deux réalités parallèles, un seul site. Le problème n'est pas que le service worker casse le SEO directement. C'est qu'il crée un décalage entre ce que Google voit et ce que vos utilisateurs expérimentent.

Googlebot et les service workers : ce qui se passe réellement

La confusion la plus répandue : croire que Googlebot exécute les service workers comme Chrome. Ce n'est pas le cas.

Googlebot utilise une version headless de Chrome (basée sur la dernière version stable depuis 2019) pour le rendering JavaScript. Mais le Web Rendering Service (WRS) de Google ne persiste pas l'état entre les visites. Chaque page est rendue dans un environnement éphémère, sans stockage local, sans cache persistant, et sans service worker installé d'une session précédente.

La documentation officielle de Google est explicite sur ce point : le WRS est stateless. Référence directe dans la documentation Google Search Central sur le JavaScript SEO — le renderer ne conserve ni cookies, ni localStorage, ni service workers entre les rendus.

Le cycle de vie du service worker vu par Googlebot

Voici ce qui se passe concrètement quand Googlebot accède à une page qui enregistre un service worker :

Googlebot fetche le HTML de la page.
Le WRS exécute le JavaScript, y compris l'appel navigator.serviceWorker.register().
Le service worker peut s'installer (événement install), mais l'événement activate nécessite que toutes les pages contrôlées soient fermées puis réouvertes.
Même si le SW s'active, le fetch handler ne sera opérationnel que pour les requêtes suivantes dans le même scope — or le WRS ne fait pas de "requête suivante" dans le même contexte.
Résultat : le service worker est enregistré mais n'intercepte aucune requête réseau lors du rendu.

Ce comportement signifie que Google indexe toujours le contenu servi par votre serveur (ou votre CDN), jamais le contenu servi depuis le cache du service worker. En théorie, c'est une bonne nouvelle. En pratique, les problèmes sont ailleurs.

Le vrai risque : l'app shell pattern

Le pattern app shell — popularisé par les PWA — consiste à servir un squelette HTML minimal puis à charger le contenu dynamiquement via JavaScript, souvent orchestré par le service worker.

<!-- App shell minimaliste - ce que le serveur renvoie -->
<!DOCTYPE html>
<html lang="fr">
<head>
  <meta charset="utf-8">
  <title>MonSite</title>
  <link rel="manifest" href="/manifest.json">
</head>
<body>
  <div id="app">
    <!-- Contenu injecté par JS après hydration -->
    <div class="shell-loading">Chargement...</div>
  </div>
  <script src="/js/app.bundle.js"></script>
  <script>
    if ('serviceWorker' in navigator) {
      navigator.serviceWorker.register('/sw.js');
    }
  </script>
</body>
</html>

Si le JavaScript s'exécute correctement dans le WRS, Googlebot verra le contenu final. Mais si le bundle JS dépasse le rendering budget de Google, si une API tierce timeout pendant le rendu, ou si le code assume la présence d'un service worker actif pour résoudre certaines requêtes — le contenu indexé sera ce squelette vide.

La combinaison app shell + service worker + SPA est la trinité toxique du SEO technique. Chaque composant fonctionne individuellement, mais leur interaction crée des modes de défaillance silencieux que ni Screaming Frog (qui ne rend pas le JS par défaut) ni un test manuel dans Chrome (où le SW est installé et actif) ne reproduisent.

Stratégies de cache et leurs implications SEO

Toutes les stratégies de cache d'un service worker ne se valent pas du point de vue SEO. L'enjeu n'est pas l'indexation directe (Googlebot ignore le SW), mais la cohérence du contenu expérimenté par les utilisateurs et la performance perçue qui impacte les Core Web Vitals.

Cache-first : rapide mais dangereux

// sw.js - Stratégie cache-first classique
self.addEventListener('fetch', (event) => {
  event.respondWith(
    caches.match(event.request).then((cachedResponse) => {
      if (cachedResponse) {
        // Sert le cache immédiatement — pas de requête réseau
        return cachedResponse;
      }
      return fetch(event.request).then((networkResponse) => {
        // Met en cache pour les prochaines visites
        const responseClone = networkResponse.clone();
        caches.open('v1').then((cache) => {
          cache.put(event.request, responseClone);
        });
        return networkResponse;
      });
    })
  );
});

Avec cache-first, un utilisateur qui a visité une fiche produit il y a 3 jours verra la version cachée, même si le prix a changé, le produit est en rupture, ou la page a été redirigée. Du point de vue SEO, le problème se manifeste ainsi :

Données structurées incohérentes : Google indexe le prix actuel (500€), l'utilisateur voit le prix caché (450€). Rich results et page affichée divergent. Google peut rétrograder vos rich results pour incohérence.
Redirections ignorées : si vous avez mis en place une 301 côté serveur (migration d'URL, consolidation de pages), le service worker cache-first continuera à servir l'ancien contenu aux utilisateurs existants. Vos métriques de redirection dans Search Console sembleront correctes, mais l'expérience utilisateur sera cassée.
Pages supprimées toujours accessibles : une page qui renvoie un 404/410 côté serveur reste accessible via le cache SW pour les visiteurs récurrents.

Stale-while-revalidate : le compromis raisonnable

// sw.js - Stale-while-revalidate avec TTL
const CACHE_NAME = 'content-v2';
const MAX_AGE = 3600 * 1000; // 1 heure en ms

self.addEventListener('fetch', (event) => {
  if (event.request.mode === 'navigate') {
    event.respondWith(
      caches.open(CACHE_NAME).then(async (cache) => {
        const cachedResponse = await cache.match(event.request);
        
        const fetchPromise = fetch(event.request).then((networkResponse) => {
          if (networkResponse.ok) {
            // Stocke avec un timestamp
            const headers = new Headers(networkResponse.headers);
            headers.set('sw-cache-time', Date.now().toString());
            const timestampedResponse = new Response(
              networkResponse.clone().body,
              { status: networkResponse.status, headers }
            );
            cache.put(event.request, timestampedResponse);
          }
          return networkResponse;
        });

        if (cachedResponse) {
          const cacheTime = parseInt(
            cachedResponse.headers.get('sw-cache-time') || '0'
          );
          const isStale = (Date.now() - cacheTime) > MAX_AGE;
          
          if (isStale) {
            // Cache expiré — attend la réponse réseau
            return fetchPromise;
          }
          // Cache frais — sert immédiatement, revalide en background
          return cachedResponse;
        }
        
        return fetchPromise;
      })
    );
  }
});

Cette approche sert le cache pour les requêtes de navigation si le contenu a moins d'une heure, tout en revalidant en arrière-plan. Si le cache est expiré, elle attend la réponse réseau. Le TTL de 1 heure est un compromis : assez court pour limiter la dérive du contenu, assez long pour un gain de performance perceptible sur les retours rapides.

Network-first pour le contenu critique SEO

Pour les pages dont le contenu change fréquemment (fiches produit, pages de catégorie, articles d'actualité), network-first est la seule stratégie défendable :

// sw.js - Network-first avec fallback offline
self.addEventListener('fetch', (event) => {
  if (event.request.mode === 'navigate') {
    event.respondWith(
      fetch(event.request)
        .then((response) => {
          // Succès réseau — cache pour usage offline
          const clone = response.clone();
          caches.open('pages-v1').then((cache) => {
            cache.put(event.request, clone);
          });
          return response;
        })
        .catch(() => {
          // Offline — sert le cache ou la page offline
          return caches.match(event.request)
            .then((cached) => cached || caches.match('/offline.html'));
        })
    );
  }
});

Vous gardez le bénéfice de l'expérience offline (un vrai différenciateur UX) sans les risques de contenu obsolète. Le coût : aucun gain de performance pour les utilisateurs connectés. Le cache ne sert qu'en cas de perte réseau.

Scénario concret : migration PWA d'un média en ligne

Un site média (actualité tech) de 18 000 articles, 2,3 millions de sessions mensuelles, déploie une PWA avec service worker en septembre 2025. L'objectif : améliorer les Core Web Vitals (LCP ciblé < 1.5s) et offrir un mode lecture offline.

La configuration initiale (problématique)

L'équipe frontend déploie un service worker avec Workbox, configuré en cache-first pour les pages d'articles et stale-while-revalidate pour les assets statiques. Le workbox-precaching pré-cache les 50 articles les plus populaires lors de l'installation du SW.

Résultats après 4 semaines :

LCP médian : passe de 2.4s à 0.9s pour les visiteurs récurrents (excellent).
Taux de rebond : baisse de 3 points (les pages chargent instantanément depuis le cache).
Mais : les articles mis à jour (corrections, ajouts de paragraphes, changements de titre) ne sont pas reflétés pour ~35% des visiteurs pendant 24 à 72 heures.

Le problème SEO se manifeste indirectement. Google Search Console montre un écart croissant entre les clics estimés et les pages vues dans leur analytics. Diagnostic : les utilisateurs qui cliquent depuis les SERP arrivent sur la version réseau (fraîche), mais ceux qui naviguent en interne depuis la homepage voient des versions cachées. Les signaux de satisfaction utilisateur divergent.

La correction

L'équipe adopte une stratégie différenciée :

Articles < 24h : network-first (le contenu change fréquemment — corrections, mises à jour).
Articles > 24h : stale-while-revalidate avec TTL de 2h.
Assets statiques (CSS, JS, images) : cache-first avec versioning dans les noms de fichiers.
Pages de navigation (homepage, catégories) : network-first systématique.

// workbox-config.js — Configuration Workbox différenciée
import { registerRoute, NavigationRoute } from 'workbox-routing';
import {
  NetworkFirst,
  StaleWhileRevalidate,
  CacheFirst
} from 'workbox-strategies';
import { ExpirationPlugin } from 'workbox-expiration';
import { CacheableResponsePlugin } from 'workbox-cacheable-response';

// Pages de navigation (homepage, catégories) — toujours réseau
registerRoute(
  ({ url }) => ['/', '/tech', '/business', '/science'].includes(url.pathname),
  new NetworkFirst({
    cacheName: 'nav-pages',
    networkTimeoutSeconds: 3,
    plugins: [
      new CacheableResponsePlugin({ statuses: [0, 200] }),
    ],
  })
);

// Articles — stale-while-revalidate avec expiration
registerRoute(
  ({ url }) => url.pathname.startsWith('/article/'),
  new StaleWhileRevalidate({
    cacheName: 'articles',
    plugins: [
      new CacheableResponsePlugin({ statuses: [0, 200] }),
      new ExpirationPlugin({
        maxEntries: 200,
        maxAgeSeconds: 7200, // 2 heures
      }),
    ],
  })
);

// Assets statiques — cache-first (versionné via filename hash)
registerRoute(
  ({ request }) =>
    request.destination === 'style' ||
    request.destination === 'script' ||
    request.destination === 'image',
  new CacheFirst({
    cacheName: 'static-assets',
    plugins: [
      new CacheableResponsePlugin({ statuses: [0, 200] }),
      new ExpirationPlugin({
        maxEntries: 500,
        maxAgeSeconds: 30 * 24 * 3600, // 30 jours
      }),
    ],
  })
);

Après correction, le LCP médian remonte légèrement (1.3s pour les visiteurs récurrents sur les articles récents) mais la cohérence contenu indexé / contenu affiché est restaurée. Les Core Web Vitals restent dans les seuils "good" du rapport Search Console.

Auditer l'impact d'un service worker sur le crawl

Diagnostiquer les problèmes liés aux service workers demande une approche en couches, car les outils standards ne simulent pas le comportement du WRS.

Chrome DevTools : tester sans SW

La première vérification est triviale mais souvent oubliée. Dans Chrome DevTools, onglet Application > Service Workers > cochez "Bypass for network". Naviguez sur votre site. Si le contenu diffère significativement de ce que vous voyez avec le SW actif, vous avez un problème de cohérence.

Pour simuler Googlebot plus fidèlement :

DevTools > Network > cochez "Disable cache"
Application > Service Workers > "Unregister" tous les SW
Application > Storage > "Clear site data"
Rechargez la page

Ce que vous voyez maintenant est proche de ce que le WRS de Google verra. Comparez le contenu, les balises meta, les données structurées.

Screaming Frog : crawler sans et avec rendering JS

Screaming Frog en mode "JavaScript Rendering" utilise un navigateur headless mais — comme Googlebot — ne conserve pas les service workers entre les requêtes. C'est donc un bon proxy pour le comportement du WRS.

Lancez deux crawls :

Mode HTML uniquement (Configuration > Spider > Rendering: None)
Mode JavaScript (Rendering: JavaScript)

Comparez les titres, les H1, le contenu textuel, les canonical, les meta robots. Des écarts entre les deux crawls signalent une dépendance JavaScript qui pourrait poser problème.

Si vous observez des pages où le rendu JS renvoie un contenu fondamentalement différent du HTML (le fameux squelette app shell), c'est le signal que votre architecture dépend trop du client-side rendering — et potentiellement du service worker pour les utilisateurs réels.

L'inspection d'URL dans Search Console

L'outil "Inspecter une URL" dans Google Search Console montre exactement ce que Googlebot a rendu. Utilisez-le pour vérifier que le contenu critique (title, description, H1, texte principal, données structurées) est bien présent dans le rendu sans service worker.

Pour aller plus loin dans l'automatisation de ce type de vérification, vous pouvez intégrer des checks SEO dans votre pipeline CI/CD — par exemple, comparer le HTML statique avec le DOM rendu par Puppeteer sur chaque déploiement.

Le piège du scope et du precaching excessif

Le scope du service worker détermine quelles URLs il peut intercepter. Un SW enregistré à la racine (/sw.js avec scope /) intercepte toutes les requêtes de navigation du domaine.

Problème des redirections soft

Un service worker cache-first peut effectuer ce qu'on appelle une "redirection soft" : au lieu de suivre la redirection 301 côté serveur, il sert la page depuis son cache, ignorant complètement la redirection.

// Ce pattern est toxique pour le SEO
self.addEventListener('fetch', (event) => {
  event.respondWith(
    caches.match(event.request).then((response) => {
      // Si l'URL /ancien-produit est en cache, le SW la sert
      // même si le serveur répond maintenant avec une 301 vers /nouveau-produit
      return response || fetch(event.request);
    })
  );
});

Pour les utilisateurs récurrents, l'ancienne URL continue de "fonctionner" — mais avec du contenu obsolète. Google, lui, suit la 301 et indexe la nouvelle URL. Vos utilisateurs et Google voient deux sites différents.

La solution : ne jamais mettre en cache les réponses de navigation sans vérifier le status code, et forcer un re-fetch réseau quand une version du SW est mise à jour.

// Version corrigée — respecte les redirections
self.addEventListener('fetch', (event) => {
  if (event.request.mode === 'navigate') {
    event.respondWith(
      fetch(event.request)
        .then((response) => {
          // Ne cache que les 200 — pas les redirections, pas les erreurs
          if (response.status === 200) {
            const clone = response.clone();
            caches.open('pages').then((c) => c.put(event.request, clone));
          }
          return response;
        })
        .catch(() => caches.match(event.request) || caches.match('/offline.html'))
    );
  }
});

Precaching : limitez le scope

Les libraries comme Workbox proposent un precaching automatique via le build manifest. Le danger : pré-cacher 500 pages produit lors de l'installation du SW mobilise de la bande passante et du stockage pour des pages que l'utilisateur ne visitera peut-être jamais.

Plus pernicieux : si votre build manifest n'est pas synchronisé avec vos redirections ou suppressions de pages, le SW pré-cache des URLs qui n'existent plus côté serveur. Le résultat est un site "fantôme" dans le cache de l'utilisateur.

Limitez le precaching aux assets strictement nécessaires au shell (CSS critique, JS principal, polices, page offline). Laissez le runtime caching gérer les pages de contenu.

Service workers et Edge SEO : la combinaison avancée

Pour les architectures les plus sophistiquées, le service worker côté client peut être complété par du traitement au niveau du CDN (Edge SEO). L'idée : le CDN modifie les réponses HTTP avant qu'elles n'atteignent le navigateur (injection de balises meta, réécriture de canonicals, ajout de headers), tandis que le service worker gère la couche cache/offline côté client.

Cette séparation des responsabilités résout un problème fondamental : les modifications SEO (meta, canonical, hreflang) sont appliquées au niveau serveur/CDN — là où Googlebot les voit — tandis que l'optimisation de performance (cache, prefetch, offline) est gérée côté client par le SW.

L'erreur serait de gérer les meta tags dynamiquement dans le service worker. Googlebot ne les verra jamais. Toute modification SEO doit être résolue avant que le HTML n'arrive au client — soit côté serveur (SSR), soit côté CDN (edge workers).

Si vous travaillez avec un headless CMS ou une architecture API-first, cette séparation est d'autant plus critique. Le contenu SEO doit être résolu au premier byte, pas délégué au client.

Détecter les régressions liées aux service workers en production

Le problème le plus sournois des service workers est leur nature silencieuse. Un SW défaillant ne génère pas d'erreur 500, pas d'alerte monitoring classique. Les pages continuent de se charger — juste avec le mauvais contenu.

Headers de diagnostic

Ajoutez un header personnalisé dans les réponses servies par votre service worker pour distinguer les réponses cache des réponses réseau :

// Dans le fetch handler du SW
self.addEventListener('fetch', (event) => {
  event.respondWith(
    caches.match(event.request).then((cached) => {
      if (cached) {
        const headers = new Headers(cached.headers);
        headers.set('X-SW-Cache', 'HIT');
        headers.set('X-SW-Cache-Date', cached.headers.get('sw-cache-time') || 'unknown');
        return new Response(cached.body, {
          status: cached.status,
          headers
        });
      }
      return fetch(event.request).then((response) => {
        const headers = new Headers(response.headers);
        headers.set('X-SW-Cache', 'MISS');
        return new Response(response.body, {
          status: response.status,
          headers
        });
      });
    })
  );
});

Ces headers apparaissent dans DevTools > Network et peuvent être captés par votre analytics côté client (via performance.getEntriesByType('resource') ou un beacon dédié) pour mesurer le taux de cache hit/miss en production.

Monitoring continu

Les vérifications manuelles ne tiennent pas à l'échelle. Sur un site de 15 000+ pages, vous avez besoin d'un monitoring automatisé qui compare régulièrement le contenu servi par le serveur avec le contenu indexé par Google. Un outil comme Seogard détecte automatiquement les divergences entre le HTML servi et ce que Google indexe réellement — le type exact de régression silencieuse qu'un service worker mal configuré provoque.

Combinez cela avec les données de la Search Console API pour corréler les baisses de pages indexées ou les changements de crawl rate avec vos déploiements de service workers. Si vous trackez vos KPIs SEO techniques correctement, une régression liée au SW se manifeste typiquement par un écart croissant entre pages crawlées et pages indexées, sans erreur 4xx/5xx associée.

La question du manifest et de l'installabilité

Le fichier manifest.json d'une PWA, combiné au service worker, permet l'installation de l'application sur l'écran d'accueil. Cela n'a aucun impact direct sur le SEO. Google ne donne pas de bonus de ranking aux PWA installables — c'est un mythe persistant qui n'est soutenu par aucune documentation officielle.

En revanche, l'installabilité a un impact indirect mesurable :

Les utilisateurs qui installent la PWA reviennent plus fréquemment (trafic direct).
Le start_url défini dans le manifest est l'URL chargée à l'ouverture — assurez-vous qu'elle est crawlable et canonicalisée correctement.
Si le start_url pointe vers une URL avec des paramètres de tracking (/?utm_source=pwa), déclarez la canonical sans paramètres pour éviter la duplication.

Le Web App Manifest est référencé par Google comme un signal technique de qualité de page dans le contexte des PWA, mais c'est un signal de qualité UX, pas un facteur de ranking. Voir la documentation officielle sur les PWA de web.dev.

Les service workers sont un outil de performance puissant, mais leur impact SEO est presque toujours indirect et insidieux. La règle cardinale : tout ce qui concerne le SEO (meta tags, contenu, données structurées, redirections) doit être résolu côté serveur, avant que le service worker n'entre en jeu. Le SW gère le cache et l'offline — rien d'autre. Monitorer en continu la cohérence entre le contenu serveur et le contenu réellement indexé est le seul filet de sécurité fiable contre les régressions silencieuses.