Chrome is about to interrupt anyone who visits your site over HTTP, and the date moved up to September 22

If you type http:// into Chrome today and the site cannot answer over HTTPS, Chrome quietly loads it anyway and puts a “Not secure” note in the address bar that essentially nobody reads. In about a month, that stops. Chrome will show a full-page warning first and ask the visitor whether they really want to continue.

Google announced this in October 2025 and gave a date of October 2026 for the final phase. That date is no longer right, and it is not right in the direction anyone would prefer. It moved earlier.

The date

The feature is a Chrome setting called Always Use Secure Connections, which some documentation still calls HTTPS-First Mode. It is not new. What is new is that it becomes the default for everyone.

The rollout has two phases:

• Chrome 147, April 2026. Already shipped. The setting was turned on by default for the users who have opted into Enhanced Safe Browsing, which Google puts at over a billion people. If your site is HTTP-only, some fraction of your visitors have been seeing this warning since the spring.
• Chrome 154. The setting becomes the default for all Chrome users.

Google’s announcement put Chrome 154 in October 2026, and almost every article written about this since has repeated that. It was accurate when written. In the meantime Chrome changed its release cadence: starting with Chrome 153 on September 8, 2026, Chrome ships a new stable version every two weeks instead of every four. Chrome’s own release blog spells out the consequence, that M153 moves from September 22 to September 8 and M154 follows two weeks later on September 22. The Chromium release schedule now lists Chrome 154’s stable date as 2026-09-22.

So the real deadline is roughly a month out, not two, and the article you read about this in November is probably still telling you October.

What actually triggers the warning

This is the part worth being precise about, because “your site needs HTTPS” is not quite the rule and it causes people to check the wrong thing.

Chrome already tries to upgrade http:// navigations to https:// on its own. When the upgrade works, nothing happens and nobody sees anything. When the upgrade fails, Chrome today falls back silently to HTTP. From Chrome 154, that silent fallback becomes an interstitial.

Two consequences follow.

A working HTTP to HTTPS redirect is fine. If your server answers on port 443 and redirects, the upgrade succeeds. Old http:// links in printed material, on business cards, in QR codes, in email signatures, and in directory listings keep working with no warning. You do not need to reprint anything.

“We have HTTPS” is not the test. “Every hostname we own answers on HTTPS” is the test. The upgrade fails if the connection fails, and a certificate that does not cover the exact hostname counts as a failure.

The warning applies to top-level navigations only, and it is bypassable: the visitor can click through. Google says users are only warned on new or infrequently visited insecure sites rather than repeatedly for ones they use. Google’s own measurement during the pilot was that the median user sees fewer than one warning per week, and the ninety-fifth percentile user fewer than three.

That statistic is reassuring if you are a Chrome user. It is less reassuring if you are the site. A rare warning across the whole web still means a warning every single time for the specific site that has the problem, in front of a visitor who has never seen your business before.

What is exempt

Private destinations are excluded, because getting a publicly trusted certificate for them is genuinely hard. Google names local IP addresses, single-label hostnames, and shortlinks of the intranet/ variety. In practice that covers:

• The private IP ranges, meaning 10.x.x.x, 172.16.x.x through 172.31.x.x, and 192.168.x.x
• localhost and 127.0.0.1
• Single-label hostnames, meaning a name with no dot in it
• Shortlinks like http://intranet/

So the office router at 192.168.1.1, the network printer, the NAS admin page, and the label printer’s little web interface are all safe. Nobody has to buy a certificate for the receipt printer.

The exemption is about the address, not about the intent. An internal tool that lives at a real public domain name over plain HTTP is not exempt. Neither is a device on a public IP address, which is a common shape for older security cameras and DVRs that someone port-forwarded years ago. Those get the warning like anything else.

Five ways a site that already has HTTPS still gets caught

The businesses that get hurt here are mostly not the ones running an entirely unencrypted website. Those are rare now. W3Techs put HTTPS-by-default at 90.0% of all websites as of August 2026, and Google reports Chrome page loads have been in the 95 to 99 percent range since about 2020. The gap between those two numbers is the interesting part: page loads are near-total because the big sites are all encrypted, while roughly one site in ten still is not, and those are overwhelmingly small ones.

The more common problem is a site that is 95 percent fine with one hostname that is not. In rough order of how often we find each:

1. The apex and the www version are not both covered. The certificate is issued for www.example.com, someone links to example.com, the HTTPS handshake fails on the name mismatch, and Chrome warns. This has always been broken. Until now it was invisible, because the fallback to HTTP hid it.

2. An old subdomain nobody remembers. blog., shop., old., staging., mail., portal., careers.. These accumulate. Some were set up by a previous agency, some point at a service you stopped paying for in 2021, and the DNS record is still live. Any of them that answers on HTTP but not HTTPS is a warning waiting for whoever finds the link.

3. The certificate expired. An expired certificate already stops anyone who follows an https:// link, and that is not new. What is new is that it also stops the ones arriving over http://, who until now got a silent fallback to plain HTTP and a page that looked fine. The timing here is unkind. Since March 15, 2026, the maximum life of a public TLS certificate is 200 days rather than 398, and as we wrote in the post on shortening certificate lifetimes, the first wave of 200-day certificates comes due around October 1. That is nine days after Chrome 154.

