Service Worker

A service worker is a JavaScript file that runs in the background, separate from your web page, and sits between the browser and the network as a programmable proxy: it can intercept requests, serve cached responses, and power offline behavior and push notifications. It matters for SEO because a badly written one can quietly hand crawlers stale, broken, or different content than real users see, and nobody notices until rankings slide.

Service workers are the engine under a Progressive Web App. They are great for speed and resilience. The catch: because they can rewrite what a request returns, they are also a place where "works on my machine" and "what Googlebot got" can diverge, and where you can accidentally block the very assets that make your page render.

A minimal, safe service worker

Here is a small worker that caches static assets but always fetches HTML fresh from the network, so crawlers and users get current content:

self.addEventListener('fetch', (event) => {
  const req = event.request;

  // HTML: always go to network first, fall back to cache offline.
  if (req.mode === 'navigate') {
    event.respondWith(
      fetch(req).catch(() => caches.match('/offline.html'))
    );
    return;
  }

  // Static assets: serve from cache, update in background.
  event.respondWith(
    caches.match(req).then((hit) => hit || fetch(req))
  );
});

The important line is req.mode === 'navigate' going network-first. Cache-first HTML is how sites end up serving a crawler a page from last week. Note that Googlebot does not persist a service worker between page loads, so it fetches from the network the way a brand-new visitor would; your caching logic still has to return correct content on that first, uncached request.

Caching strategies and their SEO risk

How to check your service worker on your own site

1. Open DevTools, Application, Service Workers. Confirm one is registered, see its scope, and check "Update on reload" while testing so you are not fighting a stale worker.
2. Tick "Bypass for network" and reload. If the page looks different with the worker bypassed, the worker is changing what gets served, which is exactly what you need to reconcile with what crawlers see.
3. Compare with a fresh, worker-free fetch. Run curl -sL https://yoursite.com/page (no service worker involved) and diff it against the in-browser HTML. Big differences mean crawlers and users are getting different pages.
4. Confirm it does not block render assets. Make sure the worker is not intercepting and failing requests for CSS or JS that Google's Web Rendering Service needs to render the page.
5. Test the update flow. Deploy a content change, reload twice (workers often activate on the second load), and confirm the new content actually appears rather than the cached old one.

Common mistakes and how to fix them

• Cache-first on HTML. This is the classic one: crawlers get a snapshot frozen at deploy time. Fix: use network-first (or stale-while-revalidate) for navigation requests and reserve cache-first for versioned static assets.
• No cache-busting on updates. Users and bots stay stuck on old JavaScript because the worker keeps serving it. Fix: version your cache name (cache-v3) and delete old caches in the activate event.
• Intercepting requests you should not. A worker that swallows a failed CSS request can leave the page unstyled for the renderer. Fix: scope the fetch handler narrowly and let unhandled requests pass straight through to the network.
• Serving an offline shell to crawlers. If the worker returns an app shell with no real content on first load, a bot indexes an empty frame. Fix: ensure the very first uncached response contains the actual content.
• Registering the worker too eagerly. Blocking first paint on worker setup hurts perceived speed. Fix: register after load and keep the install step lean.

Frequently asked questions

Does a service worker hurt my SEO?

Not by existing. It hurts SEO only when it serves crawlers stale or different content, or blocks assets the renderer needs. A network-first worker that leaves HTML fresh and passes render assets through is safe, and can even help by speeding repeat visits.

Does Googlebot run my service worker?

No. Googlebot does not register or persist service workers across page loads. It fetches each URL from the network like a first-time visitor with an empty cache. That is why your worker's uncached, first-request behavior has to return correct, complete content.

What is the difference between a service worker and browser cache?

The HTTP cache is passive and follows response headers. A service worker is programmable: you decide, in JavaScript, what to cache, when to serve it, and when to hit the network. That power is why it is more useful and also riskier than plain caching.

Do I need a service worker for a PWA?

Yes. Offline support, install prompts, and push notifications all run through a service worker; it is the defining piece of a Progressive Web App. If you do not need offline or background features, you may not need a worker at all.

Why does my site show old content after I deploy?

Almost always a cache-first service worker serving the previous version. Version your cache name, delete old caches on activate, and use network-first for HTML. Until you do, both users and crawlers can keep seeing the stale copy.

Related reading: Service Worker Impact on SEO, Progressive Web App (PWA), JavaScript SEO: How Search Engines and AI Crawlers Render Your Pages.