Mixed content (insecure resources)

On pages served over https:// we look for references to images, scripts and stylesheets starting with a bare http://. If at least one is found, the finding is raised; the report gives the count and a concrete example.

On pages running over http:// the check does not run at all. There “mixed” content makes no sense: everything is insecure. That is SEO-30's business.

What the check does not do: it does not separate active content (scripts and styles, which browsers block hard) from passive (images, usually just a warning), it cannot see resources loaded by JavaScript at runtime, and it does not check whether the target is even available over https. The finding is page-level; severity is warning.

For visibility in AI answers we have no documented effect. But here we do have something rare among SEO codes: documented behaviour you can verify yourself in ten seconds.

Browsers handle mixed content and it is documented: active content (scripts and styles over http on an https page) is blocked outright by modern browsers. It does not load. For images they behave more gently (often upgrading to https, sometimes blocking), but the result for a visitor is the same: something on the page is missing or broken and they do not know why.

That is a different class of problem from the rest of the SEO findings. It is not about how a search engine sees you; it is that your page is broken for some visitors and nobody will report it, because only a developer sees it in the browser console.

What we do not claim: that it worsens your ranking. Google nowhere lists mixed content as a ranking factor and we will not claim it either. The reason to fix it is elsewhere and it is stronger.

The fix is usually trivial: change http:// to https://. Finding every place is the harder part:

grep -rn 'http://' --include='*.html' --include='*.css' --include='*.js' .

• The usual sources: old embedded fonts, maps, video players, visit counters, and images uploaded into a CMS before the move to HTTPS.
• Content in the database will not show up in a grep. Articles with embedded images hold URLs in their text; that needs a bulk replace in the database, and a backup before it.
• Do not use scheme-relative URLs (//example.com/file.js). They work, but they are a relic of the mixed era; write https:// outright.
• When a third-party resource cannot do https, rewriting the URL will not help; replace it, or host the file yourself.

Verify without tooling: open the page, turn on the browser console and look for mixed-content messages. The browser lists them itself; they are exactly the resources it refused to load.

And as insurance for the future: a Content-Security-Policy header with upgrade-insecure-requests upgrades such references automatically. It is not a substitute for the fix, but it keeps the problem from returning with the next embedded image. A missing CSP is, incidentally, reported by SEO-33.