The warning your visitors see first
A customer clicks a link to your site and gets a full-page browser warning: "Your connection is not private". Or the page loads, but the address bar says "Not secure" next to your name. On your contact page, where people are about to type their details, that label is the last thing you want them reading.
Most people do not click past a browser warning. They assume the site is broken or dangerous, go back and choose another result.
What actually causes it
| Cause | What visitors see |
|---|---|
| No certificate installed at all | "Not secure" on every page |
| Certificate expired because renewal failed | Full-page warning, often overnight |
| Certificate covers example.com but not www.example.com | Warning on one version of the address only |
| Images or scripts loaded over plain HTTP | "Not secure" or a broken padlock on some pages |
| Site still reachable over HTTP with no redirect | Some visitors land on the insecure version |
| Hosting moved, certificate left behind | Warning appears after a migration |
The root cause is almost always that renewal and setup depend on someone remembering. Certificates are now short-lived by design and meant to renew automatically. When that automation was never set up, or broke during a hosting change, the site runs until the day the certificate lapses.
What the warning costs
People leave. Those who stay are wary of entering details on your forms. Some email systems and browsers block links to sites with certificate problems, so emails you send with links can stop working too. Google treats HTTPS as a baseline expectation, and a site that fails it looks neglected.
A certificate warning also tends to arrive at the worst time. Certificates lapse on a fixed date regardless of whether you are running a campaign, sending a newsletter or closing a large deal, and the first people to notice are usually customers rather than staff. Because it looks alarming, some visitors report it to you as a hacked site, which adds a round of reassurance emails to the fix.
If the site takes payments or logins, a certificate problem is more than cosmetic. It is the protection that stops those details being read in transit.
How we fix it for good
- Diagnose which of the causes applies, checking every version of the address, every page template and the certificate's details and expiry.
- Install a valid certificate covering every version of the domain you use, through your host or a free automated authority such as Let's Encrypt.
- Set up automatic renewal and confirm it actually runs, rather than assuming it will.
- Find every resource loaded over HTTP, in content, theme files, database settings and embedded widgets, and switch it to HTTPS.
- Redirect all HTTP traffic to HTTPS, and to one preferred version of the domain, with a permanent redirect.
- Add HTTP security headers suited to the site, such as HSTS, once everything is confirmed to work over HTTPS.
- Set up certificate expiry monitoring that alerts someone well before the date, in case renewal fails.
On WordPress sites the mixed content often lives in the database, in old image links and settings, so we update those carefully and back up first.
After the fix
Every page shows the padlock. Old links and bookmarks land on the secure version. The certificate renews on its own, and if it ever fails, someone is told before a visitor sees a warning. Forms and logins are protected in transit.
Is this happening on your site?
- The address bar shows "Not secure" on any page
- Visitors mention a warning when they open the site
- The warning appears on www but not without it, or the other way round
- You moved hosting recently
- Nobody knows who renews the certificate
- Some pages show a padlock and others do not