Mixed Content and HTTPS Issues That Break Rankings

Mixed content is what happens when a page loads over secure HTTPS but pulls in images, scripts, or stylesheets over insecure HTTP underneath it, and it matters for SEO because it triggers browser warnings, blocked resources, and broken rendering — not a direct Google penalty, but damage that shows up in the page experience signals Google does measure. Most sites pick it up during or after an HTTP-to-HTTPS migration, when some URLs get switched and others get missed.

The fix isn’t complicated once you know where to look. It’s finding every instance across a large site, database, and set of third-party embeds that takes the actual work.

What is mixed content and why does it show up after an HTTPS migration?

A page has mixed content when its initial HTML loads over HTTPS but references at least one resource — an image, a video, a script, a stylesheet, an iframe — over plain HTTP. Chrome’s own documentation calls this “the mix of HTTP and HTTPS content on a single page,” and splits it into two categories that matter for how much risk, and how much SEO damage, each one carries.

Passive mixed content covers images, audio, and video. It can’t run code, but an attacker on the network can still swap the resource, track the user, or deface the page cosmetically. Active mixed content covers scripts, stylesheets, and iframes — code the browser downloads and executes, which means an attacker who intercepts it can take over the entire page, not just the one resource. Most browsers, including Chrome, block active mixed content outright by default. Passive content is treated more leniently, sometimes auto-upgraded to HTTPS silently, sometimes flagged with a “not secure” warning even though the page itself is on HTTPS.

It reappears after a migration because the migration itself is usually a one-time cleanup — a redirect map, a database search-replace, a CDN switch — while new content keeps getting added afterward. A writer pastes an old embed code, a plugin update reintroduces a hardcoded URL, a third-party widget serves its own asset over HTTP. None of that shows up until someone checks again.

How does mixed content actually affect SEO and rankings?

There’s no line item in Google’s ranking systems for “mixed content detected.” The effect runs through three indirect paths instead, and each one is measurable:

• Broken rendering. When Chrome blocks an active mixed content script or stylesheet, the page can render incorrectly — missing styles, broken interactive elements, layout shifts as blocked resources fail to load. That’s a direct hit to Cumulative Layout Shift and, depending on what’s blocked, Largest Contentful Paint.
• Trust signals. A browser address bar showing “not secure” on a page the user expected to be secure increases bounce rate. Google has used HTTPS as a lightweight ranking signal since 2014, and a page that fails to deliver a genuinely secure experience undercuts the reason that signal exists in the first place.
• Crawl and render parity. Googlebot renders pages in a Chromium-based browser. If mixed content blocks a resource for a real user’s Chrome, it blocks the same resource when Googlebot renders the page, which means Google may be indexing a version of the page with missing content or broken functionality.

How do you find every mixed content instance on a site?

Three methods cover the ground, and each catches things the others miss.

Run the crawl first on a large site — it’s the only method that scales past a handful of pages. Configure the crawler to flag any HTTP URL referenced from an HTTPS page, export the list, then use DevTools on a sample of the worst offenders to confirm whether each one is passive or active, since that changes how urgent the fix is.

How do you fix mixed content once you’ve found it?

The fixes are mechanical, but they need to happen in the right order or you end up chasing the same handful of URLs across five different content sources.

Five steps to eliminate mixed content

• Step 1 — Run the DevTools Issues tab on your key templates to see what’s actually being blocked versus auto-upgraded right now.
• Step 2 — Pull a full-site crawl filtered to HTTP resources referenced from HTTPS pages, so you have a complete list instead of a sample.
• Step 3 — Fix hardcoded HTTP URLs in the database with a careful search-replace, covering post content, widget settings, and theme options tables.
• Step 4 — Switch to protocol-relative or explicit HTTPS paths in theme files, custom widgets, and any third-party embed code your team controls directly.
• Step 5 — Add a Content-Security-Policy header with the upgrade-insecure-requests directive so any remaining passive resource gets rewritten to HTTPS automatically at the browser level.

Step 5 is the safety net, not the primary fix. A CSP directive rewrites the request to HTTPS, but if the target server has no HTTPS version of that resource at all, the request simply fails — you still need the underlying URL corrected for anything that doesn’t have a secure equivalent.

What mistakes let mixed content come back after you’ve already fixed it?

• Treating the migration cleanup as a one-time job. New content, new plugins, and new third-party scripts keep introducing fresh HTTP references. A quarterly crawl, or a CSP report-only policy that logs violations, catches recurrences before they accumulate.
• Missing CDN and asset pipeline configuration. If your CDN or image optimizer is configured with an HTTP origin, every asset it serves inherits that, regardless of what the page’s own HTML says.
• Ignoring embedded third-party widgets. Chat widgets, review widgets, and ad tags are frequently the last holdout because nobody on the internal team owns that code directly — flag these to the vendor rather than leaving them unresolved.
• Relying on the browser warning alone. By the time a user or a QA tester sees a mixed content warning in the address bar, the insecure request has usually already fired. Detection needs to happen before the fact, not by watching for symptoms.
• Skipping HTTP embed codes from old blog posts. Older articles frequently have YouTube embeds, image hotlinks, or affiliate scripts written years before the HTTPS migration, and they don’t surface in a spot-check of recent pages.

Frequently asked questions

Does mixed content directly hurt Google rankings?

Not as a direct ranking penalty. The damage is indirect: browsers block or warn about insecure resources, which breaks page rendering, hurts Core Web Vitals, and shows security warnings that increase bounce rate — all of which Google’s systems can pick up on through user signals and page experience.

What’s the difference between passive and active mixed content?

Passive mixed content covers images, video, and audio, which can be swapped or tracked but can’t run code. Active mixed content covers scripts, stylesheets, and iframes, which can execute and take over the page. Browsers block active mixed content by default; passive is often auto-upgraded or flagged with a warning.

Why does mixed content appear months after an HTTPS migration?

New content gets added by writers, plugins, or third-party widgets that hardcode http:// URLs, unaware the site moved to HTTPS. Without an ongoing check like a CSP header or a scheduled crawl, mixed content re-accumulates silently after the original migration cleanup.

Can a Content-Security-Policy header fix mixed content automatically?

A CSP header with the upgrade-insecure-requests directive tells the browser to rewrite HTTP subresource requests to HTTPS before fetching them, which resolves most passive mixed content automatically. It won’t fix a resource that has no HTTPS version at all — that still needs a real URL change.

Sources

• What is mixed content? — web.dev (Chrome team)
• Technical SEO: The Complete Working Guide
• Faceted Navigation: Controlling the Crawl Explosion
• Pagination and SEO After rel=next/prev
• Mobile-First Indexing: What Still Trips Sites Up