Fix Legacy HTTP/1.1: Enable HTTP/2 and HTTP/3
Your site is being served over HTTP/1.1, an older protocol that handles one request per connection and can't download resources in parallel over a single link. Upgrading to HTTP/2 (many requests multiplexed over one connection) and HTTP/3 (QUIC over UDP, faster on lossy networks) cuts round-trips and speeds up delivery. On most modern hosts and CDNs this is already the default or a single toggle.
What this means
This notice means the audit connected to your site and the server negotiated HTTP/1.1 instead of a newer protocol. The version is chosen during the TLS handshake through ALPN, so whatever your origin or CDN advertises is what browsers receive.
HTTP/1.1 was standardized in the late 1990s. Its core limit is that each TCP connection handles one request at a time. Browsers work around this by opening up to six connections per host, but each connection adds handshake overhead, and requests still queue behind slow ones (head-of-line blocking).
HTTP/2 (RFC 7540, 2015) fixes this by multiplexing many requests and responses over a single connection, compressing headers with HPACK, and letting the server prioritize resources. HTTP/3 (RFC 9114, 2022) goes further: it runs over QUIC on UDP instead of TCP, which removes transport-level head-of-line blocking and cuts connection setup to as little as zero round-trips on repeat visits. Every mainstream browser only negotiates HTTP/2 and HTTP/3 over TLS, so a valid HTTPS certificate is a prerequisite.
This is a notice rather than an error because HTTP/1.1 still works. It's performance headroom, not a broken page.
Why it matters
Protocol version isn't a direct Google ranking factor, but it feeds the things that are. Fewer round-trips and multiplexed downloads improve Largest Contentful Paint and overall load time, and Core Web Vitals are a confirmed ranking signal. The gain is largest on pages with many small assets (CSS, JS, images, fonts) and for users on higher-latency mobile or international connections, where HTTP/1.1's per-connection overhead hurts most.
HTTP/3's QUIC transport helps specifically on lossy or congested networks: because packet loss on one stream doesn't stall the others, real-world mobile performance can improve even when a lab number looks similar.
For AI answer engines, the angle is crawl efficiency and reliability. Crawlers behind ChatGPT, Perplexity, and Google's AI systems fetch many URLs, and a server that delivers assets over a single multiplexed connection responds faster and more consistently under load. That reduces timeouts and partial fetches, so your content is more likely to be retrieved in full and considered. There's no penalty for HTTP/1.1, but modern protocols remove a class of slow-fetch and connection-limit problems that can make crawlers give up.
Bottom line: upgrading is low-risk, usually free, and removes a transport bottleneck that quietly caps every other speed optimization you make.
How to fix it
- 1
Confirm which protocol your site actually serves
Before changing anything, verify the current version. In Chrome DevTools, open the Network tab, right-click the column header, enable the Protocol column, and reload; each request shows h2 (HTTP/2), h3 (HTTP/3), or http/1.1. From a terminal, run curl -I --http2 https://yourdomain.com and curl -I --http3 https://yourdomain.com (curl 7.66+ with HTTP/3 support), or use an online HTTP/2 and HTTP/3 checker. Different assets can come from different origins, so check your main domain and your asset or CDN host separately.
- 2
Enable it at the CDN or edge (easiest path)
On Cloudflare, HTTP/2 is on by default and HTTP/3 is a single toggle under Speed → Optimization → Protocol Optimization → HTTP/3 (with QUIC). Fastly, Akamai, AWS CloudFront, Bunny, and Google Cloud CDN all support HTTP/2 out of the box and HTTP/3 via a setting. Putting a CDN in front is often the fastest fix because it upgrades the browser-facing connection regardless of what your origin speaks, and it handles TLS and ALPN negotiation for you. This is also the only practical way to serve HTTP/3 in front of Apache.
- 3
Turn it on at the origin web server
On Nginx 1.25.1+, use listen 443 ssl; with http2 on; for HTTP/2, then add listen 443 quic reuseport; and http3 on; plus an Alt-Svc header advertising h3 for HTTP/3. On Apache 2.4.17+, load mod_http2 and set Protocols h2 h2c http/1.1 in your HTTPS vhost; note that Apache has no production HTTP/3 module, so serve HTTP/3 through a CDN or an Nginx/LiteSpeed front proxy. HTTP/2 and HTTP/3 both require a valid HTTPS certificate, so configure TLS first, then restart and re-check the Protocol column.
- 4
Advertise HTTP/3 with the Alt-Svc header
Browsers don't try HTTP/3 on the first visit; they connect over HTTP/2 (or HTTP/1.1), then upgrade after seeing an Alt-Svc response header that points at the QUIC endpoint, for example Alt-Svc: h3=":443"; ma=86400. Most CDNs add this automatically. If you self-host and HTTP/3 isn't picked up despite being enabled, a missing or incorrect Alt-Svc header is the usual cause. Also confirm UDP port 443 is open in your firewall, since QUIC runs over UDP, not TCP.
- 5
Managed platforms: verify, don't configure
On Shopify, Wix, Squarespace, Webflow, Vercel, Netlify, and Cloudflare Pages, HTTP/2 is already served and HTTP/3 is typically enabled at their edge; you can't and don't need to change it. If an audit still reports HTTP/1.1 on one of these, the likely cause is a custom domain not fully routed through their CDN, a proxy sitting in front of the platform, or checking a subdomain that bypasses the edge. Confirm your DNS points at the platform's recommended target and that no legacy reverse proxy sits in between.
- 6
Re-test and check your asset hosts
After enabling, hard-reload with DevTools open and confirm requests show h2 or h3. Test both a fresh visit and a repeat visit, because HTTP/3 only kicks in after the Alt-Svc upgrade. Don't overlook third-party asset domains: if your images or scripts load from a subdomain or storage bucket still on HTTP/1.1, those requests keep the old overhead. Re-run the audit to clear the notice.
Example
server {
# HTTP/2 over TLS
listen 443 ssl;
http2 on;
# HTTP/3 over QUIC (UDP). Only one server block should use reuseport.
listen 443 quic reuseport;
http3 on;
server_name example.com;
ssl_certificate /etc/ssl/example.com.crt;
ssl_certificate_key /etc/ssl/example.com.key;
# Tell browsers HTTP/3 is available so they upgrade on the next request
add_header Alt-Svc 'h3=":443"; ma=86400' always;
# ... your location blocks ...
}Nginx 1.25.1+ vhost enabling HTTP/2 and HTTP/3 (QUIC) with Alt-Svc advertisement.
Platform-specific steps
HTTP/2 is on by default. For HTTP/3, go to Speed → Optimization → Protocol Optimization and enable HTTP/3 (with QUIC). Cloudflare adds the Alt-Svc header automatically. Make sure your DNS records are proxied (orange cloud) so traffic actually flows through the edge.
Requires Nginx 1.9.5+ for HTTP/2 and 1.25.1+ for HTTP/3. Add http2 on; and a listen 443 quic reuseport; / http3 on; block inside your TLS server{}, plus an Alt-Svc header. Open UDP 443 in your firewall for QUIC, then reload nginx.
Requires Apache 2.4.17+. Enable mod_http2 (a2enmod http2) and add Protocols h2 h2c http/1.1 in the HTTPS vhost, then restart and confirm with curl -I --http2. Apache has no production HTTP/3 module, so put a CDN or an Nginx/LiteSpeed proxy in front to serve HTTP/3.
HTTP/2 and HTTP/3 are handled by the platform's CDN and enabled by default. There's no setting to change. If an audit shows HTTP/1.1, verify your custom domain points at the platform's recommended DNS target with no third-party proxy in between.
Both serve HTTP/2 by default and HTTP/3 through their edge network with no configuration. If you see HTTP/1.1, check that the custom domain is verified and routed through their infrastructure rather than an external proxy or misconfigured CNAME.
WordPress doesn't control the protocol; your host or CDN does. On managed hosts (Kinsta, WP Engine, SiteGround) HTTP/2 is standard and HTTP/3 is often available in the host dashboard or via Cloudflare. There's no core setting or plugin that enables HTTP/2 at the application level.
Frequently asked
HTTP/1.1 is not a penalty and won't get you demoted. It's slower than HTTP/2 and HTTP/3, and speed (through Core Web Vitals) is a ranking signal, so the connection is indirect. On sites with many assets or high-latency visitors, the load-time improvement from upgrading can measurably help the metrics Google actually ranks on.
HTTP/2 gives you most of the benefit: multiplexing, header compression, and no per-connection queueing. HTTP/3 adds gains mainly on lossy or high-latency networks by removing transport-level head-of-line blocking. Enable HTTP/2 as the baseline, and turn on HTTP/3 too if your host offers it, since browsers automatically fall back to HTTP/2 where HTTP/3 isn't available.
In practice, yes. The spec technically allows unencrypted HTTP/2, but every major browser only negotiates HTTP/2 and HTTP/3 over TLS. So you need a valid SSL certificate first. If your site isn't on HTTPS yet, fix that before worrying about the protocol version.
Common causes: a reverse proxy or load balancer in front of your server still speaks HTTP/1.1 to clients, the change wasn't applied to the specific vhost being tested, or your server version predates HTTP/2 support (Nginx 1.9.5+ / Apache 2.4.17+). For HTTP/3 specifically, check that the Alt-Svc header is present and UDP port 443 is open. Test at the exact hostname the audit used.
It's very low risk. The protocols are backward-compatible: any client that can't do HTTP/2 or HTTP/3 falls back to HTTP/1.1 automatically. One legacy trick to retire is domain sharding (splitting assets across many subdomains to beat HTTP/1.1's connection limit), which is counterproductive under HTTP/2 because a single connection is more efficient. Otherwise, no page changes are needed.
Does your site have this issue?
Run a free, AI-powered audit and we’ll flag this and 150+ other checks in about a minute. No signup.