HTTP/3 is the newest version of the protocol that moves your pages from server to browser, and it matters for both speed and crawling. HTTP/1.1 handled one request at a time per connection, HTTP/2 let many requests share a single connection, and HTTP/3 rebuilds that on top of QUIC (which runs over UDP instead of TCP) to remove the head-of-line blocking that still slowed HTTP/2 on shaky networks. For site owners, the practical question is simple: is your server serving modern protocols, and is that helping or hurting how fast bots and users get your content?

What actually changed between the versions

HTTP/1.1 forced browsers to open six or more parallel connections to load a page, because each connection could only carry one request until it finished. That was wasteful and slow. HTTP/2 fixed it with multiplexing: one connection, many concurrent streams, plus header compression and server push. It was a real jump in efficiency, especially for pages with dozens of assets.

HTTP/2 still had a weakness. Because it runs on TCP, a single lost packet stalls every stream on that connection until the packet is re-sent. HTTP/3 solves this by running on QUIC over UDP, where each stream is independent. A dropped packet on one stream no longer freezes the others. On fast, clean networks the difference is modest; on mobile connections with packet loss, HTTP/3 can meaningfully cut load time.

Does the protocol version affect crawling?

Yes, but indirectly. Googlebot has crawled over HTTP/2 since late 2020 when a site supports it, and it can fall back to HTTP/1.1 when needed. Crawling over HTTP/2 is more efficient for both sides because the bot can request many resources on one connection instead of repeatedly opening new ones, which reduces load on your server. The content Google sees is identical either way, so this is about efficiency, not ranking.

The bigger crawl impact comes through performance. Faster server responses mean a bot can fetch more pages in the time it allots to your site. If you have a large site fighting for attention, protocol efficiency compounds with the work described in our guide to crawl budget optimization and the response-time tuning in reducing time to first byte. AI crawlers benefit the same way — a leaner connection lets GPTBot, ClaudeBot and PerplexityBot pull your pages without timing out.

How to check what your site is serving

You can see your protocol version in any browser's network panel: open developer tools, load the page, and look at the Protocol column (you may need to right-click the column header to enable it). It will show h2 for HTTP/2 or h3 for HTTP/3. From the command line, curl --http3 -I https://yoursite.com tests HTTP/3 support, and online tools report the same.

A few things to verify:

Should you rush to enable HTTP/3?

Enabling HTTP/2 is a clear win with no real downside, and almost every current server and CDN supports it — if you are still on HTTP/1.1 only, that is the upgrade to prioritise. HTTP/3 is a smaller, incremental gain that mostly helps users on unreliable networks. It is worth turning on if your CDN offers it for free, but it will not rescue a slow site whose real problems are heavy JavaScript, unoptimised images or a sluggish backend.

Protocol is the plumbing; it moves your bytes faster but does not change what those bytes are. If the underlying page is bloated, no protocol version will save your Core Web Vitals. Fix the fundamentals first — the measurable ones covered in our website performance optimization guide — then let a modern protocol shave off the last layer of latency.

Not sure which protocol your site serves, or whether AI bots can reach it quickly? Run the free CheckMy.site scanner to see how your site responds to crawlers and where its speed is leaking away.