Google's Chrome HTTP Warning: Make Your Site HTTPS-Ready

If your site already loads on HTTPS, Chrome 154 will mostly leave it alone. The catch is every address a visitor might pass through on the way there, including the bare domain, old campaign links and forwarding services, which must also answer on HTTPS, or Chrome will ask the visitor for permission first.

Here is the part that surprises people. Google says Chrome 154, planned for October 2026, turns on "Always Use Secure Connections" by default, and Chromium's own guide says a single HTTP step in a redirect chain is enough to show the warning, even when the visitor ends up on a perfectly good HTTPS page.

By the end of this guide you will be able to find every URL that triggers the warning, list each redirect hop with curl, fix the weak hops in cPanel or at your DNS and forwarding provider, and prove the fix worked.

What "Always Use Secure Connections" actually is

"Always Use Secure Connections" is a Chrome setting that tries every site over HTTPS first. If HTTPS fails and Chrome thinks plain HTTP might work, it stops and asks the visitor before loading the HTTP version.

Google's Chrome Security team announced the change on 28 October 2025. In their words, Chrome "will ask for the user's permission before the first access to any public site without HTTPS." At the time of writing (31 October 2026), I have not confirmed the exact day Chrome 154 reached every user, so treat the rollout as in progress rather than finished.

Think of it like a building with a front door and a side door. Most guests walk in through the front door (HTTPS). Chrome now wants to know about every guest who comes in through the open side door (HTTP), even if that side door only leads to a hallway that takes them straight to the front.

A few details from Google and Chromium shape what you need to fix:

• The default is the "public sites" version. Private sites such as local IP addresses like 192.168.0.1, single-label hostnames and shortlinks like intranet/ do not get the warning.
• Chrome warns only on a new or not recently visited site. Google's post says that if a user regularly visits an insecure site, Chrome will not keep warning about it.
• Chromium's guide says Chrome remembers a user's decision for 15 days, and the exception renews each time they come back.
• If a visitor clicks or types an address that starts with https:// and it fails, they get a normal network error page. Chrome does not fall back to HTTP.
• If your site uses HSTS (a header that tells browsers "only ever use HTTPS here"), Chrome does not fall back to HTTP either.
• The warning can be clicked through. It is a prompt, not a block.

Why this matters: the visitors most likely to see the prompt are new ones, the very people you are trying to win over.

Google's post also planned an earlier step: Chrome 147, scheduled for April 2026, would turn on the public-sites version for users who opted in to Enhanced Safe Browsing. So some of your visitors may have met this prompt before Chrome 154.

Before you start

Gather these before you change anything:

• A computer with Chrome installed, and a terminal where the curl command works.
• Your hosting control panel login, for example cPanel.
• Your DNS provider login, and your registrar login if you use domain forwarding there.
• A list of every hostname you own that people might type or click: example.com, www.example.com, old shop or blog subdomains, short campaign domains.
• A backup of any file you will edit, such as .htaccess, before you touch it.
• Time: about 30 to 60 minutes for a single site with a couple of hostnames.
• Risk level: low for testing, medium for redirect changes. A wrong redirect rule can take a site offline or create a loop, so change one thing at a time and test after each change.

Quick tip: do the testing part first. It changes nothing on your server, and it often shows that only one hostname needs work.

Find and fix every HTTP hop

Step 1: Turn on the setting in your own Chrome

Chromium's guide recommends that site owners turn the setting on themselves to find problems early. On a desktop computer, type this into the address bar and press Enter:

chrome://settings/security

Find Always Use Secure Connections on that page and turn it on, choosing the public sites option. On Android, Google's help page puts it under the three-dot menu, then Settings > Privacy and security, then Always use secure connections under "Security", with the option Warns you for insecure public sites.

You should see the setting switched on. If you had set it before, Chromium says Chrome keeps your earlier choice, so check that it is really on.

Heads up: because Chrome remembers a decision for 15 days, clicking through a warning during testing hides it on your next test. My own habit is to test in a fresh Chrome profile with no history, so every test is a first visit.

