In October 2026, Chrome stops quietly tolerating sites that don't load securely. With the release of Chrome 154, the setting called "Always Use Secure Connections" flips on by default for everyone, and from that point Chrome will "ask for the user's permission before the first access" to any public site that has no HTTPS. Not a small gray label near the address bar. A page the visitor has to click through before they see anything of yours.

Google announced this on the Chrome Security blog in October 2025, so nobody can say it came out of nowhere. The part most business owners missed is that the first phase already shipped. In April 2026, Chrome 147 turned the same setting on for the billion-plus people who use Enhanced Safe Browsing. If your site has a problem here, a slice of your customers has been running into it since spring.

We scanned 1,168 Front Range business websites to see how bad this is locally. One local business in eight fails, and almost none of them fail the way the October deadline is about. The numbers are further down.

Two doors, and each one has a job

Every website answers on two doors. Port 80 is the http door. Port 443 is the https door. A correctly configured site keeps both of them open, permanently, and gives them different jobs.

Port 443 serves your website.

Port 80 serves exactly one thing: an instruction that says "go to the secure version," and then it gets out of the way. In technical terms that's a 301 redirect. In practical terms, someone types yourbusiness.com, hits the insecure door first because that's what browsers historically did, and gets handed straight to the secure one before a single pixel loads.

Both doors stay open forever. That part gets missed. Every business card you printed, every old Facebook post, every backlink from a chamber directory in 2019, every Google Business Profile field somebody filled in years ago: a lot of those point at http://. If you close port 80 entirely, all of those become dead links instead of redirects. Keeping the insecure door open is not a security hole as long as the only thing behind it is a redirect. Closing it costs you traffic you already earned.

Here's what a correct site looks like from the outside:

That last row matters more than it looks. Some hosts redirect every http request to the https homepage instead of the https version of the page that was asked for. Someone clicks a link to your pricing page from a five-year-old blog post and lands on your front page instead, with no idea what they were supposed to be looking at. You keep the visit and lose the reason for it.

The three ways this actually breaks

We sorted every failure we found into three buckets. They're different problems with different fixes and different levels of urgency, and lumping them together as "SSL problems" is how they stay unfixed for years.

No certificate at all. Nothing answers on port 443. There is no secure version of the site to reach, so the browser has nothing to upgrade to. This is the one Chrome 154 is aimed at. From October, a first-time visitor gets the full permission prompt before your homepage renders.

A certificate that doesn't check out. Something answers on 443, but the certificate is expired, or self-signed, or issued for a different hostname than the one people type. The classic version of this is a certificate that covers yourbusiness.com but not www.yourbusiness.com, which means half your visitors are fine and half get a red full-page interstitial that uses words like "attackers might be trying to steal your information." This is the most damaging of the three and the most likely to be invisible to the owner, because owners usually type the version that works.

A certificate that works, and a front door that ignores it. Port 443 is perfect. Port 80 answers with the actual website instead of a redirect. So the visitor who typed the bare domain, or tapped an old link, stays on the insecure copy for the whole visit, sees "Not secure" in the address bar the entire time, and never knows a secure version existed. This was the most common failure in our scan by a wide margin.

That third one deserves a second sentence, because the site owner in that situation genuinely believes they're covered. They bought the certificate. They can see the padlock. Both of those things are true and neither of them is the question.

Why you are the last person to find out

Chrome is deliberately designed so that you, the owner, will not see this.

Google built in a rule to stop the warnings from becoming background noise: as long as someone visits an insecure site regularly, Chrome stops warning them about that site. The warning is reserved for sites the person hasn't been to, or hasn't been to recently. Google's stated reasoning is that warning on every insecure page load would be so disruptive that people would turn the feature off.

For a local business, that has one specific consequence. Nobody on earth visits your website more regularly than you do. You are the single person most reliably excluded from the warning. Your web designer, your office manager, your spouse who checks the hours page: all regulars, all excluded. The warning lands on people who have never been to your site before, which is the exact population you built the site for.

Three more reasons your own experience is misleading:

• Your browser autocompletes to the https version because that's the one you've typed a thousand times. You never test the door your customers use.
• You reach your own site from a bookmark, or from the WordPress admin bar, both of which are already secure.
• On your phone you probably tap the Google Maps listing or a saved link, not the bare domain.

If you want to know what your customers see, you have to deliberately behave like someone who has never been to your site. We'll show you how in a minute.

What we found across 1,168 Front Range business domains

We ran the check against every business website in our Front Range dataset: med spas, dermatology practices, salons, contractors, wellness clinics, restaurants, the ordinary mix of a local economy. One check per domain, both doors, plus a direct look at the certificate.

Of the 1,168 domains, 979 gave us a clear answer. 851 of those were configured correctly. 128 were not, which is 13 percent, or roughly one local business in eight.

The interesting part is how they failed:

Only three businesses in the whole set have no certificate. That surprised us, and it's good news for the October deadline: almost nobody around here is going to get the full permission prompt. The failures that matter locally are the other two rows, and neither is on Google's timeline. They're broken now.

Ninety-four businesses hold a working certificate and never send anyone to it. Every one of those owners believes they're done. Thirty-one have a certificate a browser refuses to accept, which produces a red interstitial rather than a gray label, and it's the version most likely to be losing them customers today.

