Chrome HTTP warnings:audit your site in 15 minutes

Chrome is turning on its "Always Use Secure Connections" setting for public sites by default, so visitors who reach any part of your site over plain HTTP may get a full-page warning before the page loads. Google's post says Chrome 154 is releasing in October 2026, and that Chrome will ask for the user's permission before the first visit to any public site without HTTPS. The fix is usually not a new certificate: it is making sure every hostname and every redirect hop answers over HTTPS.

Here is the part that catches people out. You click your own old http:// link from a business card or an email signature, and Chrome shows a warning, even though your homepage has a valid padlock. Most of the time the culprit is one step in the middle of the redirect chain, like the bare domain that only exists to send people to www.

By the end of this guide you will have checked every hostname with two curl commands, fixed the certificates and redirects in your control panel, cleaned up WordPress and mixed content, and tested your site the way a Chrome visitor will see it.

What the Chrome HTTP warning actually is

Think of your site as a building with several front doors. Chrome tries the secure door first on each one, and if a door only opens the old way, it stops the visitor and asks before letting them in.

In technical terms, Chrome tries to upgrade every http:// address to https://. According to the Chromium adoption guide, the warning appears when Chrome cannot connect over HTTPS but thinks the site may still work over HTTP. If a visitor clicks "continue", Chrome remembers that choice for 15 days, and the 15 days restart each time they come back.

At the time of writing (19 October 2026), here is where things stand, based on Google's announcement of 28 October 2025:

• Google's post says Chrome 147, releasing in April 2026, enables the public-sites version of the setting for people who opted in to Enhanced Safe Browsing.
• Google's post says Chrome 154 is releasing in October 2026 and turns it on by default for everyone else.
• Private sites are left out by default. That means local addresses such as 192.168.0.1 and single-label names such as intranet.
• Visitors can still switch the setting off at chrome://settings/security.

Google says that in its experiment the median user saw fewer than one warning per week, and the user at the 95th percentile saw fewer than three. Rare warnings get noticed.

Why this matters: a warning on your own link looks like a security problem to a customer, even when the real issue is one forgotten redirect.

Before you start

Run through this list first.

• Access: your hosting control panel login (cPanel or similar), and access to your DNS if it lives somewhere else, such as your domain registrar.
• Backup: a fresh backup of your files and database, especially if you run WordPress. Most control panels have a backup tool, and WP-CLI can export a copy of the changes it would make.
• Time window: about 15 minutes for the audit, plus up to an hour if certificates need to be issued or WordPress needs a URL update. Pick a quiet time of day.
• Risk level: the checks in Steps 1, 2 and 7 are read-only and safe. Steps 3 to 6 change live settings, so do them one at a time and recheck after each.
• Tools: a terminal with curl installed and the Chrome browser.

The 15-minute audit

List every way people reach your site, follow each one hop by hop, and fix any hop that is plain HTTP or has a broken certificate.

Step 1: List every hostname visitors use

A hostname is the full name in front of your domain, such as www.example.com or shop.example.com. Chrome checks each one on its own, so your list needs to cover them all.

Write down every version people might type or click:

• example.com (the bare domain, also called the apex)
• www.example.com
• blog.example.com
• shop.example.com
• any addon or parked domains that point to the same site

Quick tip: in cPanel, the Domains page lists the domains on the account in one table. Scan it to catch the ones you forgot about.

Step 2: Follow each redirect chain with curl

curl is a small command-line tool that fetches a web address and shows you what the server sends back. A redirect chain is the list of hops a browser makes, for example from http://example.com to https://example.com to https://www.example.com.

The first command fetches only the response headers for each hop and follows every redirect until it reaches the final page:

curl -sIL http://example.com

You will see one block of headers per hop. Look at the first line of each block (the status code) and the Location: line (where it sends you next). A healthy result looks something like this:

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

HTTP/2 301
location: https://www.example.com/

HTTP/2 200

The second command gives you a compact one-line summary: the final URL, how many redirects it took, and the final status code:

