HTTP/2 and HTTP/3

TL;DR — HTTP/2 and HTTP/3HTTP/2 and HTTP/3 are the modern versions of the HTTP protocol. HTTP/2 multiplexes many requests over one TCP connection; HTTP/3 swaps TCP for QUIC (over UDP) so a dropped packet only stalls the one stream it belongs to, not every stream (streams still share the connection's congestion control). Neither is a Google ranking factor — the SEO payoff is indirect, through faster real-user page speed. are newer versions of the “language” your browser and a website’s server use to talk. They make pages load faster by fetching lots of files over one connection instead of many. They won’t directly boost your Google rankings — but a faster site can help indirectly. For most sites, turning them on is a setting at your CDN, not a big project.

What HTTP/2 and HTTP/3 are

Every time you open a web page, your browser and the site’s server have a conversation using a protocol called HTTP. For years that was HTTP/1.1, which had a real bottleneck: it fetched files mostly one at a time, so browsers had to open several parallel connections just to load a normal page.

HTTP/2 (from 2015) fixed the biggest part of that. It lets the browser and server send many requests and responses over a single connection at the same time — a trick called multiplexing — and it compresses the repetitive header information that gets sent with every request. The result is a faster page load with less overhead.

HTTP/3 (from 2022) goes one step further. It keeps everything HTTP/2 does but changes the plumbing underneath. HTTP/2 rides on top of a transport called TCP, and TCP has a quirk: if a single packet of data gets lost, everything on that connection has to wait for it to be re-sent. HTTP/3 swaps TCP for a newer transport called QUIC, where a lost packet only holds up the one file’s stream instead of every stream on the connection — not every file becomes fully independent (they still share the same connection underneath), but a dropped packet no longer drags the whole page down with it. This helps most on shaky connections (think phone on a weak signal).

Do I need to do anything for SEO?

Short answer: not much, and definitely not for rankings.

• Neither is a direct ranking factor. Google has said plainly there’s no ranking boost from HTTP/2. HTTP/3 isn’t even part of how Google’s crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. works yet, so the question mostly doesn’t apply to it.
• The real benefit is speed, and speed helps indirectly. A faster site can improve your Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data., which are part of Google’s page experienceGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. signals. So the payoff is real, just one step removed.
• You probably already have HTTP/2. Most of the web is on it. If you use a CDNA CDN (content delivery network) is a geographically distributed network of edge servers that caches and serves your content from a location close to each visitor and crawler. It isn't a ranking factor itself, but it affects things Google and Bing do use — page speed and Core Web Vitals, crawl efficiency, uptime, and HTTPS delivery — and, if misconfigured, can block crawlers or muddle canonicalization. (like Cloudflare or Fastly), HTTP/2 — and often HTTP/3 — is usually just a toggle you turn on. Worth a quick check afterward, though: confirm the protocol actually negotiated (browser Network panel) rather than assuming the toggle worked for every visitor.

The one thing people get wrong

There’s an old feature called HTTP/2 Server Push that people still ask about. Don’t build for it — it’s dead in practice. Chrome disabled it by default starting with Chrome 106, hardly anyone used it, and it often made sites slower, not faster. If you want to hint the browser to grab a resource early, use modern replacements like 103 Early Hints or a <link rel=preload> tag instead.

Want the full picture — how QUIC actually works, exactly what GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. does today, real adoption numbers, and how to enable it? Switch to the Advanced tab.

TL;DR — HTTP/2 = multiplexing + HPACK header compressionCompression (HTTP content encoding) shrinks text-based responses — HTML, CSS, JS, JSON, SVG, XML sitemaps — before they're sent over the network, using an algorithm like Gzip, Brotli, or Zstd, so the browser or crawler downloads fewer bytes. It's not a ranking factor, but it speeds up page loads and helps pages stay under crawler fetch limits. + RFC 9218 priority hints over one TCP connection. HTTP/3 = the same semantics over QUIC/UDP instead of TCP, which stops a lost packet on one stream from stalling the other streams — streams still share the connection’s congestion control and QPACK state, so it’s a real fix, not full independence per file. Neither is a direct ranking factor: Google states there’s no ranking boost from crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor. over HTTP/2, and Google’s crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. documentation doesn’t list HTTP/3 as a supported protocol — GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. uses HTTP/1.1 by default and HTTP/2 when eligible (HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.' + h2 support), with a 421 status as the documented opt-out. The SEO payoff is indirect, via real-user speed feeding Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. — negotiating a newer protocol doesn’t guarantee better Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. or Search performance on its own. Most of the web is on HTTP/2; HTTP/3 is still a minority of actual requests, and even where a CDN “supports” it, discovery/fallback mean a given visit doesn’t always land on it. Two things to skip: chasing a ranking boost, and Server Push (disabled by default in Chrome/Chromium since v106 — use 103 Early Hints or rel=preload).

What each protocol actually changes

Keep the two upgrades straight and everything else follows.

HTTP/2 (2015, RFC 7540) kept HTTP’s semantics but overhauled how bytes move:

• Multiplexing. Many requests and responses are interleaved on a single connection, instead of HTTP/1.1’s one-at-a-time-per-connection model that forced browsers to open several parallel connections.
• HPACK header compressionCompression (HTTP content encoding) shrinks text-based responses — HTML, CSS, JS, JSON, SVG, XML sitemaps — before they're sent over the network, using an algorithm like Gzip, Brotli, or Zstd, so the browser or crawler downloads fewer bytes. It's not a ranking factor, but it speeds up page loads and helps pages stay under crawler fetch limits.. Repetitive headers sent with every request are compressed, cutting overhead.
• Stream prioritization — though not the original scheme. RFC 7540’s priority tree was deprecated by the HTTP/2 update, RFC 9113. The current signal is RFC 9218’s Extensible Priority Scheme — simple urgency/incremental hints (usable by both HTTP/2 and HTTP/3HTTP/2 and HTTP/3 are the modern versions of the HTTP protocol. HTTP/2 multiplexes many requests over one TCP connection; HTTP/3 swaps TCP for QUIC (over UDP) so a dropped packet only stalls the one stream it belongs to, not every stream (streams still share the connection's congestion control). Neither is a Google ranking factor — the SEO payoff is indirect, through faster real-user page speed.), and it’s advisory: a server can honor it, partially honor it, or ignore it.
• Originally, Server Push too — still technically defined in the HTTP/2 and HTTP/3 specs, but browsers dropped support in practice (more below).
• In practice it requires HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.' — no mainstream browser negotiates unencrypted HTTP/2.

HTTP/3 (2022, RFC 9114) keeps HTTP/2’s semantics but replaces the transport:

• It runs over QUIC, a transport built on UDP, rather than TCP.
• This narrows HTTP/2’s transport-level head-of-line blocking, but doesn’t erase every form of it. Under HTTP/2, all multiplexed streams ride one TCP connection, so a single lost packet stalls every stream until it’s re-sent. QUIC gives each HTTP request its own stream, and a lost packet on one stream no longer blocks the other streams — that’s the real fix. It doesn’t make every file fully independent, though: streams in the same QUIC connection still share congestion control and flow control (so a bad network path still slows everything, just without the cross-stream stall), bytes within one stream still arrive in order (a resource spanning several packets still waits on its own lost packet), and QPACK header decoding runs over a shared control stream other streams can depend on. Think “loss stops leaking across streams,” not “every file travels in total isolation.”
• QUIC folds in TLS 1.3 (encryption is mandatory) and supports faster connection setup through session resumption — including an optional 0-RTT mode for repeat visits. 0-RTT is conditional, not a universal fast lane: the “early data” it sends can be replayed by an attacker, so browsers and servers restrict which requests are safe to send that way and the server can reject it and fall back to a normal handshake (see 425 Too Early).
• QUIC also supports connection migration — a client can carry a connection across a network change (WiFi → cellular) by validating a new network path — but in QUIC v1 this is client-initiated only (a server can’t migrate the connection on its own), and path validation, address changes, and a reset congestion state mean continuity is conditional, not guaranteed.

The honest nuance: HTTP/3’s biggest wins land on slow or lossy connections. Users already on fast, stable networks see less of a difference — the slowest slice of your traffic gets most of the gain, a point Will Nye makes well in Search Engine Journal. Don’t oversell HTTP/3 to a site whose audience is all on fiber.

Does this affect rankings? (No — and here’s the exact wording)

This is the question every SEO actually lands here for, so lead with Google’s own crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. documentation. On the Google crawlers overview, Google states its crawlers support HTTP/1.1 and HTTP/2, choose whichever gives the best crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor. performance, and that:

“The default protocol version used by Google’s crawlers is HTTP/1.1; crawling over HTTP/2 may save computing resources (for example, CPU, RAM) for your site and GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer., but otherwise there’s no Google-product specific benefit to the site (for example, no ranking boost in Google Search).”

That’s about as unambiguous as Google gets. HTTP/2 is a transport-layer efficiency lever for both sides of the connection — it can save your server and Googlebot some work — but it is not a ranking signal.

The real SEO angle is indirect and worth stating clearly: faster real-user page loads feed Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data., which is part of Google’s page experience signals. So the value of HTTP/2 and HTTP/3 for SEO is a user-experience investment that shows up in the metrics Google actually measures — not a switch that lifts rankings on its own.

What Googlebot actually does today

This is the part most competing explainers skip, and it’s the most useful section on this page. Google’s own crawler docs are specific:

• Default is HTTP/1.1. Per the crawlers overview, HTTP/1.1 is the default protocol; Googlebot may switch to HTTP/2 between crawling sessions depending on past crawling statistics.

• HTTP/2 crawling is eligibility-based, not on-demand. Googlebot began crawling some sites over HTTP/2 in mid-November 2020 (announced in Google’s Googlebot will soon speak HTTP/2 post). A site becomes eligible by serving over HTTPS with HTTP/2 support and being crawled enough for the upgrade to pay off — you don’t force it on.

• You can opt out with a 421. Google documents the opt-out on the crawlers overview:

  “To opt out from crawling over HTTP/2, instruct the server that’s hosting your site to respond with a 421 HTTP status codeAn HTTP status code is the three-digit number a server returns with every response to tell a browser or crawler what happened to its request — success, redirect, client error, or server error. For SEO the code matters as much as the content: it tells Google and Bing whether to index a page, follow a redirect, retry later, or drop the URL from the index. when Google attempts to access your site over HTTP/2.”

• HTTP/3 isn’t in Google’s crawler documentation. As of this writing, the current crawler-overview doc lists HTTP/1.1 and HTTP/2 as the supported versions and says nothing about HTTP/3 — so it isn’t offered as a documented crawling protocol. That’s a statement about what Google has (and hasn’t) published, not a promise that no request anywhere ever touches HTTP/3. Barry Schwartz has reported the same absence at Search Engine Roundtable, and Will Nye’s SEJ guide notes Googlebot is not currently supporting HTTP/3.

There was roughly a five-year gap between HTTP/2’s publication (2015) and Googlebot supporting it (2020). HTTP/3 was finalized in 2022, so by that pattern, crawler support may still be a while off. My read: don’t hold your breath for HTTP/3 crawling, but don’t wait on it to improve your site either — the reason to adopt HTTP/3 is your users, not Googlebot.

Two things worth flagging before we move on. First, back around Google I/O in 2021, John Mueller said Google was already crawling more than half of all URLs over HTTP/2, and that multiplexing and header compression had brought the number of connections and the bandwidth down significantly — good for both Google’s crawling infrastructure and your serving infrastructure. Second, on the Bing side: I couldn’t find a comparable published HTTP/2 or HTTP/3 crawling policy statement from Microsoft. Bing has plenty of material on crawl efficiency generally (IndexNow, Crawl Control, sitemapA sitemap is a file that lists the pages, images, videos, and other files on your site so search engines can discover them. It helps discovery, but submitting a sitemap doesn't guarantee crawling or indexing. processing), but no explicit protocol-support declaration on par with Google’s — so I’m not going to infer one. If a Bing-specific answer matters to you, check the Bing Webmaster Blog directly.

What Chrome’s tools do (and don’t) show

Chrome’s LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. has a Modern HTTP insight that flags when a site is served over an older HTTP version — it essentially checks whether your files come over HTTP/2 or HTTP/3. Useful, but with one catch worth knowing: that insight shows up in Chrome DevTools performance traces, not in the standard public PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking. report most SEOs check. Lighthouse also used to have a dedicated uses-http2 audit, but it was disabled because reliably detecting h1 vs h2 vs h3 across every request proved difficult. So don’t go looking for a live “uses HTTP/2” pass/fail in your regular PSI report — it isn’t there reliably. To actually confirm your protocol, check the Protocol column in your browser’s Network panel, or use a tool like WebPageTest.

Real-world adoption in 2026

The best public dataset is the 2024 Web Almanac’s HTTP chapter (authored by Robin Marx of Akamai). The shape of the web:

• Home pages: HTTP/1.1 ~22% · HTTP/2 ~71% · HTTP/3 ~7% on desktop (mobile is similar: ~21% / ~70% / ~9%).
• All requests combined: roughly 85% are HTTP/2 or newer; only ~15% still on HTTP/1.1.
• More sites are ready for HTTP/3 than actually use it — around 26–28% of home pages announce HTTP/3 support via the alt-svc header, but far fewer requests are actually served over it.
• CDNs do the heavy lifting. In the Almanac’s data, about 96% of CDN-served requests use HTTP/2 or newer, versus roughly 29% of non-CDN requests still on HTTP/1.1. That gap is the whole “just use a CDN” argument in one statistic.

One caveat on stats you’ll see quoted elsewhere: an older figure that “25% of the top 10 million sites support HTTP/3” is measuring something different from the Almanac’s “7–9% of actual requests are served over HTTP/3.” Site-level support among big domains and share of real requests are two different things — both can be true at once, so don’t treat one as contradicting the other.

How to actually enable it

For the overwhelming majority of sites, this is not a server migration — but “toggle it on” isn’t the whole story either, because HTTP/3 has to be discovered and can fail back silently:

• Use a CDN. Turning on HTTP/2 and HTTP/3 at a CDNA CDN (content delivery network) is a geographically distributed network of edge servers that caches and serves your content from a location close to each visitor and crawler. It isn't a ranking factor itself, but it affects things Google and Bing do use — page speed and Core Web Vitals, crawl efficiency, uptime, and HTTPS delivery — and, if misconfigured, can block crawlers or muddle canonicalization. — Cloudflare, Fastly, Google Cloud CDN, and others — is usually a checkbox, and it’s the easiest path by far. Then verify: check the negotiated protocol in the browser’s Network panel or with curl --http3, rather than assuming the checkbox worked end to end. TLS/ALPN configuration, origin-to-edge support, and edge-to-client support all have to line up.
• Serve over HTTPS. It’s a practical prerequisite for both protocols; no major browser negotiates HTTP/2 or HTTP/3 unencrypted.
• Know how HTTP/3 gets discovered — and falls back. A browser’s first connection to your site typically still negotiates over TCP (HTTP/2 or HTTP/1.1); your server or CDN advertises HTTP/3 availability via the Alt-Svc header, or a DNS HTTPS/SVCB record, and the browser caches that and tries QUIC on a later connection. If a network blocks UDP, or the QUIC handshake fails, the browser falls back to HTTP/2 or HTTP/1.1 automatically. That’s the system working as designed, but it means “the origin supports HTTP/3” doesn’t guarantee every visit — especially a first visit — actually uses it. Measure the real split rather than assuming 100%.
• Mind server software support if you self-host. Web server support for HTTP/3 specifically has historically lagged (it moves fast, so verify your stack’s current status before assuming it’s supported). This is exactly why the CDN route is the pragmatic default.

What NOT to bother with: Server Push

If someone suggests implementing HTTP/2 Server Push, the answer is no — it’s dead in the browsers that matter, even though it’s still technically defined in both the HTTP/2 and HTTP/3 specs. Chrome’s own team documented the removal in Removing HTTP/2 Server Push (Barry Pollard). The key points:

“support of HTTP/2 Server Push will be disabled by default in Chrome 106 and other Chromium-based browsers.”

Adoption had already cratered — Pollard notes usage among HTTP/2 sites “dropped to 0.7%” — and, critically, the performance case never held up: the post describes push producing results “without a clear net performance gain and in many cases performance regressions.” That’s a Chrome/Chromium-documented removal specifically; other browser engines have moved the same direction in practice, but treat “Push is gone everywhere” as the practical reality to design around rather than a claim about every engine’s source code.

The documented replacements:

“103 Early Hints is a much less error-prone alternative with many of the same upsides as Push, and a lot less of the downsides”

plus a standard <link rel=preload> for resources you know you’ll need. Those are also covered under resource hintsResource hints are <link> elements (or equivalent HTTP Link headers) that tell the browser to do network work — DNS lookups, connection setup, or fetching a resource — earlier than it would discover the need on its own. The main ones are dns-prefetch, preconnect, preload, modulepreload, and prefetch.. Bottom line: don’t design around Server Push in 2026.

The security caveat (one honest paragraph)

HTTP/2’s great strength was also, briefly, a weakness. In 2023, the multiplexing that makes HTTP/2 fast became the mechanism behind a record-breaking DDoS technique, HTTP/2 Rapid Reset (CVE-2023-44487). As Cloudflare’s engineers explained, the ability to rapidly open and cancel large numbers of streams was “an obvious vector for denial-of-service,” and the major providers had to mitigate attacks in the hundreds of millions of requests per second. This isn’t a reason to avoid HTTP/2 — modern servers and CDNs are patched — but it’s worth one honest sentence so the protocol isn’t oversold as pure upside. If you self-host, keep your server software current.

Where this sits in web performance

HTTP/2 and HTTP/3 are a transport-layer lever, and they pull the same downstream metrics as the rest of the web performance cluster. Faster delivery improves TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good. and LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good., which is why the protocol story connects to Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data.; a CDNA CDN (content delivery network) is a geographically distributed network of edge servers that caches and serves your content from a location close to each visitor and crawler. It isn't a ranking factor itself, but it affects things Google and Bing do use — page speed and Core Web Vitals, crawl efficiency, uptime, and HTTPS delivery — and, if misconfigured, can block crawlers or muddle canonicalization. is the usual way you turn these protocols on and the biggest single driver of adoption in the wild; cachingCaching stores a copy of a page or resource — in a browser, a CDN edge node, or a search crawler's own cache — so it can be served again without regenerating or re-downloading it. It isn't a direct ranking factor, but it feeds page speed and crawl efficiency. and resource hintsResource hints are <link> elements (or equivalent HTTP Link headers) that tell the browser to do network work — DNS lookups, connection setup, or fetching a resource — earlier than it would discover the need on its own. The main ones are dns-prefetch, preconnect, preload, modulepreload, and prefetch. (including the Early Hints and preload that replaced Server Push) round out how quickly resources reach the browser. Treat HTTP/2/HTTP/3 as one part of that delivery layer — worth getting right for users, but not a ranking button.

AI summary

A condensed take on the Advanced version:

• HTTP/2 (2015) = multiplexing + HPACK header compressionCompression (HTTP content encoding) shrinks text-based responses — HTML, CSS, JS, JSON, SVG, XML sitemaps — before they're sent over the network, using an algorithm like Gzip, Brotli, or Zstd, so the browser or crawler downloads fewer bytes. It's not a ranking factor, but it speeds up page loads and helps pages stay under crawler fetch limits. + RFC 9218 priority hints (the old RFC 7540 priority tree was deprecated) over a single TCP connection. HTTP/3 (2022) = the same semantics over QUIC/UDP instead of TCP, which stops a lost packet on one stream from stalling the other streams — streams still share the connection’s congestion control and QPACK header state, so it’s a real fix for cross-stream head-of-line blocking, not full per-file independence.
• Not a direct ranking factor. Google states explicitly there’s no ranking boost from crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor. over HTTP/2 — it’s a transport-layer efficiency lever, not a signal. Negotiating a newer protocol doesn’t guarantee better Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. or Search performance on its own, either.
• GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer.’s actual policy: HTTP/1.1 by default, HTTP/2 when eligible (HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.' + h2 support + enough crawl volume), opt out with a 421. Google’s crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. documentation doesn’t list HTTP/3 as a supported protocol as of this writing — that’s a statement about what’s documented, not proof no request anywhere ever touches it.
• The SEO payoff is indirect: faster real-user loads → Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. → page experience. HTTP/3 helps slow/lossy connections most.
• QUIC’s other wins are conditional, not automatic: 0-RTT resumption sends replay-sensitive “early data” that can be rejected (425 Too Early), and connection migration (surviving WiFi → cellular) is client-initiated and path-validated in QUIC v1, not guaranteed continuity.
• Adoption (2024 Web Almanac): ~85% of all requests are HTTP/2+; HTTP/3 is still a minority (~7–9% of requests) though more sites announce support (~26–28%). CDN requests are ~96% HTTP/2+.
• Enable it via a CDN toggle (Cloudflare, Fastly, Google Cloud CDN), then verify the negotiated protocol — HTTP/3 is discovered via Alt-Svc/DNS records and falls back to HTTP/2 or HTTP/1.1 if UDP is blocked, so “supported” isn’t the same as “used on every visit.” HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.' is a prerequisite for both protocols.
• Server Push is dead in practice — Chrome disabled it by default from v106 on (still defined in the specs, just not implemented by default), adoption fell to ~0.7% of HTTP/2 sites, and it often caused performance regressions. Use 103 Early Hints or <link rel=preload> instead.
• Security caveat: HTTP/2 multiplexing was the mechanism behind 2023’s Rapid Reset DDoS (CVE-2023-44487) — patched, but keep server software current.
• No Bing-specific HTTP/2/HTTP/3 crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor. policy was foundA 302 (\"Found\") is a temporary redirect: it forwards users to a new URL while telling search engines the original URL should stay in the index. It's a weak canonicalization signal, not the zero-equity dead end of SEO folklore. — don’t infer one.

Official documentation

Primary-source documentation from the search engines and browser vendors.

Google

• Overview of Google crawlers and fetchers — the current, authoritative statement that GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. supports HTTP/1.1 and HTTP/2 (default HTTP/1.1, no ranking boost from HTTP/2), and the 421 opt-out. No mention of HTTP/3.
• Googlebot will soon speak HTTP/2 (Sept 2020) — the announcement that HTTP/2 crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor. would begin in mid-November 2020, eligibility, and the opt-out.

Chrome / web.dev

• Removing HTTP/2 Server Push from Chrome (Barry Pollard) — the removal timeline (Chrome 106+), the adoption/performance rationale, and the recommended replacements (103 Early Hints, rel=preload).

Bing / Microsoft

• No comparable HTTP/2 or HTTP/3 crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor. policy statement was located in this research. For general Bing crawl-efficiency guidance, see the Bing Webmaster Blog and IndexNow.

Standards & data

• RFC 9114 — HTTP/3 and RFC 9113 — HTTP/2 — the current protocol specifications (RFC 9113 obsoletes the original RFC 7540 and deprecates its priority scheme).
• RFC 9000 — QUIC and RFC 9001 — Using TLS to Secure QUIC — QUIC’s transport and TLS 1.3 integration, including stream flow control and connection migration.
• RFC 9218 — Extensible Prioritization Scheme for HTTP — the current, advisory urgency/incremental priority signal for HTTP/2 and HTTP/3HTTP/2 and HTTP/3 are the modern versions of the HTTP protocol. HTTP/2 multiplexes many requests over one TCP connection; HTTP/3 swaps TCP for QUIC (over UDP) so a dropped packet only stalls the one stream it belongs to, not every stream (streams still share the connection's congestion control). Neither is a Google ranking factor — the SEO payoff is indirect, through faster real-user page speed..
• RFC 8470 — Using Early Data in HTTP — 0-RTT’s replay risk and the 425 Too Early response.
• RFC 7838 — HTTP Alternative Services and RFC 9460 — Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Records) — how a client discovers HTTP/3 availability (Alt-Svc, DNS records).
• Web Almanac 2024 — HTTP chapter (Robin Marx, Akamai) — the best public real-world adoption dataset.

Quotes from the source

On-the-record statements from Google and the Chrome team. Each link is a deep link that jumps to the quoted passage on the source page.

Google — no ranking boost, and the crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor. policy

• “The default protocol version used by Google’s crawlersA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. is HTTP/1.1; crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor. over HTTP/2 may save computing resources (for example, CPU, RAM) for your site and GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer., but otherwise there’s no Google-product specific benefit to the site (for example, no ranking boost in Google Search).” — Google Crawling Infrastructure docs. Jump to quote
• “To opt out from crawling over HTTP/2, instruct the server that’s hosting your site to respond with a 421 HTTP status codeAn HTTP status code is the three-digit number a server returns with every response to tell a browser or crawler what happened to its request — success, redirect, client error, or server error. For SEO the code matters as much as the content: it tells Google and Bing whether to index a page, follow a redirect, retry later, or drop the URL from the index. when Google attempts to access your site over HTTP/2.” Jump to quote

Chrome team (Barry Pollard) — Server Push is gone

• “support of HTTP/2 Server Push will be disabled by default in Chrome 106 and other Chromium-based browsers.” — Chrome for Developers blog. Jump to quote
• On adoption, usage among HTTP/2 sites “dropped to 0.7%”, and analysis showed push producing results “without a clear net performance gain and in many cases performance regressions.” Jump to quote
• The recommended replacement: “103 Early Hints is a much less error-prone alternative with many of the same upsides as Push, and a lot less of the downsides.” Jump to quote

Cloudflare (Lucas Pardue & Julien Desgats) — the security caveat

• HTTP/2’s ability to launch large amounts of parallel work made rapid stream cancellation “an obvious vector for denial-of-service” — the basis of the 2023 Rapid Reset attack (CVE-2023-44487). Read the technical breakdown

Should I do anything about HTTP/2 or HTTP/3?

A quick walk-through for the “do I need to act on this” question.

Start: Are you already on a CDN?

• Yes → You almost certainly already have HTTP/2, and likely HTTP/3 as a toggle. Confirm HTTP/2 is on; enable HTTP/3 if your CDN offers it. Done — this is a UX/Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. win, not a ranking lever. Move on.
• No → Continue.

Are you self-hosting and serving over HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.'?

• Not on HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.' → Fix that first. HTTPS is a practical prerequisite for both protocols (and matters for other reasons). Then re-evaluate.
• On HTTPS, self-hosted → The easiest upgrade path is still to put a CDN in front rather than reconfigure your web server. If you’d rather configure the server directly, verify your server software’s current HTTP/2 (and, separately, HTTP/3) support before assuming it’s available.

Is your goal a ranking boost?

• Yes → Reset expectations. Google says there’s no ranking boost from HTTP/2, and Google’s crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. documentation doesn’t list HTTP/3 at all. The benefit is indirect speed → Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data., and even that isn’t guaranteed just from switching protocols. Adopt it for users and page experience, not for a direct signal.

Is your audience mostly on slow or unstable connections (mobile-heavy, emerging markets)?

• Yes → HTTP/3 is worth prioritizing — QUIC’s per-stream loss isolation and (client-initiated, conditional) connection migration help most exactly here.
• No, mostly fast/stable → HTTP/2 captures most of the win; HTTP/3 is a smaller incremental gain. Still fine to enable via CDN, just don’t over-invest.

Thinking about HTTP/2 Server Push?

• Stop. Chrome disabled it by default from v106 on, and other engines have followed in practice. Use 103 Early Hints or <link rel=preload> instead.

HTTP/2 & HTTP/3 cheat sheet

HTTP/1.1 vs HTTP/2 vs HTTP/3 at a glance

What GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. does

Fast facts

• No ranking boost from HTTP/2 — Google states this explicitly. Negotiating a newer protocol doesn’t guarantee better Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. or Search performance on its own, either.
• The SEO benefit is indirect: speed → Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. → page experience.
• Adoption (2024 Web Almanac): ~85% of requests HTTP/2+; HTTP/3 ~7–9% of requests; ~96% of CDN-served requests are HTTP/2+.
• Easiest way to enable: a CDN toggle — then verify the negotiated protocol; HTTP/3 discovery (Alt-Svc/DNS) and UDP fallback mean “supported” isn’t the same as “used every visit.”
• Server Push: dead in practice (Chrome 106+ disabled it by default, other engines followed suit) though still defined in the specs. Use 103 Early Hints or <link rel=preload>.
• Security: HTTP/2 multiplexing enabled the 2023 Rapid Reset DDoS (CVE-2023-44487) — patched; keep servers current.

Mistakes and myths to avoid

Myth: “Switching to HTTP/2 or HTTP/3 will boost my rankings.” It won’t, directly. Google states there’s no ranking boost from crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor. over HTTP/2, and Google’s crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. documentation doesn’t list HTTP/3. Any SEO value is indirect — faster real-user loads feeding Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. — and even that isn’t guaranteed just from negotiating a newer protocol. Adopt it for users, not for a signal.

Myth: “GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. crawls my site over whatever protocol my server/CDN supports, including HTTP/3.” Not according to Google’s published documentation. GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. crawls HTTP/1.1 by default and HTTP/2 when eligible; its current crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. docs don’t list HTTP/3 as a supported protocol at all. Your CDN can serve human visitors over HTTP/3 while Googlebot still fetches over HTTP/1.1 or HTTP/2 — both facts are true at once.

Myth: “I should implement HTTP/2 Server Push for better performance.” It’s dead in practice — Chrome disabled it by default from v106 on, adoption fell to ~0.7% of HTTP/2 sites, and its own creators’ data showed frequent performance regressions. Use 103 Early Hints or <link rel=preload> instead.

Anti-pattern: Treating “one dropped packet only stalls one file” as absolute. QUIC isolates loss between HTTP/3 streams — a lost packet on one stream no longer stalls unrelated streams the way it does on HTTP/2’s shared TCP connection. But streams in the same QUIC connection still share congestion control and flow control, and QPACK header decoding runs over a shared control stream. A bad network path still slows the whole page; QUIC just stops one lost packet from cascading across every other stream.

Anti-pattern: Assuming 0-RTT and connection migration always work. 0-RTT sends replay-sensitive “early data” that a server can reject and fall back from (425 Too Early); it’s not a guaranteed zero-round-trip start on every visit. QUIC v1 connection migration is client-initiated and requires path validation — a server can’t migrate the connection on its own, and continuity across a network change is conditional, not automatic.

Anti-pattern: Trying to force Googlebot onto HTTP/2 on demand. You can’t. Eligibility is Google’s call based on its own crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor. heuristics. You make yourself eligible (HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.' + HTTP/2 support); opting out via 421 is documented, opting in on demand is not.

Anti-pattern: Conflating “25% of top sites support HTTP/3” with “7–9% of requests use HTTP/3.” These measure different things — site-level support among big domains vs. share of actual requests served. Both can be true; don’t present one as if it refutes the other.

Anti-pattern: Over-investing in HTTP/3 for a fast-connection audience. HTTP/3’s gains concentrate on slow/lossy connections. If your users are mostly on fast, stable networks, HTTP/2 already captures most of the benefit — enable HTTP/3 via CDN, but don’t treat it as a major project.

Anti-pattern: Looking for a “uses HTTP/2” pass in standard PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking.. That old Lighthouse auditLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. was disabled, and the current “Modern HTTP” insight lives in Chrome DevTools traces, not the public PSI report. Confirm your protocol in the browser Network panel or a tool like WebPageTestWebPageTest is a free, open-source, lab-based website performance testing tool — created by Patrick Meenan in 2008 and acquired by Catchpoint in 2020 — that runs pages on real browsers from distributed locations and produces deep diagnostics (waterfalls, filmstrips, connection views, Core Web Vitals). It's a diagnostic tool, not a Google ranking input. instead.

HTTP/2 & HTTP/3 checklist

A quick pass to confirm you’re getting the delivery benefits without chasing myths:

• Site is served over HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.' (prerequisite for both protocols).
• HTTP/2 confirmed on — check the Protocol column in your browser’s Network panel, or a tool like WebPageTestWebPageTest is a free, open-source, lab-based website performance testing tool — created by Patrick Meenan in 2008 and acquired by Catchpoint in 2020 — that runs pages on real browsers from distributed locations and produces deep diagnostics (waterfalls, filmstrips, connection views, Core Web Vitals). It's a diagnostic tool, not a Google ranking input. (not the standard PSIPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking. report).
• HTTP/3 enabled where your CDN supports it (bigger win for slow/mobile audiences) — and verified as actually negotiating, not just toggled on (check curl --http3 or the Network panel; UDP-blocking networks fall back automatically).
• You’re relying on a CDN toggle, not a from-scratch server migration, unless you have a specific reason to self-configure.
• If self-hosting, server software’s HTTP/2 / HTTP/3 support verified as current.
• No HTTP/2 Server Push implementation — replaced with 103 Early Hints or <link rel=preload> where useful.
• Expectations set internally: this is a UX / Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. improvement, not a direct ranking lever.
• If you ever need GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. off HTTP/2, you know the mechanism (421 status code) — most sites never need this.
• Server/CDN patched against HTTP/2 Rapid Reset (CVE-2023-44487).

Resources worth your time

My related writing

• The Beginner’s Guide to Technical SEO — where site speed and delivery fit in the bigger technical-SEO picture.
• Core Web Vitals: A Complete Guide — the metrics that actually turn faster delivery into a ranking-adjacent signal (the indirect payoff of HTTP/2 and HTTP/3HTTP/2 and HTTP/3 are the modern versions of the HTTP protocol. HTTP/2 multiplexes many requests over one TCP connection; HTTP/3 swaps TCP for QUIC (over UDP) so a dropped packet only stalls the one stream it belongs to, not every stream (streams still share the connection's congestion control). Neither is a Google ranking factor — the SEO payoff is indirect, through faster real-user page speed.).

My speaking

• How Search Works (SlideShare) — my walkthrough of crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor., renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM., indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed., and ranking, including how GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. fetches pages. (My standing disclaimer applies: “This is my understanding of systems… not going to be 100% complete or accurate.”)

Official

• Google — Overview of Google crawlers and fetchers — the “no ranking boost” statement, HTTP/1.1 default, and the 421 opt-out.
• Google — Googlebot will soon speak HTTP/2 (Sept 2020).
• Chrome — Removing HTTP/2 Server Push (Barry Pollard).

From around the industry

• Web Almanac 2024 — HTTP chapter (Robin Marx, Akamai; reviewed by Barry Pollard & Chris Böttger) — the real-world adoption dataset: HTTP/2 dominant, HTTP/3 still a minority, and the stark CDN effect.
• How HTTP/3 Helps Feed SEO’s Need For Speed (Search Engine Journal, Will Nye, Builtvisible) — good practical framing on the indirect Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. benefit and why HTTP/3’s gains concentrate on slow connections.
• Google: Googlebot Not Crawling Over HTTP/3 Yet (Search Engine Roundtable, Barry Schwartz) — corroborates that GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. doesn’t crawl HTTP/3.
• Google: We’re Crawling Half Of The URLs Over HTTP/2 (Search Engine Roundtable, Barry Schwartz) — John Mueller’s HTTP/2 crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor. stat from Google I/O.
• HTTP/2 Rapid Reset: deconstructing the record-breaking attack (Cloudflare, Lucas Pardue & Julien Desgats) — the security caveat, technical breakdown of CVE-2023-44487.
• High Performance Browser Networking (Ilya Grigorik, O’Reilly) — the free, in-depth reference on HTTP/2, QUIC, and the underlying networking.

Check the negotiated HTTP version

Use curl’s version-specific flags to test whether the endpoint can negotiate each protocol. Protocol support in your local curl build may vary.

curl -sS -o /dev/null -w 'HTTP/%{http_version}\n' --http2 https://example.com/
curl -sS -o /dev/null -w 'HTTP/%{http_version}\n' --http3 https://example.com/

Inspect the browser’s resource protocols

Paste this into the DevTools Console after a page load to see the protocol recorded for each request.

console.table(
  performance.getEntriesByType('resource').map((entry) => ({
    resource: entry.name,
    protocol: entry.nextHopProtocol,
    duration: Math.round(entry.duration),
  }))
);

An HTTP/3 result proves browser delivery, not GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor.. The article’s GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. guidance remains separate.

Test yourself: HTTP/2 and HTTP/3

Five quick questions on the protocols and what they mean for SEO. Pick an answer for each, then check.

HTTP/2 and HTTP/3

HTTP/2 and HTTP/3 are the modern versions of the HTTP protocol. HTTP/2 multiplexes many requests over one TCP connection; HTTP/3 swaps TCP for QUIC (over UDP) so a dropped packet only stalls the one stream it belongs to, not every stream (streams still share the connection's congestion control). Neither is a Google ranking factor — the SEO payoff is indirect, through faster real-user page speed.

Related: Caching for SEO, CDN and SEO, Core Web Vitals

HTTP/2 and HTTP/3

HTTP/2 (2015) and HTTP/3 (2022) are the two modern upgrades to HTTP, the protocol a browser and a server use to move web pages. Both make pages load faster than HTTP/1.1 by letting a browser fetch many resources over a single connection instead of opening lots of them or fetching one at a time.

HTTP/2 introduced multiplexing (many requests and responses interleaved on one TCP connection), header compressionCompression (HTTP content encoding) shrinks text-based responses — HTML, CSS, JS, JSON, SVG, XML sitemaps — before they're sent over the network, using an algorithm like Gzip, Brotli, or Zstd, so the browser or crawler downloads fewer bytes. It's not a ranking factor, but it speeds up page loads and helps pages stay under crawler fetch limits. (HPACK), and stream prioritization — though the original RFC 7540 priority tree was later deprecated; the current advisory signal is RFC 9218’s urgency/incremental scheme, usable by both HTTP/2 and HTTP/3. HTTP/2’s original “server push” feature is still technically defined in the spec, but Chrome disabled it by default from Chrome 106 on and other browsers have followed suit in practice.

HTTP/3 keeps HTTP/2’s behavior but replaces the transport underneath: instead of TCP, it runs over QUIC, a protocol built on UDP. That narrows HTTP/2’s transport-level head-of-line blocking — under HTTP/2, one lost TCP packet stalls every stream on the connection; QUIC gives each request its own stream, so a lost packet only delays the stream it belongs to. It isn’t full per-file independence, though: streams in the same QUIC connection still share congestion control and flow control, and QPACK header decoding runs over a shared control stream. QUIC also folds in TLS 1.3 (mandatory encryption) and supports faster connection setup via session resumption — including a conditional, replay-sensitive 0-RTT mode — plus client-initiated, path-validated “connection migration” (surviving a switch from WiFi to cellular, though not guaranteed in every case).

For SEO, the key fact is that neither is a direct Google ranking factor. Google states there’s no ranking boost from crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor. over HTTP/2, and Google’s current crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. documentation doesn’t list HTTP/3 as a supported protocol. GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. crawls over HTTP/1.1 by default and HTTP/2 when a site is eligible (HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.' plus HTTP/2 support), with a 421 status code as the documented opt-out. The realistic SEO benefit is indirect: faster real-user page loads can improve Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data., which does feed page experience — though negotiating a newer protocol doesn’t guarantee that improvement on its own. For most sites, turning either protocol on is a CDN configuration toggle rather than a server migration, but it’s worth verifying the negotiated protocol afterward since HTTP/3 discovery and UDP fallback mean support doesn’t equal use on every visit.

Related: Caching for SEO, CDN and SEO, Core Web Vitals

Changelog