Why does my secure site still show a warning?
Worth a look
This is mixed content: the page itself arrives securely, but something on it — an image, a font, a script, an embedded map — is still being fetched over the old insecure connection. Browsers either block those items outright or downgrade the padlock, and either way the page looks wrong.
Why browsers treat it so harshly
A secure page is only as trustworthy as the least secure thing on it. If your page loads a script over an insecure connection, anyone able to tamper with that connection can replace the script with their own — and their code then runs with full access to your secure page.
So browsers draw a distinction. Active content (scripts, stylesheets, iframes) is blocked outright, which is why a page sometimes loses its layout or its booking widget after moving to https. Passive content (images, video) is usually allowed but downgrades the padlock, or gets silently upgraded to https where the browser can manage it.
That's why the symptom varies so much: sometimes a missing padlock, sometimes a visibly broken page.
Where it usually comes from
Almost always a site that moved to https and left old references behind. Images uploaded before the move keep their full old http:// address in the page content, and nothing rewrites them.
The other common source is a third party — an embedded map, a review widget, a chat tool or a font service that hasn't been updated to its secure address, or an old plugin hard-coding an insecure URL.
How it gets fixed
Usually a search-and-replace across the site's content, changing http://yoursite.co.uk to https://yoursite.co.uk — a routine job on any platform, and one with well-established tools on WordPress.
For third-party items, the fix is either switching to the provider's secure address or dropping the widget if the provider never got round to supporting https, which by now says something.
A stopgap called upgrade-insecure-requests can tell browsers to try everything over https automatically. It's a reasonable safety net but not a substitute for fixing the references.
How to check this yourself
- Open the page in Chrome and press F12 to open developer tools, then choose the Console tab.
- Reload the page. Mixed content is reported there in plain terms — “Mixed Content: The page at … was loaded over HTTPS, but requested an insecure …”, followed by the exact address of the offending item.
- That address tells you what to fix: your own domain means it's your content; someone else's means it's a third-party embed.
- Check a few different page types — home, a blog post, a product page — because the culprit is often in older content rather than the template.
What to ask your web person
Copy this. It's phrased so you don't have to know the jargon to ask for the right thing.
Our site is served over https but the browser console reports mixed content on some pages. Could you run a search-and-replace across the content to update old http:// references to https://, and check any third-party embeds? The console lists the specific URLs.
Want to know if this applies to your site?
This one is measured by Google's Lighthouse, which takes minutes rather than seconds — so it comes with the in-depth assessment rather than the free check-up. The free check-up still covers your security, your email protection and how search engines see you, in about a minute and with no account.