curl -s -o /dev/null -L -w "%{url_effective} %{num_redirects} %{response_code}\n" http://example.com

Good output looks like this:

https://www.example.com/ 2 200

Here is what each part means:

• url_effective is the last URL curl fetched. It must start with https://.
• num_redirects is how many hops it took. One or two is normal. Five is a sign of a messy chain.
• response_code is the final status. You want 200.

Now repeat both commands for every hostname on your list, and for both the http:// and https:// versions. Here is the loop for the HTTP versions, which saves typing:

for h in example.com www.example.com blog.example.com shop.example.com; do curl -s -o /dev/null -L -w "$h -> %{url_effective} %{num_redirects} %{response_code}\n" "http://$h"; done

Then check each one directly over HTTPS, because Chrome will try that first. This prints only the status code, and an error if the certificate is bad:

curl -sS -o /dev/null -w "%{response_code}\n" https://example.com

Heads up: the Chromium guide gives this exact example: if http://example.com redirects to www.example.com, the bare example.com still needs a working HTTPS certificate, or Chrome warns before the redirect even happens.

Made-up example: Priya's bakery site at www.example.com has a valid certificate, but her bare domain example.com only forwards to www and never got one. Customers who type the short name see a Chrome warning, and the curl -sS check on https://example.com shows a certificate error.

Note that curl does not follow meta refresh or JavaScript redirects. If curl ends at 200 but the browser moves on, that extra hop is inside the page.

Step 3: Fix certificates in SSL/TLS Status

A TLS certificate (often called an SSL certificate) proves your site is really yours and lets the browser connect over HTTPS. cPanel's AutoSSL issues certificates for your domains automatically.

In cPanel, open the SSL/TLS Status page. You will see your domains with their certificate state.

1. Click Run AutoSSL. The page reloads when the run finishes.
2. Use the status filter and pick Unsecured. Anything listed here has no certificate.
3. Switch the filter to Has AutoSSL Problems to see domains where AutoSSL ran into trouble.
4. Check Expiring Soon too, so nothing lapses next week.

One common reason a domain shows up under Has AutoSSL Problems is that it does not point to your server. cPanel's own example is a domain that does not resolve to a public IPv4 address. Fix the DNS record first, then run AutoSSL again.

Another blocker is a CAA record, a DNS record that says which certificate authorities may issue certificates for your domain. If your CAA records do not allow the authority your host uses, issuance fails. Our guide on adding CAA records in cPanel shows how to check and fix them.

Step 4: Turn on Force HTTPS Redirect

Once every hostname has a certificate, make the server send HTTP visitors to HTTPS automatically.

In cPanel, open the Domains page. Each main domain in the table has a Force HTTPS Redirect toggle. Switch it on for every main domain you want to secure. To do several at once, tick their checkboxes and click Force HTTPS Redirect On at the top of the table.

Heads up: cPanel only lets you turn this on for a main domain that already has a valid certificate, which is why Step 3 comes first. The toggle does not appear for aliases (parked domains), so those need their own redirect.

If the toggle is missing or your host uses a different panel, add the redirect yourself with the rules in redirecting HTTP to HTTPS with .htaccess.

Why this matters: Chrome tries HTTPS on each hostname before it ever sees your redirect, so the redirect only helps once the certificate is in place.

Step 5: Move WordPress to HTTPS

WordPress stores its own address, plus full URLs inside posts, menus and widgets, in the database. If those still say http://, the site keeps producing HTTP links and mixed content.

First, update the two address fields. In your WordPress dashboard, go to Settings » General and change both WordPress Address (URL) and Site Address (URL) to the https:// version. Include https:// and leave off the trailing slash.

Next, update old links stored in the database with WP-CLI, the command-line tool for WordPress. Start with a dry run, which shows a report of what would change but saves nothing:

wp search-replace 'http://example.com' 'https://example.com' --skip-columns=guid --dry-run

The --skip-columns=guid part matters. The guid column is a permanent ID for each post, and WordPress documentation says never to change it, because feed readers can show old posts as new.

