Chrome 154 will warn on HTTP-only sites: what to check first

Chrome 154, shipping in October 2026, turns on "Always Use Secure Connections" by default for every user. Chrome will try HTTPS first for any public site, and warn before falling back to plain HTTP. Google's own announcement confirms the rollout is already underway: Chrome 147 enabled the same setting in April 2026 for the roughly one billion users on Enhanced Safe Browsing, and Chrome 154 extends it to everyone.

What actually triggers the warning, and what does not

The warning is scoped to public sites specifically. Private and local addresses, a router's admin page at 192.168.0.1, a single-label internal hostname, a corporate intranet shortlink, are excluded, since certificate coverage does not apply cleanly to them and the attack surface is different. For everything public, Chrome tries HTTPS first and only warns if that fails.

Google's own numbers from Chrome 141 experiments put this in perspective: the median user sees fewer than one warning a week, and the 95th-percentile user sees fewer than three. Warnings do not repeat for a site a user visits regularly once they have accepted it once. This is not designed to be a wall of scary prompts, it is designed to catch the occasional stale link to a subdomain nobody finishes migrating.

Finding your subdomains is not the hard part

A wildcard Certificate Transparency query returns every subdomain a public CA has ever issued a certificate for, including the staging environment and the marketing microsite nobody remembers standing up. WebPixie already has a full walkthrough of that method, Certificate inventory: skip the spreadsheet, including the exact wildcard query pattern and what each CT log entry tells you. That post covers the "how do I find what exists" question thoroughly, this one starts from the list you already have and covers the question Chrome 154 actually raises: which of those subdomains are still a problem, and which ones matter.

The triage question nobody's answering

A CT log entry tells you a certificate was issued for a name. It does not tell you whether that subdomain is still live, still public, or still HTTP-only. Treating every discovered subdomain as equally urgent is how a five-minute check turns into a week of chasing dead ends.

• Is it actually reachable right now: a subdomain with a stale DNS record or a decommissioned host is not going to trigger a warning for anyone, because nobody is loading it. Confirm reachability before spending time on it
• Does it redirect to HTTPS, or serve content directly over HTTP: a same-host redirect from HTTP to HTTPS means Chrome never gets far enough to warn. A subdomain that serves real content over plain HTTP, or redirects through a chain that touches an insecure hop along the way, is the actual risk
• Does the redirect chain stay on infrastructure you still control: a chain that bounces through an old CDN entry, a decommissioned redirect service, or a domain you no longer renew is worth flagging even if it currently works, since it can silently break in a way that looks identical to the Chrome warning
• Is anything on the page still loaded over plain HTTP: an otherwise-HTTPS page pulling an image, script, or stylesheet from an http:// URL creates mixed-content warnings independent of the Chrome 154 change, and is worth fixing in the same pass since you are already checking the page

This is the part the existing prep guides skip. They tell you to audit your subdomains, without saying which of the ones you find are actually worth the time.

A fast first pass

For each subdomain from the CT log list, one command tells you most of what matters, following every redirect and showing each hop:

curl -sIL http://subdomain.example.com

A clean 301 or 302 straight to HTTPS on the same host is fine, deprioritize it. Anything that serves content directly over HTTP, or takes more than one hop to get to HTTPS, goes on the list to actually fix before October.

Checking for mixed content is a separate one-liner: fetch the rendered page and grep it for a plain http:// resource reference.

curl -s https://subdomain.example.com | grep -oE '(src|href)="http://[^"]*"'

This catches resources baked into the initial HTML; anything a script injects client-side still needs a quick check in the browser’s DevTools console instead.

What to do with the list once it is triaged

WebPixie's Certificates Manager already surfaces the CT-log subdomain list this whole process starts from, one click to add any discovered subdomain to monitoring. Once a subdomain is being watched, SSL monitoring validates what it actually serves daily, chain, expiry, TLS configuration, so a subdomain that passes today does not silently regress to HTTP-only again without anyone noticing before the next Chrome release makes that regression visible to every visitor.

Before October

• Pull the CT-log subdomain list: see the linked walkthrough if this step is new to you
• Run the redirect-chain check on each one: deprioritize clean same-host HTTPS redirects, flag everything else
• Fix the flagged list, not the whole inventory: most discovered subdomains will already redirect cleanly, spend the effort on the ones that do not
• Put the fixed subdomains under ongoing monitoring: a one-time audit answers today's question, not next quarter's