Skip to main content
Founder-Led · Practicing Since 1997 You work directly with Tony Paris, the founder, same person from quote to launch. No sales reps. No account managers.
Tech Tips

Chrome Will Warn Visitors About Non-HTTPS Sites This October: A Checklist

Tony Paris
October 1, 2026
5 min read
29
Years in Business
BBB Accredited
600+
Websites Built & Hosted
Star Rated

Starting with Chrome 154 in October 2026, Chrome will ask visitors for permission before it loads any public website that does not use HTTPS. The warning can be bypassed, but it interrupts the visit and makes a business look careless. If your site already uses HTTPS everywhere, you are in good shape. If not, you have a short window to fix it.

This post explains what Google announced, who is really at risk, and a simple checklist you can finish in an afternoon.

What Google Announced

Google's security team said Chrome will turn on its "Always Use Secure Connections" setting by default for all users in Chrome 154. Until now, people had to switch this setting on themselves. Chrome first enabled it in April 2026 for users of Enhanced Safe Browsing, in Chrome 147.

With the setting on, Chrome tries to load every page over HTTPS. If a public site does not support it, Chrome shows a warning first. The visitor can then choose to continue to the site.

The change covers public sites only. Internal company tools and local network addresses are treated differently, so Google expects less friction for offices and developers.

How Often Will Visitors See the Warning?

Google tested the setting before making it the default. It reported that the median user sees fewer than one warning per week, and the ninety-fifth percentile user sees fewer than three per week.

That is good news for the web overall. It also means the warning is rare, so people will notice it when it does appear. A visitor who sees one on your site may assume something is wrong with your business, not with a setting.

Google also noted that HTTPS already accounts for about 95 to 99 percent of Chrome page loads. On public sites alone, the figures it gave were 97 percent on Linux, 98 percent on Windows, and above 99 percent on Android and Mac. The remaining HTTP traffic is mostly private networks.

Who Should Worry

Most small business sites already run on HTTPS, so this will not hit them directly. The risk sits in the corners that owners forget about. Here are the common ones:

  • Old subdomains such as a retired blog, a booking page, or a staging copy that is still public.
  • Old links in email signatures, printed materials, directory listings, and social profiles that point to the HTTP version of your address.
  • Hosting plans where the certificate was never set to renew on its own.
  • Embedded tools like forms, maps, or widgets that load content over HTTP.
  • Landing pages built on a separate service that never had a certificate attached to your custom domain.

Any one of these can send a customer to a warning page, even when your main home page looks fine.

A Practical Checklist

Work through these steps in order. Each one is simple, and most hosting providers offer certificates at no extra charge or include them in a plan.

  1. Turn on the setting in your own browser. In Chrome, open Settings, then Privacy and security, then Security, and enable Always Use Secure Connections. Google suggests doing this to find affected sites before the default changes.
  2. Visit your main address with and without "www". Type both versions starting with http:// and confirm each one lands on the HTTPS page with no warning.
  3. Check every subdomain you own. List them from your domain settings or hosting panel. Retire the ones you no longer use, and fix the ones you do.
  4. Confirm the certificate renews automatically. Look at the expiration date and ask your host whether renewal is automatic. An expired certificate causes a warning of its own.
  5. Add a permanent redirect from HTTP to HTTPS. This sends anyone who uses an old link to the secure version of the same page.
  6. Fix mixed content. Open key pages and look for images, scripts, or forms still loaded over HTTP. Update their addresses to HTTPS.
  7. Update outside listings. Change your website address in business profiles, social accounts, email signatures, and ad landing pages.

Why This Matters Beyond Chrome

HTTPS protects the information people send to you, such as names, phone numbers, and payment details. Without it, a third party on the same network can read or change what travels between your visitor and your site. Google's own explanation for the change is that unencrypted page loads expose people to attacks that deliver malware or alter content.

There is also a trust effect. A customer deciding between two businesses will usually pick the one whose site opens without a warning. Fixing this is a low-cost way to avoid losing a sale before the visit even starts.

What About Search Visibility?

This announcement is about browser behavior, not about rankings or AI citations. Still, a visitor who bounces from a warning page is a lost visit. If your pages are slow to load or hard to reach, the same visitors may also be less likely to return or recommend you.

What to Do If You Find a Problem

