SSL and “Not secure” warnings
When a browser labels a site “Not secure”, it is warning visitors that the connection is not protected with HTTPS — or that a page loaded over HTTPS is still pulling in insecure files. Both problems are common on small business sites after a migration or a partial upgrade. This guide covers certificates, redirects and mixed content in plain English.
Check your site with the SSL certificate checker and the mixed content checker.
What HTTPS and certificates do
HTTPS encrypts traffic between the visitor’s browser and your server so passwords, form fields and cookies are harder to snoop on a shared network. The padlock (or equivalent UI) means the browser checked a certificate that says the hostname matches and that a trusted certificate authority signed it.
People still say “SSL certificate” out of habit. Modern sites use TLS; the practical point is the same: you need a valid certificate for every hostname visitors type, including www and the apex if you use both.
Certificates expire. If yours has lapsed, browsers show a full-page interstitial and many visitors leave immediately. Renew before the end date. Most hosts and reverse proxies can renew automatically with Let’s Encrypt or a similar service — turn that on and confirm the renewal job is actually running. After a host move, double-check that the new edge is the one presenting the certificate you renewed.
Common certificate and HTTPS problems
- Expired certificate — renew it; verify auto-renew; check you are looking at the certificate the live edge actually serves (CDN vs origin).
- Wrong name — the certificate does not include the hostname people type (for example only
example.co.ukwhen visitors usewww.example.co.uk). - Incomplete chain — the server omits intermediate certificates; some desktops work while older mobiles fail.
- HTTP still open without redirect — the site answers on
http://and never sends people tohttps://. Redirect once to the canonical HTTPS URL. - Mixed hostnames — apex and
wwwboth work but only one has a clean certificate or redirect story. - Self-signed or private CA — fine for lab machines, not for a public customer site. Browsers will warn.
Mixed content: HTTPS pages that still warn
Mixed content means an HTTPS page loads images, scripts, stylesheets, iframes or fonts over plain HTTP. Modern browsers block active mixed content (especially scripts) and may warn about or block passive mixed content (such as images). Visitors then see a broken padlock, blocked features, or a “Not secure” label even though the address bar says https://.
Typical causes on real sites:
- Hard-coded
http://links in theme templates, widgets or old blog posts. - A CMS media library that still stores absolute HTTP URLs from before the upgrade.
- Third-party embeds (maps, video, booking tools) still pointing at HTTP endpoints.
- Canonical, Open Graph or schema URLs that still use HTTP, which confuses tools even when the visible page looks fine.
- Email HTML that links images over HTTP when opened inside a webmail client on HTTPS.
Fix by serving those assets over HTTPS, switching to root-relative paths (/images/hero.jpg), or running a careful search-and-replace in the CMS after a backup. After changes, hard-refresh and re-check with the mixed content checker. Our check looks at the page you enter; deep archive pages may need their own pass.
HSTS — after HTTPS is solid
Once every hostname you care about serves HTTPS correctly, consider HTTP Strict Transport Security (HSTS). That header tells browsers to use HTTPS only for a period of time. Do not enable it while any required subdomain is still HTTP-only, or you can lock browsers out. Start with a moderate max-age while you gain confidence, then extend. See security headers that matter.
What “Not secure” is not
A missing padlock does not by itself mean the site is a scam or has malware. It means the connection is not encrypted, or is mixed. Separately, a site can show a padlock and still host harmful content. Our tools do not judge scams or malware, and a green padlock is not a safety certificate for the business behind the site.
Practical next steps
- Run the SSL certificate checker on the exact hostname customers use.
- Redirect HTTP to HTTPS in one hop; pick one canonical host (
wwwor apex) and stick to it. - Fix mixed content with the mixed content checker.
- Confirm auto-renew for the certificate and diary a manual check before expiry the first few times.
- Only then add HSTS, as described in the security headers guide.
For a wider passive pass, use the free scan.