What does Googlebot see of service workers?

Our test in Search Console

For a progressive web app, we wanted to know what Googlebot does with the service worker. So we built a test page that registers a file sw.js with the scope “/” on load and prints the result on the page. We tested this page live with the URL Inspection tool in Search Console.

The message gives no reason. Still, this is not a bug, because Googlebot behaves the way Google built the renderer.

Why doesn't Googlebot run service workers?

Since May 2019, Googlebot has rendered with a current version of Chromium. At the time, Google spoke of over 1,000 new features compared with the old Chrome 41, including ES6, IntersectionObserver and Web Components. Service workers were not on the list.

The reason lies in how the Web Rendering Service (WRS) is built. According to Google's documentation, it keeps no state between two page loads. Cookies, local storage and session storage are cleared, and Googlebot declines permission requests. A service worker only helps on the second visit, because it stores files for later. For Googlebot, every request is a first visit, and users coming from search have often never been on the page before.

The feature detection trap

The check 'serviceWorker' in navigator still returns true in the renderer, because Chromium knows the interface. Only the call to register() fails. If you only check for support and then make content depend on the service worker, you show Googlebot an empty or half-empty page. sw.js may still show up in server logs as a request by Googlebot. The file is not executed.

Typical failure patterns

The same patterns keep coming up in forums and in our own analyses.

• Subpages only via the service worker. The app expects the user to load the homepage first and the service worker to deliver all further pages afterwards. Googlebot requests subpages directly and gets an empty shell or an error. In extreme cases, only the homepage ends up in the index.
• SEO elements change on the second visit. The service worker swaps the title, description or structured data, for example for A/B tests. Googlebot sees a different version from returning visitors. This can be treated as cloaking.
• Cache-first for changing content. Returning visitors see old prices or text for weeks, while Googlebot sees the current state. For many users, the search result then does not match the page.
• Service worker from the framework default. Starter templates and PWA plugins often ship a service worker with aggressive caching, without the team knowing.

How to use service workers safely for SEO

1. Progressive enhancement. Every page works fully without a service worker. It only speeds up repeat visits.
2. Catch errors. If registration fails, the page keeps running without a message.
3. Deliver content from the server. Server-side rendering or static generation for the first request, then hydration in the browser. Next.js, Nuxt, SvelteKit, Angular SSR and Gatsby support this.
4. Network-first for changing content. The service worker asks the server first and only falls back on the cache if that fails.
5. Set the scope deliberately. An sw.js under /blog/ only controls URLs under /blog/. For the whole website, it belongs in the root directory.
6. Never change SEO elements in the service worker. Title, description, canonical, meta robots, hreflang, structured data and Open Graph tags are the same for all visitors.

This is what a registration looks like that does not disturb Googlebot.

This is what a simple network-first strategy looks like in the service worker.

Edge workers as an alternative

If responses need to be adjusted for all visitors, for example for redirects or tests with metadata, an edge worker is the right place. Cloudflare Workers, Lambda@Edge, Fastly Compute or Netlify Edge Functions run on the server before the response reaches the browser. Googlebot gets the same response as every other visitor. If the website needs neither offline mode nor background sync, doing without a service worker is often the simplest solution.

How to check your pages

For a first look, use our Service Worker Test. It shows whether a page registers a service worker, what the page uses it for and what a crawler gets on the first visit without it. Then continue checking by hand.

1. Open Chrome DevTools, the “Application” tab, the “Service Workers” section.
2. Enable “Bypass for network”. The browser then loads pages as if there were no service worker.
3. Under “Storage”, delete all stored data with “Clear site data”.
4. Open a subpage directly and reload it. Text, images, navigation, crawlable links and the title and meta tags in the source code must be there.
5. In Search Console, start URL Inspection and choose “Test live URL”. Compare the screenshot, rendered HTML and console messages with the source code.

The message “Registration failed: Rejected” in the console is to be expected. All that matters is whether everything is there without a service worker. If content is missing, there is an architecture problem that a setting cannot fix.

searchVIU Service Worker Test

The test fetches a URL like a new visitor and renders it without an active service worker. This is how Googlebot gets every page too. The test then looks for the registration in the source code, in the rendered HTML and in up to 15 of the page's scripts. It reads the service worker script without running it.

• Registration with script address, scope and the Service-Worker-Allowed header. If the scope is above the script's folder or the script is served with the wrong content type, the test reports an error.
• Usage: offline page, precache, caching strategy per resource type, push messages, background sync, navigation preload and the detected library, such as Workbox with its version.
• Cache: the offline page and up to 10 precache files with their status code. If one file is missing, the service worker's installation aborts.
• Signals on the first visit: status code, title, canonical, meta robots, H1, words and links, plus a comparison of the selected user agent with Chrome.

The test does not yet run a second visit in which the service worker already controls the page. It derives what returning visitors see differently from the script.

The previous tool on searchviu.com was a self-test. It registered a service worker in whichever browser opened the page and checked cache, messaging and background sync there. Combined with the URL Inspection tool in Search Console, this showed how Googlebot reacts. The new test checks any URL from the outside. For Googlebot's own view, the URL Inspection tool in Search Console remains the direct route.

What has changed since then?

Google retired the Mobile-Friendly Test, which in 2020 offered a second look at Google's rendering, at the end of 2023. For testing, the URL Inspection tool in Search Console remains. Google's documentation still describes the renderer as stateless and based on a current version of Chromium (as of March 2026). The test page still shows the same result in the live test.

Common mistakes

• Feature detection is taken as proof that the service worker is running.
• Content or internal links only get onto the page via the service worker.
• If registration fails, the page shows an error message or stays empty.
• Cache-first for pages with prices, availability or news.
• The framework's default service worker stays active without being checked.

FAQ