Next, save a review copy. The --export option writes the transformed data to a SQL file instead of changing the database:

wp search-replace 'http://example.com' 'https://example.com' --skip-columns=guid --export=https-update.sql

When the dry run report looks right and you have your full backup, run the command without --dry-run or --export:

wp search-replace 'http://example.com' 'https://example.com' --skip-columns=guid

Quick tip: if your site uses www, run it again for http://www.example.com. If the report shows trouble with serialized data from page builders, add --precise. It is slower but handles complex data more reliably.

Finally, force the admin area and logins onto HTTPS. This line goes in wp-config.php, not in a plugin file:

define( 'FORCE_SSL_ADMIN', true );

You may still see FORCE_SSL_LOGIN in old tutorials. It was deprecated in WordPress 4.0, so use FORCE_SSL_ADMIN instead.

Step 6: Find and fix mixed content

Mixed content is when an HTTPS page loads something, like an image or a script, over plain HTTP.

According to MDN, modern browsers handle this in two ways:

• Upgraded automatically: images set with src, audio and video. The browser quietly tries HTTPS instead.
• Blocked: scripts, stylesheets, iframes, fetch() and XMLHttpRequest requests, web fonts, and images loaded through srcset or <picture>.

Blocked content is the dangerous kind, because a blocked stylesheet or script can break your layout or checkout.

To find it, open the page in Chrome, open DevTools, and click the Console tab. The console shows a warning for each item that was upgraded or blocked. Click through your homepage, a blog post, your contact form and your checkout.

Fix each one at the source by changing the URL to https:// in the theme, plugin setting, widget or post. If a third-party service has no HTTPS at all, replace it.

As a stopgap while you clean up, you can send this header, which tells the browser to treat every http:// URL on your site as https://:

Content-Security-Policy: upgrade-insecure-requests

Heads up: this only helps when the resource is actually available over HTTPS. If it is not, MDN says the request simply fails, with no fallback to HTTP. It also does not upgrade links to other sites, and it does not protect people arriving from old links elsewhere.

Step 7: Test as a Chrome visitor

Open chrome://settings/security in Chrome and turn on Always Use Secure Connections. Google's post very strongly recommends enabling this setting now so site owners can find sites that still rely on HTTP.

Then type each http:// address from your Step 1 list into the address bar, and click old HTTP links you control, such as email signatures and social profiles.

What you should see: each one lands on your site with a padlock and no warning page. If a warning appears, go back to Step 2 for that hostname.

Quick tip: if you clicked through a warning earlier, Chrome remembers that choice for 15 days and renews it each time you revisit, so a quiet result may not prove anything. Test from a browser profile that never saw the warning, or test again after 15 days away from the site, to be sure the fix is real.

To compare with the old behaviour, the Chromium guide lists the flag --disable-features=HttpsFirstBalancedModeAutoEnable. Companies can control the setting with the enterprise policies HttpsOnlyMode and HttpAllowlist.

Step 8 (optional): Add HSTS once everything works

HSTS (HTTP Strict Transport Security) is a response header that tells browsers "only ever use HTTPS for this site". The Chromium guide notes that sites with HSTS never fall back to HTTP, so the warning does not apply to them.

That is also the risk. A browser keeps the HSTS rule until it expires, and you cannot switch it off over plain HTTP. If you add includeSubDomains, any subdomain that only works over HTTP becomes unreachable.

So start small. Set a short max-age (the number of seconds the browser remembers the rule), such as one day, and raise it only after a week or two of clean tests. Our HSTS and security headers guide has the exact header lines.

How to check it worked

Run these after all your changes:

1. For every hostname, curl -s -o /dev/null -L -w "%{url_effective} %{num_redirects} %{response_code}\n" http://HOSTNAME ends with an https:// URL and 200.
2. For every hostname, curl -sS -o /dev/null -w "%{response_code}\n" https://HOSTNAME prints a status code with no error line above it.
3. In SSL/TLS Status, the Unsecured and Has AutoSSL Problems filters show nothing you care about.
4. In Domains, Force HTTPS Redirect is on for every main domain.
5. In the WordPress dashboard, both address fields under Settings » General start with https://.
6. The Chrome Console shows no mixed content warnings on your key pages.
7. With Always Use Secure Connections on, typing each http:// address in a browser profile that never approved a warning loads the site without one.