Ten certificates in the set expire within three weeks of this scan, one of them in four days. If those renewals aren't automatic, those sites are about to move from the first row to the third.

The failure rate is not evenly spread, which is the part we'd have bet against:

A nail salon on the Front Range is roughly five times more likely to have a broken secure setup than a med spa down the same street. Both are cash-paying local service businesses selling to the same customer. The difference is who built the site and whether anyone has touched it since.

One note on the 189 domains missing from those tables, because this is where scans like ours quietly cheat. 178 of them answered with a 403 or a 429 instead of a page, meaning their bot protection blocked the check, and 11 pointed at a booking or social platform rather than a site the business controls. A blocked check tells us nothing about whether that site's HTTPS works, so those domains are excluded from every number above instead of being folded into the failure column to make the headline bigger. A failed check is a failure of the check, not evidence against the site.

The 60-second version you can run right now

No terminal, no developer.

1. Type your bare domain into a fresh browser window. No https, no www, just yourbusiness.com and Enter. Use a browser you don't normally use for your own site, or a private window, so autocomplete doesn't help you cheat. Then look at the address bar. If it now reads https://, your redirect works. If it still reads http://, or shows "Not secure," you've found failure number three.

2. Force the insecure door. Type http://yourbusiness.com deliberately, with the http spelled out. Same check. Then do it again with http://www.yourbusiness.com, because the www and non-www versions are configured separately and it's common for one to be right and the other wrong.

3. Look at the certificate. Click the icon at the left of the address bar, then the connection or certificate detail. You want a valid certificate, issued to a name that matches what people type, with an expiry date comfortably in the future. If the expiry is inside the next three weeks, find out today whether renewal is automatic, because an expired certificate takes a site from fine to full-page-warning overnight, usually on a weekend.

4. Check a deep link. Take any page other than the homepage, request it over http, and confirm you land on that same page over https rather than getting dumped on the front page.

If you're comfortable at a command line, one line answers the first two steps at once:

curl -sI http://yourbusiness.com | head -n 5

You want to see 301 and a Location: header that starts with https://.

What it costs to fix

For most businesses, nothing.

Certificates have been free since Let's Encrypt made them free, and every mainstream host issues and renews them automatically. On Squarespace, Wix, Shopify, and Cloudflare it's on by default and there's nothing to buy. On WordPress hosts like SiteGround, Bluehost, WP Engine, or Kinsta, it's a toggle in the dashboard labeled something like "Force HTTPS," and turning it on writes the redirect for you. The whole job is usually under ten minutes, and the hardest part is remembering which company you're paying for hosting.

Two things to do at the same time, while you're in there:

Update your internal links and your images. If your pages still point at http:// versions of your own pages or load an image over http, browsers flag the page as having mixed content and the padlock goes away even though your certificate is fine. Most WordPress hosts have a one-click search-and-replace for this, and the better ones do it as part of the Force HTTPS toggle.

Tell Google. In Search Console, the http and https versions of your site are two different properties. If you've only ever verified the http one, add the https one, and make sure your sitemap lists https URLs.

The genuinely expensive case is rare: a custom-built site on hosting old enough that TLS was never set up, where nobody currently working for you knows how it was deployed. Even then this is a small job, not a rebuild, and it's worth doing before October rather than during the week your traffic drops.

Does this move rankings?

A little, and we'd rather say so plainly than sell you a bigger number.

Google confirmed HTTPS as a ranking signal in 2014 and described it then as lightweight, affecting a small fraction of queries and carrying far less weight than content quality. That's still a fair description in 2026. Fixing your redirect will not move you from page five to page one.

The traffic argument is the one worth caring about. From October, a first-time visitor to a site with no HTTPS gets a permission prompt standing between them and your homepage. Some percentage of people will not click through it, and that percentage is made up entirely of people who had never been to your site before. For a local service business, first-time visitors are the whole point of having a website.

There's also a second-order effect that's easy to miss. Anyone comparing three local providers, which is exactly what people do before booking anything medical, expensive, or in their home, is making a trust judgment in about four seconds. A browser warning on one of the three ends that comparison early.

If you'd rather someone just checked

We keep this scan running across the Front Range as part of our local research, so we usually know the answer for a given business before they ask. Send us the domain and we'll tell you which of the three buckets you're in, when the certificate expires, and whether the fix is a toggle or a real job. No charge for the answer, and no pitch if the answer is that you're fine, which is what it was for 87 percent of the businesses we scanned.

[PHOTO/DIAGRAM NEEDED: a simple two-door diagram, port 80 and port 443 drawn as two doors on the same building, with the port 80 door containing only an arrow pointing to the 443 door. Labeled "serves nothing, points everything" and "serves the website." Free image search: no good stock exists for this, it should be drawn. AI image prompt: "clean minimal technical diagram, two labeled doorways side by side on a simple building facade, left door labeled port 80 with a curved arrow leading to the right door, right door labeled port 443 and open with light coming through, flat editorial illustration, muted teal and cream palette, no text rendering errors, wide aspect"]

[PHOTO/DIAGRAM NEEDED: a screenshot of Chrome's "Not secure" address bar label next to the same site loading correctly with the padlock, side by side at the same zoom. Free image search: take this ourselves from a real failing local site, cropped so the business is not identifiable.]