Fix the 'Not Secure' Warning on Your Website
The "Not Secure" warning means your site either has no SSL certificate, an expired one, or is loading some content over an insecure http:// connection — and you fix it by installing (or renewing) a certificate, forcing every page to load over https://, and cleaning up any leftover http:// links.
This is for any small business owner, blogger, or shop owner who opened their site and saw "Not Secure" next to the address bar — and now customers are asking about it (or worse, leaving). You don't need to be technical. Below is the exact sequence: diagnose, fix, verify, in about 20-40 minutes depending on your platform.
What "Not Secure" actually means
Every browser checks whether your site is using HTTPS — the encrypted version of the web address protocol. HTTPS relies on an SSL/TLS certificate, a small file that proves your domain is who it says it is and encrypts the connection between your visitor's browser and your server. Chrome explains its address-bar security indicators directly here: Chrome's "Not secure" warning explained.
You'll see the warning for one of three reasons:
- No certificate at all — your site is still served over plain
http://. - A broken certificate — expired, self-signed, or issued for the wrong domain (e.g., it covers
example.combut notwww.example.com). - Mixed content — the page itself loads over HTTPS, but it's pulling in an image, script, or stylesheet from an
http://address, so the browser can't call the whole page secure.
All three are fixable without touching code. Here's the order to work through them.
Step 1: Diagnose which one you have
Before fixing anything, find out exactly what's broken:
- Click the padlock or "i" icon in your browser's address bar and choose Certificate is not valid or Connection is not secure to see the reason.
- Run your domain through Qualys SSL Labs' free SSL Test — it grades your certificate and flags expired, mismatched, or misconfigured setups in plain terms.
- If the padlock looks fine but you still see a warning or a "not fully secure" icon, open your browser's developer console (F12 → Console tab) and look for lines mentioning "Mixed Content" — that confirms issue #3 above.
Write down which case you're in; it determines which step below actually applies to you.
Step 2: Install or renew the SSL certificate
If you have no certificate or an expired one, get a new one. Most hosts now offer this for free:
| Platform | How to get/renew the certificate |
|---|---|
| WordPress (shared hosting) | Host's control panel → SSL/TLS → "Enable free SSL" (usually powered by Let's Encrypt) |
| Shopify | Settings → Domains — SSL is automatic and free; if it's missing, remove and re-add the domain |
| Squarespace / Wix | Settings → Domains → SSL — toggle on; provisioning can take up to 24-48 hours |
| Cloudflare (in front of any site) | SSL/TLS tab → set mode to "Full" or "Full (strict)", not "Flexible" |
| Custom server / VPS | Install Certbot for free Let's Encrypt certificates, set to auto-renew every 90 days |
Let's Encrypt certificates expire every 90 days by design, specifically so renewal gets automated rather than forgotten — that's the single most common cause of a site suddenly going "Not Secure" after working fine for months. Confirm your host has auto-renewal turned on, not a manual reminder on someone's calendar.
One more gotcha: make sure the certificate covers every version of your domain you actually use — example.com, www.example.com, and any subdomains. A certificate issued for only one of those will show "Not Secure" on the others.
Step 3: Force every visitor onto HTTPS
Having a certificate isn't enough if your site still lets people load the http:// version. You need a redirect that automatically bumps every visitor to https://.
- WordPress: install the free plugin Really Simple SSL — it detects your certificate and forces the redirect with one click, no code.
- Cloudflare: SSL/TLS → Edge Certificates → turn on "Always Use HTTPS."
- Apache (.htaccess): add this to the top of your
.htaccessfile:
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
- Nginx: in your server block:
server {
listen 80;
server_name example.com www.example.com;
return 301 https://$host$request_uri;
}
Once the redirect works, add one more header to tell browsers to always use HTTPS for your domain from now on, even if someone types http:// again later: Strict-Transport-Security: max-age=31536000; includeSubDomains. This is called HSTS, and OWASP's cheat sheet covers exactly how to set it safely: OWASP HSTS Cheat Sheet. You can check whether yours (and other security headers) are already in place with our free security headers checker.
Step 4: Clean up mixed content
If the padlock shows a warning icon even after Steps 2-3, some element on the page is still loading over plain http://. Browsers block or flag this because an attacker on the same network could tamper with that one insecure file and use it to attack the rest of the page — Mozilla's developer docs explain the mechanics here: MDN: Mixed content.
Common culprits and fixes:
- Old image or script tags hardcoded as
http://yoursite.com/logo.png— change them tohttps://or, better, a protocol-relative//yoursite.com/logo.png. - Embedded content (YouTube videos, fonts, ad scripts, widgets) pulled from a third party still on
http://— check the embed code and swap to the provider'shttps://version. - Database-stored links in WordPress posts/pages from before you had SSL — use the plugin Better Search Replace (or Really Simple SSL's built-in "Mixed Content Fixer") to bulk-update
http://yoursite.comtohttps://yoursite.comacross your database.
After fixing, reload the page and re-check the browser console — no more "Mixed Content" warnings means you're done.
Step 5: Verify the fix actually stuck
Check all of these before calling it fixed:
- [ ]
https://yourdomain.comloads with a padlock, no warning - [ ]
http://yourdomain.comautomatically redirects tohttps:// - [ ]
http://www.yourdomain.comandhttps://www.yourdomain.comalso redirect correctly - [ ] Browser console shows zero mixed-content errors on your homepage and top 2-3 pages
- [ ] SSL Labs test shows grade A or A+, not a warning
- [ ] Certificate expiry date is at least a month out, and auto-renewal is confirmed on
If any box stays unchecked after these steps, the underlying cause is usually a caching layer (CDN or browser cache serving an old version) — clear your CDN cache and hard-refresh before troubleshooting further.
Key takeaways
- "Not Secure" almost always means one of three things: no certificate, a broken/expired certificate, or mixed content — diagnose which one first.
- Get a free certificate from Let's Encrypt (via your host or Certbot) and confirm auto-renewal is on, since 90-day expiry is the #1 cause of recurring warnings.
- Force HTTPS with a 301 redirect (plugin, Cloudflare toggle, or a few lines in
.htaccess/Nginx config), then add an HSTS header. - Hunt down and update any leftover
http://links in images, embeds, or your database — that's what causes mixed-content warnings even after the certificate is fixed. - Re-test with SSL Labs and your browser console before considering it closed.
If you've fixed the padlock but you're still wondering what else on your site might be exposed, that's worth a second look — our guide on what makes a website hackable covers the other common gaps. And if you'd rather have a person confirm everything is actually locked down (not just the padlock, but the whole site), Bug Circuit's Circuit audit is a one-time $49 manual review by a real security engineer, with a full report of anything else worth fixing. You can also start with a free passive security check — no card, no login — before deciding if you need more.
A real human security engineer audits your whole site by hand and sends a full report — every issue, its severity, and the exact fix. From $49, with a 14-day money-back guarantee.
See pricing