September 5, 2026 / websites, security, https, utah-business
Chrome HTTPS Warning in October 2026: What to Check Now
Chrome turns on HTTPS warnings for every user this fall. Your homepage is almost certainly fine. What breaks is the stuff nobody has looked at in years.
The change, in one sentence
Later this year, Chrome starts asking permission before it will load a public website that has no HTTPS, and that behavior is on by default for everybody.
Google announced this on its security blog and the plan has two stages. Chrome 147 turned the setting on for people enrolled in Enhanced Safe Browsing, a group Google puts at over a billion users. Chrome 154 turns it on for everyone else. Google's post names October 2026 for that second stage.
If you want to know how close that actually is, the public Chromium release schedule lists Chrome 154 hitting early stable on September 9, 2026 and late stable on September 30, 2026. Google can stage the setting separately from the browser version, so October is still the number to plan against. But the browser carrying it starts landing on your customers' phones this month, not next.
Why your homepage is probably fine already
Here is the part that gets lost in the security-newsletter version of this story.
Chrome has been quietly upgrading insecure links for three years. The Chrome 115 release notes describe the feature plainly: Chrome will "automatically and optimistically upgrade all main-frame navigations to HTTPS, with fast fallback to HTTP." Somebody clicks a stale http:// link to your site, Chrome silently tries the secure version first, it works, and nobody sees anything.
The warning only appears when the secure attempt genuinely fails. Not when a link is old. Not when a link is written wrong. Only when the hostname on the other end truly has no working certificate.
So the question is not "is my website on HTTPS." Your website is on HTTPS. The question is whether every hostname a customer can reach is on HTTPS, and that is a different list than most owners think.
I ran the check on our own domain on September 5, 2026. http://articulatevision.net redirects once and lands on the secure version. http://www.articulatevision.net takes two hops and lands in the same place. The response carries a Strict-Transport-Security header with a two year max-age, which tells Chrome not to even try the insecure version next time. That is the shape you want, and you can verify it on your own site in about a minute.
The four places this actually bites
Across small business sites, the failures are boringly consistent.
Subdomains that were set up once and forgotten. The old blog on a legacy host. A shop. or booking. name pointed at a vendor who never finished the certificate. A staging site at dev. that got indexed. The apex domain has a certificate; these often do not, because they were configured by a different person on a different afternoon.
Second, hostnames you do not control but did hand out. A scheduling tool, a customer portal, an email-marketing landing page on a vendor subdomain. Chrome does not care whose server it is. It cares whether the connection is secure.
Third, printed links and QR codes. A QR code encodes whatever string it was generated from. If somebody generated it from an http:// address years ago, the auto-upgrade still saves you, as long as the destination serves HTTPS. If the destination is one of those forgotten subdomains, the customer standing in your lobby gets an interstitial instead of your menu.
Fourth, mixed content inside otherwise secure pages. An image, script, or embedded font pulled over plain HTTP from a source that has not been touched since 2019. Chrome's DevTools Security panel lists these for a page in about ten seconds, and this failure mode is separate from the navigation warning but tends to live in the same neglected corners.
None of that is exotic. It is just old, and old is the actual risk here.
The certificate clock got a lot shorter
The second half of this story is the one almost nobody has told small business owners, and it has a harder deadline.
In April 2025 the CA/Browser Forum, the body that sets the rules browsers and certificate authorities follow, passed Ballot SC081v3. It shortens how long a public TLS certificate may live, on a published schedule.
That cap is already in force. It drops again in March 2027, and again in 2029. A certificate you could once buy and forget for a year is now a thing that expires while you are still thinking about it.
Our own certificate is a good illustration because I can read it off the wire. It was issued by Let's Encrypt on July 20, 2026, expires October 18, 2026, and had 42 days left when I checked on September 5. That is a 90 day certificate, well inside the new cap, and it renews itself without anyone touching it. If it did not renew itself, we would be doing that four or more times a year forever.
There is a trap attached. Let's Encrypt stopped sending expiration reminder emails on June 4, 2025. Their reasoning was straightforward, that most subscribers now automate renewal and the notifications cost real money to run. But if your mental model of certificate management is "I will get an email," that email is not coming, and the first notice you get will be a customer telling you your site looks broken.
A twenty minute check you can run yourself
You do not need a consultant for this, and you should not pay for an audit before you have looked.
- Write down every hostname a customer can reach. Apex, www, and every subdomain. Check your DNS records if you are unsure, because forgotten names live there.
- Visit each one with
http://in front. Confirm it ends on a padlock with no interstitial. - On your main pages, open DevTools, go to the Security panel, and look for mixed content warnings.
- Confirm your host renews certificates automatically. If you cannot find that answer in your host's dashboard in five minutes, assume it does not.
- Check anything printed. Business cards, vehicle wraps, window decals, QR codes on menus and signage. You cannot reprint them, which is exactly why the destination has to keep working.
- Ask your vendors. Any tool that serves customers from a name with your brand in it is your problem when it fails.
Do this once. Fix what it finds. Then leave it alone, because a site with automatic renewal and a clean subdomain list does not need to be revisited.
If something fails the check
The fix is usually free and usually fast. A certificate from Let's Encrypt costs nothing, and every major host has a one-click path to enabling it. The slower cases are subdomains pointed at services you no longer use, and the correct move there is often to delete the DNS record rather than secure a page nobody needs.
The instinct I would push back on is treating this as an emergency requiring a rebuild. It is not. It is a maintenance item, in the same family as the things we cover in Core Web Vitals for small business and website accessibility: unglamorous, cheap to handle early, expensive to ignore until a customer notices. The same is true of the crawler and indexing decisions we walked through in should you block AI crawlers.
If you would rather have somebody run the list for you, that is a normal part of what we do on the website side, including for the businesses we keep on ongoing care.
Questions we actually get asked
Will this hurt my Google rankings? Not directly. This is a browser behavior, not a ranking system. The damage is to conversion. A visitor who sees a security interstitial before your homepage usually does not continue.
My site is HTTPS but the padlock has a warning icon. Same thing? No, that is mixed content, which means the page loaded securely but pulled something over plain HTTP. Different fix, same neighborhood. The DevTools Security panel names the offending resource.
Do I need to do anything about my office router or internal tools?
Google's post carves out private addresses. Local IP addresses like 192.168.0.1, single-label hostnames, and internal shortlinks are excluded from the default warning. This applies to public sites.
If you want a second set of eyes on your list before the fall,
and we will tell you what we find.