Why does my site say Not Secure when I have a certificate?

Browsers treat two kinds of insecure content differently

This is the mechanism, and it is why the damage looks so uneven.

MDN describes the split plainly: "Mixed content in a web page is divided into two categories: 'upgradable content' and 'blockable content'."

What the browser does with each is the important half: "Browsers mitigate the risks of mixed content by auto-upgrading image, video, and audio mixed content requests from HTTP to HTTPS, and block insecure requests for all other resource types."

So pictures usually survive. Stylesheets and scripts do not. An insecure image is quietly fixed for you and you never learn it was wrong. An insecure stylesheet is blocked, and the page loads with no design.

Downloads get the same treatment. MDN notes that browsers "should also block mixed downloads by default", and explains the risk: such files "appear to come from a secure origin, but could have been modified or viewed en-route."

There is a reason older advice on this reads differently. MDN records the earlier vocabulary: what are now called blockable and upgradable were once "blockable" and "optionally blockable", also known as active and passive mixed content. If you find guidance using those words, it is not wrong so much as dated.

It is also getting stricter rather than looser. MDN states the direction of travel: "any new file types will be defined as blockable content, and some upgradable content may become blockable in future." A site limping along on auto-upgrades is relying on a grace period.

Some things stop working, not just look wrong

The warning is the visible part. The invisible part is that entire browser features switch off.

MDN defines the gate: "A secure context is an environment such as a Window or Worker which meets a defined standard of authentication and confidentiality." The consequence for a site owner is in the next sentence: "Many Web APIs and features are accessible only in a secure context."

That is why insecure pages fail in ways nobody connects to a padlock. Location lookups, camera access, and other modern browser features simply are not available. Nothing errors in a way a visitor understands. The feature is absent.

So a site can pass a visual check and still be losing function. Looking at the page tells you about layout. It does not tell you what the browser declined to offer.

What Google does with it, and what it does not

Worth separating the security problem from the ranking question, because they get conflated and only one of them is urgent.

Google groups HTTPS with a set of page experience considerations rather than treating it as a lever. Asked whether there is a single page experience signal, its documentation answers directly: "There is no single signal. Our core ranking systems look at a variety of signals that align with overall page experience."

The practical value is diagnostic rather than competitive. Google points to a report built for exactly this: "Search Console's HTTPS report: Check if you're serving secure HTTPS pages and what to fix, if you're not."

That report matters because it works at the scale of a site rather than a page. You can check your homepage by eye. You cannot check four hundred pages by eye, and mixed content usually hides on the pages nobody visits, like an old landing page with a hard-coded image address.

Testing in one browser is not testing

Browsers do not agree on how much insecure content to tolerate, so where you look changes what you see.

MDN gives the useful example while describing how to test: "Disable all mixed content on your browser and test that pages work as expected. This is the default for Safari".

Read that as a warning about your own checking habit. Safari already refuses the content other browsers upgrade for you. A site that looks correct in Chrome can be visibly broken for anyone on an iPhone, and nobody on your team will see it unless somebody tests there.

The console is the reliable witness in every browser. MDN notes that it "shows warnings when mixed content is upgraded or blocked", so it reports the quiet upgrades as well as the visible failures. Those upgrade warnings are the early list of things that will break when a resource type moves from upgradable to blockable.

There is also a header that papers over the whole problem. MDN describes the content security policy directive upgrade-insecure-requests as one that "upgrades all requests to HTTPS, including blockable mixed content". It works, and it is worth knowing about for a large old site.

Be clear about what it does, though. It rewrites requests at the browser. It does not fix a single reference in your code, so the underlying HTTP addresses are still there, still wrong, and still waiting for the day something stops being upgradable. Useful as a stopgap while you repair the source, and a poor place to stop.

What to check, in order

Five checks, and the first four are free.

• Open the page in a browser and look at the developer console. MDN notes that browsers report mixed content there, and it names the exact file that caused the problem rather than leaving you to guess.
• Check whether anything is merely missing rather than warned about. A page with no styling and no warning is still a mixed content story, because the stylesheet was blocked.
• Run the HTTPS report in Search Console to find the pages you would never have checked.
• Test a feature that needs a secure context, not just the appearance. If a form, a map or an upload is quiet rather than broken, that is the secure context rule at work.
• Fix the references rather than the certificate. The certificate is doing its job. Something inside the page is asking for HTTP.

Work through what a small number of bad references actually costs, because "only a few files" understates it badly. Suppose a page loads 40 resources and 3 of them use HTTP addresses. One is a photograph, which gets upgraded automatically and shows no symptom at all. One is a stylesheet, which is blocked, so the page renders unstyled and looks broken to every visitor. One is a script that runs your contact form, which is blocked, so the form silently stops submitting.

Three bad references, three completely different outcomes, and only one of them is visible as a warning. That is the shape of this problem. The numbers are an illustration, but the spread is the point: the count of insecure references tells you almost nothing about the damage, and the type of each one tells you everything.

Tracking down which references are insecure, across a site rather than a page, is part of what we do on websites.

Terms used on this page

• SSL certificate

Sources

• Mixed content (MDN Web Docs, Mozilla)
• Secure contexts (MDN Web Docs, Mozilla)
• Understanding Google Page Experience (Google Search Central)

Last reviewed 2026-09-11.