Chrome 154 Turns On HTTPS by Default: What Websites Must Fix

Google released Chrome 154 to the stable channel on 22 September 2026, and with it Chrome now asks users for permission before loading a public website over insecure HTTP. Google calls the feature "Always Use Secure Connections" and first announced the plan on 28 October 2025. Any website that still serves pages, redirects or links over plain HTTP may now show visitors an interstitial warning before they reach it.

What happened

In its "HTTPS by default" post on 28 October 2025, the Chrome security team said it would "change the default settings of Chrome to enable 'Always Use Secure Connections'". The rollout came in two stages:

The Chrome 154 release notes describe the change as "Ask before HTTP on by default": "Chrome prompts users by default when they connect to a site over an insecure (http) connection." Businesses that manage Chrome centrally can change the default with the HttpsOnlyMode enterprise policy, and individual users can switch the warnings off in settings.

How the warning works

Google designed the feature to avoid warning fatigue:

• Public sites only. The default applies to public websites. Private destinations such as local IP addresses, single-label hostnames and intranet shortlinks are excluded, because an attacker usually needs to be on the same local network to exploit them.
• First visit only. Chrome "will only warn users when they visit a new (or not recently visited) site without using HTTPS". A site you open every day will not keep triggering the prompt.
• Users stay in control. Visitors can choose to continue to the HTTP page, and anyone can turn the warnings off in Chrome's settings.

Google said that in a Chrome 141 experiment "the median user sees fewer than one warning per week", with warnings appearing on well under 3% of navigations. It also reported that, excluding private sites, the share of HTTPS navigations had reached about 98% on Windows and over 99% on Android and Mac. The remaining HTTP traffic is small, but Google noted that much of it comes from sites that use HTTP only to redirect to HTTPS, which is precisely the sort of setup that can now trigger a prompt.

What this means for businesses

Most websites already use HTTPS, so the main page loads fine. The risk is in the edges, which are easy to forget:

• Old HTTP links in email signatures, printed QR codes, social profiles, directory listings and paid ads. If the first hop is http:// and the server cannot answer over HTTPS on that hostname, visitors can now see a warning before the redirect.
• Subdomains and microsites such as an old shop., booking. or campaign domain left on HTTP after the main site moved.
• Tracking and redirect domains used by email platforms and link shorteners that still start on HTTP.
• Bare domain or www variants where one version has a valid certificate and the other does not.

For a small business, a warning page on the first visit from a customer or a Google Ads click is lost trust and, very often, a lost sale. Google's own page experience guidance also asks whether your pages are served securely, so cleaning up insecure URLs is good technical SEO as well as good security.

What to do now

1. Test every hostname you own over HTTPS. Include the bare domain, www, and every subdomain used in links. The MakeItFlow SSL checker shows whether each serves a valid certificate.
2. Redirect HTTP to HTTPS on the same hostname first. A single, direct 301 from http://example.com to https://example.com is best. Avoid redirect chains; our guide to broken links and redirect chains explains why.
3. Turn on HSTS. The Strict-Transport-Security header tells browsers to use HTTPS automatically on return visits. Read our HSTS explainer before adding preload.
4. Update links at the source. Change printed materials, QR codes, email templates, Google Business Profile, social bios and ad final URLs to https://.
5. Ask suppliers about tracking domains. If your email or SMS platform wraps links with an HTTP tracking domain, ask them to enable HTTPS link tracking.
6. Test with the setting on. Google encourages developers and IT teams to switch on "Always use secure connections" in Chrome now to find pages that still need moving.
7. Run a full check. A free website audit on MakeItFlow checks your TLS certificate, security headers including HSTS, and a sample of broken links in one scan. Use the security headers checker for a quick header-only test.

Frequently asked questions

Will Chrome block my HTTP website completely?

No. Chrome shows a warning and asks the visitor whether to continue. They can still proceed, and the prompt does not reappear for sites they visit regularly. But many visitors will turn back, so it is best to treat the warning as a fault to fix.

Does this affect our internal systems on the office network?

Generally not. The default covers public sites only, and excludes local IP addresses, single-label hostnames and intranet shortlinks. IT teams can also manage the behaviour through the HttpsOnlyMode policy.

We already have an SSL certificate. Is there anything else to check?

Yes. Make sure the certificate covers every hostname you use, that HTTP redirects straight to HTTPS, and that the certificate renews automatically. With the maximum certificate lifetime now 200 days, see our news on 200-day TLS certificates.

Related reading

• How to Read a Website Audit Report and Decide What to Fix First: Read a website audit report by sorting issues by impact and effort: fix anything blocking indexing, security or email first, then speed, then polish.
• What Is Mixed Content and How Do I Fix It? A Step-by-Step Guide: Mixed content is when an HTTPS page loads images, scripts or fonts over HTTP. Learn how to find mixed content errors and fix them for good, in WordPress too.

Sources

• Google Security Blog: HTTPS by default (28 October 2025)
• Chrome for Developers: Chrome 154 release notes
• Google Search Central: Understanding page experience in Google Search results