HTTP/2 and HTTP/3 and crawling
Googlebot supports crawling over HTTP/2 where it is beneficial, and HTTP/2 and HTTP/3 improve connection efficiency through multiplexing and reduced overhead. Switching transport does not by itself change rankings, but it can make crawling more efficient and reduce server load. Google may crawl over HTTP/2 or fall back to HTTP/1.1 depending on what the server supports and what is efficient.
What this means
HTTP/2 introduced multiplexing (many requests over one connection), header compression, and lower connection overhead. HTTP/3 moves the transport onto QUIC over UDP, reducing connection-setup latency and head-of-line blocking. Both are about how bytes move, not about page content.
Google has stated that Googlebot can crawl over HTTP/2 when it is beneficial for the server, and that doing so saves resources for both sides. Crawling over HTTP/2 does not change a site's ranking; it is purely an efficiency improvement.
How protocol choice affects crawling
Multiplexing lets a crawler fetch multiple resources over a single connection, which can reduce the per-request overhead of a busy crawl. Where HTTP/2 is supported and efficient, Googlebot may use it; otherwise it falls back to HTTP/1.1.
HTTP/3 adoption by crawlers is more limited than HTTP/2; do not assume a crawler speaks h3. The practical guidance is to support modern protocols correctly and ensure clean negotiation, not to expect a ranking benefit from the transport itself.
- HTTP/2: multiplexing, header compression, lower overhead
- HTTP/3: QUIC over UDP, faster connection setup
- Googlebot can crawl over HTTP/2 when beneficial; can fall back to HTTP/1.1
- Transport choice is an efficiency detail, not a ranking factor
Operational checks
Verify that protocol negotiation (ALPN) works and that your server does not break on h2 or h3 for legitimate clients. Misconfigured upgrades or broken fallbacks can cause connection errors that look like crawl problems.
If you front your site with a CDN, the protocol between the crawler and the edge may differ from the protocol between the edge and origin. Diagnose crawl efficiency at the edge where the crawler actually connects.
How it appears in analytics and logs
Seeing HTTP/2 connections from Googlebot in logs means Google determined h2 crawling was beneficial for your server. Protocol choice is an efficiency detail, not a ranking signal, and Google can switch between h2 and HTTP/1.1.
Diagnostic use case
Understand whether enabling HTTP/2 changes how Googlebot crawls, and confirm your server negotiates protocols cleanly so crawlers are not forced into inefficient fallbacks or errors.
What WebmasterID can help detect
WebmasterID records crawler requests server-side regardless of whether they arrive over HTTP/1.1, HTTP/2, or HTTP/3, so your crawl-coverage view is consistent across transports.
Common mistakes
- Expecting an HTTP/2 or HTTP/3 switch to raise rankings — it improves efficiency, not ranking.
- Assuming all crawlers speak HTTP/3; h3 crawler support is more limited than h2.
- Ignoring broken protocol negotiation that surfaces as connection errors in crawl logs.
- Diagnosing origin protocol when the crawler actually connects to a CDN edge.
Privacy and accuracy notes
Protocol negotiation involves transport metadata only, never visitor identity. WebmasterID classifies crawler requests by user-agent token regardless of transport and never fingerprints visitors by connection details.
Related pages
- Time to first byte (TTFB) and crawl health
Time to first byte (TTFB) measures how long the server takes to start sending a response. High TTFB slows every fetch and, when sustained, can cause Googlebot to crawl more conservatively because slow responses signal the server is under strain. TTFB is a server-and-network metric distinct from rendering metrics like LCP, and improving it benefits both crawlers and users.
- How CDNs interact with crawlers
A CDN sits between crawlers and your origin, so it shapes what crawlers see: cached responses, edge-served status codes, bot-management challenges, and region-specific edges. Configured well, a CDN speeds crawling and absorbs load; configured poorly, it can block legitimate crawlers, serve stale or wrong content, or return CDN-specific errors that look like origin problems. Understanding the interaction prevents silent crawl failures.
- Server response time and crawling
Server response time directly affects how much Google can crawl. Googlebot adjusts its crawl rate to avoid overloading a server, so consistently slow responses reduce the number of pages it fetches. Persistent slowness or 5xx errors cause Google to back off. This page explains the crawl-rate-versus-response-time relationship, its connection to time-to-first-byte, and how to keep responses fast under crawl load.
- Website observability
See crawler requests recorded server-side across transports and edges.
Sources and verification notes
- Google Search Central Blog — Googlebot will crawl over HTTP/2Googlebot HTTP/2 crawling; no ranking change, efficiency only.
- MDN — Evolution of HTTP
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.