Your Site Has SSL but Still Says 'Not Secure': The Mixed Content Problem, Explained

You did everything right. You have an SSL certificate, it is valid, it has not expired, and yet the browser bar on one of your pages still reads "Not Secure" in grey letters where a padlock should be. I was reviewing a customer migration this morning and hit exactly this, so it is a good moment to explain what is going on.

The short version is this. Your certificate is almost certainly fine. The problem is that the page is loading at least one item, often something as small as a logo or a font, over the old insecure http protocol instead of https. Browsers judge a page by its weakest link. One insecure item, and the whole page loses its secure status. The name for this is mixed content, and it is one of the most misdiagnosed problems in web hosting.

This is a reference article. Read it top to bottom once, then come back to the diagnosis and fix sections when you need them.

What "Not Secure" Actually Means When You Have a Valid Certificate

An SSL certificate encrypts the connection between a visitor's browser and your server. When every single item on a page arrives over that encrypted connection, the browser shows the page as secure. That is the state almost the entire web now runs in. According to Google's own HTTPS transparency reporting, the share of pages loaded over HTTPS in Chrome has sat north of 90% for years, and Google has confirmed that from Chrome 154 in October 2026, the browser will default to "Always Use Secure Connections" and warn before loading anything insecure.

Mixed content is what happens when a secure page breaks that rule. As Mozilla's MDN Web Docs defines it, mixed content occurs when an https page pulls in a resource over plain http. The page itself is encrypted. One image on it is not. To the browser, that is enough to say the page can no longer be trusted as fully secure, because that one insecure item can be read or tampered with in transit while everything around it is protected.

So the warning is not lying to you. It is telling you, correctly, that part of the page is exposed. The trap is that it looks like a certificate failure, so people go and buy another certificate, or ring their host in a panic about SSL, when the certificate was never the issue.

The Two Kinds of Insecure Content, and Why One Is Worse

Not all mixed content behaves the same way. The browser treats it differently depending on how much damage the insecure item could do, and understanding the split tells you whether you are looking at a cosmetic problem or a broken page.

Insecure item on the page	What the browser does	What your visitor actually sees
Images, video, audio	Upgraded to https where possible, dropped if not	A missing photo, or the padlock replaced by "Not Secure"
Scripts and stylesheets	Blocked outright, no option to allow	Broken layout, a button that no longer works
Web fonts and embedded frames	Blocked outright	The wrong font, or a blank booking or map widget
File downloads over http	Blocked	A download link that does nothing when clicked

The first row is the gentle case. As MDN describes the modern model, browsers now try to auto-upgrade insecure images, video and audio to https automatically. If a secure version exists at the same address, the browser quietly uses it and you may never notice. If it does not exist, the image simply fails to load, and your page loses its padlock. Low risk, real trust cost.

The other three rows are the harsh case. Scripts, stylesheets, web fonts, embedded frames and file downloads cannot be safely upgraded, because an attacker who intercepted them could rewrite the behaviour of your page entirely. So the browser blocks them completely. There is no "load anyway" button for your visitors. This is why a mixed content problem does not just strip the padlock. It can leave your booking form blank, your menu unstyled, or a payment button dead on the page, and the owner often does not connect the two.

Where Mixed Content Comes From

In my experience running Irish sites, it almost never appears out of nowhere. Something changed. These are the usual triggers, in roughly the order I see them.

A migration from an old http site. If a site ran on http for years and was moved to https, every image, link and reference that was hard-coded with an http:// address is now mixed content. The certificate went on fine. The thousands of old links inside the content and the database did not update themselves.

An embedded third-party widget. This is the one that catches people out after launch. Consider a Carlow physiotherapy clinic that adds an online booking widget to a new appointments page. The widget provider serves its embed over http, and the moment that page goes live, the padlock on it vanishes. The rest of the site is perfect. That single page is flagged, and it happens to be the page where customers were about to hand over their name and phone number.

Hard-coded links in the theme or content. An old logo, a background image set in a stylesheet, a tracking pixel or an advert tag that someone pasted in years ago with an http address. It sat there harmlessly while the site was http. The day you switched to https, it became the weak link.

A plugin that has not kept up. Older plugins sometimes load their own assets over http. When one does, it drags the padlock down with it.

What It Actually Costs You

Now for the part that matters more than the mechanics. A visitor does not know what mixed content is. They do not inspect certificates. They see two words, "Not Secure", next to your web address, and they draw the obvious conclusion: this business has been hacked, or is dodgy, and I am not typing my card or my phone number in here.

Picture the version of this that hurts. Someone finds your business, clicks through to book or buy, and lands on the one page carrying an insecure widget. The warning appears. They close the tab. You never see the enquiry, you never get the call, and you have no idea it happened, because nothing on your end broke. The site is up. It just quietly told a customer not to trust you.

Sometimes you find out the awkward way, when a careful customer messages to say their browser is warning them about your site and is everything alright. That message is a gift, because most people will not send it. They will simply leave. A padlock is not decoration. It is the single most visible trust signal your site has, and mixed content removes it on exactly the pages where trust matters most.

How to Find the One Insecure Item

The good news is that the browser will tell you precisely what is at fault. You do not have to guess.

Open the offending page in Chrome and press F12 to open developer tools. Click the Console tab. Any insecure item is listed there in plain text, with its full http:// address. That address is the entire answer: it names the exact image, script or embed that is dragging the page down, and often which plugin or folder it lives in.

If developer tools feel like a step too far, a free online mixed content scanner does the same job from the outside. You paste in the page address, it crawls the page, and it hands you back the list of insecure items. Either way, you are looking for the http:// addresses. Everything on a secure page should read https://. The ones that do not are your targets.

