Mixed Content: Why Your Site Has No Padlock Despite Having SSL

A scenario we see all the time: a site owner installs an SSL certificate, opens the site, and — instead of a padlock, a warning that "the connection is not fully secure". The first thought is that the certificate is faulty, but nine times out of ten the certificate is perfectly fine. The problem is mixed content: the page loads over HTTPS, but some of its parts — images, scripts, stylesheets — are still pulled over old, unencrypted HTTP.

Why it matters

HTTPS guarantees that nobody between the visitor and the server can read or modify the traffic. But if a script loads over HTTP on an encrypted page, an attacker can intercept and replace that script — and the whole protection collapses. That''s why browsers react: passive content (images, video) loads with a warning and the padlock disappears, while active content (JavaScript, CSS, iframes) is blocked outright. The result: a broken-looking site, forms that don''t work, and visitors scared off by the warning — studies consistently show a significant share of users abandon a site the moment they see a security warning.

Where mixed content comes from

• Hard-coded HTTP URLs in the database — WordPress stores full image URLs inside post content, so after switching to HTTPS, hundreds of images still point to http:// versions.
• Themes and plugins loading fonts, scripts, or styles from HTTP addresses.
• External services — an old banner snippet, visitor counter, or map embed added ten years ago that nobody has touched since.
• CSS files with background images on http:// paths — the easiest to miss because they don''t show up in the HTML.

How to find the culprits

Open the site in Chrome, press F12, and check the console: every mixed content item is listed with its exact URL. To scan the whole site at once, use a free tool like Why No Padlock or JitBit SSL Checker, which crawls pages and lists every HTTP resource. On WordPress, searching the database for "http://yourdomain" with the Better Search Replace plugin reveals all hard-coded addresses.

The fix, step by step

• 1. Search & replace in the database: replace "http://yourdomain.com" with "https://yourdomain.com" (Better Search Replace has a dry-run mode so you can preview the changes — and always back up first).
• 2. Check the WordPress address: in Settings → General, both URLs (WordPress and Site URL) must start with https://.
• 3. Switch external resources to their https:// versions (virtually all services have them today), or drop the ones that don''t.
• 4. Set up a 301 redirect from HTTP to HTTPS at the server level, so nobody lands on the unencrypted version anymore.
• 5. For stubborn leftovers: the Content-Security-Policy: upgrade-insecure-requests header tells the browser to upgrade HTTP requests to HTTPS on its own — an elegant safety net, though cleaning the source is always better than masking it.

Verification and prevention

After cleanup, walk through your key pages with the console open — the padlock must be solid on every one. Going forward: whenever you embed any external code, check that the URL starts with https://. If you''re still setting up SSL, start with our SSL certificate guide — and on our hosting plans SSL is free and renews automatically, so the only job left is exactly this: cleaning up mixed content.