Mixed Content

TL;DR — Mixed contentMixed content is when a page served over HTTPS loads a sub-resource — a script, stylesheet, image, iframe, or similar — over insecure HTTP. Browsers' current taxonomy is upgradable versus blockable; active mixed content (scripts, styles, iframes) is blocked, and passive mixed content (images, audio, video) is warned about or increasingly auto-upgraded, with exceptions like CORS-enabled images and srcset/picture candidates that are blockable, not upgradable. is when a secure https:// page loads something — an image, a script, a stylesheet — over insecure http://. That mixes a secure page with insecure pieces, which defeats the point of HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.'. Browsers block the dangerous kinds (scripts, styles, iframesHTML element that displays one webpage inside another — how embeds work.) and warn about the milder kinds (images, media). It’s the most common thing that breaks a site right after you switch to HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.', and the fix is simple: make every resource load over https:// too.

What mixed content is

When you move a site to HTTPS, the page itself loads securely. But a page is never just the HTML — it pulls in images, scripts, stylesheets, fonts, videos, and sometimes embedded frames from other places. If any of those pieces are still requested over plain http://, you have mixed content: a secure page carrying insecure cargo. Evidence for this claim Mixed content occurs when a secure page loads resources over insecure HTTP, and browsers upgrade or block mixed-content requests by resource type. Scope: MDN documents current browser categories and behavior; individual browser versions may differ at the margins. Confidence: high · Verified: 2026-07-14 MDN: Mixed content

As Google’s own explainer puts it, “A page has mixed content when its initial HTML is loaded over a secure HTTPS connection, but other resources (such as images, videos, stylesheets, and scripts) are loaded over an insecure HTTP connection.”

That matters because the insecure pieces reopen exactly the hole HTTPS closed. Anyone sitting on the network between the visitor and the server can read or tamper with those http:// requests — so the padlock in the address bar is promising more security than the page actually has.

The two kinds, and what browsers do about them

Browsers don’t treat all mixed content the same. They sort it by how much damage the insecure resource could do:

• Active mixed content — scripts, stylesheets, and iframes. These can control the whole page, so a tampered one could rewrite everything. Browsers block it. This is what actually breaks your layout, your interactivity, or a whole embedded widget after a migration.
• Passive mixed content — images, audio, and video. These can’t take over the page, so browsers have historically loaded them but taken away the padlock and shown a “not fully secure” warning. That’s changing — modern browsers increasingly upgrade or block these too.

One thing that is not mixed content: a plain link (<a href="http://…">) to an HTTP page. That just navigates you somewhere; it doesn’t load an insecure piece into your secure page.

How to fix it

The fix is almost always the same: make the insecure resource load over HTTPS. Change http:// to https:// in the reference, or use a path that doesn’t hard-code the protocol at all. Most of the time the resource is already available over HTTPS — someone just left an old http:// URL in a template, a plugin, or the database.

If you want a safety net for anything you missed, you can add a single line of configuration — the upgrade-insecure-requests header — that tells the browser to quietly rewrite leftover http:// resource requests to https:// before it sends them. It’s a great backstop, but it’s not a reason to skip cleaning up the real source. Evidence for this claim The upgrade-insecure-requests CSP directive rewrites insecure URLs as secure URLs before requests are made. Scope: MDN documents the directive's rewriting behavior and limits; it does not guarantee that an HTTPS version of every resource exists. Confidence: high · Verified: 2026-07-14 MDN: CSP upgrade-insecure-requests

Want the full picture — the exact resource lists browsers block, how to detect mixed content at scale with the DevTools console and CSP reports, the upgrade-insecure-requests and block-all-mixed-content directives, why your CMSA content management system (CMS) is software that lets users create, manage, and publish digital content — like blog posts and pages — without writing raw code. WordPress, Drupal, and Joomla are the most common open-source CMS platforms. keeps reintroducing it, and how mixed content interacts with HSTSHSTS (HTTP Strict Transport Security) is a response header that tells browsers to always connect to your site over HTTPS — even when a user types or clicks an http:// link — closing the insecure-first-request gap that a plain 301 redirect leaves open.? Switch to the Advanced tab.

TL;DR — Mixed contentMixed content is when a page served over HTTPS loads a sub-resource — a script, stylesheet, image, iframe, or similar — over insecure HTTP. Browsers' current taxonomy is upgradable versus blockable; active mixed content (scripts, styles, iframes) is blocked, and passive mixed content (images, audio, video) is warned about or increasingly auto-upgraded, with exceptions like CORS-enabled images and srcset/picture candidates that are blockable, not upgradable. is an HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.' page loading a sub-resource over HTTP. The current browser/W3C taxonomy sorts this into upgradable and blockable content; the older active/passive split (used below as a blast-radius framing) still tracks that divide for most resource types, with exceptions — CORS-enabled images, srcset/picture candidates, and IP-host requests are blockable even though a plain img src is upgradable. Active (scripts, stylesheets, iframesHTML element that displays one webpage inside another — how embeds work., XMLHttpRequest/fetch, and anything the browser executes) is blocked — a tampered script can rewrite the page — so it’s the launch-day regression to fix first. Passive (images, audio, video) historically loaded with a downgraded indicator and is now increasingly auto-upgraded or blocked. Anchor links and other top-level HTTP navigation aren’t mixed content; neither are insecure downloads, which are a related but separate boundary. Detect it across three layers — fetched source, rendered/runtime state, and real user sessions — by crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor. the HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.' site, reading the Chrome DevTools console (exact wording is browser/version specific), or collecting Content-Security-Policy-Report-Only violations; fix it by confirming an HTTPS equivalent actually works, then pointing every sub-resource at https:// (relative/protocol-relative paths are fine once you’ve verified ownership and base-URL behavior, not a universal default). Content-Security-Policy: upgrade-insecure-requests rewrites in-scope http:// sub-resource requests (including cross-origin ones) to https:// before they’re sent and before mixed-content/CSP checks run — a net, not a substitute for fixing the source, with no HTTP fallback if the upgrade fails, and it does not upgrade top-level navigation to third-party origins, so it doesn’t replace HSTSHSTS (HTTP Strict Transport Security) is a response header that tells browsers to always connect to your site over HTTPS — even when a user types or clicks an http:// link — closing the insecure-first-request gap that a plain 301 redirect leaves open.. Putting the directive itself in report-only mode is a no-op — monitor with a separate report-only policy instead. CMSA content management system (CMS) is software that lets users create, manage, and publish digital content — like blog posts and pages — without writing raw code. WordPress, Drupal, and Joomla are the most common open-source CMS platforms. databases (back up and dry-run any replacement — naive string-replace can corrupt serialized data), plugins, themes, service workers/caches, and ad/analytics tags are the recurring re-offenders — audit at scale, not page by page.

The HTTPS hubHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.' introduces mixed content as one of the two launch-day failure modes of a migration (the other being redirectsA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't.). This is the deep dive it points to — the exact resource tiers, the detection stack, the CSP directives, and the operational reasons it keeps coming back.

What counts as mixed content — and what doesn’t

