Chrome Warns Before HTTP Sites: Check and Fix Yours Now

What changed

Chrome 154, released in October 2026, turns on a setting called Always Use Secure Connections for everyone. With it on, Chrome tries every navigation over HTTPS first. If a public site cannot be reached over HTTPS, Chrome shows a warning page before loading it, and the visitor has to choose to continue.

It was already on, since Chrome 147 in April 2026, for people who had opted into Enhanced Safe Browsing. October is when it reaches everyone else.

Three details from Google’s announcement decide who notices:

• Private sites are excluded in the default setting: local IP addresses, single-label hostnames (http://intranet) and corporate intranets get no warning.
• Regular visits are not warned repeatedly. Chrome warns when someone opens a site without HTTPS that they have not visited recently. The people who see it are first-time and occasional visitors — the ones a landing page, a campaign link or a QR code is meant for.
• It can be bypassed and turned off. That does not make it harmless. A warning screen between a visitor and your page is a lost visitor more often than not.

None of this is about mixed content, an HTTPS page that loads some http:// images or scripts. That is a separate problem with its own browser behaviour; see mixed content.

Who is affected

Any public address someone can type, tap or scan that ends up on plain HTTP:

• a site that has no HTTPS at all;
• a site where HTTPS exists but http:// does not redirect to it, and people arrive on the http:// form from old links, printed material, QR codes or email signatures;
• a subdomain nobody thought about: an old campaign site, a status page, a booking system, a vendor portal on your name;
• a device or appliance with a public address and its own web interface;
• a site whose HTTPS is broken, for example by an expired certificate. Fix that first; it fails on its own merits regardless of this change (expired certificates).

Check your sites now

1. See where http:// goes

curl -sI http://example.com/ | head -5

What you want is a redirect to the HTTPS address:

HTTP/1.1 301 Moved Permanently
Location: https://example.com/

A 200 OK here means the site serves its pages over plain HTTP. If the Location points to another http:// address, follow the chain with curl -sIL and check where it ends. Do this for the bare domain and for www, and for every hostname that appears in your links.

The HTTP check follows the whole redirect chain and flags a site whose final page is plain HTTP.

2. Confirm HTTPS actually works

curl -sI https://example.com/ | head -3
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -enddate

A certificate for the right name, not expired, from a CA browsers trust. The SSL check reads the certificate over a real connection and checks the chain.

3. Find the hosts you forgot

The forgotten subdomain is the usual surprise. Every publicly trusted certificate ever issued for your names is in Certificate Transparency logs, so the logs list subdomains you may not remember. The exposed admin page check finds subdomains in those logs, opens each one once from outside and marks the ones that answer only over HTTP.

4. Turn the setting on yourself

Google’s own advice to site owners is to enable it in your browser today and see what breaks. In Chrome it is under Settings → Privacy and security → Security → “Always use secure connections”. Then go through your own sites, your links and your QR codes the way a visitor would.

Fix it

Get a certificate

Most hosting control panels issue a free certificate in a few clicks. On your own server, Let’s Encrypt with certbot:

sudo certbot --nginx -d example.com -d www.example.com

Behind a CDN, the CDN usually issues the visitor-facing certificate; make sure the connection from the CDN to your server is HTTPS as well.

Redirect HTTP to HTTPS

nginx:

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

Apache (.htaccess or the :80 virtual host):

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Use a permanent (301) redirect that keeps the path, so an old link to http://example.com/booking lands on the same page over HTTPS, not on the home page (301 vs 302). If the site sits behind a proxy or CDN and the redirect loops, the proxy is talking to your server over HTTP; see redirect loops.

Fix what still says http://

• Links, canonical tags and sitemaps on the site itself.
• Forms whose action points to an http:// address.
• Email templates, signatures, printed material and QR codes. A QR code cannot be edited, so keep the redirect for as long as the printed material exists.

Then make browsers remember

Once HTTPS works everywhere, send a Strict-Transport-Security header so browsers stop trying HTTP at all for your site. Start with a short max-age and raise it once you are sure every subdomain works over HTTPS; read the HSTS checklist before adding includeSubDomains or preload.

When you can’t move a host to HTTPS yet

An old device or a third-party system you don’t control may not support HTTPS. Then the honest choices are:

• put it behind a reverse proxy or CDN that terminates HTTPS for it;
• take it off the public internet and reach it over a VPN at a private IP address or an internal name, which the default setting does not warn about;
• or retire it.

Leaving it public on HTTP means every new visitor meets a warning screen first.

Check your own domain now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.

Diagnose