Audit and fix your app from your editor, over MCP
Actuant
Get early access

Insights › Technical SEO

HTTPS mixed content: what it is, why it blocks your page, and how to fix it

Mixed content is when an HTTPS page loads an HTTP resource — an image, a script, a font. Browsers block it, search engines penalize it, and visitors see a broken lock icon. Here's how to find every mixed-content request and fix each one.

Aug 8, 2026 · 5 min read

The short version

Mixed content is when an HTTPS page includes a resource loaded over HTTP. Browsers block active mixed content (scripts, iframes) outright. Passive mixed content (images, audio) loads but shows a broken lock icon. Both hurt your SEO because Google treats the page as not fully secure. The fix is always one of two things: upgrade to HTTPS or remove the resource.

The two kinds of mixed content

  • Active (blocked). Scripts, stylesheets, iframes, fonts, and XHR/fetch requests loaded over http://. Browsers refuse to load these entirely — the page breaks. The console shows "Mixed Content: The page was loaded over HTTPS but requested an insecure script."
  • Passive (loaded, but flagged). Images, video, audio loaded over http://. Browsers load them, but the address bar shows a "Not secure" or broken-lock indicator. Google treats the page as not fully secure.

Where mixed content hides

A generated app typically introduces mixed content through a few predictable paths:

  • Hardcoded `http://` URLs in templates or config. An image src that was written during dev on localhost and never updated to the production HTTPS URL.
  • Third-party embeds. A chat widget, analytics script, or embedded video that loads over HTTP by default because its provider hasn't enabled HTTPS on their CDN.
  • User-generated content. A profile image or uploaded asset that was stored with its original http:// URL from before the site went HTTPS.
  • CDN or asset proxy misconfiguration. The site is HTTPS, but the CDN origin or the image proxy fetches from an HTTP backend.
  • API calls from the client. A front-end that calls an internal API over http://api.yourapp.com while the page is served over HTTPS.

How to find every mixed-content request

  1. 1

    Open the browser console

    Load your page over HTTPS, open DevTools → Console. Mixed content warnings are red and tell you the exact URL of each blocked or flagged resource.

  2. 2

    Check the Network tab

    Filter by domain to spot any http:// requests. They'll be flagged or blocked depending on type.

  3. 3

    Crawl the whole site

    A single page might be clean while another page (with an old blog post image or a user-uploaded asset) has mixed content.

  4. 4

    Use a content security policy in report-only mode

    Add Content-Security-Policy-Report-Only: default-src https: and monitor the violation reports. This finds mixed content without breaking anything.

The two fixes

  • Upgrade to HTTPS (preferred). Change the http:// URL to https://. Most modern CDNs and APIs support HTTPS — you just need to update the URL. If the resource is on your own domain, make sure HTTPS is configured on the origin server.
  • Remove the resource (fallback). If the resource's provider doesn't support HTTPS, find an alternative that does. Loading active content (scripts, iframes) over HTTP is blocked in all modern browsers — there's no workaround.

The header that masks the problem

A quick fix that's actually a trap: Upgrade-Insecure-Requests: 1 header. This tells the browser to rewrite all http:// requests to https:// automatically. It works — until the HTTPS endpoint doesn't exist and the resource silently fails. Use it as a temporary safety net, not a permanent fix.

Why it matters for SEO

Google's ranking algorithm treats HTTPS as a positive signal and mixed content as a partial failure of HTTPS. Pages with active mixed content get flagged in Search Console. Pages with passive mixed content lose the full HTTPS ranking boost. For a new app, that boost is small — but it's one of the few ranking signals entirely under your control.

Actuant loads your deployed URL in a real browser and reports every resource loaded over HTTP — the exact URL, the resource type, and whether it's blocked or just flagged.

Keep reading

Content-Security-Policy: what it protects, how to write one, and the mistake that makes it useless

A Content-Security-Policy tells the browser which scripts, styles and connections to trust — it's your primary defense against XSS. A generated app ships with none. Here's how to write one that's strong enough to matter and test it without breaking anything.

Core Web Vitals: the three numbers Google uses to judge your page

Core Web Vitals are the three metrics Google uses as a ranking signal: how fast the largest element paints, how quickly the page responds to input, and whether the layout jumps around while loading. Here's what each one means, what a passing score is, and how generated apps fail them.