Mixed content is scoped precisely: it’s about sub-resources the page loads, not about links the page contains. Google’s definition: “A page has mixed content when its initial HTML is loaded over a secure HTTPS connection, but other resources (such as images, videos, stylesheets, and scripts) are loaded over an insecure HTTP connection.” Evidence for this claim Mixed content occurs when a secure page loads resources over insecure HTTP, and browsers upgrade or block mixed-content requests by resource type. Scope: MDN documents current browser categories and behavior; individual browser versions may differ at the margins. Confidence: high · Verified: 2026-07-14 MDN: Mixed content

The trap that reassures people falsely is the anchor tag. A <a href="http://…"> link to an HTTP page is not mixed content — it navigates to a new document; it doesn’t load an insecure resource into the current secure one. That’s true of any top-level navigation to an HTTP page, not just anchor clicks.

It’s still worth sending outbound links to HTTPS destinations. Under the modern browser-default Referrer-Policy (strict-origin-when-cross-origin), a click from an HTTPS page to an HTTP destination does drop the Referer header, which can mangle referral analytics — but that behavior is policy- and browser-dependent, not a universal rule: a page (or an upstream proxy/CDN) that sets a looser Referrer-Policy can still send a referrer on that downgrade. Check the actual Referrer-Policy in effect before asserting how much referral data a given site loses — but in any case, that’s a separate problem from mixed content, not mixed content itself.

Active vs. passive: the distinction that sets your priorities

Modern browser and W3C documentation classifies mixed content primarily as upgradable versus blockable content — resource types the browser will silently retry over HTTPS versus ones it refuses outright — rather than the older active/passive split. Active/passive is still useful shorthand for why browsers draw that line (how much of the page the resource could compromise), and it’s how Google’s own explainer frames it, so it’s kept below as the primary triage framing — just don’t treat it as the current official taxonomy when you need to reason about a specific resource type; see the exceptions after the two lists.

Browsers classify mixed content by how much of the page the insecure resource could compromise. Google: “Active mixed content poses a greater threat than passive mixed content.” That single sentence should drive your triage order.

Active mixed content interacts with — and can take over — the whole page. Google describes it as “scripts, stylesheets, iframes, and any other code the browser can download and execute.” In practice the active list is:

• <script src="http://…"> — the worst case; an intercepted script can rewrite the entire DOM, exfiltrate form data, or inject content.
• <link rel="stylesheet" href="http://…"> — CSS can hide, reposition, or overlay anything, so it’s treated as active.
• <iframe src="http://…"> — an embedded insecure document inside your secure one.
• XMLHttpRequest / fetch() to http:// — insecure data the page then acts on.
• Web fonts, <object>/<embed> resources, and the <link> variants that pull in executable or layout-controlling content.

Because a tampered active resource can rewrite the page, “Most browsers already block this type of content by default to protect users.” That’s why active mixed content is what visibly breaks things after a migration — a blocked stylesheet strips your CSS, a blocked script kills interactivity, a blocked iframe leaves a hole. Fix active first. It’s a functional bug, not just a security nag.

Passive (display) mixed content — Google: “including images, video, and audio” — “doesn’t interact with the rest of the page.” An intercepted image can be swapped but can’t seize the document. So historically browsers loaded it and just downgraded the indicator: “Until recently, passive mixed content was loaded in all browsers, because blocking it would have broken many websites. This is now beginning to change.” The direction of travel across browsers is toward auto-upgrading passive resources to HTTPS where possible and blocking what can’t be upgraded, so “passive = harmless” is no longer a safe assumption to build on.

Exceptions the active/passive split doesn’t capture

The upgradable/blockable line has several exceptions that don’t follow the general “images upgrade, scripts block” pattern above — these are the cases that actually trip people up in practice:

• CORS-enabled image requests are force-failed, not upgraded. An ordinary <img src="http://…"> is upgradable, but an image request made with crossorigin set is treated differently by the mixed-content algorithm and fails instead of silently upgrading.
• srcset and <picture> candidates are blockable, not upgradable. The same image, requested through a responsive-image mechanism instead of a plain src, falls into the blockable category — don’t assume every image reference behaves the same way.
• IP-address hosts are blocked, not upgraded, even for an otherwise-upgradable resource type. A reference like http://203.0.113.5/logo.png doesn’t get the automatic-upgrade treatment a domain-hosted equivalent would.
• Nested contexts and workers are in scope. Mixed-content checks apply inside iframes and inside service/shared workers too, not just the top document — a worker fetching an insecure script is still mixed content.
• Local and loopback origins have their own nuance. localhost, loopback addresses, and file:// contexts are “potentially trustworthy origins” under the spec even without TLS, so a simple HTTP-vs-HTTPS heuristic doesn’t map cleanly onto local development environments.
• Insecure downloads are a related but separate boundary. A download initiated from a secure page over http:// is a real risk, but it’s governed by its own download-security handling, not the sub-resource mixed-content rules in this section.
• Top-level HTTP navigation still isn’t mixed content, including the anchor-link case above — that’s a property of navigation, not of a loaded sub-resource, however many of these other exceptions apply.

Detecting mixed content — the whole stack

TIP Confirm the insecure resource before choosing the remediation

This finding reports an HTTP subresource in fetched source. Browser-only, conditional, and tag-manager resources still require DevTools, crawling, or CSP reports.

Run a suspect URL through my Website Safety Checker for a quick source-level confirmation, then expand the audit across templates. Website Safety Checker Free

1. Start with broken templates and pages that lost the secure indicator.
2. Identify whether the HTTP resource is active or passive and whether an HTTPS equivalent exists.
3. Fix the source reference, rerun the page, then crawl and collect CSP reports for the long tail.

Tap to enlarge

There is no single button, and each layer below answers a different question — a clean result at one layer doesn’t clear the others. Diagnose fetched source (what the raw HTML actually references), rendered/runtime state (what the browser requests once it’s parsed the page and run its scripts), and real user sessions (what happens for a visitor behind a consent banner, a geoGenerative Engine Optimization (GEO) is the practice of optimizing content and brand presence so AI-powered search engines and assistants — Google AI Overviews, ChatGPT, Perplexity — cite, recommend, or mention you when generating answers. Google's position is that it's still SEO.-redirect, a login wall, or a third-party tag that only fires under specific conditions) separately. Layer these from “one page” to “whole site”:

1. The Chrome DevTools console (rendered/runtime state). Load the HTTPS page and open the console. Blocked active mixed content logs a message along the lines of “Mixed Content: The page … was loaded over HTTPS, but requested an insecure … This request has been blocked; the content must be served over HTTPS.” Passive that gets loaded logs a warning rather than a block. The Security panel (or the Issues tab) groups it up per page. Fast for spot-checks and for confirming a specific fix — but treat the exact message wording, panel layout, and even which resource types get blocked as browser- and version-specific; this was confirmed against Chrome as of 2026-07 and you should verify current wording on the actual browser/version you’re diagnosing rather than quoting it as a fixed UI string, and expect Firefox, Safari, and Edge to differ.

2. A site crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. (fetched source, at scale). DevTools is per-page; a crawl is site-wide. Ahrefs Site Audit and Screaming Frog both flag pages that reference http:// sub-resources on an HTTPS site — the only realistic way to find mixed content across thousands of URLs. This is the primary tool for an audit, but it’s still reading source: a crawl passing clean doesn’t prove the rendered page or a real session is clean too — record which browser/tool/version produced a given result rather than reporting one unqualified pass/fail.

