Why does my website say "Not secure"? How to fix it, and Chrome's new warning

12 Oct 2026

Chrome puts "Not secure" next to your address, or a visitor sends you a picture of a warning page. It's almost always one of four addresses, and you can test all four in a minute.

When Chrome shows "Not secure" next to your website's address, the page was loaded over http://, not https://. The fix is a certificate on every address your site answers on (most hosts give them free) and a redirect from http:// to https://.

On 9 October 2026 I ran the four-address test from step 1 below on 200 small-business websites picked at random from a business directory: all four addresses of each, http:// and https://, with and without www. 198 answered. 158 passed, with every address ending on https://. The other 40 failed in five ways:

• 23 worked on https:// but left visitors on http:// when they typed the address without it.
• 6 had no working https:// on either name. Three certificates had expired, in 2019, 2022 and 2023. Three servers broke off the secure connection before sending any certificate.
• 5 had one of their two names missing from DNS, so that address led nowhere.
• 3 had a certificate for one name but not the other.
• 3 sent visitors who typed https:// back to http://.

"Not secure" used to be a cosmetic problem. Since Chrome 154, released on 22 September 2026, it can stop people at the door. Chrome now tries https:// first for every public site. If that fails, it shows a full-page warning and asks the visitor whether to carry on. Google calls this "Ask before HTTP".

Below: the three warnings and what each one means, a one-minute test of the four addresses your site has, and the fix for each kind of failure.

Three warnings, three causes

People say "my site says it's not secure" about three different things. Find yours first, because the fixes differ.

Google's help page puts the first one plainly: "The site doesn't use a private connection. Someone may be able to view and change the information you send and get through this site. To resolve this issue, the site owner must secure the site and your data with HTTPS." (Chrome Help)

The second is the new one. Chrome Help says that when "Always use secure connections" is on and a site doesn't support HTTPS, Chrome shows a "Connection is not secure" warning. Chromium's guide for site owners says it appears when "Chrome was unable to connect to a site via HTTPS but believes that it may be able to connect over HTTP." A visitor who clicks through isn't asked again for 15 days, and the 15 days restart each time they come back. So your regulars may see it once. New visitors, the ones who found you on a flyer or a search, see it first thing.

The third is a certificate error. It isn't new, and the guide says Chrome 154 doesn't change it. If that's yours, skip to step 2.

Step 1: test the four addresses your site answers on

Every site has four starting addresses: with and without www, each over http:// and https://. People reach all four. They type the bare name, scan an old QR code, or click a link someone wrote by hand years ago. All four have to end on your one real address.

On a Mac or Linux, open Terminal, put your own domain in place of example.com, and paste:

for u in http://example.com http://www.example.com https://example.com https://www.example.com; do
  printf '%s -> ' "$u"
  curl -sI -o /dev/null -w '%{http_code} %{redirect_url}\n' --max-time 10 "$u"
done

On Windows 10 or 11, open PowerShell and paste this instead (curl.exe ships with Windows):

foreach ($u in "http://example.com","http://www.example.com","https://example.com","https://www.example.com") {
  Write-Host -NoNewline "$u -> "
  curl.exe -sI -o NUL -w "%{http_code} %{redirect_url}`n" --max-time 10 $u
}

Here's what it printed for this site when I ran it:

http://taktekbot.com -> 301 https://taktekbot.com/
http://www.taktekbot.com -> 301 https://taktekbot.com/
https://taktekbot.com -> 200
https://www.taktekbot.com -> 301 https://taktekbot.com/

That's the shape you want: one address answers 200, and the other three send a 301 straight to it, each over https://. Here's how to read anything else:

• 200 on an http:// line: your site loads without encryption and never redirects. That's the "Not secure" label. Go to steps 2 and 3.
• 000 on an https:// line: nothing answered over https on that address, or the certificate doesn't cover it. That's the new full-page warning. Go to step 2. To see which it is, run curl -sSI -o /dev/null --max-time 10 https://example.com (on Windows, curl.exe and -o NUL). Read the line that starts curl: ( and a number. curl: (60) is a certificate problem: expired, or made for another name. curl: (7) or (28) means nothing answered on https at all. curl: (6) means the name doesn't exist in DNS, so check the spelling and your DNS records first. I got (60), (7) and (6) on a Mac, against badssl.com (a set of test sites built to fail), a closed port and a made-up name. (28) is curl's code for a timeout, from curl's error list. I haven't run these on Windows.
• A 301 that points back at the same address: a redirect loop. Browsers show "too many redirects". A common cause is a CDN such as Cloudflare in "Flexible" mode: it talks to your server over plain http, your server's own "redirect to https" rule fires on every request, and the visitor goes round in circles. Cloudflare's fix: set the encryption mode to Full or higher (your server needs its own certificate for that), or remove the redirect from your server and let Cloudflare do it.
• A 301 to an http:// address: the redirect goes the wrong way. Three sites in my sample sent https://example.com to http://www.example.com, even though https://www.example.com worked. Go to step 3.
• Two lines with 200: both names serve the full site. It works, but pick one and redirect the other to it, so search engines don't count two copies.
• A 302 or 307: it works, but it's a temporary redirect. Make it a 301 so search engines treat the move as permanent.

No terminal? Type each of the four addresses into Chrome's address bar by hand. Watch where you land and whether a warning page appears. Chrome hides https:// and www. in the address bar, so right-click it and tick Always show full URLs first. Do it in a Guest window (click your profile picture, then Guest): Chrome remembers a click-through on the warning, so your usual window may skip a warning that a new visitor still gets. It takes longer and shows less, but it catches the same failures.

Step 2: get a certificate that covers every name