Step 2: Test every way people reach your site

Type each of these into Chrome, one at a time, without the https:// part where shown. Typing the bare name lets Chrome try HTTPS first, which is what a real visitor does.

example.com
www.example.com
http://example.com
http://www.example.com

Then click a few real inbound links: the link in your email signature, a QR code, an ad, a link in an old newsletter.

Each time the warning appears, write down the exact address shown. If a test loads your site with no prompt, that path is already fine.

Step 3: List the redirect chain with curl

Chrome tells you that something failed. curl tells you which hop failed. The -I option asks for headers only, -L follows each redirect, and the curl manual says that when -L is used with --head, headers from every page in the chain are shown.

This command prints the status line and the Location header (where the server sends you next) for each hop, starting from plain HTTP:

curl -sSIL http://example.com | grep -iE '^(HTTP/|location:)'

A healthy chain looks like this, with every Location starting with https://:

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

Now test all four common variants in one go. This loop runs the same check for each address and prints a header line so you can tell them apart:

for url in http://example.com http://www.example.com https://example.com https://www.example.com; do
  echo "== $url"
  curl -sSIL --max-redirs 10 "$url" | grep -iE '^(HTTP/|location:)'
done

The --max-redirs 10 part stops curl from following a loop forever. -s hides the progress meter, and -S still shows an error if something fails.

What to look for:

• Any Location: line that starts with http:// is an insecure hop.
• Any https:// variant that prints a curl error instead of a status line means that host has no working HTTPS, usually a missing or invalid certificate.

Step 4: Check each HTTPS host on its own

This is the step that catches the classic apex problem. Chromium's guide gives this exact example: the site lives at https://www.example.com, the bare example.com has no HTTPS, so visitors who type example.com see the warning.

This command connects to one HTTPS address without following redirects, and prints the status code, the certificate check result and where the redirect would go:

curl -sS -o /dev/null -w 'code: %{http_code}  cert: %{ssl_verify_result}  next: %{redirect_url}\n' https://example.com/

According to the curl manual, ssl_verify_result is 0 when certificate verification succeeds, and redirect_url shows where a redirect would have gone. A good result for an apex that forwards to www looks like this:

code: 301  cert: 0  next: https://www.example.com/

Repeat it for https://www.example.com/ and every other hostname. A curl error instead of that line means the host is not ready for HTTPS.

Made-up example: Priya runs a small bakery site at www.example.com. Her printed menus say "example.com". The www site has a certificate, but the bare domain was only ever set up as an HTTP redirect at her registrar. Step 3 shows http://example.com returning a 301, and Step 4 shows https://example.com/ failing with a curl error. That one missing certificate is the only reason new customers scanning her menu QR code would see Chrome's prompt.

Step 5: Get a valid certificate on every hostname (cPanel)

If a hostname failed Step 4, it needs a certificate. In cPanel, go to cPanel > Security > SSL/TLS Status. On some servers this appears as a tab inside the SSL/TLS Certificates interface instead.

Click Show Unsecured Domains to list domains without a certificate. The filter next to the search box also lets you set SSL Statuses to Expired, Expiring Soon or Has AutoSSL Problems.

Check that both example.com and www.example.com appear as secured. The Domain Types filter has a www and mail domain option if you want to see the www entries on their own.

