SSL Isn't Enough: What Small Website Owners Still Get Wrong About HTTPS

The padlock icon in the address bar tells a visitor almost nothing about whether your site is actually safe. I have audited enough small business sites to know that gap trips up good, careful people constantly.

A padlock icon secures the connection. It says nothing about what happens once the data arrives.

In this post

What SSL/TLS actually promises, and what it does not
Mixed content, the silent padlock killer
Certificate misconfiguration mistakes that are easy to miss
What HTTPS does nothing to protect against
A short, realistic checklist beyond the certificate

A lot of small site owners treat getting the padlock icon as the finish line. Install a certificate through the hosting panel, see the lock appear, move on to the next task. I understand why. Certificate authorities and hosts have made getting HTTPS running genuinely easy, and that is a real win for the web overall. The problem is that "the connection is encrypted" and "the site is secure" got flattened into the same idea in a lot of people's heads, and they are not the same thing at all.

What SSL/TLS actually promises, and what it does not

TLS, which is what actually runs behind the padlock now (SSL is the older, deprecated protocol the name stuck around from), does two specific jobs. It encrypts the data traveling between a visitor's browser and your server, so nobody on the network in between can read or tamper with it, and it verifies that visitors are actually talking to your server and not an impostor. That is genuinely valuable. It stops a huge category of interception attacks, especially on public Wi-Fi.

What it does not do is check whether your site's code is secure, whether your login form is protected against brute-force attempts, whether your database is exposed, or whether the WordPress plugin you installed three years ago and forgot about has a known vulnerability. The padlock covers the pipe, not what is flowing through it or what is sitting behind it.

Mixed content, the silent padlock killer

This is one of the most common issues I find on small sites that technically "have SSL." If your HTTPS page loads even one resource, an image, a script, a stylesheet, over plain HTTP instead of HTTPS, browsers flag it as mixed content. Depending on the type of resource, this either downgrades your padlock to a warning icon or gets silently blocked, sometimes breaking page functionality without an obvious error message pointing at the cause.

This happens constantly after a site migrates from HTTP to HTTPS, because old hardcoded links in theme files, widget settings, or database entries do not update themselves. Checking your site's console in Chrome DevTools, or running it through a tool like SSL Labs' server test, will surface this quickly if it is happening.

Certificate misconfiguration mistakes that are easy to miss

Expired certificates. Most modern hosts auto-renew through Let's Encrypt, but manually purchased certificates on older setups still lapse, sometimes silently, taking your entire site offline in visitors' browsers with a hard warning page.
Missing intermediate certificates. A certificate chain that is incomplete can work fine in some browsers and fail in others, which makes this kind of misconfiguration easy to miss if you only ever test in one browser.
No HSTS header. Without HTTP Strict Transport Security enabled, a visitor who types your domain without "https://" can still be intercepted on that first request before the redirect to HTTPS even happens. Enabling HSTS closes that specific gap.
Wildcard certificates covering more than intended. Convenient for subdomains, but worth knowing that a compromise of the certificate's private key affects every subdomain it covers, not just the one that got breached.

What HTTPS does nothing to protect against

This is the part that actually matters most for a small site owner's threat model, since these are the things that cause real breaches:

SQL injection through an unsanitized form field or search box
Outdated CMS plugins and themes with known, published vulnerabilities
Weak or reused admin passwords with no two-factor authentication
Unrestricted file upload forms that accept executable file types
Exposed configuration files or backups sitting in a publicly accessible directory

Every one of these can exist on a site with a flawless A+ SSL Labs rating and a perfectly green padlock. Certificate configuration and application security are two separate jobs, and treating the first as a substitute for the second is where a lot of otherwise careful site owners get caught out.

Where I see this go wrong most: small business owners who paid a developer once, years ago, to "set up the website securely," and have not thought about it since. HTTPS was probably part of that original setup. Plugin updates, password hygiene, and backup integrity were not a one-time job, they are ongoing, and that is the part that quietly slips.

A short, realistic checklist beyond the certificate

Run your site through SSL Labs' test once, then set a reminder to check again every few months
Enable automatic updates for your CMS core, and check plugin updates monthly at minimum
Use a unique, strong admin password with two-factor authentication enabled, not just for the CMS login but for your hosting panel and domain registrar too
Review the OWASP guidance for whatever platform you run, the OWASP Top 10 covers the most common web application risks in plain terms and is worth reading even without a technical background
Keep a recent backup stored somewhere other than your hosting account itself, so a compromised site is not also a lost site