One practical warning from experience. Check the interior pages, not just the homepage. Years ago I signed off on a migration and told the owner it was done because the homepage showed a clean padlock. A week later they rang: an old logo file on their contact page was still loading over http. I had verified the front door and not the rooms behind it. Now every URL gets checked, not just the obvious one.

How to Fix Mixed Content for Good

Once you know what is insecure, the fix is methodical. Work through it in order rather than poking at symptoms.

Verify the certificate first. Confirm the certificate itself is valid and covers your domain. This clears the false alarm and proves you are dealing with mixed content, not an expired or misissued certificate.

Update the site address. In WordPress, under Settings, make sure both the WordPress Address and Site Address use https://, then re-save your permalinks. This corrects the foundation that everything else is built on.

Rewrite the old links in the database. For a migrated site, the http references are buried in years of content and settings. A careful search-and-replace across the database, swapping http://yourdomain for https://yourdomain, clears them in one pass. A phpMyAdmin-style database manager makes this a controlled operation rather than a gamble. Take a backup before you run it, always.

Force https at the server. Configure the server to redirect every request to https, so even an old link that slips through is upgraded before it reaches the visitor. Where your hosting panel offers this as a one-click option, use it. Where it does not, it is a server configuration task.

Re-verify every affected page. Reload each page, confirm the padlock is back, and check the console is clean. Do not declare it fixed from the homepage alone.

Why This Should Not Be a Job You Do Twice

Everything above is doable. The question worth asking is why it fell to the business owner at all.

A properly managed WordPress platform removes most of the causes before they reach you. The certificate is provisioned and renewed automatically, so it is never the thing that broke. Every request is redirected to https at the server, so a stray old link is upgraded before a visitor ever sees a warning. And when a site is migrated onto the platform, the http references are rewritten as part of the move, rather than left as landmines in the database. This is the standard a hosting provider should be held to. It is also the standard we build to at Web60: free SSL via Let's Encrypt that provisions and renews itself, server-level https enforcement, and a free migration that brings your content across clean, and it all runs on enterprise-grade Irish infrastructure that serves every page over one secure connection. If you would rather the platform simply never let this happen in the first place, that is the whole point of managed hosting done properly.

There is one honest limit, and it is worth naming. No host can fix a third-party embed that only offers an insecure version. If a booking, map or advertising widget hands you an http:// embed code, the padlock on that page depends on the widget provider, not on you. Your host can force https on everything it controls. It cannot force it on a snippet that a third party serves insecurely. In that case the real fix is to get the secure embed code from the provider, or to change providers. It is rare, but when it happens, no amount of server configuration will paper over it.

And the strategic concession, because I do not believe in overselling: if you run a heavily customised site with a developer who manages a build pipeline and a content delivery network, handling https enforcement yourself at the edge gives you finer control than any automatic setup. You decide exactly how each asset is rewritten. For a business owner without a developer on call, that control is a cost, not a benefit. You want the platform to make the right call by default, not a dashboard of switches you have to understand.

For the wider picture of how certificates, backups and hardening fit together, our complete WordPress security and backup guide for Irish sites is the place to start, and if you are still weighing up certificate options, what free SSL actually includes and why you should never pay extra for it covers that ground.

Conclusion

"Not Secure" beside a valid certificate is not a mystery and it is not a certificate failure. It is one insecure item on an otherwise secure page, and the browser is doing exactly what it should by flagging it. Find the http:// address, fix or replace it, force https at the server, and re-check every page rather than just the homepage.

The deeper lesson is that a padlock is a promise to your customer, and it only takes one overlooked file to break it. Once you know where mixed content comes from, you know what to look for the next time a page loses its lock. That is a good thing to be able to spot before a customer spots it for you.

Frequently Asked Questions

Why does my website say 'Not Secure' when I already have an SSL certificate?

Your certificate is almost certainly fine. The warning usually means the page is loading at least one item, often an image, a font, or a script, over plain http instead of https. The browser judges the whole page by its weakest link, so one insecure item downgrades the entire page. That is mixed content, and it is a different problem from an expired or missing certificate.

Is mixed content dangerous or just cosmetic?

Both, depending on the item. An insecure image is mostly a trust cost, because the padlock disappears but little else happens. An insecure script or stylesheet is a real risk, because anything loaded over http can be intercepted or altered in transit, which is why modern browsers block it outright. That is also why a page with mixed content sometimes looks visually broken, not just flagged.

How do I find what is causing the mixed content warning?

Open the page in Chrome, press F12 to open developer tools, and look at the Console tab. It lists every insecure item by its full http address. If you would rather not touch developer tools, a free online mixed content scanner will crawl the page and report the same list. The http addresses are the clue to which image, plugin, or embed is at fault.

Will fixing mixed content improve my Google ranking?

Not directly and not dramatically. HTTPS is a lightweight ranking signal, but the real gain is trust and conversions. A visitor who sees "Not Secure" and leaves is a lost enquiry, and that costs you well before any ranking effect does. Fix it for the customer first, and treat any ranking benefit as a bonus.

Does a managed WordPress host prevent mixed content?

A properly managed host removes most of the causes. It provisions and renews the certificate automatically, redirects every request to https at the server, and handles migrations so old http links are rewritten rather than left in the database. The one thing no host can fix for you is a third-party embed, such as a booking or map widget, that only offers an insecure version. That one you have to swap at source.

Sources

HTTPS encryption on the web, Google Transparency Report

HTTPS by default, Google Security Blog, October 2025

Mixed content, MDN Web Docs, Mozilla

The HTTPS-Only Standard, Mixed Content, US Government