Somebody usually has to tell you. A customer replies to your email with a screenshot: your own website, their browser, and the words “Not secure” in the address bar where a padlock should be. Or they phone to ask whether you've been hacked, because their browser put up a full-screen warning telling them to turn back.
Neither means you were hacked. It means your site is missing — or has broken — the certificate that turns on HTTPS. This is one of the cheapest, most fixable problems in small-business IT, and about half the time it's a five-minute job.
What visitors see, and what it does to you
Every major browser now treats an encrypted connection as the default and flags anything less. On a plain HTTP site, Chrome and Edge print “Not secure” beside your address; Firefox draws a slashed padlock. Ordinary visitors don't parse the technical meaning. They read one word, and the word is insecure.
A broken or expired certificate is worse. Instead of a quiet label, the browser throws a full-page warning — “Your connection is not private”, an error code like NET::ERR_CERT_DATE_INVALID, and a button inviting the visitor to retreat. Most people press it. If your website is your shop window, that page is a locked door with a hazard sign on it.
There's a quieter cost. Browsers warn extra loudly when an insecure page asks for a password or card number, and Google has counted HTTPS in its rankings for years — a slow leak of trust, enquiries and search position.
HTTP vs HTTPS in one honest paragraph
HTTPS does two jobs: it encrypts the traffic between the visitor's browser and your server, so nobody on the same coffee-shop Wi-Fi can read or tamper with it, and the certificate behind it proves the visitor is really talking to your domain. Here's the honest part — if your site is a five-page brochure with no logins and no payments, the real-world risk to any reader was always small. Browsers stopped making that distinction years ago. The label is identical whether you sell nothing or take card numbers, so you need HTTPS because the browser says so, and your visitors believe the browser.
The causes, and how to tell which one you have
No certificate at all
The site was built on plain HTTP and nobody ever added a certificate — common with older sites that have quietly worked for years. The tell: https:// in front of your address fails or warns, while http:// loads fine. The fix is installing a certificate and redirecting all traffic to the secure address.
An expired certificate
You had HTTPS, and the certificate passed its built-in expiry date. The tell is the full-page warning naming a date problem. The fix is renewing it — and finding out why renewal stopped being automatic, covered below. If the site is unreachable entirely rather than flagged, work through the website-down checklist instead.
Mixed content — the sneaky one
The page itself loads over HTTPS, but something on it — an image, a script, a widget pasted in years ago — still loads over plain http://. The browser downgrades your padlock or silently blocks the item. This is the cause behind every conversation that starts “but I already have a certificate”. You do. One of your passengers doesn't.
The wrong name on the certificate
Certificates cover exact names. One issued only for www.yourdomain.com will fail on yourdomain.com, and the other way round. It usually surfaces after a host move, and the tell is a warning on one version of your address but not the other.
Free certificates are real — the work is in the plumbing
A certificate does not need to cost money. Let's Encrypt, a non-profit certificate authority, issues them free, and most hosting control panels will install and renew one with a checkbox. The paid certificates your registrar keeps offering don't encrypt anything better; the padlock is identical.
The certificate is the easy part. The work is configuration: installing it on the server, redirecting every http:// address to https://, fixing the mixed content that surfaces afterwards, and keeping renewal automatic. As of September 2026, Let's Encrypt certificates last 90 days by design, and the industry is moving to even shorter lifetimes — fine while auto-renewal works, a recurring outage when it doesn't. If your host charges a monthly fee for something Let's Encrypt gives away, weigh that next time you review your hosting.
Check your own site in five minutes
- Load https://yourdomain.com and the www version. Note what each shows: padlock, label, or full-page warning.
- Click the padlock — or the icon where it should be — and open the certificate details. Check the expiry date and which names it covers.
- Type the http:// version deliberately. It should bounce you to the secure address on its own; if not, everyone arriving from an old link or bookmark lands on the insecure page.
- Run your domain through a free online checker such as Qualys SSL Labs. It grades the setup, shows the expiry date, and catches name mismatches you'd miss by eye.
- Repeat the first step on your phone with Wi-Fi off — if the warning shows there too, it's genuinely the site, not your computer's clock or antivirus.
Hunting mixed content in plain words
Mixed content sounds technical; finding it isn't. Open the affected page in Chrome, press F12, and click the Console tab. Look for lines beginning “Mixed Content” — each one names the exact file being loaded insecurely. Nine times out of ten it's an image address typed with http:// into an old page or theme.
The fix is changing each address to https:// (nearly every server that served http now serves https) or deleting the item. On WordPress, most mixed content traces back to the site's own address stored as http:// in the database, and one careful search-and-replace fixes thousands of instances at once. A tech on Koadi can do the whole cleanup over a screen-share in under an hour.
Why the warning comes back
The classic pattern: HTTPS worked for a year or two, then the warning appeared from nowhere. That's automatic renewal breaking silently — the certificate works until the day it dies, so there is no symptom until expiry morning. The usual suspects:
- The site moved hosts and the renewal job stayed behind on the old server.
- A DNS change or a new proxy in front of the site means the renewal check no longer reaches your server.
- Renewal needs to answer a challenge over plain HTTP, and a new redirect or firewall rule now blocks it.
- A control-panel toggle got reset during a plan change or migration.
- The domain itself quietly lapsed — in which case email dies with it, and you want the domain rescue steps, not a certificate.
Prevention is dull and effective. Put a monthly reminder in your calendar to glance at your own padlock, or use a free monitoring service that emails you before expiry. A certificate always announces the day it will die; the trick is having somebody read it.
Getting the padlock back without learning server administration
SSL and HTTPS repair is a named Koadi service, and it's usually a same-day, remote job: install or renew the certificate, set the redirects, clear the mixed content, and leave renewal automatic so you don't meet this warning again. Post the problem free at /post-a-problem in plain words — “my site says Not secure” is enough. Set a fixed price or take bids from vetted, identity-verified technicians, and the money sits in escrow until you've seen the padlock with your own eyes and approved the work. Remote help covers every US state, evenings included; local technicians are available when hands are needed.