Should you really redirect Googlebot to www to bypass CORB errors?

What is a CORB error and why does it affect Googlebot?

CORB (Cross-Origin Read Blocking) is a browser security mechanism that prevents a web page from reading certain cross-origin resources. When a service worker makes requests to a domain different from that of the page (e.g., the page is on example.com, the service worker is hitting www.example.com), the browser blocks the read to protect users.

Googlebot uses a modern rendering engine that implements these protections. If your service worker is misconfigured and generates CORB errors, Googlebot may encounter crawl or rendering issues similar to those of a real browser. Result: poorly indexed pages or critical resources not loading.

Why are some sites redirecting Googlebot to www?

Faced with these errors, some developers found a technical shortcut: detect Googlebot via the user-agent and automatically redirect it to the www domain while users remain on the non-www version (or vice versa). The idea? Artificially align the page domain with the one targeted by the service worker, only for the bot.

This is technically acceptable according to Google—no immediate penalty—but it's like putting a Band-Aid on a broken leg. You are circumventing the symptom without treating the root cause, and you create a divergence between the bot experience and the user experience.

Why does Google recommend fixing the root cause?

Martin Splitt is clear: fixing the service worker to target the right domain is the only sustainable solution. A workaround like this adds complexity to debugging: if a problem arises later, you won’t know if it’s related to the service worker, the conditional redirect, or another factor.

Moreover, this approach masks a real bug on the front-end that could impact users in certain scenarios (HTTPS migration, CDN changes, evolving service worker). Fixing the root ensures technical consistency and avoids unpleasant surprises during audits or redesigns.

• CORB protects users by blocking cross-origin reads—Googlebot is subject to it like a modern browser
• Redirecting Googlebot to www to bypass CORB is technically allowed but highly discouraged
• The best practice: fix the service worker to target the domain consistent with the page
• A workaround complicates debugging and masks a real technical issue
• Avoid bot/user divergence—they weaken long-term maintenance

Is Google's tolerance a trap to avoid?

When Google says, "it's technically acceptable," it doesn't mean "it's a good idea." The history of SEO is filled with tolerated practices that end up causing problems during an algorithm update or a change in guidelines. Here, Martin Splitt takes the time to clarify that he recommends NOT doing it—it’s a strong signal.

In practice, redirecting only Googlebot introduces an asymmetry between what the bot sees and what users experience. Even if it’s not strict cloaking (no different content), it remains a form of differential treatment that can complicate audits, tests, and migrations. If tomorrow Google decides to tighten its stance on conditional redirects, you’ll be on the front line.

What concrete risks does this pose for a production site?

The main risk is not an immediate penalty, but an invisible technical debt. Imagine: you migrate to a new CDN, switch to strict full HTTPS, or refactor your service worker. Suddenly, the conditional redirect conflicts with another mechanism, and you spend hours figuring out why Googlebot sees a different version.

[To be verified] Google has not published data on the frequency of these CORB errors in crawling, nor on their actual impact on indexing. We lack massive field feedback confirming that this workaround remains stable over time. My advice: if you absolutely must implement it, document it VERY clearly in your technical wiki and plan a proper fix as soon as possible.

In what cases could this workaround justify itself temporarily?

Let’s be pragmatic. If you are in an absolute emergency—for example, a major migration launched and CORB errors blocking the indexing of critical pages—conditional redirection can act as a band-aid until you fix the service worker. But it must remain temporary and tracked in a prioritized backlog.

In contrast, if you are building a new site or refactoring your PWA, don't even consider this option. Properly configure your domains and service workers from the get-go. It’s less glamorous than a clever hack, but it distinguishes a solid project from a house of cards.

How can I check if my site is affected by CORB errors?

The first step: inspect the Search Console in the "Coverage" and "Crawl Issues" sections. Look for rendering errors, timeouts, or blocked resources. Then, use the rich results testing tool or the URL inspector to see if Googlebot encounters specific CORB errors.

On the browser side, open the developer console (F12), enable the Application > Service Workers mode, and monitor network requests. If you see "Cross-Origin Read Blocking" warnings when the service worker tries to load resources, you have a problem. Test across multiple domains (www vs non-www, HTTP vs HTTPS) to identify inconsistencies.

What is the right method to fix a misconfigured service worker?

Modify the scope of the service worker to target the same domain as your pages. If your users are browsing on example.com, the service worker must register its fetch handlers on example.com, not on www.example.com. Also, ensure that the cache URLs and API requests respect the same domain.

Next, test locally, then in staging, and then in production with a progressive deployment. Monitor the Core Web Vitals metrics and network errors. If you are using Workbox or a PWA framework, ensure that the routing and cache configuration aligns with your domain architecture. No hacks, no conditional redirects—just clean configuration.

Should you really avoid conditional redirection even in emergencies?

If you are in a crawl crisis with thousands of non-indexed pages due to CORB errors, conditional redirection can be an acceptable band-aid for 48-72 hours. But document it, track it in a priority ticket, and plan the proper fix immediately. Never leave such a workaround in production for more than a few weeks.

In all other cases, invest the necessary time to fix the root cause. It may seem burdensome, but it guarantees long-term stability. A well-configured service worker is an investment that pays off for years. A conditional redirect is a debt that will catch up with you at the worst time.

• Audit CORB errors in Search Console and in the browser console
• Ensure the service worker targets the same domain as your pages (www vs non-www)
• Avoid conditional redirects except in absolute and temporary emergencies (max 2-3 weeks)
• Test the configuration locally, in staging, then in production with a progressive rollout
• Document all technical workarounds in a wiki and a prioritized backlog
• Monitor Core Web Vitals and network errors after each change