If you manage the site yourself, start with your hosting control panel. Most panels have a section for certificates where you can issue one and turn on automatic renewal. If a third-party service hosts a landing page for you, check its settings for a custom domain and a certificate option.

If a page cannot be fixed, consider whether it needs to exist. An abandoned page on an old subdomain gives you no benefit and can scare off the visitors who find it. Removing it, or redirecting it to a current page, is often the best answer.

If you are not comfortable making these changes, ask your web developer or host to run through the list above. The work is usually small, and the date is fixed.

The Bottom Line

Chrome 154 arrives in October 2026, and the new default will reach everyone who uses the browser. Sites that already use HTTPS, renew their certificates on time, and redirect old links will see little change. Sites with forgotten pages or lapsed certificates will meet a warning screen in front of their customers.

Spend a short time testing your own site this week, and fix what you find before your visitors do.

Sources

Want a second pair of eyes on this for your own site? Contact us or schedule a call.

Tags

https chrome website security ssl certificate web hosting small business websites browser warnings
TP

Tony Paris

Founder and Tech Wizard at AppWT Web & AI Solutions. With over 29 years of experience in web development, Tony helps businesses succeed online through custom websites, SEO, and AI integration.

Learn more about Tony

Frequently Asked Questions

Will Chrome block my website if it does not use HTTPS?

Chrome will not block it outright. Starting with version 154 in October 2026, it shows a warning before the first visit to a public site without HTTPS, and the visitor can choose to continue. Many visitors will still leave.

Does this affect sites that already have an SSL certificate?

Only if something is broken. A site with a valid certificate that redirects all HTTP addresses to HTTPS should see no warning. An expired certificate or a leftover HTTP link can still cause trouble.

How can I test my site the way Chrome will?

Open Chrome settings, go to Privacy and security, then Security, and turn on Always Use Secure Connections. Then visit your main pages, including old links and subdomains, and see whether any warning appears.

Enjoyed this article?

Share it with your network

Ready to Get Started?

Contact us today for a free consultation. Let's discuss your project.

Contact Us View Services

Share This Article

Awards & Recognition

Tech Wizards an AppWT Anthem

Accessibility

by AppWT Web & AI Solutions
🛡️ Accessibility Profiles
📝 Content Adjustments
100%
100%
1.4
0px
🎨 Color Adjustments
100%
🎛️ Orientation & Controls
♿

Accessibility Statement

Our commitment to digital accessibility and inclusive design

Our Commitment to Accessibility

AppWT Web & AI Solutions is committed to ensuring digital accessibility for people with disabilities. We continually improve the user experience for everyone and apply the relevant accessibility standards to achieve these goals.

Conformance Status

The Web Content Accessibility Guidelines (WCAG) defines requirements for designers and developers to improve accessibility for people with disabilities. It defines three levels of conformance: Level A, Level AA, and Level AAA.

AppWT Web & AI Solutions is partially conformant with WCAG 2.1 level AA. Partially conformant means that some parts of the content do not fully conform to the accessibility standard.

Accessibility Features

  • Built-in accessibility toolbar with multiple customization options
  • Keyboard navigation support throughout the website
  • Screen reader compatibility and proper ARIA labels
  • High contrast mode and color customization options
  • Text size adjustment and font modification capabilities
  • Reading guide and focus indicators for improved navigation
  • Alternative text for all images and media
  • Semantic HTML structure for better screen reader interpretation

Technical Specifications

Accessibility of AppWT Web & AI Solutions relies on the following technologies to work with the particular combination of web browser and any assistive technologies or plugins installed on your computer:

  • HTML
  • WAI-ARIA
  • CSS
  • JavaScript

These technologies are relied upon for conformance with the accessibility standards used.

Feedback

We welcome your feedback on the accessibility of AppWT Web & AI Solutions. Please let us know if you encounter accessibility barriers:

Phone: (888) 565-0171

Email: sales@appwt.com

Address: 33300 Five Mile Rd, Livonia, MI 48154 (by Appointment Only)

Assessment Approach

AppWT Web & AI Solutions assessed the accessibility of our website by the following approaches:

  • Self-evaluation
  • External evaluation
  • Automated testing tools
  • Manual testing with assistive technologies

Date

This statement was created on January 15, 2025 using the W3C Accessibility Statement Generator Tool.

Last updated: