Why does Googlebot still crawl using HTTP/1.1 instead of HTTP/2?

What is the concrete difference between HTTP/1.1 and HTTP/2?

HTTP/2 offers several major advantages that developers exploit to speed up modern sites. Multiplexing allows multiple requests to be sent simultaneously over a single TCP connection, whereas HTTP/1.1 requires sequential processing.

HPACK header compression drastically reduces the size of repetitive headers. Server push enables the server to anticipate necessary resources and send them before the browser even requests them. In contrast, HTTP/1.1 forces multiple parallel connections (typically 6 per domain) to work around its limitations.

Why hasn't Google migrated Googlebot to HTTP/2 yet?

The official reason has never been detailed by Martin Splitt or other Google spokespersons. It is assumed that crawling billions of pages while maintaining persistent HTTP/2 connections would pose infrastructure and compatibility challenges—some poorly configured servers still crash with HTTP/2.

Another hypothesis is that Googlebot needs to crawl the entire web, including sites hosted on outdated servers. HTTP/1.1 remains the safest common denominator. However, this is just an interpretation—Google does not communicate its internal crawl infrastructure constraints.

How does this affect JavaScript rendering?

Modern JavaScript often relies on dozens of requests to load components, APIs, frameworks, and data. With HTTP/2, a browser multiplexes them efficiently. Googlebot, however, must process them using HTTP/1.1, which increases the loading time on the crawler side.

If your site requires 40 JavaScript requests to fully render, Googlebot will saturate its 6 parallel connections and wait for each batch to complete before moving on to the next. The rendering time elongates, and if you exceed Googlebot's timeout (about 5 seconds for the first meaningful render), it may end up crawling an incomplete page.

• Googlebot uses HTTP/1.1, not HTTP/2, for all its crawling operations
• HTTP/2 multiplexing only benefits users, not Google's bot
• Sites with numerous JS resources need to specifically optimize for HTTP/1.1
• HTTP/2 server push is invisible to Googlebot and does not speed up its crawl
• The JavaScript rendering time can be significantly longer for the bot than for a modern browser

Is this limitation consistent with real-world observations?

Yes, absolutely. Real-world crawl tests show that Googlebot indeed establishes HTTP/1.1 connections, even on servers that support HTTP/2. This is clearly seen in server logs and with tools like OnCrawl or Botify.

What is more interesting is that this constraint amplifies the gap between user experience and bot experience. A site might display excellent Core Web Vitals for real visitors thanks to HTTP/2, modern CDN, and aggressive lazy loading, but can struggle completely on the Googlebot side if the JS architecture is not designed for HTTP/1.1. This is a classic trap for poorly optimized React/Vue/Angular sites.

What nuances should be added to this statement?

Google does not say that HTTP/2 has no SEO value — just that Googlebot does not use it for crawling. However, HTTP/2 improves user experience, which indirectly enhances behavioral signals (session duration, bounce rate, pages viewed). It is not a direct ranking factor, but it contributes to the overall picture.

The other nuance is that this limitation could evolve. Google has already migrated Googlebot to an evergreen Chrome for rendering JavaScript. Switching to HTTP/2 for crawling is technically feasible, but there’s no indication that it’s a priority. [To be verified]: there is no public roadmap on this topic, so caution is advised with any claims about future changes.

In what cases could this rule pose a critical problem?

Poorly designed Single Page Applications (SPAs) are the first victims. If your React app loads 60 JavaScript chunks in parallel to display the main content, HTTP/1.1 will create a massive bottleneck. Googlebot may timeout before seeing the indexable content.

E-commerce sites with aggressive lazy loading and unoptimized third-party scripts (ad tags, analytics, chat bots) also fall into this trap. Each third-party script = an additional HTTP/1.1 request that blocks or slows down rendering. And that’s where the issue lies: the crawler cannot see your product listings because they load too late.

How to optimize JavaScript for HTTP/1.1 crawling?

Reduce the number of requests to the bare minimum. Bundle your JavaScript files instead of splitting them into 40 micro-chunks. Yes, HTTP/2 makes bundling less necessary for users, but Googlebot needs it. Aim for fewer than 10 critical JS requests for the first render.

Prioritize Server-Side Rendering (SSR) or Static Site Generation (SSG) for indexable content. Next.js, Nuxt, or SvelteKit allow you to serve pre-rendered HTML to Googlebot, which no longer needs to execute 50 scripts to see your content. This is the most robust solution if you are in SPA.

What mistakes should absolutely be avoided?

Don’t rely solely on HTTP/2 and multiplexing to compensate for a heavy JS architecture. What works for your users doesn't work for the crawler. Front-end developers often optimize for Lighthouse and modern browsers, forgetting that Googlebot still operates in the HTTP/1.1 world.

Avoid also blocking rendering with non-critical third-party scripts. Google Tag Manager, Facebook Pixel, HotJar—all of these should be loaded asynchronously/deferred and not block the display of the main content. Every millisecond counts when Googlebot runs on a tight timeout.

How can I check if my site is crawlable in HTTP/1.1?

Use Google Search Console and its live URL testing tool. It shows you exactly what Googlebot sees and measures the rendering time. If indexable content does not appear in the rendered DOM, that’s an immediate red flag.

On the logging side, check that Googlebot is not generating 5xx errors or timeouts on your critical JavaScript resources. Botify or Oncrawl monitoring enables you to cross-reference server response times and crawl depth—if Googlebot abandons certain sections of your site, it may be linked to an HTTP/1.1 bottleneck.

• Bundle your JavaScript files to reduce the number of requests (goal: fewer than 10 for the initial render)
• Implement SSR or SSG to serve pre-rendered HTML to Googlebot
• Load third-party scripts asynchronously/deferred to avoid blocking rendering
• Test with Chrome DevTools by throttling HTTP/1.1 and slowed CPU (minimum 4x slowdown)
• Monitor your server logs for specific timeouts or errors associated with Googlebot
• Use the URL testing tool in Search Console to validate rendering on Google’s side