What does HTTPS by default in Chrome mean for your website?

Chrome now asks for permission before it opens any public website that doesn't work over HTTPS, so a site still on plain HTTP greets new visitors with a warning page instead of its homepage. Google calls the change HTTPS by default, and it became the standard setting for all Chrome users in Chrome 154, released on 22 September 2026.

If your site loads over HTTPS at every address and through every redirect, nothing changes for you. If it doesn't, the cost falls on the people you most want to reach. Regular visitors click past the warning once and rarely see it again. New ones, tapping your ad, your Google listing or a link a colleague forwarded, have never heard of you and now have to decide whether to trust a page their browser just flagged.

What visitors see when a public site has no HTTPS

Chrome first tries the HTTPS version of the address. If that fails but the page would load over HTTP, Chrome pauses the visit, shows a warning where your site should be, and waits for the visitor to choose to continue. According to Chrome's adoption guide for site owners, Chrome remembers that choice for 15 days and renews it each time the person comes back.

The rule covers public sites such as example.com. Local IP addresses like 192.168.0.1, single-label names like intranet/ and http://localhost are left alone, so office routers and local development keep working. A staging site on a real domain, such as staging.yourbrand.com, counts as public.

Few sites are left to warn about. Google's Chrome security team reports that the share of Chrome traffic using HTTPS climbed from around 30 to 45 percent in 2015 to the 95 to 99 percent range around 2020, then stopped improving. In Google's testing, the median user saw fewer than one warning a week. That is why the warning stands out: if your site triggers it, your visitors are seeing something most other sites never show them.

Why Chrome switched to HTTPS by default

A page sent over plain HTTP can be read or changed by anyone on the network between your visitor and your server, from a hotel Wi-Fi operator to a compromised router. Google's announcement says an attacker can hijack an HTTP link and push the user to malware, targeted attacks or social engineering. One insecure click is enough, even when the rest of the site is secure.

For visitors, the trade is easy to accept: an occasional extra click in return for not being quietly redirected on public Wi-Fi. For site owners, the fix itself costs little. Let's Encrypt issues certificates free, and many hosting providers request and renew them for you. The trouble sits in places nobody has opened in years, like an old campaign microsite or the shop subdomain a previous agency set up.

The warning is a speed bump rather than a wall. Visitors can click through, and anyone can switch the setting off. You just don't get to choose which first-time visitors decide your site isn't worth the risk.

Five checks to run on your site now

Most fixes are settings changes, not rebuilds. The first three find what triggers the warning, and the last two keep HTTPS working once it's on.

1. Turn the setting on in your own browser. Open chrome://settings/security, switch on Always use secure connections, then click through your homepage, landing pages, forms and checkout. Google's Chrome team recommends this to website developers and IT teams.
2. Type every version of your address: http://yourdomain.com, http://www.yourdomain.com and each subdomain you use, such as shop or blog. Each one should end on an HTTPS page with a valid certificate. A certificate that covers www.yourdomain.com but not yourdomain.com still fails on the second address.
3. Follow your redirect chains. Chrome warns if any step on the way lacks HTTPS, not only the final page, so test link shorteners, ad click trackers, QR code services and the click-tracking domain your email platform uses.
4. Clear out mixed content. On an HTTPS page, browsers block scripts, stylesheets and iframes requested over http://, which can break forms, chat widgets and embedded videos. Change those addresses to https://, or send the Content-Security-Policy header with upgrade-insecure-requests.
5. Automate renewal, then add HSTS. Let your host or an ACME client such as Certbot renew certificates, because an expired certificate breaks HTTPS for everyone who visits. Once all your subdomains work over HTTPS, an HSTS header tells browsers to use only HTTPS for your domain. Add it last, since it removes the fallback to HTTP.

Step three catches sites that did everything else right. An online store can run on HTTPS for years and still trip the warning if its campaign emails go through a click-tracking domain that only works on plain HTTP. Subscribers who click meet a Chrome warning before they reach a secure product page. The store's site was never the problem.

Who needs to act, and who can relax

Sites that pass all five checks are done. The owners who should check this week run sites on old hosting plans, keep forgotten subdomains, or send paid and email traffic through tracking links that haven't been tested since setup.

Developers have one more case to cover. Private addresses are exempt, but internal tools on a public domain are not, so an HTTP-only admin panel at tools.yourcompany.com will warn each new user. Companies that need more time to migrate an internal site can allowlist it on staff browsers with the HttpAllowlist enterprise policy, or manage the whole setting with HttpsOnlyMode.

The cheapest test tool is the browser you already have. Switch the setting on today and Chrome will show you each page that still needs work. If you'd like the Techno Mantra team to check your domains and redirect chains for you, use the Get a Quote form on our contact page or email info@technomantraa.com.