HTTP/2 and HTTP/3: What Upgrading Changes, and What It Does Not

Last updated: 19 September 2026

Your hosting provider has offered an HTTP/3 upgrade and attached an SEO benefit to the quote. Somebody wants to know whether it will move rankings.

It will not, and the more useful question is whether it will make the site faster for the people already on it — which depends entirely on what is currently slow.

Google has stated that there is no explicit drawback to being crawled over HTTP/1.1, and that crawl quality and quantity remain the same either way. A protocol upgrade is a genuine efficiency improvement for connections and server resources. It is not a ranking lever, and on a site whose problem is a 900KB hero image it will change almost nothing a visitor can feel.

Key facts

• Googlebot began crawling selected sites over HTTP/2 in mid-November 2020, per Google’s Search Central announcement.
• Google states that if a server only supports HTTP/1.1, “there’s no explicit drawback for crawling over this protocol; crawling will remain the same, quality and quantity wise”.
• Google describes the change as making crawling “more efficient in terms of server resource usage”, not as a ranking benefit.
• Googlebot decides which sites to crawl over HTTP/2, and Google’s stated answer to how you persuade it is “You can’t”.
• Google found “little to no benefit” for some sites, giving those with very low queries per second as its example.
• A site must use HTTPS and support HTTP/2 to be eligible; Googlebot does not support plaintext HTTP/2, known as h2c.
• 98% of HTML requests served through a CDN used HTTP/2 or better in 2024, against 71% served from origin servers — up from 42% in 2022, per the HTTP Archive Web Almanac.

This article covers what each protocol version actually changes, what Google has said about crawling, where the real speed gains are on a typical site, and how to tell whether the upgrade in front of you is worth buying.

What does HTTP/2 actually change?

It lets the browser fetch many files over a single connection instead of opening a new one for each.

What it looks like: under HTTP/1.1 a browser opens roughly six connections per host and queues everything else behind them. Under HTTP/2 one connection carries many requests in parallel.

Key data: Google describes the benefit in exactly these terms — a single TCP connection transferring multiple files in parallel, so fewer resources are spent by both the server and Googlebot.

Why it matters: the gain is largest on pages making many small requests, which is why the old workarounds — sprite sheets, concatenated stylesheets, sharding assets across subdomains — stopped being useful and became counterproductive.

The check: open the browser developer tools, go to the Network tab, right-click the column headers and enable Protocol. If the column reads h2 you are already on HTTP/2; h3 is HTTP/3 and http/1.1 is the old one. This takes ten seconds and settles most of the argument.

What does HTTP/3 add on top?

It moves the transport from TCP to QUIC, which runs over UDP. The practical effect is that a lost packet no longer stalls every stream on the connection.

Why it matters: HTTP/2 removed head-of-line blocking at the HTTP layer but not at the transport layer, so on a lossy connection one dropped packet still held everything up. HTTP/3 addresses that, and connections also survive a network change — moving from wi-fi to mobile data does not restart the handshake.

Where it helps most: poor mobile networks and long distances. On a fast fixed connection to a nearby server the difference is small enough that you will struggle to see it in field data.

That last point deserves emphasis because it is usually left out of the summary. If your audience is on good connections close to your servers, HTTP/3 is a refinement rather than a fix.

Does any of this improve rankings?

No. Google has never described protocol version as a ranking signal, and its own announcement of HTTP/2 crawling says the opposite.

Key data: Google stated that a server supporting only HTTP/1.1 is “also fine”, with no explicit drawback, and that crawling remains the same in quality and quantity.

Why it matters: that sentence is the answer to any quote that attaches an SEO benefit to a protocol upgrade. The efficiency is real and it accrues to your server, not to your position.

The check: ask for the Google documentation behind any ranking claim attached to the quote. The announcement is the relevant page and it says the reverse.

Can you make Googlebot crawl you over HTTP/2?

No. Google’s published answer to that exact question is “You can’t.”

Key data: Googlebot chooses based on whether the site supports HTTP/2 and whether both parties would benefit. Google reported little to no benefit for some sites, naming those with very low queries per second, and said it continues to crawl those over HTTP/1.1.

Why it matters: a small brochure site will not be switched no matter what it configures, because there is nothing to save. This is not a failure to optimise.

The check: if your site is eligible and switched, the Search Console account receives a message saying some crawl traffic may move to HTTP/2. You can also confirm it directly in your server access logs. If you ever need to opt out, Google documents responding with a 421 status code to Googlebot over h2.

What is required before HTTP/2 is even possible?

HTTPS. Googlebot does not support plaintext HTTP/2, known as h2c, which mirrors how browsers behave.

Why it matters: if any part of the site is still served over HTTP, or the certificate chain is broken on a subdomain, the protocol question is premature. Fix the transport security first; it is a prerequisite rather than a parallel task.

Where is the actual speed problem on most sites?

