First, Work Out Which "Not Secure" You Have
Visitors do not all see the same warning, and site owners waste the most time fixing the wrong one. "Not Secure" in the address bar is not one problem — it is a label browsers put on at least six different failures. The fix for an expired certificate does nothing for mixed content, and a perfect certificate does nothing if your site never redirects visitors from HTTP to HTTPS.
Start with the two-minute diagnosis below before you touch a setting. It will tell you which section of this guide applies to you, and it stops the most common mistake: reinstalling a certificate that was never the problem.
If you just want a fast verdict on your own site, run it through Nomlen's free SSL checker first — it reports the certificate, its expiry date and the domains it covers, which answers half the diagnosis on its own.
The 2-Minute Diagnosis
Open your site in a browser and answer these questions in order. Stop at the first "yes".
What you see | Likely cause | Fix (section below) |
|---|---|---|
Address starts with http://, and https:// loads fine | No HTTPS redirect — visitors land on the insecure version | Force HTTPS |
https:// fails, or shows "Your connection is not private" | Missing, expired or wrong-domain certificate | Install, renew or reissue the certificate |
Homepage is fine, but some pages warn or block resources | Mixed content — some files still load over HTTP | Fix mixed content |
Warning appears only in one browser, or only on one device | Stale cache, old browser, or wrong device date/time | Clear cache and check the clock |
Warning appears only on www, or only without www | Certificate covers one version, not both | Reissue covering both names |
Warning appears only on a checkout or form page | Form or widget posts to an HTTP address | Fix the form action or widget |
Why Browsers Show This Warning At All
HTTP sends data between a browser and a server unencrypted, so anyone on the same network path can read it. HTTPS is the same protocol with TLS encryption added, and it only works when the server presents a certificate signed by a certificate authority (CA) that browsers already trust.
Google has pushed this for over a decade. In August 2014 it announced HTTPS as a ranking signal, describing it at the time as a "very lightweight signal" affecting fewer than 1% of global queries and carrying less weight than high-quality content — a nudge, not a ranking shortcut. Then, from July 2018 with Chrome 68, Chrome began marking all HTTP sites as "Not Secure" in the address bar. That is why a site that changed nothing suddenly looked broken in 2018: the browser's labelling changed, not the site.
Cause 1: No Certificate At All
The fix costs nothing in most cases. Let's Encrypt is a free certificate authority whose domain-validated certificates are trusted by all major browsers, and most hosting control panels now issue and renew them in a few clicks. If your host offers a free SSL option, turn it on there first — it is faster than any manual install. On a server you manage yourself, Certbot, the official Let's Encrypt client, issues the certificate and configures Apache or Nginx for you. Either way, do not stop at installation: the next section is where most new HTTPS sites break.
Cause 2: The Certificate Expired, Or Never Auto-Renewed
Let's Encrypt certificates last 90 days by design, and Certbot sets up automatic renewal — but renewal fails more often than owners expect. A changed DNS record, a closed port 80, a moved web server or a failed validation challenge can all silently break it, and the first anyone notices is the browser warning.
Cause 3: The Certificate Covers the Wrong Name
A certificate is issued for specific hostnames. A certificate for example.com does not automatically cover www.example.com unless that name is listed as a Subject Alternative Name, and a certificate for one subdomain does not cover another. The symptom is distinctive: the site loads securely on one version and warns on the other, and the browser error mentions a name mismatch.
Cause 4: Mixed Content — The Certificate Is Fine, The Page Is Not
Find it precisely instead of guessing. Open the browser's developer tools (F12), go to the Console tab, and look for "mixed content" messages — they name the exact files still loading over HTTP. The usual culprits are hardcoded http:// URLs in a theme, a database full of old image URLs from before the HTTPS migration, and third-party widgets pasted in years ago.
Cause 5: No Redirect From HTTP to HTTPS
This trap catches sites that did everything else right. The certificate is valid, the HTTPS version is perfect — but visitors who type the bare domain, click an old link or follow an old bookmark still land on http://, because nothing tells the server to send them to the secure version. Chrome then correctly labels what they see as "Not Secure".
Cause 6: Incomplete Chain, Self-Signed, Or Untrusted Certificates
A certificate alone is not enough: browsers need the full chain from your certificate up to a trusted root, via intermediate certificates. A missing intermediate produces a warning that looks like a certificate error even though your own certificate is valid and in date. The fix is to install the full chain file your CA provides — Certbot's fullchain file exists for exactly this reason — rather than only the leaf certificate.
Self-signed certificates are a different case: they encrypt the connection, but no trusted authority vouches for the server, so browsers rightly refuse to trust them for public sites. They belong on internal test servers, not on anything visitors use. If your site shows a self-signed warning in production, replace the certificate with one from a trusted CA; do not ask visitors to click through an exception.
The 10-Minute Fix, In Order
- Minute 0–2: Diagnose. Run the decision table above and check the certificate's expiry and covered names with an SSL checker.
- Minute 2–5: Fix the one cause you found. Install, renew or reissue the certificate; or fix the redirect; or update the mixed-content URLs. Do one fix at a time so you know what worked.
- Minute 5–7: Force HTTPS everywhere. Add the server redirect and confirm http:// pages 301 to their https:// equivalents.
- Minute 7–9: Hunt mixed content. Check the Console on the homepage and two deep pages, update every http:// resource, and hard-refresh.
- Minute 9–10: Verify like a visitor. Open the site in a private window, check both www and non-www, and re-run the SSL checker. If it is clean in private mode but warns in your normal window, clear your browser cache — you were looking at a stale copy.
When It Is Not Your Site: Advice For Visitors
If you are a visitor, not the owner, do not try to fix the site — decide how much to trust it. Reading an article on an HTTP page is low risk; typing a password, payment details or personal information into a "Not Secure" page is not, because that data travels unencrypted and can be intercepted, especially on public Wi-Fi. Do not click through a full-page certificate warning to reach a login or checkout: a genuine site with a lapsed certificate is inconvenienced, but a lookalike site with a mismatched certificate is exactly what the warning exists to catch. If the site matters to you, contact its owner or use its official app or phone channel instead, and come back once the warning is gone.
How To Stop This Happening Again
- Automate renewal and prove it works. A renewal job that has never been tested is a hope, not a system. Run the dry-run check after setup and after any server move.
- Monitor expiry, not just uptime. An uptime monitor that pings HTTP will happily report a site "up" while browsers warn every visitor. Monitor the certificate's expiry date specifically, with an alert at least seven days out.
- Redirect at the server, not in page code. A JavaScript or meta redirect to HTTPS fires after the insecure page has already loaded. A server 301 happens before any content is served.
- Search for http:// after every migration or theme change. New themes, plugins and pasted embeds reintroduce mixed content quietly. A post-change Console check takes a minute.
- Keep one canonical version. Pick www or non-www, redirect the other, and make sure the certificate covers both so a stray link never lands a visitor on a warning.
Most "Not Secure" warnings are a ten-minute fix once you know which of the six causes you have. Diagnose first, fix that one thing, force HTTPS, sweep for mixed content, and verify in a private window. Then automate renewal so you never have to do it under pressure again — and re-check with Nomlen's SSL checker to confirm the warning is gone for good.
Frequently Asked Questions
Why does my site say "Not Secure" even though I installed SSL?
Usually one of three things: the redirect from HTTP to HTTPS is missing, so visitors still land on the insecure version; some page resources still load over HTTP (mixed content); or the certificate covers a different hostname than the one visitors use, such as www versus non-www. Work through the diagnosis table at the top — reinstalling the same certificate rarely helps.
Is a "Not Secure" website hacked?
Not necessarily. The warning means the connection is unencrypted or the certificate cannot be trusted; it does not by itself mean the site has been compromised. Treat it as a reason not to enter sensitive data there, not as proof of a breach.
How do I know if my SSL certificate has expired?
Click the icon left of the address in Chrome and open the certificate details to see its expiry date, or use an online SSL checker. Let's Encrypt certificates last 90 days, so an expiry warning usually means automatic renewal failed — check the renewal job and port 80 access, not just the date.
Do I need a paid SSL certificate, or is free Let's Encrypt enough?
For most sites, free is enough: Let's Encrypt issues domain-validated certificates trusted by all major browsers, with the same encryption as paid certificates. Paid certificates mainly add organisation validation or warranties that larger businesses may want; they do not remove the warning any better than a correctly installed free one.
What is mixed content and how do I fix it?
Mixed content is an HTTPS page loading some resources — images, scripts, stylesheets or widgets — over HTTP. Find the exact files in the browser Console's mixed-content messages, change their URLs to HTTPS, and search your database for leftover http:// references to your own domain. One missed footer image can keep the warning on every page.
Will fixing "Not Secure" improve my Google rankings?
Only slightly, and honestly. Google announced HTTPS as a ranking signal in August 2014 but called it a very lightweight signal, weaker than high-quality content. The real gain is trust: visitors who are not warned away stay, fill in forms and complete checkouts.
Why does the warning appear on only some pages?
Because mixed content and form actions are per-page: a page that embeds an old HTTP image or posts a form to an HTTP address warns, while clean pages do not. Check the Console on each affected page rather than assuming a site-wide certificate fault.
Is it safe to visit a "Not Secure" site at all?
Reading public content is low risk, but do not enter passwords, payment details or personal information on an unencrypted page, and do not click through a full-page certificate warning to reach a login or checkout. If you need that site, contact its owner or use its official app instead.