3. CSP violation reporting (real user sessions). You can make the browsers of real visitors report mixed content back to you, which catches resources that only load on certain pages, for certain users, under certain consent states, or from third-party tags you don’t control — the layer neither a crawl nor a single DevTools check can reach. web.dev: “You can use content security policy to collect reports of mixed content on your site. To enable this feature, set the Content-Security-Policy-Report-Only directive by adding it as a response header for your site.” Report-Only mode reports violations without enforcing the policy, so you can measure the problem in production before you turn on blocking. (The mechanism is the modern report-to / Reporting-Endpoints header, or the older report-uri. Note this is a different, general-purpose report-only policy than upgrade-insecure-requests itself — putting that specific directive in report-only mode doesn’t work, as covered below.)

Use all three: DevTools to verify a rendered page, a crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. to inventory fetched source, CSP reports to catch the real-session long tail that only shows up in the wild. One crawl passing is evidence about the source, not a guarantee that every consent state, ad-tech variant, personalization branch, or worker is clean.

Fixing at the source

The real fix starts before you touch a single reference: verify the HTTPS equivalent actually exists, presents a valid certificate, and returns the content you expect — don’t assume swapping the scheme is safe just because the domain resolves. Once that’s confirmed, every sub-resource reference should resolve over HTTPS. Options below are in rough order of preference, but each one still depends on ownership and context, not just the string you type:

