What Is Mixed Content? Fixing HTTP Leaks on HTTPS Sites

Jul 24, 2026 · SEO Glossary

A checkout page audit, a few years ago: the client had paid for an SSL certificate, migrated to HTTPS, and celebrated. One product image on the payment page still loaded from an old http:// URL. Result: browsers flagged the connection as not fully secure, right at the moment customers were entering card numbers. Conversion on that page had quietly sagged for months and nobody knew why.

What is mixed content? It's what you get when a page served over secure HTTPS loads some of its resources — images, scripts, stylesheets, iframes — over unencrypted HTTP. The page is "mixed": partly secure, partly not. Since the whole promise of HTTPS is that nothing in transit can be read or tampered with, one insecure resource breaks the promise for the page, and browsers respond accordingly.

What Is Mixed Content, and Why Browsers Care So Much

An HTTP resource on an HTTPS page is an open door in a locked house. An attacker positioned on the network (public wifi being the classic venue) can read or modify anything sent over HTTP. If that something is a script, they can rewrite it in transit and effectively run their own code on your secure page — harvesting form input included. This isn't theoretical paranoia; it's why browser vendors have spent a decade tightening the screws.

Passive vs. Active: The Distinction That Decides Severity

Browsers split mixed content into two classes, treated very differently:

• Passive (display) content — images, audio, video. An attacker could swap or observe them but can't execute code. Historically browsers loaded these with a degraded padlock warning; modern Chrome and Firefox now auto-upgrade them to HTTPS and block them if the secure version doesn't exist.
• Active content — scripts, stylesheets, iframes, fetch/XHR requests. These can manipulate the entire page, so browsers have hard-blocked them for years. No warning dialog, no mercy: the resource simply doesn't load.

That blocking behavior explains a whole category of "mysterious" bugs: a map widget that vanished, a font that stopped rendering, a form that broke — often traced to one hardcoded http:// script URL that browsers silently refuse. The site isn't down; it's being quietly protected from itself.

Where Mixed Content Hides

After enough of these hunts, the hiding spots are predictable:

1. Hardcoded URLs in the database. The big one on CMS sites. Every image inserted into WordPress content before the HTTPS migration has its full http:// URL baked into the post HTML. Migrations that don't rewrite the database leave thousands of these behind.
2. Theme and template files. Logos, background images, and script includes hardcoded with http:// by a developer in 2015.
3. CSS files. background-image: url(http://...) is invisible to anyone reviewing HTML and skipped by scanners that don't parse stylesheets.
4. Third-party embeds. Old ad tags, tracking pixels, badge widgets from vendors that no longer exist. If the vendor never provisioned HTTPS, no fix on your side except removal.
5. Custom fields and metadata. Image URLs stored in plugin settings, sliders, and page-builder modules — places a content-only search misses.

Hunting It Down Systematically

Spot-checking pages in DevTools works for one page: open the console and the mixed-content warnings list each offending URL. For a whole site, that approach is a weekend you won't get back. The systematic version:

• Crawl the site. An automated audit that crawls every page and flags HTTP resources referenced from HTTPS pages gives you the complete inventory at once — page, resource, and type — instead of a page-by-page scavenger hunt. It's the difference between finding the three pages someone reported and finding all two hundred.
• Search the database. On WordPress, a search-and-replace of http://yourdomain.com to the HTTPS version (with a proper serialized-data-aware tool) clears the biggest category in one pass.
• Use CSP in report-only mode. A Content-Security-Policy-Report-Only header can report every insecure request real users encounter — catching the dynamic cases a crawler might not trigger.

Fixing It for Good

The fix hierarchy, best to worst: rewrite URLs to https:// at the source (database, templates, CSS); replace or drop third-party resources with no HTTPS version; and only then consider the upgrade-insecure-requests CSP directive, which asks browsers to upgrade everything automatically — a good safety net, a lazy primary strategy. Avoid protocol-relative URLs (//example.com/...); they're an obsolete workaround from the transition era.

If you're doing this for a client, document the finding properly: which pages, which resources, passive or active, and the user-visible consequence. "Your checkout shows a security warning in Chrome" gets a fix approved the same day; "mixed content detected" gets filed under someday. There's a reason severity-sorted findings are the backbone of a decent audit report — the writing is half the fix. The same applies when the client is future-you.

Does any of this matter for SEO? Mildly and indirectly: HTTPS is a lightweight ranking signal, and a page whose resources are blocked can render broken, which affects everything downstream. The bigger cost is the trust hit — "Not secure" warnings next to a checkout form are conversion poison. Fix it once, then let scheduled site monitoring catch regressions, because the next plugin install or content import will happily reintroduce the problem while nobody's looking.