4. A vendor subdomain you delegated. A booking widget, a help centre, a status page, or a marketing landing page hosted somewhere else on book.yourdomain.com. You own the DNS record; someone else owns whether it has a certificate. Worth asking them now rather than in October.

5. Redirect chains that pass through HTTP. A link goes to HTTPS, which redirects to an HTTP tracking domain, which redirects back to HTTPS. Common with older link shorteners and some email marketing platforms. The intermediate hop is a navigation like any other.

How to check in ten minutes

Do this rather than trusting a memory of what your site does.

Turn the setting on yourself. In Chrome, go to Settings, then Privacy and security, then Security, and enable “Always Use Secure Connections.” This is what Google explicitly recommends for site owners and IT staff: run the future default now and go click around your own site, your own booking flow, your own client portal. This is the highest-value ten minutes in this post.

List every hostname you actually own. Export your DNS zone, or open your registrar’s DNS panel and read every A, AAAA, and CNAME record. Most people are surprised by two or three entries. Then, for each one, check that https://thathostname/ loads without a certificate error. From a terminal:

curl -sSI https://example.com | head -1
curl -sSI https://www.example.com | head -1
curl -sSI http://example.com | head -1

The third command should return a 301 or 308 pointing at the HTTPS version. If the first two return a TLS error instead of a status line, that hostname is a problem.

Check what other people link to. Your Google Business Profile, your directory listings, your social profiles, and your invoices. If any of them still carry an http:// URL, that is fine as long as the redirect works, which is the thing you just verified. If you are cleaning up listings anyway, our local SEO notes cover what else is worth fixing while you are in there.

The fix, and how much it costs

Nothing. That is genuinely the answer for most small businesses in 2026.

Domain-validated certificates are free from Let’s Encrypt and issued automatically by essentially every modern host. If your site is on Vercel, Netlify, Cloudflare, Shopify, Squarespace, Wix, or WordPress.com, the certificate is handled for you and renewed for you, and you should confirm rather than assume that the coverage includes every hostname you use. If you are on traditional shared hosting, the control panel almost certainly has a one-click option, and it is usually called AutoSSL or Let’s Encrypt.

The two things worth doing beyond the certificate itself:

• Redirect HTTP to HTTPS at the server, permanently (301 or 308), for every hostname, including the apex and every subdomain.
• Automate renewal, and then verify the automation actually ran. With certificate lifetimes dropping to 100 days in March 2027 and 47 days in March 2029, a manual annual renewal is no longer a viable process. It is going to fail, and now it fails loudly.

If you run something on the office network at a real domain over HTTP and moving it to HTTPS is genuinely hard, Chrome has enterprise policies for this: HttpAllowlist suppresses the warning for named hostnames, and HttpsUpgradesEnabled turns the upgrade behaviour off entirely. Use the allowlist, not the global off switch, and treat both as a way to buy time rather than a solution.

Why this is worth caring about beyond the warning

Two reasons, one obvious and one less so.

The obvious one is conversion. A warning page in front of a first-time visitor who found you through search is a lost lead, and it is lost in the most expensive possible way, after you paid for the click or earned the ranking. Nobody who is comparison-shopping three trades companies clicks through a security warning to reach the third one.

The less obvious one is that this is a visible symptom of an invisible class of problem. HTTPS has been a Google ranking signal since 2014, and mixed-content subresources have been blocked for years, so a site with certificate problems has usually been quietly underperforming for a while. The reason nobody fixed it is that nothing ever surfaced. That is what changes on September 22: the browser stops covering for the configuration.

Chrome’s shift to a two-week release cycle is worth registering separately, for the same reason. The web platform your clients’ sites run on now changes twice as often, and “we tested it in Chrome” has a shorter shelf life than it used to. Extended Stable stays on its eight-week cycle for enterprises, so that eight-week gap now spans four milestone numbers instead of two. (An earlier version of this paragraph said the spread between the fastest and slowest Chrome in your audience had got wider. That was loose. In calendar terms it is unchanged at eight weeks; what changed is that version numbers no longer measure it the way they used to.) We have since written that up on its own, along with the Edge and Firefox schedules that changed in the same fortnight, in the post on every browser going biweekly. The short version, and the reason it matters here: a milestone number is no longer a rough month, so every deprecation date you were tracking by version number has quietly moved forward.

One more thing lands on September 22. Chrome 154 is also the release where the unload event stops firing for 100 percent of page loads, the end of a rollout that has been ramping since March and is already at 80 percent. It is unrelated to HTTPS and it affects a different kind of site, the ones with booking flows, record locks or custom analytics rather than certificate problems, but it is the same version on the same day. If you are opening a ticket for one, open it for both: what breaks when unload handlers stop running.

If you are not sure how many hostnames your business actually has, or whether all of them will still load in Chrome in October, send us a note. It is a short check, and it is a much better conversation to have in August than in the week your certificate expires.