Does Googlebot really ignore your WebP images served through Service Workers?

What is a Service Worker and why do some sites use it for images?

A Service Worker is a JavaScript script that runs in the background of the browser, independently of the web page. It allows intercepting network requests and manipulating responses before they reach the browser.

Some developers use it to dynamically serve WebP images to compatible browsers, while maintaining JPEG/PNG for older browsers. It is a form of progressive enhancement on the client side, technically elegant, but invisible to a bot that does not execute JavaScript at the same level as a modern browser.

Why doesn’t Googlebot execute Service Workers?

Googlebot has been executing JavaScript for years, but not all types of scripts. Service Workers operate outside the main thread of the page and require persistent state management between requests — something Googlebot does not implement.

The bot treats each URL as an isolated request, with no session context or Service Worker cache. As a result, any image substitution logic on the Service Worker side is simply bypassed. Googlebot sees what the HTML directly returns, period.

What’s the difference between what the user sees and what Google sees?

The user with a modern browser benefits from the optimized WebP version, with significant gains in weight and loading speed. Googlebot, on the other hand, fetches the original formats defined in the HTML or <picture> tags without the Service Worker layer.

This means that your Core Web Vitals on the user side may be excellent, but Google indexes heavier images than those actually served. Crawling is not blocked — JPEG/PNG images are discovered — but you miss out on the WebP label in Google’s Image index.

• Googlebot completely ignores Service Workers, no matter how sophisticated they may be.
• Images served only via Service Worker will not be indexed in WebP, even if the end user receives them in that format.
• Crawling of images continues normally on the original formats defined in the source HTML.
• User performance remains intact, but the SEO impact of WebP is lost for image indexing.
• This limitation applies to all resources served exclusively via Service Worker, not just images.

Is this statement consistent with field observations?

Absolutely. Tests with Google Search Console and rendering tools have long shown that Googlebot does not handle Service Workers. The URL Inspection Tool does not execute them either. No surprises here.

What’s more interesting is that Martin Splitt is taking the time to clarify this publicly. It shows that enough sites have adopted this strategy for Google to deem it necessary to explicitly lay down the limits. Purely client-side JavaScript implementations remain a partial blind spot for crawling.

What nuances need to be added to this rule?

The issue only concerns sites where the Service Worker is the sole method of serving WebP. If you use <picture> tags with WebP sources declared on the server side, Googlebot will see them perfectly — Service Worker or not.

In other words, Martin Splitt’s statement targets architectures where the source HTML contains only JPEG/PNG, and where a Service Worker performs transparent substitution on the client side. In this specific case, yes, Google indexes the original formats. [To verify]: it is unknown whether Google plans to execute Service Workers one day — nothing indicates that it is on the roadmap.

What risks are there if we ignore this limitation?

The main risk? You believe you are serving WebP to Google when that’s not the case. This skews your SEO assumptions, particularly for image search where format and weight matter.

Another perverse effect: if you completely disable JPEG/PNG on the server thinking the Service Worker is sufficient, you risk breaking image indexing or making certain resources inaccessible to the bot. Let’s be honest, this is rare — but it happens on excessively optimized client-side stacks without server fallback.

What should you do to ensure Google indexes your WebP images?

The most robust solution is to serve WebP on the server side, via <picture> or <img> tags with declared srcset and types. Googlebot fully understands this syntax and will index the WebP versions without any issues.

If you are using a modern CDN (Cloudflare, Fastly, Akamai), activate automatic WebP conversion with content negotiation via the Accept header. The bot sends this header, receives WebP if available, and indexes it correctly. No need for JavaScript.

What mistakes should be avoided in the WebP implementation?

Never rely solely on client-side JavaScript — Service Worker or otherwise — as the only method of serving an image format. It is a layer of enhancement, not a foundational architecture for SEO.

Also, avoid conditional JavaScript redirects that load different URLs based on detected WebP support on the browser side. Googlebot will follow the default version, often the JPEG, and ignore the WebP branch. Always favor server logic or native HTML tags.

How to check if your WebP implementation is crawl-compatible?

Use the URL Inspection Tool in Google Search Console to test a page containing your images. Look at the rendered HTML version: if the <img> or <picture> tags point to .webp, you’re good. If you only see .jpg/.png, your Service Worker is doing the job — and Google does not see it.

Also, test with curl -A "Googlebot" -H "Accept: image/webp" on your image URLs. If the server returns WebP with the correct Content-Type, you’re safe. If it returns JPEG regardless, you need to revisit your server configuration.

• Implement WebP images server-side via <picture> tags or HTTP content negotiation.
• Never rely only on a Service Worker to serve optimized formats intended for indexing.
• Check Googlebot’s rendering using the URL Inspection Tool and confirm that .webp appears in the HTML.
• Test server responses with curl by simulating a Googlebot user-agent and an Accept: image/webp header.
• Maintain an explicitly declared JPEG/PNG fallback for non-compatible bots and browsers.
• Monitor server logs to ensure Googlebot receives the correct resources during crawling.