A certificate is the file that lets your server answer on https://. It names the addresses it's valid for. A common gap is a certificate for www.example.com only, while the bare example.com redirects over plain http.

Chromium's guide uses exactly that case as its example. If your site lives on https://www.example.com, http://example.com redirects to http://www.example.com, and https://example.com doesn't work, "your users will see warnings when navigating to example.com." The page they end up on is fine. The step before it isn't.

The three one-name certificates in my sample were this gap the other way round. Two named only the bare domain, so https://www. failed. On the third, the www name pointed at the hosting platform, which answered with a certificate for the platform's own name instead of the site's.

Where to fix it depends on who runs the server:

• Shared hosting or a website builder: look in the domain or security settings for SSL, HTTPS or certificate. It's usually a switch. Make sure both names are listed: the bare domain and www. If only one is, add the other as a domain on the same site. If you're stuck, ask your host's support: "Does my certificate cover both example.com and www.example.com?"
• Domain forwarding at your registrar: if the bare name only "forwards" to your site, that forwarding service has to answer on https too. Many older ones don't. The Chromium guide says to ask the provider. If the bare name is a CNAME pointing at the provider, the guide says the provider should be able to get the certificate for you. If the answer is no, point the bare name at your real host instead and redirect it there.
• Your own server: Let's Encrypt issues certificates free. They're valid for 90 days, so renewal has to be automatic. Renewal is the part that breaks quietly: the three expired certificates in my sample had run out years earlier, and those sites were still up, serving plain http://. Apache, nginx and Caddy can now fetch and renew them themselves (the guide links each one). Mozilla's SSL Configuration Generator writes the server settings for you.

When the https:// lines in step 1 stop showing 000, this step is done.

Step 3: redirect every http address to https, in one hop

Now send all http:// traffic to the one real address with a 301. Hosts and builders often have a "Force HTTPS" or "Always use HTTPS" switch. Turn it on and run step 1 again.

On your own nginx, a server block like this catches both names on port 80. Change the target to your real host, with or without www, so there's no second hop:

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

On Apache, in the site's .htaccess or virtual host:

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

Then, and only then, think about HSTS. It's a header that tells browsers to never try http on your site again. The Chromium guide notes that with HSTS, Chrome doesn't fall back to http at all. That's good once everything works. It's painful if you turn it on while one name still has no certificate, because browsers remember the header. Leave it for a week after everything passes.

Step 4: if the page is on https but the padlock still looks wrong

Sometimes all four lines pass and a page still looks broken: no styling, a missing map, a contact form that warns as people type. That's mixed content: an https:// page asking for files at http:// addresses.

Browsers handle it in two ways. Images, audio and video get quietly upgraded to https://; if that fails, they don't load. Scripts, stylesheets, fonts and embedded frames are blocked outright (MDN). A form that sends to an http:// address gets a warning in Chrome (Chromium blog).

To find them, open the page in Chrome, right-click, choose Inspect, and open the Console tab. Each one is listed with the words "Mixed Content" and the address. Then fix the address in the place it comes from:

• In a theme or template: change http:// to https:// in the file. Most services that hand out embed code (maps, fonts, video) answer on https today.
• In WordPress posts and pages: first check Settings, then General. Both "WordPress Address (URL)" and "Site Address (URL)" should start with https://. Old links inside posts stay as they were written. With a backup taken first, WP-CLI rewrites them across the database, and --dry-run shows the count before anything changes:

  wp search-replace 'http://www.example.com' 'https://www.example.com' --dry-run

  Run it again without --dry-run when the count looks right.
• As a stopgap: the header Content-Security-Policy: upgrade-insecure-requests, or the same thing as a <meta http-equiv> tag, makes browsers request every file on the page over https (MDN). MDN warns that if a file isn't available over https, "the request will fail without any fallback to HTTP." It hides the problem until you fix the source. It doesn't remove it.

If you'd rather not read the console line by line, the free mixed content checker does it from the page source. Paste the source and it lists every http:// address, what browsers do with each one, and the fix. It runs in your browser and sends nothing you paste anywhere.

Step 5: change the links you printed and posted

Once step 1 passes, old http:// links work: they redirect cleanly over https. Still, every one of them is a hop that has to keep working. Update the ones you control when you next touch them:

• the website field in your Google Business Profile, Bing Places and any directory listing;
• social media bios and link pages;
• your email signature and invoice template;
• QR codes on the next print run of menus, cards and flyers.

If you send people through a link shortener or tracking link, test it too. The guide warns that each redirect step without https can show its own warning before the visitor reaches you.

What you don't need to worry about

• Your own setup at home or at the office. Chrome doesn't show the new warning for localhost, local IP addresses like 192.168.0.1, or single-word names like intranet/ (Chromium's guide and the Google Security Blog). A printer page or a router page won't start nagging staff.
• Other browsers. The guide says Safari, Firefox and Edge already try https first and have optional warnings of their own. A site that passes step 1 works in all of them.
• Paying for a certificate. For a business website, a free one does the same job. The padlock looks the same.

The checklist

1. All four addresses tested: one 200, three 301s, every target on https://.
2. The certificate names both the bare domain and www, and renews itself.
3. Every http:// address redirects in one hop to the real address.
4. No "Mixed Content" lines in Chrome's console on your main pages.
5. Profiles, bios, signatures and new QR codes point at https://.
6. HSTS only after a week of all of the above.

To see exactly what your visitors see, check that "Always use secure connections" is on at chrome://settings/security, then visit your site by its bare name. Chrome 154 turns it on by default, but if you changed the setting before, Chrome keeps your old choice, so yours may be off. Chromium's guide gives site owners the same advice: turn it on and go about your normal work.

taktekbot