Blog · 6 November 2026 · 8 min read

HTTPS is not enough: 7 things that break behind the padlock

“We have SSL, there's a padlock, done.” That is the most common answer a small-business owner gives when asked about website security. The padlock only says that this one page was loaded over an encrypted connection with a certificate the browser trusts. It says nothing about whether the http:// version is still live, whether the certificate expires next week, or whether a customer who types the address without “www” ends up in the right place. Here are seven things we keep finding on sites “with a padlock”.

What the padlock actually means

A TLS certificate (colloquially “SSL”) does two things: it encrypts data between the browser and the server, and it confirms the server really answers for the domain in the address bar. That's all. It does not check whether the page is free of malicious code, whether the form sends data to the right place, or whether the rest of your site is protected too. That's why the problems below are so common: every one of them coexists with a perfectly green padlock.

Seven problems the padlock hides

1. The certificate that's about to expire

This is the most spectacular failure on the list because it isn't gradual. Until midnight the site works; after midnight every visitor sees a full-screen warning most people close without reading. The causes are mundane: someone paid for a one-year certificate and then changed jobs, the Let's Encrypt automation stopped working after a DNS change or a hosting move, the card on file expired.

It's worth knowing that one- or two-year certificates are on their way out. Following a 2025 CA/Browser Forum decision, the maximum lifetime of public certificates is being cut in stages: to 200 days from March 2026, 100 days from March 2027 and eventually 47 days from March 2029. Manual renewal stops being realistic; automation (ACME) becomes the only sensible option, and its failures will show up more often. If your host doesn't offer automatic renewal, that's a reason to change hosts or put Cloudflare in front of the site.

2 and 3. The http redirect and HSTS

Installing a certificate doesn't switch the unencrypted version off. The server still answers on port 80, and when a user types a bare address without “https://”, the browser tries http first. If nothing redirects it, it stays on the unencrypted page – and remembers that address for autocomplete next time.

The redirect is one rule. The three most common environments:

# Apache / most shared hosting (.htaccess)
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

# nginx – a separate block for port 80
server {
  listen 80;
  server_name yourdomain.com www.yourdomain.com;
  return 301 https://yourdomain.com$request_uri;
}

# Cloudflare: SSL/TLS → Edge Certificates → “Always Use HTTPS”: On

HSTS goes one step further: a header after which the browser never tries http for that domain again, not even the first time after clicking an old link. Enable it only once the whole site (including subdomains, if you use includeSubDomains) runs on HTTPS – rolling HSTS back takes as long as the max-age you set.

4 and 5. Two versions of the domain

To browsers and to Google, the domain with “www” and without it are two different addresses. They should lead to one place, but that has to be configured on two levels. First, the certificate must cover both names; a certificate issued only for domain.com throws a red warning on www.domain.com, which the owner usually never sees because they arrive from a bookmark. Second, one version should 301-redirect to the other, and the chosen version should be the same in the canonical tag, the sitemap and Search Console. Which one is better? It doesn't matter. Consistency does.

You can check this in a minute: type all four combinations (http/https × www/non-www) and see whether each one ends in the same place, with no warnings.

6. Mixed content: an encrypted page with unencrypted parts

The page loads over HTTPS, but its code still contains addresses starting with http://: photos pasted years ago, a font from an external server, a chat script. The browser reacts differently by type: it shows images but takes away the padlock; scripts, styles and frames it blocks outright. The result: “the photo slider disappeared after the SSL migration” or “the form stopped working”.

In WordPress the cause is almost always the database, where image URLs were saved with http. The fix is a replace across the whole database – but with a tool that understands serialized data (the Better Search Replace plugin, or wp search-replace 'http://domain.com' 'https://domain.com'), not a manual SQL export and “replace all” in a text editor. If an external resource has no https version, it has to be replaced. As a stopgap, the header Content-Security-Policy: upgrade-insecure-requests tells the browser to try https for everything, but that's a bandage, not a cure.

7. Redirect chains

A single redirect is invisible. The problem is chains, which build up in layers: the host adds http→https, the SEO plugin adds www→non-www, the site adds a trailing slash, and the language setup adds /en/. On a desktop with fibre that's tens of milliseconds. On a phone on 4G every hop is a separate connection and half a second of blank screen adds up before the browser even starts downloading the page (more in why your website is slow on mobile). The rule: from any old address, one redirect straight to the destination. You'll see the chain in DevTools (Network tab, the first row and the following ones with 301/302 codes) or in our scan result.

The 5-minute checklist

• Certificate expiry date, and whether it renews itself (ask your host directly: “does the certificate renew automatically?”).
• All four address combinations (http/https × www/non-www) end in one place, with no warnings, in a single hop.
• A padlock without a warning on the homepage, in the shop/form, and on the page with the most images.
• HSTS header present (after confirming everything is on HTTPS).
• The address in canonical, the sitemap and Search Console is the same variant.