• Absolute HTTPS URLs — change http://cdn.example.com/app.js to https://cdn.example.com/app.js. Explicit and unambiguous; the safest default when you’re not certain about the serving context below.
• Root-relative or relative paths — for resources you own on the same site, /assets/app.js inherits the page’s scheme automatically. Google’s HTTPS guidance: “Make sure intrasite URLs and external URLs don’t depend on a specific protocol. Use relative paths or leave out the protocol as in //example.com/something.js.” Treat this as conditional, not a universal recommendation: it only holds once you’ve confirmed you actually own the resource (a relative path to a third-party asset doesn’t make sense), that the page’s real base URL resolves the way you expect (a <base> tag, a proxied path, or an embedded/AMPAMP (Accelerated Mobile Pages) is an open-source web framework Google launched in 2015 to make mobile pages load near-instantly via restricted HTML/CSS/JS and CDN caching. It was never a ranking factor and, since June 2021, is no longer required for Top Stories. context can change what “relative” means), and that nothing downstream reconstructs the URL in a way that reintroduces http:// — client-side code building a URL from window.location or a stored absolute value, for example.
• Protocol-relative URLs (//example.com/something.js) still work, but they’re not the preferred universal fix — gate them on the same ownership/base-URL checks above, not just habit. On an all-HTTPS web, an explicit https:// is usually clearer and avoids surprises if the file is ever opened from a non-HTTP context; reach for protocol-relative only where you have a specific reason not to hard-code the scheme.

At scale you almost never hand-edit templates one by one — but don’t run an unguarded database string-replacement against production either. http://yourdomain → https://yourdomain looks like a simple find-and-replace, and for plain-text fields it often is safe, but CMS content can be serialized or structured (PHP serialized arrays, JSON blobs, block-editor data) where a naive substring swap corrupts the record instead of fixing it. Use application-aware tooling that understands the serialization format, back up the database first, and dry-run the replacement so you can review the affected rows before committing. Then fix the handful of template/config files that emit the URLs; the crawler and CSP reports mop up the stragglers.

upgrade-insecure-requests: the safety net (and its limits)

The proactive backstop is a Content-Security-Policy directive. web.dev: “The upgrade-insecure-requests CSP directive instructs the browser to upgrade insecure URLs before making network requests.” Set the header:

Content-Security-Policy: upgrade-insecure-requests

Per MDN, it “instructs user agentsA user agent is the HTTP request header a client (browser, crawler, or bot) sends to identify itself. For crawlers, a short user-agent token — a substring of that string — is what robots.txt rules actually target. to treat all of a site’s insecure URLs (those served over HTTP) as though they have been replaced with secure URLs (those served over HTTPS).” Concretely, MDN says it upgrades: “requests to load resources (such as images, scripts, or fonts),” “navigation requests (such as link targets) which are same-origin with the document,” “navigation requests in nested browsing contexts, such as iframes,” and “form submissions.” Evidence for this claim The upgrade-insecure-requests CSP directive rewrites insecure URLs as secure URLs before requests are made. Scope: MDN documents the directive's rewriting behavior and limits; it does not guarantee that an HTTPS version of every resource exists. Confidence: high · Verified: 2026-07-14 MDN: CSP upgrade-insecure-requests

Two operational details matter beyond that quote. First, the sub-resource upgrade isn’t limited to same-origin requests — it’s the navigation upgrade that’s same-origin-only per the quote above; ordinary sub-resource requests get rewritten across origins too, so a CDN-hosted script or a third-party font gets upgraded, not just same-site assets. Second, the rewrite happens before the browser’s mixed-content and CSP checks evaluate the request, which is why a resource that would otherwise be blocked outright as mixed content can load cleanly once it’s been upgraded — the upgrade pre-empts the block.

Three limits you must not paper over:

• It does not upgrade third-party top-level navigation. MDN: “However, top-level navigation requests whose target is a different origin will not be upgraded.” Because of that, it is explicitly not a replacement for HSTS: “The upgrade-insecure-requests directive will not ensure that users visiting your site via links on third-party sites will be upgraded to HTTPS for the top-level navigation and thus does not replace the Strict-Transport-Security (HSTS) header.” (More on that split below.)
• It’s a net, not a fix, and it doesn’t fall back. If the resource genuinely isn’t available over HTTPS, the upgraded request just fails outright — it does not fall back to the original http:// version. Cleaning the source is still the job; the directive covers what you missed, not what’s genuinely broken.
• Report-only mode doesn’t perform the upgrade — it’s a no-op. Putting upgrade-insecure-requests inside a Content-Security-Policy-Report-Only header is ignored by the browser: nothing gets rewritten, and nothing gets reported for it either. If you want visibility into what the upgrade would affect before you enforce it, run a separate, general-purpose report-only policy that reports disallowed http:// destinations (the same default-src https: report-only approach used for detection above) — you can’t get that visibility by making upgrade-insecure-requests itself report-only.

block-all-mixed-content — mostly historical

There’s a companion directive, block-all-mixed-content, which — per MDN — “prevents loading any assets over HTTP when the page uses HTTPS,” including “both blockable and upgradable mixed content,” and applies to iframes too. In practice it’s been superseded. MDN marks it deprecated and “obsolete in the specification,” noting: “Content that isn’t blocked is now always upgraded to a secure connection, so this directive is not needed.” Reach for upgrade-insecure-requests; treat block-all-mixed-content as legacy you might inherit, not something to deploy new. If you already send upgrade-insecure-requests, block-all-mixed-content has nothing left to do for upgraded requests — the upgrade rewrite happens first, so by the time a block-all check would run, the request has already been upgraded (or has already failed). It’s not just legacy; it’s redundant wherever UIR is already deployed.

Why your CMS keeps reintroducing it

Mixed content isn’t a one-time cleanup — it recurs, because several systems quietly re-inject http:// URLs after you think you’re done:

• The content database. In WordPress, Drupal, and most CMSes, editors paste images and embeds with absolute http:// URLs straight into post bodies. Those live in the database, not in a template, so a code-level fix never touches them — hence the DB search-and-replace.
• Themes and plugins. A theme or plugin that hard-codes an http:// asset URL (a font, a script, a background image) reintroduces mixed content on every page it renders, and a plugin update can bring it back after you’ve cleaned it.
• Ad tech, analytics, and third-party tags. Tag managers, ad networks, chat widgets, and analytics snippets load their own sub-resources — and if a vendor’s tag still calls http://, it’s mixed content you can’t fix in your own codebase. This is exactly the long tail CSP reporting is for; the durable fix is pressing the vendor to serve over HTTPS (or dropping the tag). If a vendor has no working HTTPS endpoint, the durable choices are the same three: get them to fix it, replace the dependency, or drop it — there isn’t a fourth option that keeps the insecure version running safely.
• Service workers and caches. A service worker can cache a response (or the request itself) that still points at http://, and it’ll keep serving that stale reference on repeat visits even after you fix the source. Reproduce a suspected fix in an incognito/uncached session before concluding it didn’t work, and make sure a deploy that changes resource URLs also bumps the service worker/cache version so stale entries get evicted rather than replayed.
• Hard-coded http:// in old content and email/print templates that get reused.

The operational takeaway: bake detection into a recurring audit (crawler + CSP reports), not a launch-day checklist you run once.

How mixed content interacts with HSTS

Mixed content and HSTS solve adjacent but different problems, and conflating them is a common mistake:

• upgrade-insecure-requests fixes sub-resources your own secure page requests — it upgrades the images/scripts/iframes the page pulls in.
• HSTS (Strict-Transport-Security) forces the top-level navigation to your site onto HTTPS — even the very first request, before any redirect fires — and defends against SSL-stripping. Google frames HSTS as a way to “avoid the cost of the 301 redirectA 301 redirect is the HTTP status code for a permanent move: it tells browsers and search engines a URL has moved for good, and it's the strongest signal for consolidating a page's ranking signals onto the new URL. Google says permanent redirects don't cause a loss in PageRank.” and to “defeat attacks like SSL StrippingHSTS (HTTP Strict Transport Security) is a response header that tells browsers to always connect to your site over HTTPS — even when a user types or clicks an http:// link — closing the insecure-first-request gap that a plain 301 redirect leaves open..”

They don’t substitute for each other. As MDN spells out, upgrade-insecure-requests “will not ensure that users visiting your site via links on third-party sites will be upgraded to HTTPS for the top-level navigation and thus does not replace the Strict-Transport-Security (HSTS) header.” A fully hardened setup uses both: upgrade-insecure-requests (or clean source URLs) so the secure page has no insecure cargo, and HSTS so nobody reaches the site over HTTP in the first place. And the usual HSTS caution still applies — Google: “Don’t enable HSTS until you’re certain your site operation is robust enough to avoid ever deploying HTTPS with certificate validation errors,” and preloading is close to a one-way door.

Does mixed content hurt SEO directly?

Lead with the direct effects, because they’re the ones you actually control: mixed content is first a security and functional problem. Blocked active mixed content breaks renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. and interactivity outright — a missing stylesheet or script is a real regression regardless of what a search engine makes of it. That’s reason enough to fix it before you think about rankings at all.

The SEO consequences are real but conditional, not direct or guaranteed. Current official Google guidance does not establish fixing mixed content as a direct ranking boost — the HTTPS ranking signal itself is scheme-based (whether the URL starts with https://), not a sub-resource cleanliness check, so a stray insecure image doesn’t by itself cost you “the HTTPS signal.” But downstream effects can still show up depending on what’s actually broken: if GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. renders a page whose CSS or JS was blocked as mixed content, it may index a broken or incomplete version; a downgraded security indicator can hurt user trust, engagement, and conversions even with no ranking change at all; and Google’s general preference for HTTPS canonicals is itself conditional — invalid certificates, insecure dependencies, HTTPS-to-HTTP redirects, or conflicting canonical signals elsewhere on the page can all change which URL gets chosen, independent of mixed content specifically. Treat rendering, indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed., canonicalizationHow search engines pick one canonical URL among duplicates and consolidate signals onto it., and analytics effects as things to verify on your own pages, not universal outcomes to promise — and fix mixed content for the security and functional reasons first.

This sits inside the broader HTTPS for SEOHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.' topic, which covers the migration playbook, the ranking-signal weight, and HSTS in full; if you’re also debugging the certificate itself (chain errors, expiry, DV/OV/EV), that’s a sibling deep dive.

AI summary

A condensed take on the Advanced version:

• Mixed contentMixed content is when a page served over HTTPS loads a sub-resource — a script, stylesheet, image, iframe, or similar — over insecure HTTP. Browsers' current taxonomy is upgradable versus blockable; active mixed content (scripts, styles, iframes) is blocked, and passive mixed content (images, audio, video) is warned about or increasingly auto-upgraded, with exceptions like CORS-enabled images and srcset/picture candidates that are blockable, not upgradable. = an HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.' page loading a sub-resource over HTTP. It’s about resources the page loads, not links it contains — an anchor to an HTTP page (or any top-level HTTP navigation) is not mixed content, and neither is an insecure download (a related but separate boundary).
• Current taxonomy is upgradable/blockable; active/passive is the older but still- useful blast-radius framing. Active (scripts, stylesheets, iframesHTML element that displays one webpage inside another — how embeds work., XMLHttpRequest/fetch — anything the browser executes) is blocked because a tampered script can rewrite the page; it’s the launch-day regression, fix it first. Passive (images, audio, video) historically loaded with a downgraded padlock and is now increasingly auto-upgraded or blocked. Exceptions to the general pattern: CORS-enabled image requests are force-failed rather than upgraded, srcset/<picture> candidates are blockable (not upgradable) like plain img src is, IP-address hosts are blocked rather than upgraded, and nested contexts/workers and local/loopback origins have their own nuances.
• Detect across three layers, not one: fetched source (a crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. like Ahrefs Site Audit or Screaming Frog, site-wide), rendered/runtime state (the Chrome DevTools console/Security panel, per-page — exact wording is browser/version specific, confirmed against Chrome as of 2026-07), and real user sessions (Content-Security-Policy-Report-Only violation reports, the production long tail including third-party tags and consent-gated resources). A clean result at one layer doesn’t clear the others.
• Fix at the source, after verifying the HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.' equivalent actually works: point every sub-resource at https://; relative/protocol-relative paths are fine only once you’ve verified ownership and the page’s real base-URL behavior, not a default. At scale, back up the database and dry-run any replacement — naive string-replace can corrupt serialized/structured CMSA content management system (CMS) is software that lets users create, manage, and publish digital content — like blog posts and pages — without writing raw code. WordPress, Drupal, and Joomla are the most common open-source CMS platforms. data — then fix the remaining template/config files. Watch for service workers/caches replaying stale http:// references after the source is fixed.
• upgrade-insecure-requests (a CSP header) rewrites in-scope http:// sub-resource requests — including cross-origin ones — to https:// before they’re sent and before mixed-content/CSP checks run, a safety net with no HTTP fallback if the upgrade fails. It does not upgrade top-level navigation to third-party origins, so it is not a replacement for HSTSHSTS (HTTP Strict Transport Security) is a response header that tells browsers to always connect to your site over HTTPS — even when a user types or clicks an http:// link — closing the insecure-first-request gap that a plain 301 redirect leaves open., and putting the directive itself in report-only mode is a no-op — monitor with a separate report-only policy instead.
• block-all-mixed-content is deprecated/obsolete, and redundant once upgrade-insecure-requests is deployed (the upgrade runs first, so block-all has nothing left to block).
• It recurs because the CMS database, themes/plugins, service workers/caches, and ad/analytics tags keep reintroducing http:// URLs — audit on a schedule, not once.
• SEO impact is conditional, not direct: current Google guidance doesn’t establish a direct ranking boost from fixing mixed content, and the HTTPS signal is scheme-based. But blocked active resources can make GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. render/indexStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. a broken page, the padlock downgrade costs trust, and Google’s HTTPS-canonical preference is itself conditional on things like certificate validity and conflicting signals — not a guarantee tied to mixed content specifically.

Official documentation

Primary-source documentation from Google and the browser/standards teams.

Google / web.dev

• What is mixed content? — the definition, and the active vs. passive split with browser behavior.
• Fixing mixed content — finding it, fixing sub-resource URLs, upgrade-insecure-requests, and CSP reporting.
• Enable HTTPS on your servers — relative/protocol-relative URLs, the HTTP <iframe> note, and HSTSHSTS (HTTP Strict Transport Security) is a response header that tells browsers to always connect to your site over HTTPS — even when a user types or clicks an http:// link — closing the insecure-first-request gap that a plain 301 redirect leaves open. guidance.
• Preventing mixed content is one part of Google’s HTTPS guidance — the surrounding site-move/migration playbook mixed contentMixed content is when a page served over HTTPS loads a sub-resource — a script, stylesheet, image, iframe, or similar — over insecure HTTP. Browsers' current taxonomy is upgradable versus blockable; active mixed content (scripts, styles, iframes) is blocked, and passive mixed content (images, audio, video) is warned about or increasingly auto-upgraded, with exceptions like CORS-enabled images and srcset/picture candidates that are blockable, not upgradable. fixes sit inside.

MDN / standards

• CSP: upgrade-insecure-requests — what it upgrades, what it doesn’t, and why it doesn’t replace HSTS.
• CSP: block-all-mixed-content — the deprecated/obsolete blocking directive.
• MDN — Mixed content — the browser-behavior reference for blockable vs. upgradable content.
• Content Security Policy (CSP) — the header these directives live in, including reporting.

Quotes from the source

On-the-record definitions from Google’s web.dev and the MDN standards docs. Each link is a deep link that jumps to the quoted passage where the platform supports it.

Google / web.dev — what mixed contentMixed content is when a page served over HTTPS loads a sub-resource — a script, stylesheet, image, iframe, or similar — over insecure HTTP. Browsers' current taxonomy is upgradable versus blockable; active mixed content (scripts, styles, iframes) is blocked, and passive mixed content (images, audio, video) is warned about or increasingly auto-upgraded, with exceptions like CORS-enabled images and srcset/picture candidates that are blockable, not upgradable. is

• “A page has mixed content when its initial HTML is loaded over a secure HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.' connection, but other resources (such as images, videos, stylesheets, and scripts) are loaded over an insecure HTTP connection.” Source
• “Active mixed content poses a greater threat than passive mixed content.” Source
• Active mixed content “includes scripts, stylesheets, iframesHTML element that displays one webpage inside another — how embeds work., and any other code the browser can download and execute,” and “Most browsers already block this type of content by default to protect users.” Source
• Passive mixed content, “including images, video, and audio,” “doesn’t interact with the rest of the page.” And: “Until recently, passive mixed content was loaded in all browsers, because blocking it would have broken many websites. This is now beginning to change.” Source

Google / web.dev — detecting and fixing

• “You can use content security policy to collect reports of mixed content on your site. To enable this feature, set the Content-Security-Policy-Report-Only directive by adding it as a response header for your site.” Source
• “The upgrade-insecure-requests CSP directive instructs the browser to upgrade insecure URLs before making network requests.” Source
• “Make sure intrasite URLs and external URLs don’t depend on a specific protocol. Use relative paths or leave out the protocol as in //example.com/something.js.” Source

MDN — upgrade-insecure-requests and its limits

• “The HTTP Content-Security-Policy (CSP) upgrade-insecure-requests directive instructs user agentsA user agent is the HTTP request header a client (browser, crawler, or bot) sends to identify itself. For crawlers, a short user-agent token — a substring of that string — is what robots.txt rules actually target. to treat all of a site’s insecure URLs (those served over HTTP) as though they have been replaced with secure URLs (those served over HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.').” Source
• “However, top-level navigation requests whose target is a different origin will not be upgraded.” Source
• “The upgrade-insecure-requests directive will not ensure that users visiting your site via links on third-party sites will be upgraded to HTTPS for the top-level navigation and thus does not replace the Strict-Transport-Security (HSTSHSTS (HTTP Strict Transport Security) is a response header that tells browsers to always connect to your site over HTTPS — even when a user types or clicks an http:// link — closing the insecure-first-request gap that a plain 301 redirect leaves open.) header.” Source

MDN — block-all-mixed-content is legacy

• “The HTTP Content-Security-Policy (CSP) block-all-mixed-content directive prevents loading any assets over HTTP when the page uses HTTPS.” But it is marked deprecated and “obsolete in the specification,” because “Content that isn’t blocked is now always upgraded to a secure connection, so this directive is not needed.” Source

Mixed-content checklist

Run this during and after an HTTP→HTTPS migrationAn HTTP to HTTPS migration is the process of moving every URL on a site from the insecure http:// scheme to the encrypted https:// scheme — installing a TLS certificate and 301-redirecting each old URL to its secure equivalent. Done correctly, it doesn't lose rankings or PageRank., then on a recurring basis:

Find it

• Loaded key templates (home, product, article, checkout) over HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.' with the Chrome DevTools console open and noted every “Mixed ContentMixed content is when a page served over HTTPS loads a sub-resource — a script, stylesheet, image, iframe, or similar — over insecure HTTP. Browsers' current taxonomy is upgradable versus blockable; active mixed content (scripts, styles, iframes) is blocked, and passive mixed content (images, audio, video) is warned about or increasingly auto-upgraded, with exceptions like CORS-enabled images and srcset/picture candidates that are blockable, not upgradable.” message.
• Ran a full crawl (Ahrefs Site Audit or Screaming Frog) and pulled the list of pages referencing http:// sub-resources.
• Set Content-Security-Policy-Report-Only with a reporting endpoint to catch the production long tail (per-user, per-page, and third-party tags).

Fix it (active first)

• All active references fixed: <script>, <link rel="stylesheet">, <iframe>, fetch/XMLHttpRequest, fonts — these are blocked, so they break the page.
• All passive references fixed: <img>, <audio>, <video>, and their <source>/poster URLs.
• CMSA content management system (CMS) is software that lets users create, manage, and publish digital content — like blog posts and pages — without writing raw code. WordPress, Drupal, and Joomla are the most common open-source CMS platforms. database replacement (http://yourdomain → https://yourdomain) for pasted content — backed up, dry-run with application-aware tooling, not a raw string-replace against serialized/structured fields.
• Theme/plugin hard-coded http:// asset URLs foundA 302 (\"Found\") is a temporary redirect: it forwards users to a new URL while telling search engines the original URL should stay in the index. It's a weak canonicalization signal, not the zero-equity dead end of SEO folklore. and patched.
• Service worker/cache entries reproduced in an uncached session, and the cache/service-worker version bumped so stale http:// references don’t replay.
• Third-party tags (ads, analytics, chat, embeds) confirmed to load over HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.' — or the vendor pushed / the tag dropped.

Backstop and verify

• Content-Security-Policy: upgrade-insecure-requests header set as a safety net (understanding it does not replace HSTSHSTS (HTTP Strict Transport Security) is a response header that tells browsers to always connect to your site over HTTPS — even when a user types or clicks an http:// link — closing the insecure-first-request gap that a plain 301 redirect leaves open.).
• Re-crawled and re-checked the console — zero blocked active resources, clean padlock on the checked pages.
• Mixed-content detection added to the recurring audit, not just the launch checklist (plugin updates and new content reintroduce it).

Which fix does this mixed-content case need?

Work down from the symptom.

Is the insecure thing a resource the page loads, or a link the page contains?

• A link (<a href="http://…">) → not mixed contentMixed content is when a page served over HTTPS loads a sub-resource — a script, stylesheet, image, iframe, or similar — over insecure HTTP. Browsers' current taxonomy is upgradable versus blockable; active mixed content (scripts, styles, iframes) is blocked, and passive mixed content (images, audio, video) is warned about or increasingly auto-upgraded, with exceptions like CORS-enabled images and srcset/picture candidates that are blockable, not upgradable.. Leave it (optionally point it at HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.' for referral-data cleanliness). Stop here.
• A loaded resource (script, style, iframeHTML element that displays one webpage inside another — how embeds work., image, font, media, fetch) → keep going.

Is the resource available over HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.'?

• Yes, and you’ve verified it (valid cert, returns the intended content) → change the reference to https:// (the safe default), or a relative / protocol-relative path only if you own the resource and have checked the page’s base-URL behavior. This is the real fix. Done.
• No / unsure → is it first-party (your own asset)?
  • First-party → serve it over HTTPS (it’s your server; you can). Then fix the reference as above.
  • Third-party (a vendor tag, ad, embed) → ask the vendor for an HTTPS endpoint; if they don’t have one, replace or drop the tag. upgrade-insecure-requests will try to upgrade it, but if the vendor has no HTTPS version the upgraded request just fails.

Is it active or passive?

• Active (script / stylesheet / iframe / fetch / font) → highest priority — it’s blocked, so the page is functionally broken until you fix it.
• Passive (image / audio / video) → fix it too, but it’s lower urgency (padlock downgrade / possible future block, not an immediate break).

Do you want a safety net for whatever you missed?

• Set Content-Security-Policy: upgrade-insecure-requests. Remember: net, not substitute — and it doesn’t cover third-party top-level navigation, so it is not a stand-in for HSTSHSTS (HTTP Strict Transport Security) is a response header that tells browsers to always connect to your site over HTTPS — even when a user types or clicks an http:// link — closing the insecure-first-request gap that a plain 301 redirect leaves open..

Do you also need to force the top-level page onto HTTPS for first-time / third-party referrals?

• That’s HSTS, a separate control. Add Strict-Transport-Security — but only once your certificate operation is rock-solid, because HSTS (especially preloadResource hints are <link> elements (or equivalent HTTP Link headers) that tell the browser to do network work — DNS lookups, connection setup, or fetching a resource — earlier than it would discover the need on its own. The main ones are dns-prefetch, preconnect, preload, modulepreload, and prefetch.) is close to a one-way door.

The mental models

1. Resources, not links. Mixed contentMixed content is when a page served over HTTPS loads a sub-resource — a script, stylesheet, image, iframe, or similar — over insecure HTTP. Browsers' current taxonomy is upgradable versus blockable; active mixed content (scripts, styles, iframes) is blocked, and passive mixed content (images, audio, video) is warned about or increasingly auto-upgraded, with exceptions like CORS-enabled images and srcset/picture candidates that are blockable, not upgradable. is about what the secure page loads, never about where it links. If you can’t decide whether something counts, ask: does the browser fetch this to build the current page? Yes → possible mixed content. It just takes me to another page → not mixed content.

2. Triage by what the browser does, not by severity in the abstract. Active (scripts, styles, iframesHTML element that displays one webpage inside another — how embeds work.) is blocked → it’s a functional bug, fix first. Passive (images, media) is warned/upgraded → fix next. The browser’s own behavior is your priority queue.

3. Detection is a funnel: verify → inventory → catch the tail. DevTools console (one page, exact), crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. (whole site, the bulk), CSP reports (production, third-party, per-user long tail). No single tool sees all three.

4. Fix the source; net the rest. Clean the actual URLs — DB, templates, tags. Then add upgrade-insecure-requests as a backstop for what slips through. The directive is insurance, not a repair.

5. Two different “force HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.'” jobs, two different tools. upgrade-insecure-requests upgrades the sub-resources your secure page requests. HSTSHSTS (HTTP Strict Transport Security) is a response header that tells browsers to always connect to your site over HTTPS — even when a user types or clicks an http:// link — closing the insecure-first-request gap that a plain 301 redirect leaves open. forces the top-level navigation to your site onto HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.'. They don’t overlap and one never replaces the other — a hardened site uses both.

6. It’s a recurring audit, not a one-time task. The CMSA content management system (CMS) is software that lets users create, manage, and publish digital content — like blog posts and pages — without writing raw code. WordPress, Drupal, and Joomla are the most common open-source CMS platforms. database, plugin/theme updates, and third-party tags keep reintroducing http://. Treat detection as a scheduled sweep, or it silently comes back.

Mixed-content anti-patterns

Mistakes that leave insecure content live — or paper over it instead of fixing it.

• Treating upgrade-insecure-requests as the fix. It’s a net. If the resource has no HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.' version the upgraded request fails, and you’ve hidden a broken dependency instead of resolving it. Clean the source URLs; use the directive for the tail.
• Assuming a code deploy cleaned the database. In a CMSA content management system (CMS) is software that lets users create, manage, and publish digital content — like blog posts and pages — without writing raw code. WordPress, Drupal, and Joomla are the most common open-source CMS platforms., most http:// image and embed URLs live in content rows, not templates. A template fix leaves every old post mixed. Run the DB search-and-replace.
• Deprioritizing active mixed contentMixed content is when a page served over HTTPS loads a sub-resource — a script, stylesheet, image, iframe, or similar — over insecure HTTP. Browsers' current taxonomy is upgradable versus blockable; active mixed content (scripts, styles, iframes) is blocked, and passive mixed content (images, audio, video) is warned about or increasingly auto-upgraded, with exceptions like CORS-enabled images and srcset/picture candidates that are blockable, not upgradable. because “it’s just a warning.” It isn’t — active is blocked. A blocked stylesheet or script is a functional outage, not a cosmetic nag.
• Spot-checking the homepage and calling it done. Mixed content hides on product pages, old blog posts, and paths only some users hit. Crawl the whole site and use CSP reporting for what the crawl can’t reach.
• Ignoring third-party tags. An ad, analytics, or chat vendor still calling http:// is mixed content you can’t fix in your own repo. Chasing it in your codebase forever is wasted effort — push the vendor or drop the tag.
• Using block-all-mixed-content on a new build. It’s deprecated and obsolete. Reach for upgrade-insecure-requests instead.
• Confusing upgrade-insecure-requests with HSTSHSTS (HTTP Strict Transport Security) is a response header that tells browsers to always connect to your site over HTTPS — even when a user types or clicks an http:// link — closing the insecure-first-request gap that a plain 301 redirect leaves open.. One upgrades sub-resources; the other forces top-level HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.' and defends against SSL strippingHSTS (HTTP Strict Transport Security) is a response header that tells browsers to always connect to your site over HTTPS — even when a user types or clicks an http:// link — closing the insecure-first-request gap that a plain 301 redirect leaves open.. Shipping one and assuming you’ve covered the other leaves a real gap.
• Leaving detection out of the recurring audit. Fixing it once and never checking again guarantees a plugin update or a pasted http:// image brings it back unnoticed.

Mixed content — cheat sheet

Active vs. passive

Detection stack

The CSP directives

Don’t-confuse-these

One-liner fix (CMSA content management system (CMS) is software that lets users create, manage, and publish digital content — like blog posts and pages — without writing raw code. WordPress, Drupal, and Joomla are the most common open-source CMS platforms.): DB search-and-replace http://yourdomain → https://yourdomain, then patch templates/plugins, then set upgrade-insecure-requests.

Find mixed content — snippets

1. Crawl one page from the command line

Grab a page and flag any insecure src/href sub-resources left in the HTML.

macOS / Linux

# Flag insecure script/img/link/iframe/source references on a single URL
curl -s https://example.com/ \
  | grep -Eo '(src|href)="http://[^"]+"' \
  | sort -u

Windows (PowerShell)

(Invoke-WebRequest -Uri "https://example.com/").Content `
  | Select-String -Pattern '(src|href)="http://[^"]+"' -AllMatches `
  | ForEach-Object { $_.Matches.Value } | Sort-Object -Unique

This only sees the raw HTML — resources injected by JavaScript won’t show up, which is exactly why you also use DevTools and a real crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index..

2. Chrome DevTools Console — list insecure resources on the rendered page

Paste into the console on the HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.' page to catch even JS-inserted references:

// Every element with an http:// resource attribute in the live DOM
[...document.querySelectorAll('[src],[href],[srcset],[data-src]')]
  .filter(el => /^http:\/\//.test(
    el.src || el.href || el.getAttribute('srcset') || el.getAttribute('data-src') || ''
  ))
  .map(el => ({ tag: el.tagName, url: el.src || el.href }));

The browser also logs blocked active mixed contentMixed content is when a page served over HTTPS loads a sub-resource — a script, stylesheet, image, iframe, or similar — over insecure HTTP. Browsers' current taxonomy is upgradable versus blockable; active mixed content (scripts, styles, iframes) is blocked, and passive mixed content (images, audio, video) is warned about or increasingly auto-upgraded, with exceptions like CORS-enabled images and srcset/picture candidates that are blockable, not upgradable. on its own as Mixed Content: … This request has been blocked; the content must be served over HTTPS. — read those first.

3. Bookmarklet — one-click console dump

Save as a bookmark; click it on any HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.' page to console-log its http:// references:

javascript:(()=>{const h=[...document.querySelectorAll('[src],[href]')].filter(e=>/^http:\/\//.test(e.src||e.href)).map(e=>e.src||e.href);console.log('%cMixed content candidates:','font-weight:bold',h.length);h.forEach(u=>console.log(u));})();

4. Turn on CSP reporting (detect in production)

Add a report-only header so real visitors’ browsers tell you about violations — including third-party tags and pages your crawl misses:

Content-Security-Policy-Report-Only: default-src https:; report-uri /csp-report-endpoint

Report-only reports without enforcing, so you can size the problem safely before switching on upgrade-insecure-requests or enforcement. (The modern equivalent uses report-to with a Reporting-Endpoints header.)

5. The safety-net header (once you’ve fixed the source)

Content-Security-Policy: upgrade-insecure-requests

Remember it doesn’t upgrade third-party top-level navigation and is not a replacement for HSTSHSTS (HTTP Strict Transport Security) is a response header that tells browsers to always connect to your site over HTTPS — even when a user types or clicks an http:// link — closing the insecure-first-request gap that a plain 301 redirect leaves open..

Recurring mixed-content audit SOP

Run this after HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.' launches, CMSA content management system (CMS) is software that lets users create, manage, and publish digital content — like blog posts and pages — without writing raw code. WordPress, Drupal, and Joomla are the most common open-source CMS platforms. or theme releases, tag-manager changes, and on a regular schedule for sites whose content changes frequently.

1. Crawl HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.' pages in raw and rendered modes. Export insecure URLs from src, srcset, stylesheet, iframeHTML element that displays one webpage inside another — how embeds work., media, and fetch/XHR requests; ordinary HTTP anchor links are not mixed contentMixed content is when a page served over HTTPS loads a sub-resource — a script, stylesheet, image, iframe, or similar — over insecure HTTP. Browsers' current taxonomy is upgradable versus blockable; active mixed content (scripts, styles, iframes) is blocked, and passive mixed content (images, audio, video) is warned about or increasingly auto-upgraded, with exceptions like CORS-enabled images and srcset/picture candidates that are blockable, not upgradable..
2. Collect browser evidence. Review DevTools on representative templates and use Content-Security-Policy-Report-Only to capture violations triggered by real visitors and third-party tags.
3. Classify each finding. Mark it active or passive, first-party or third-party, static or JavaScript-injected, and identify the template, database field, plugin, tag, or vendor that owns the source.
4. Fix the source reference. Point it to a working HTTPS resource or a safe relative URL. Do not assume changing http:// to https:// is enough; verify the destination actually supports TLS.
5. Use CSP as a safety net. Add upgrade-insecure-requests only after reviewing the findings. It can reduce exposure, but it does not repair the CMS record or replace HSTSHSTS (HTTP Strict Transport Security) is a response header that tells browsers to always connect to your site over HTTPS — even when a user types or clicks an http:// link — closing the insecure-first-request gap that a plain 301 redirect leaves open..
6. Re-crawl and render. Active mixed-content errors should be zero on tested templates; passive resources should also resolve over HTTPS without fallback.
7. Prevent recurrence. Correct the originating template or editor workflow, retain report-only collection where appropriate, and assign new violations to the system owner.

Symptom → likely cause → fix

Mixed-content release tests

Test 1: rendered template sweep

• Purpose: Catch active and passive resources that raw HTML alone misses.
• Method: Render a representative URL from every template and interaction state; inspect Console and Network output for insecure or blocked requests.
• Expected result: No sub-resource is requested over HTTP and no active content is blocked.
• Failure trigger: Any mixed-content warning, auto-upgrade failure, or missing layout/function caused by a blocked resource.
• Next action: Trace the request to its template, tag, plugin, or stored field; fix the source and rerun the sweep.

Test 2: source and CSP comparison

• Purpose: Detect violations introduced only for real visitors or by third parties.
• Method: Compare crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. findings with Content-Security-Policy-Report-Only events, grouped by blocked URL, page template, directive, and owner.
• Expected result: No unexplained production-only violations remain; known noise is documented and excluded narrowly.
• Failure trigger: A repeatable violation absent from the crawl or an unowned third-party source.
• Next action: Reproduce the visitor state and correct or remove the injecting integration.

Test 3: recurrence test after publishing

• Purpose: Verify the CMSA content management system (CMS) is software that lets users create, manage, and publish digital content — like blog posts and pages — without writing raw code. WordPress, Drupal, and Joomla are the most common open-source CMS platforms. no longer generates new insecure references.
• Method: Publish a test item through the normal editorial workflow, then crawl and render it with the same checks used for production.
• Expected result: Generated markup and loaded resources use valid HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.' URLs.
• Failure trigger: The new page recreates an HTTP reference previously cleaned from older content.
• Next action: Fix the editor default, template, plugin, or content transform before the release proceeds.

Resources worth your time

My speaking

• Better Safe Than Sorry with HTTPS — SMX East 2016 (SlideShare) — my deep-dive on TLS, common HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.' implementation failures, and the migration gotchas that produce mixed contentMixed content is when a page served over HTTPS loads a sub-resource — a script, stylesheet, image, iframe, or similar — over insecure HTTP. Browsers' current taxonomy is upgradable versus blockable; active mixed content (scripts, styles, iframes) is blocked, and passive mixed content (images, audio, video) is warned about or increasingly auto-upgraded, with exceptions like CORS-enabled images and srcset/picture candidates that are blockable, not upgradable. in the first place. (Standing disclaimer: it’s my understanding of these systems, and the adoption stats in it are from 2016.)

My related writing

• The Beginner’s Guide to Technical SEO — where HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.' and mixed content fit in the bigger technical picture.

From around the industry

• What is mixed content? (web.dev / Google) — the canonical definition and the active-vs-passive split.
• Fixing mixed content (web.dev / Google) — the step-by-step: finding it, fixing sub-resource URLs, upgrade-insecure-requests, and CSP reporting.
• MDN — upgrade-insecure-requests — precisely what it upgrades, what it doesn’t, and why it doesn’t replace HSTSHSTS (HTTP Strict Transport Security) is a response header that tells browsers to always connect to your site over HTTPS — even when a user types or clicks an http:// link — closing the insecure-first-request gap that a plain 301 redirect leaves open..
• MDN — block-all-mixed-content — the deprecated blocking directive, for when you inherit it.
• MDN — Mixed content — the browser-behavior reference for blockable vs. upgradable resources.
• Enable HTTPS on your servers (web.dev / Google) — relative/protocol-relative URLs and the surrounding HTTPS setup guidance.

Stats worth citing

• Active mixed contentMixed content is when a page served over HTTPS loads a sub-resource — a script, stylesheet, image, iframe, or similar — over insecure HTTP. Browsers' current taxonomy is upgradable versus blockable; active mixed content (scripts, styles, iframes) is blocked, and passive mixed content (images, audio, video) is warned about or increasingly auto-upgraded, with exceptions like CORS-enabled images and srcset/picture candidates that are blockable, not upgradable. is blocked by default. Google: “Most browsers already block this type of content by default to protect users.” — the reason active mixed content is a functional outage, not a warning. Source
• Active mixed content is the greater threat. Google’s own ranking of the two tiers: “Active mixed content poses a greater threat than passive mixed content.” — right-sizes your triage order. Source
• Passive mixed content is no longer safely “allowed.” Google: “Until recently, passive mixed content was loaded in all browsers … This is now beginning to change.” — the “images are harmless” assumption is expiring. Source
• upgrade-insecure-requests is not a substitute for HSTSHSTS (HTTP Strict Transport Security) is a response header that tells browsers to always connect to your site over HTTPS — even when a user types or clicks an http:// link — closing the insecure-first-request gap that a plain 301 redirect leaves open.. MDN states it plainly: it “does not replace the Strict-Transport-Security (HSTS) header.” — the two controls solve different halves of the problem. Source
• ~89% of the web is on HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.' (W3Techs, 2026; confirm the current figure), which is exactly why leftover http:// sub-resources on an otherwise-secure page are the common failure mode now — the pages are HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.'; the cargo lags behind. Context via the HTTPS hubHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.'.

Test yourself: Mixed Content

Five quick questions on mixed contentMixed content is when a page served over HTTPS loads a sub-resource — a script, stylesheet, image, iframe, or similar — over insecure HTTP. Browsers' current taxonomy is upgradable versus blockable; active mixed content (scripts, styles, iframes) is blocked, and passive mixed content (images, audio, video) is warned about or increasingly auto-upgraded, with exceptions like CORS-enabled images and srcset/picture candidates that are blockable, not upgradable.. Pick an answer for each, then check.

Mixed Content

Mixed content is when a page served over HTTPS loads a sub-resource — a script, stylesheet, image, iframe, or similar — over insecure HTTP. Browsers' current taxonomy is upgradable versus blockable; active mixed content (scripts, styles, iframes) is blocked, and passive mixed content (images, audio, video) is warned about or increasingly auto-upgraded, with exceptions like CORS-enabled images and srcset/picture candidates that are blockable, not upgradable.

Related: HTTPS

Mixed Content

Mixed content happens when the initial HTML of a page loads over a secure HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.' connection, but the page then requests other resources — images, videos, stylesheets, scripts, fonts, iframesHTML element that displays one webpage inside another — how embeds work. — over plain, insecure HTTP. The connection is a mix of secure and insecure, which undermines the guarantees HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.' is supposed to provide: an attacker who can tamper with an HTTP request can, depending on the resource type, read or rewrite part of a page the user believes is fully secure.

Browsers split mixed content into two buckets by how much damage the resource could do:

• Active mixed content — scripts, stylesheets, iframes, XMLHttpRequest/fetch, and anything else the browser executes or that can control the whole page. Because a tampered script can rewrite the entire document, browsers block active mixed content outright. This is the category that visibly breaks a page after an HTTP→HTTPS migrationAn HTTP to HTTPS migration is the process of moving every URL on a site from the insecure http:// scheme to the encrypted https:// scheme — installing a TLS certificate and 301-redirecting each old URL to its secure equivalent. Done correctly, it doesn't lose rankings or PageRank..
• Passive (display) mixed content — images, audio, and video that don’t interact with the rest of the page. Browsers historically loaded it but downgraded the security indicator (no padlock, a “Not fully secure” warning); modern browsers increasingly auto-upgrade or block it too.

You find mixed content across three layers — fetched source (crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor. the HTTPS site), rendered/runtime state (watching the Chrome DevTools console, whose exact wording is browser/version specific), and real user sessions (collecting CSP violation reports). You fix it by first confirming the HTTPS equivalent actually works, then pointing every sub-resource at https://; relative or protocol-relative paths are fine once you’ve verified you own the resource and understand the page’s base-URL behavior, not as a default. You can add the Content-Security-Policy: upgrade-insecure-requests header as a safety net that rewrites lingering http:// sub-resource requests (including cross-origin ones) to https:// before the browser sends them — it has no HTTP fallback if the upgrade fails, and setting the directive itself in report-only mode is a no-op. Ordinary anchor links and other top-level HTTP navigation are not mixed content — they just navigate.

Related: HTTPS

Changelog