Not the protocol. Less than half of mobile origins pass Core Web Vitals, and the metric most of them fail is Largest Contentful Paint — which is usually decided by one image, one font, or a blocking script.

Why it matters: upgrading the protocol while lazy-loading the hero image is a precise description of optimising the wrong layer. The connection is not what the browser is waiting for.

The check: run the template through PageSpeed Insights and read the named LCP element and the Time to First Byte figure. If TTFB is high, the problem is server response — caching, database queries, or a redirect chain — and no protocol change fixes a slow origin. If TTFB is fine and LCP is poor, it is an asset problem, and the fixes are the ones in our guide to what images actually cost you.

What should you stop doing once you are on HTTP/2?

The HTTP/1.1 workarounds, which now actively hurt.

Domain sharding split assets across hostnames to escape the six-connection limit; under HTTP/2 it forces extra connections and extra handshakes. Aggressively concatenating every stylesheet and script into one bundle defeats granular caching, since one small change invalidates the whole file. Image sprites do the same thing to images.

The check: look at how many distinct hostnames serve your own static assets. More than one or two, on a site running HTTP/2, is a legacy decision worth reversing.

Does a CDN make the protocol question moot?

Largely, and that is the cheapest route for most sites. The adoption gap is the evidence: 98% of CDN-served HTML was on HTTP/2 or better in 2024, against 71% served directly from origin servers.

Why it matters: a CDN terminates the connection at an edge location near the visitor and speaks whatever protocol that visitor’s browser supports, regardless of what your origin runs. You get the modern protocol without touching the application server, and you get the larger win of a shorter physical distance at the same time.

The check: if you already sit behind a CDN, open its dashboard and look for the HTTP/3 or QUIC toggle. On most providers it is a switch rather than a project, and it is frequently already on without anyone having noticed.

What about server push?

Ignore it. Server push was the HTTP/2 feature that generated the most excitement and the least benefit, and browser support for it has been withdrawn rather than expanded.

Key data: in its 2020 announcement Google listed server push among the features still being evaluated for Googlebot, and it never became a recommendation.

Why it matters: push was intended to send resources before the browser asked, but it routinely sent things the browser already had cached, wasting the bandwidth it was meant to save. Where a resource genuinely needs prioritising, a preload hint in the HTML does the job predictably, which is the approach worth using on a hero image or a critical font.

How should you decide whether to upgrade?

On hosting and operational grounds, the same way you would decide anything else in the stack. If your CDN or host offers HTTP/3 at no extra cost, enable it — the downside is negligible and the upside is real for mobile users on poor connections. If it carries a meaningful cost and an SEO justification, the justification is wrong and the cost should be judged on its own.

Most sites get there by putting a CDN in front of the origin rather than by reconfiguring the origin, which is what the adoption gap in the chart above reflects: 98% against 71%.

Does the protocol affect crawl budget?

Indirectly at most, and only for sites large enough for crawl budget to be a real constraint. Google’s stated reason for crawling over HTTP/2 is reduced resource usage on both sides, which in principle lets a crawler fetch more for the same cost.

Why it matters: Google did not promise more crawling, and said the opposite about quality and quantity remaining unchanged. For the overwhelming majority of sites, crawl budget is not the limiting factor on what gets indexed — relevance and internal linking are.

The check: open Settings, then Crawl stats in Search Console and look at total crawl requests and average response time. If response time is high and crawl requests are flat, the constraint is your server’s speed rather than its protocol, and that is worth fixing for visitors as well as for Googlebot.

Which protocol does what

Symptom, cause and how to confirm it

What to do, and what to decline

Treat the protocol as infrastructure rather than as SEO. Google framed HTTP/2 crawling as a server-resource efficiency and said in the same post that staying on HTTP/1.1 carries no explicit drawback and no change to crawl quality or quantity — which is as close to a denial of the ranking claim as Google gives on anything.

The single next action is to open the Network tab on your own site, enable the Protocol column, and read what it says. If it already reads h2 or h3, the upgrade someone is quoting for has largely happened, and the money belongs somewhere else.

What not to do: do not approve a protocol upgrade on an SEO justification — judge it on hosting and user-experience merits, where the case is often perfectly good. Do not keep HTTP/1.1-era sharding and bundling once you are on HTTP/2, and do not treat the protocol as a substitute for fixing the element the browser is actually waiting on. Where speed genuinely matters to the business, the work sits in Core Web Vitals on real field data rather than in the connection layer, and an SEO audit that reads Time to First Byte alongside the LCP element will tell you in an afternoon which layer to spend on. If rankings rather than speed are the real concern, diagnose that separately before anyone touches the server.

About the author

Shabir MS leads SEOValley Solutions and has worked in search since 2005. He has reviewed a good number of hosting quotes that attach an SEO benefit to a protocol line item, and checks each one against Google’s own documentation before advising on it. Read more from Shabir MS.

Frequently asked questions