Troubleshooting

The curl HTTPS check fails with error 60

Symptom: the command prints an error starting with curl: (60). The curl documentation describes this code as "The remote server's SSL certificate or SSH fingerprint was deemed not OK."

Likely cause: that hostname has no certificate, an expired one, or a certificate that covers a different name.

Fix: run AutoSSL in SSL/TLS Status and check whether the hostname appears under Unsecured or Has AutoSSL Problems.

curl stops with error 47 or the browser says too many redirects

Symptom: curl: (47) in the terminal, which curl describes as "Too many redirects". In the browser, the page never loads.

Likely cause: two rules fight each other, for example a host-level HTTPS redirect plus a plugin redirect, or WordPress behind a proxy that does not tell it the visitor used HTTPS.

Fix: keep only one HTTPS redirect. If your site sits behind a reverse proxy or CDN, WordPress documentation explains that FORCE_SSL_ADMIN can cause an endless loop unless WordPress reads the HTTP_X_FORWARDED_PROTO header. Ask your host or developer to confirm the proxy sends it.

curl says it could not resolve the host

Symptom: curl: (6), which curl describes as "Could not resolve host".

Likely cause: the hostname has no DNS record, or it was deleted or mistyped.

Fix: add an A record (or AAAA record for IPv6) pointing to your server, such as 192.0.2.10, then wait for DNS to update before running AutoSSL again.

The Force HTTPS Redirect toggle is missing

Symptom: some domains on the Domains page have no Force HTTPS Redirect toggle.

Likely cause: the domain is an alias, or it does not have a valid certificate yet. cPanel only allows the toggle on a main domain with a valid certificate.

Fix: finish Step 3 first. For aliases, use a redirect rule as described in our .htaccess redirect guide.

The layout breaks after the switch

Symptom: the page loads over HTTPS, but styles, fonts or scripts are missing, or a form stops working.

Likely cause: mixed content. Blocked stylesheets, scripts or fonts are still loading over http://.

Fix: open the Console in DevTools, note each blocked URL, and update it to https:// at the source. Rerun the WP-CLI search-replace dry run to find stored URLs you missed.

The warning still appears after you fixed everything

Symptom: Chrome still shows the warning on an http:// link, even though curl looks clean.

Likely cause: a hop in the chain you have not tested, often a redirect from another domain or an old marketing short link, or a redirect done with JavaScript that curl does not follow.

Fix: open DevTools, go to the Network tab, and load the http:// link. The Chromium guide recommends this to inspect each redirect hop. Find the first hop that is still HTTP-only.

Pro tips and security notes

Quick tip: save your hostname list and the curl loop in a text file, and rerun it whenever you add a subdomain or change hosts.

A certificate that quietly fails to renew turns into a Chrome warning on that hostname. Our guide on Let's Encrypt 64-day certificates covers how to keep an eye on renewals.

Heads up: an HTTPS DNS record, also called an HTTPS RR, is another way to tell browsers your site supports HTTPS, according to the Chromium guide. It is worth asking your DNS provider about, but fix the redirect chain first.

The one message worth forwarding

If someone else manages your site or hosting, send them this:

Hi, Chrome is turning on HTTPS warnings by default for public sites. Could you please check that every hostname we use (example.com, www.example.com, and any subdomains) has a valid certificate and redirects to HTTPS on every hop, including the bare domain? Please also turn on Force HTTPS Redirect for each main domain, fix any mixed content in the browser console, and confirm WordPress uses https:// in Settings > General. A quick test is: curl -s -o /dev/null -L -w "%{url_effective} %{num_redirects} %{response_code}\n" http://example.com should end in an https:// URL and 200. Thanks!

If every hostname and every hop answers over HTTPS with a valid certificate, Chrome has nothing to warn your visitors about.