Why does my website say "Not secure"? How to fix it

What the "Not secure" and "Your connection is not private" warnings mean, their six usual causes, and how to fix each on any host or WordPress site.

You open your own website and the address bar says Not secure. Or worse, visitors get a full-page warning, Your connection is not private, and have to click through a scary button to reach you. Most people leave at that point, and some will message you to ask whether your site has been hacked.

In almost every case it has not. Both warnings are about the site's SSL certificate, the file that lets a browser load a page over encrypted https://. Either the certificate is missing, it is not being used, or something about it does not match. This guide shows how to tell which, and how to fix each cause.

Two different warnings, two different problems

Click the icon to the left of the address to see the browser's own explanation. On the full-page warning, the small error code under the message (for example NET::ERR_CERT_DATE_INVALID) tells you exactly which cause you are dealing with, and the sections below are named after them.

1. There is no certificate at all

If https://yourdomain.com does not load, or shows a certificate for your hosting company's server name instead of your domain, no certificate has been issued for your site yet. On most hosting this is free and automatic. On cPanel hosting, look for SSL/TLS Status and click Run AutoSSL. Other control panels have an equivalent "Let's Encrypt" or "free SSL" switch.

AutoSSL can only issue a certificate when your domain already points at that server, because the certificate authority checks it by visiting your domain. If you have just moved your site or changed nameservers, wait until the change is visible everywhere (see why DNS changes take time to show) and run it again. Every Serverlys shared hosting plan includes a free certificate that is issued and renewed automatically, and our free SSL setup guide walks through it step by step.

2. The certificate exists, but visitors land on http://

This is the most common cause of the "Not secure" label. Type https:// in front of your domain: if the padlock appears, the certificate is fine and the site simply is not redirecting people to it. Anyone who types your domain without https://, or follows an old link, gets the plain version.

The fix is a permanent (301) redirect from every http:// address to its https:// twin. Many control panels have a Force HTTPS toggle in the domain settings; use that if you have it. On Apache or LiteSpeed hosting without one, add these lines near the top of the .htaccess file in your site's root folder:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [L,R=301]

Take a copy of .htaccess before editing it, so you can put it back in one step if the site stops loading. More redirect patterns are in our .htaccess redirects guide.

3. Mixed content: the page is https, some files are not

If the address bar shows https:// but no padlock, the page is pulling in something over http://: usually images pasted in years ago, a logo set in a theme option, or an old embed. Browsers block insecure scripts outright and try to upgrade or block insecure images, so the page may also look broken.

1. 1Open the page, press F12 (or right-click and choose Inspect) and select the Console tab. Each mixed-content warning names the exact file that loaded over http://.
2. 2Fix the source of that link. In page content, edit the image or link. In a theme or page-builder setting, re-select the file so it is saved with the new address.
3. 3On WordPress, a search-and-replace plugin can change every stored http://yourdomain.com to https://yourdomain.com in the database at once. Take a backup first, and run it in "dry run" mode before doing it for real.
4. 4For a file hosted on someone else's site that has no https:// version, download it and host it yourself, or remove it.

4. NET::ERR_CERT_DATE_INVALID: the certificate expired

Certificates are only valid for a limited time and must be renewed. Free certificates from Let's Encrypt and AutoSSL renew themselves, so an expired one usually means renewal failed silently: the domain stopped pointing at the server, a firewall rule blocked the check, or the certificate was installed by hand and nobody set a reminder.

Renewal is about to become something nobody can do by hand. Under rules adopted by the CA/Browser Forum, the body that sets certificate standards, the longest a public certificate may last is 200 days from March 15, 2026, 100 days from March 15, 2027, and 47 days from March 15, 2029. If you still buy a certificate and install it manually every year, now is the time to move to automatic renewal.

5. NET::ERR_CERT_COMMON_NAME_INVALID: the name does not match

A certificate lists the exact names it covers. If it was issued for yourdomain.com but the visitor typed www.yourdomain.com, or the other way round, the browser refuses it. The same happens on a new subdomain such as shop.yourdomain.com that the certificate never included.

Re-issue the certificate so it covers every name people use. With AutoSSL, make sure each name has a DNS record pointing at the server (the www record is the one most often missing) and run it again. Then pick one version as the main address and redirect the other to it, so search engines only see one. Our DNS records explained guide shows what the www record should look like.

6. NET::ERR_CERT_AUTHORITY_INVALID: the certificate is not trusted

This means the browser does not recognise who issued the certificate. Usually it is a self-signed certificate the server generated as a placeholder, or a paid certificate installed without its intermediate ("CA bundle") file. The second case is tricky because it can work on your computer, which has cached the intermediate, and fail on phones and other people's browsers.

Replace a self-signed certificate with a free Let's Encrypt or AutoSSL one. For a paid certificate, re-install it and paste the CA bundle your certificate provider supplied into the field for it. The free SSL Labs server test checks your site from outside and reports a missing intermediate as a "chain issue".

If you use Cloudflare or another proxy

A proxy in front of your site adds a second connection: visitor to proxy, then proxy to your server. Two problems are common here:

• A redirect loop ("too many redirects") after you force HTTPS. This usually means the proxy is set to talk to your server over plain HTTP (Cloudflare calls this Flexible mode) while your server redirects everything to HTTPS. Install a certificate on the server and set the proxy's SSL mode to Full (strict).
• A valid padlock that hides a broken server certificate. The visitor sees the proxy's certificate, so everything looks fine until the proxy is turned off. Full (strict) mode also catches this, because it refuses an invalid certificate on your server.

Check the fix worked

1. 1Open the site in a private window and type the domain with no https://. It should land on https:// with a padlock.
2. 2Try both www. and the bare domain, and any subdomains you use.
3. 3Open your three or four most important pages, including the contact form and checkout, and look for the padlock on each.
4. 4Run the SSL Labs test linked above and confirm there are no certificate or chain errors.
5. 5In Google Search Console, make sure the https:// version of the site is the one being indexed.