The Certificate Status column shows certificate details, when AutoSSL (cPanel's free automatic certificate tool) last ran for that domain, and any AutoSSL errors. Read that error before doing anything else: it usually tells you what blocked the certificate.

You should end with every hostname you listed showing a valid certificate. If a domain says Has AutoSSL Problems and the error makes no sense to you, send the exact error text to your host.

Step 6: Make the redirect go straight to HTTPS

Once every host has a certificate, make sure each redirect points to an https:// address.

In cPanel, go to cPanel > Domains > Domains. In the domain list, set the Force HTTPS Redirect toggle to On. The cPanel docs say you can only turn this on for a Main Domain that has a valid SSL certificate, and the toggle does not appear for aliases.

For other redirects, such as apex to www, cPanel's docs point to cPanel > Domains > Redirects. When you add or edit a redirect there, make sure the target address starts with https://.

If you manage redirects in .htaccess instead, follow my step-by-step guide to redirect HTTP to HTTPS using .htaccess. Back up the file first, and keep the target of every rule on https://.

If your site sits behind Cloudflare, check the SSL mode before you add more redirect rules. A mismatch between Cloudflare and your server can cause redirect loops, and this guide on Cloudflare SSL mode Full (strict) without redirect loops walks through it.

After this step, rerun the Step 3 loop. Every Location: line should start with https://.

Step 7: Fix domain forwarding and campaign links

Domain forwarding means a service, often your registrar, redirects one domain to another without you hosting anything on that domain.

Chromium's guide says to contact your forwarding provider and ask whether they support HTTPS and whether extra setup is needed. It also says that if the inbound domain is a CNAME to the provider (a DNS record that points one name at another), the provider should be able to get certificates for you.

For every forwarded domain on your list:

1. Run the Step 4 command on its https:// address.
2. If it fails, check your provider's settings for an HTTPS or SSL option on forwarding.
3. If there is none, either move the redirect to your own hosting, where you control the certificate, or ask the provider for HTTPS support.

Then update links you control so they start with https://: email templates, ad destinations, QR code targets, social bios and link shorteners.

Quick tip: QR codes printed on paper cannot be changed. If an old one points to an HTTP address, make sure that hostname has a certificate so Chrome's HTTPS attempt succeeds.

Step 8: Add HSTS only after HTTPS is stable (optional)

HSTS (HTTP Strict Transport Security) is a response header that tells browsers to use HTTPS for your site from now on. RFC 6797 defines it. The basic form looks like this:

Strict-Transport-Security: max-age=31536000

max-age is the number of seconds the browser remembers the rule, and 31536000 is one year. The optional includeSubDomains directive extends the rule to every subdomain.

Two rules from the RFC matter in practice. A server must not send this header over plain HTTP, and a browser must ignore it if it arrives over plain HTTP. So the header belongs on your HTTPS responses only.

My own advice, not something the RFC says: start with a short value such as max-age=300 (five minutes) for a few days, check that nothing breaks, then raise it. Add includeSubDomains only when you are sure every subdomain, including old ones, works on HTTPS. A long HSTS value is hard to undo, because browsers keep it until it expires.

To add the header on Apache or Nginx and confirm it is being sent, use this guide to check security headers on Apache and Nginx.

How to check it worked

Run these checks after every change, and once more when you think you are finished.

First, this command follows the full chain from plain HTTP and prints where you ended up, the final status and how many redirects it took:

curl -sSL -o /dev/null -w 'final: %{url_effective}  code: %{response_code}  hops: %{num_redirects}\n' http://example.com/

You should see something like this, with your real canonical address and one or two hops:

final: https://www.example.com/  code: 200  hops: 1

Second, rerun the Step 3 loop for all four variants. Every Location: line should begin with https://, and every https:// variant should return a status line, not a curl error.

Third, if you added HSTS, check that it appears on HTTPS:

curl -sSI https://www.example.com/ | grep -i strict-transport-security

You should see your Strict-Transport-Security line. Then confirm it is not sent over HTTP, which should print nothing:

curl -sSI http://example.com/ | grep -i strict-transport-security

Fourth, test in the browser. In a fresh Chrome profile with Always Use Secure Connections turned on, type each variant from Step 2 and click your main inbound links. No prompt should appear.

For a hop-by-hop view, open Chrome DevTools, go to the Network panel and load example.com, as Chromium's guide suggests. Every request should use https://.

Troubleshooting

The warning shows for example.com but www.example.com is fine

Symptom: typing example.com shows the prompt, while www.example.com loads with no prompt.

Cause: the bare domain has no working HTTPS. This is the exact case in Chromium's guide.

Fix: get a certificate covering example.com (Step 5), then confirm https://example.com/ returns a 301 to https://www.example.com/ with cert: 0 in the Step 4 command.

curl shows a Location header that starts with http://

Symptom: in the Step 3 output you see a line like Location: http://www.example.com/, even when the request started on HTTPS.

Cause: a redirect rule, a cPanel redirect or an app setting writes the target as http://.

Fix: change the target to https://, then rerun the Step 3 loop. If the bad hop comes from your application, update its own site URL setting too.

The Force HTTPS Redirect toggle is missing in cPanel

Symptom: you open cPanel > Domains > Domains and there is no Force HTTPS Redirect toggle for the domain you want.

Cause: according to cPanel's docs, the toggle does not appear for aliases, and it can only be enabled on a Main Domain with a valid certificate.

Fix: get the certificate first (Step 5). For aliases or other domains, use cPanel > Domains > Redirects or .htaccess. If you still cannot enable it, cPanel's docs say to contact your hosting provider.

SSL/TLS Status shows Expired or Has AutoSSL Problems

Symptom: a hostname appears under Expired, Expiring Soon or Has AutoSSL Problems in cPanel > Security > SSL/TLS Status.

Cause: AutoSSL could not issue or renew the certificate for that name.

Fix: read the AutoSSL error in the Certificate Status column and fix what it names. If you cannot tell what it means, send the exact text to your host. Then repeat the Step 4 check.

Visitors see two warnings in a row

Symptom: someone clicks a link in your newsletter and Chrome asks twice before they reach your site.

Cause: the link passes through more than one HTTP hop, for example an HTTP click tracker and then your HTTP apex. Chromium's guide says multiple insecure redirects can cause multiple warnings.

Fix: run the Step 3 command on the full tracking link to see every hop. Switch the tracker to HTTPS and fix your own hops.

An https:// link shows an error page instead of the warning

Symptom: a link that starts with https:// shows a normal network error page, and there is no option to continue over HTTP.

Cause: this is expected. Chromium's guide says Chrome does not fall back to HTTP when someone goes to an https:// address directly, or when the site uses HSTS.

Fix: this means that host has no working HTTPS. Fix its certificate (Step 5). Do not remove HSTS just to get the warning back.

The page keeps redirecting and never loads

Symptom: the page never finishes loading and Chrome shows a redirect error page, or curl stops after reaching the --max-redirs limit.

Cause: two redirect rules send traffic back and forth, often HTTP at one layer and HTTPS at another, such as a CDN and your server disagreeing.

Fix: remove one of the duplicate rules. If you use Cloudflare, check the SSL mode with the Cloudflare Full (strict) guide.

A note for offices and managed browsers

If you manage Chrome for a company or school, Chromium documents two enterprise policies. HttpAllowlist lets listed hostnames load over HTTP without the warning. HttpsOnlyMode lets you enforce the setting, for example with force_balanced_enabled for the new default or force_enabled for a strict mode that also warns on private sites. Use them for internal tools you cannot move yet, and fix public sites properly instead.

When to ask your host or a developer

Ask for help if a hostname will not get a certificate, your forwarding provider has no HTTPS option, or redirects come from an app you did not build. Send them the Step 3 loop output: it shows the exact hop that fails.

The one message worth forwarding

Copy this, replace the example names with yours, and send it to whoever looks after your site:

Hi, Chrome now asks visitors for permission before loading any public page over plain HTTP, including redirect hops. Can you confirm that example.com, www.example.com and any forwarded or campaign domains all have a valid HTTPS certificate, and that every redirect points to an https:// address? This command should show only https:// in each Location line: curl -sSIL http://example.com | grep -iE '^(HTTP/|location:)'. Please hold off on HSTS until this is confirmed.

Every hostname a visitor can touch needs to answer on HTTPS, so fix the bare domain and the forwarding links before you worry about anything else.