You ran the audit, and one or more of the modern protocols came back missing. The good news is that fixing them is almost never a rebuild — most are a single toggle in your host or CDN, or one response header. Here’s how to fix each gap, in the order that actually matters, without breaking anything.
This is the companion to checking your site’s protocol support: that article shows you how to confirm what you serve, and this one shows you how to fix whatever came back missing. If you haven’t run the checks yet, start there — you can’t fix a gap you haven’t measured.
Record what you serve now. Without it you cannot prove a gain or revert cleanly.
Host, origin server or CDN owns the setting — rarely WordPress. Fix it where it lives.
Change exactly one protocol. Never batch changes you cannot untangle later.
Re-run the same tester. Confirm the change took and nothing else moved with it.
Keep the win. If something broke, roll back the single change — you know exactly which.
The expensive failure is the batch change: flip five switches, something breaks, and now you cannot tell which one did it.
Table of Contents
Before you change anything
Two habits make the difference between a clean fix and a confusing afternoon.
Re-baseline first. Run a page-speed report and save the scores before you change a setting. A protocol change that “feels faster” is worth nothing you can point to; a change that moves the score from X to Y is a result. It also gives you a known-good state to compare against if something regresses.
Know which layer owns the setting. This is the part most owners get stuck on, so it’s worth saying plainly: HTTP/2, HTTP/3, Brotli, IPv6, TLS and HSTS almost never live in WordPress. They live in the origin server (Nginx, Apache or LiteSpeed), your host’s control panel, or the CDN/edge in front of the site. Where you make each change depends on your stack, and on managed hosting it’s often a dashboard toggle or a one-line support request rather than anything you edit yourself.
Almost every one of these fixes is a host or CDN setting, not a WordPress one — configuration, not code.
Then the rule that keeps you sane: change one thing at a time and re-test before the next. Flip five switches at once, watch something break, and you’ve no idea which switch did it.
HTTP/2 isn’t being served
What the failed check looked like: the Network-tab Protocol column reads http/1.1, or an online tester reports no HTTP/2.
How to fix it: HTTP/2 is enabled at the server or host, and it requires HTTPS, so make sure your certificate is in place first (see the TLS section below). On managed hosting it’s usually a toggle in the panel, or a quick support request if it isn’t already on. On a server you manage yourself it’s an Nginx/Apache/LiteSpeed module and a directive on the HTTPS listener. If a CDN sits in front of your site, it almost certainly serves HTTP/2 to visitors from its edge already — so check where the test is actually hitting before assuming the origin is the problem.
Then re-test: reload with the Protocol column showing, or re-run the tester — it should read h2.
HTTP/3 (over QUIC) isn’t available
What the failed check looked like: the tester finds no HTTP/3, and the Protocol column never shows h3 even after a couple of reloads.
How to fix it: HTTP/3 is a CDN or edge feature — it needs QUIC (UDP on 443) and an Alt-Svc advertisement so browsers know to upgrade. Providers with a modern edge offer it as a single toggle; older origin stacks often can’t speak it directly, in which case fronting the site with a CDN that does is the practical route. It’s the lowest priority on this list: a genuine gain for visitors on mobile or lossy networks, but an upgrade on top of HTTP/2, never a substitute for it. If you want the background on why QUIC helps, Cloudflare’s what is HTTP/3 explainer is a good, vendor-neutral primer.
No IPv6 (missing AAAA record, or nothing listening)
What the failed check looked like: an IPv6 test reports no AAAA record for your domain, or an AAAA exists but the server never answers over it.
How to fix it: add the AAAA record your host or CDN provides to your DNS. Many hosts and CDNs handle this for you once IPv6 is enabled; some leave you to add the record. If you’re behind a CDN, turning on IPv6 at the edge is often one toggle, and the edge will answer visitors over IPv6 even when your origin is still IPv4-only. The one thing to verify: that something actually answers over IPv6, not just that the record resolves — an AAAA record pointing at a server that doesn’t listen is worse than no record at all.
An AAAA record with nothing listening behind it is worse than none — it sends IPv6 visitors down a dead end.
Only gzip, or no compression at all (Brotli off)
What the failed check looked like: a text asset’s content-encoding header says gzip, or the header is absent entirely.
How to fix it: enable Brotli at the server or CDN. It’s a module on Nginx/Apache/LiteSpeed and a toggle on most modern CDNs and caching layers — one of the cheapest transfer-size wins available. Make sure it’s applied to the text types that benefit (HTML, CSS, JavaScript, SVG, JSON), not just the document. One gotcha: if a CDN or page cache already stored an uncompressed copy, purge it so the next request re-fetches a compressed one.
A newer method, Zstandard (content-encoding: zstd), is starting to appear and compresses comparably; enable it too if your stack offers it, but Brotli is the one to make sure of first. If you want to double-check what each value means, MDN’s Content-Encoding reference lists them.
TLS is old, weak, or graded down
What the failed check looked like: an SSL/TLS report grades your site below A — old protocol versions (TLS 1.0/1.1) still enabled, weak ciphers, an incomplete certificate chain, or an expiring certificate.
How to fix it: most of this is a host or CDN setting or a support request, not a manual job. Renew or replace the certificate — most hosts issue free automated certificates, so an expired one is rarely a cost problem. Enable TLS 1.3 and keep 1.2 for older clients, and disable 1.0 and 1.1. Remove weak ciphers, and fix the intermediate/chain if the report flags it. Finally, redirect all HTTP traffic to HTTPS so there’s one canonical secure address. Then re-run the SSL Labs test until the grade is A — it checks the configuration, not just whether a certificate exists, so it’s the tool that tells you when you’re actually done.
An SSL report grades your configuration, not just “is there a certificate” — chase the grade, not the padlock.
The HSTS header is missing
What the failed check looked like: a security-header scan finds no Strict-Transport-Security header, so the site is one insecure redirect away from a downgrade.
How to fix it: add the header at the server, host or CDN: Strict-Transport-Security: max-age=31536000; includeSubDomains. Order matters here more than anywhere else on this list — HSTS assumes HTTPS is already solid, so fix TLS first, and confirm every subdomain works over HTTPS before you turn it on. Start with a short max-age while you verify nothing breaks, then raise it. Add preload (and submit to the browser preload list) only once you’re certain, because preloading is baked into browsers and is deliberately hard to undo. The MDN HSTS reference covers the directives in detail.
Which failed check to fix first
The checks are easy to run in any order, but the fixes are not equal, so spend your effort where it counts:
- TLS/HTTPS and HTTP/2 — the biggest wins, and prerequisites for almost everything else. Fix these first.
- HSTS — cheap and worthwhile once TLS is solid, and a real security improvement.
- Brotli — a low-effort transfer-size win.
- HTTP/3 and IPv6 — genuine upgrades, but nice-to-have. Don’t let a missing HTTP/3 badge distract you from a missing HTTP/2 or a B-grade TLS.
When a fix isn’t yours to make (and the one move that fixes several)
Sometimes the setting simply isn’t exposed — basic shared hosting may not offer Brotli or HTTP/2 toggles at all. When that’s the case, the real fix is a bigger decision: a better hosting plan, or a CDN in front of the site. And that CDN is often the single highest-leverage move on this whole list — a modern edge can serve HTTP/2, HTTP/3, Brotli, IPv6 and strong TLS, and add the HSTS header, all from one place, without you touching the origin. If several checks failed at once, reach for that before chasing them one by one.
The opposite trap is over-tuning: don’t chase a flawless grade by disabling TLS 1.2 and locking out older visitors, or by setting an aggressive HSTS preload before you’re sure. Modern and compatible beats perfect-on-paper.
The short version
The loop is the same for every failed check:
- Re-baseline first — record what you serve, so you can prove the fix and revert cleanly.
- Fix at the right layer — host, origin server or CDN; almost never WordPress.
- Change one thing, then re-test with the same tool, and keep it or roll it back.
- Work in impact order — TLS and HTTP/2 first, then HSTS, then Brotli, then HTTP/3 and IPv6.
- When your host can’t, a CDN in front enables several at once — often the highest-leverage single move.
None of it is a rebuild, and almost none of it is WordPress.
Frequently Asked Questions
I don’t have server access — can I still fix these?
Yes. Most of these settings are available through your host’s dashboard or a quick support request, and a CDN placed in front of your site can enable HTTP/2, HTTP/3, Brotli, IPv6 and strong TLS, and add the HSTS header, all from its own edge without you ever touching the origin server. Server access is the exception, not the requirement.
Will turning these on break my site?
Rarely, as long as you change one thing at a time and re-baseline so you can revert. The two to treat with respect are TLS (keep TLS 1.2 enabled so older clients still connect) and HSTS (get HTTPS working on every subdomain first, start with a short max-age, and only add preload once you’re certain). The rest — HTTP/2, HTTP/3, Brotli, IPv6 — are additive and safe to enable.
My host says it’s already enabled, but the test still fails — why?
Usually a layer or cache mismatch. The CDN edge may serve the protocol while the origin doesn’t (or the reverse), a cached uncompressed or old-protocol response may still be handed out until you purge the cache, or a DNS change (an AAAA record, say) may not have propagated yet. Re-test with a fresh request against the exact hostname your visitors use, and purge any CDN or page cache before you conclude it’s broken.
Do I need a developer for any of this?
Mostly no. These are dashboard toggles, support tickets, or a single DNS record — an owner can do them. The one place a developer or your host’s help earns its keep is editing origin server configuration by hand (Nginx or Apache), where a wrong directive can take the site down. Everything else is safe to do yourself.
Are these fixes something I change in WordPress?
No. HTTP/2, HTTP/3, Brotli, IPv6, TLS and HSTS all live in the server, host or CDN — not in a WordPress setting or a plugin. WordPress only needs to know that its site address is https://; the protocols themselves are enabled in the layers underneath it.
