Mixed content on 27 homepages: 0 of 10,138 fetched URLs use http://, and 8 sites still send the header that would fix it

FIELD TEST · 2026-09-12 · 30 domains · 27 readable · one pass

Sample and method: the same 30-site panel in use since 2026-08-15, each homepage requested once on 2026-09-12 with a desktop Chrome user agent over HTTP/2, redirects followed, no JavaScript executed. We kept the final response's headers and its HTML, and counted every URL the HTML asks a browser to fetch. Three domains answered 403 to our client — canva.com, medium.com and stackoverflow.com — leaving 27.

Mixed content is an HTTPS page that loads some part of itself over plain HTTP. On 2026-09-12 the HTML of 27 homepages named 10,138 subresource URLs, and none of them began with http://. What survives of the old scheme is small and specific: 24 protocol-relative // URLs on four sites, six http:// hyperlinks on three sites, and a safety net that eight sites still send in their Content-Security-Policy, upgrade-insecure-requests. Two of those eight also send the directive the specification now calls obsolete.

How we measured this

One request per homepage, from outside, with no account anywhere. From the HTML we took the attribute that makes a browser fetch something: src on script, img, iframe, source, video, audio and embed; srcset on img and source; data on object; and href on link elements whose rel is a fetch (stylesheet, preload, modulepreload, prefetch, icons, manifest). Each URL was sorted by scheme. Separately we read every a href, every canonical, alternate, og:image, og:url and twitter:image value, every url, image, logo and sameAs inside JSON-LD, and the Content-Security-Policy header or meta tag.

# Every http:// URL a browser would fetch from this page, before any script runs
curl -sL --compressed -A 'Mozilla/5.0 (Macintosh) Chrome/126.0' https://example.com/ \
  | grep -oiE '(src|srcset|href|data)="http://[^"]+"' | sort | uniq -c

# Does the page ask the browser to upgrade for it?
curl -sI -A 'Mozilla/5.0 (Macintosh) Chrome/126.0' https://example.com/ \
  | grep -i '^content-security-policy' | grep -oiE 'upgrade-insecure-requests|block-all-mixed-content'

Four limits. We did not execute JavaScript, so a resource that a script injects later is not counted here, and on a page like reddit.com, whose HTML is an 8 KB shell, almost everything is injected later. We did not parse CSS, so a background-image: url(http://…) inside a stylesheet is invisible to this pass. A homepage is one URL, and the page most likely to carry an old http:// image is a ten-year-old blog post, not the front door. And we counted URL strings, not network requests: a browser that sees http:// in an img would rewrite it to https:// before fetching, which is exactly the behaviour this survey is about.

Mixed content on this panel: zero of 10,138 fetched URLs start with http://

The number that the word mixed content is about is zero on this panel. Of the 10,138 URLs, 1,507 are the kind a browser blocks outright when insecure (scripts, stylesheets, preloads, frames) and 8,631 are the kind it tries to upgrade (images, media, icons). Neither group contained a single http://. The 492 metadata URLs (canonical, alternate, Open Graph, Twitter card) and the 398 URL values inside JSON-LD were clean as well.

"Upgrade" is upgrade-insecure-requests in the page's CSP; "both" means block-all-mixed-content is there too. The HSTS column is the same 25 of 27 we reported on 2026-08-30 in HSTS on 27 homepages, still with wired.com and railway.com as the two without it.

What is left of http:// is 30 strings on six sites

The residue splits into two kinds, and neither one is mixed content. Twenty-four fetched URLs are written with no scheme at all, //host/path, the form that inherits whatever scheme the page has. Twenty-one of them are on github.com, all images on the same asset host. The other three are one third-party script each, on netlify.com, techcrunch.com and webflow.com. On an HTTPS page these resolve to https://, so the browser never sees an insecure request; the notation is a fossil from the years when a page might be served either way.

The six http:// hyperlinks are the second kind. A link is navigation, not a subresource, and the Mixed Content specification says so: navigation requests to a top-level browsing context "are not considered mixed content" (W3C Mixed Content, Candidate Recommendation Draft of 23 February 2023, read 2026-09-12). We followed all four distinct targets on 2026-09-12; each answered with one redirect to an https:// page. The odd one is bbc.com, which links to its own domain over plain HTTP, twice, from a page that sends HSTS; the browser will upgrade that click before it leaves. Wikipedia adds 369 more scheme-less hyperlinks, one per language edition, which we list here for completeness and count as nothing.

Eight sites send upgrade-insecure-requests, and two still send the obsolete one

The directive tells the browser to rewrite the page's own insecure requests before sending them, and it exists, in the words of its specification, "to reduce the burden of migrating websites from insecure origins by reducing the negative side effects of mixed content blocking" (W3C Upgrade Insecure Requests, Editor's Draft of 13 October 2022, read 2026-09-12). Nineteen of the 27 homepages carry a Content-Security-Policy at all — 18 as a header, gitlab.com as a meta tag — and eight of the 19 include it: arstechnica.com, cloudflare.com, figma.com, github.com, mozilla.org, nytimes.com, stripe.com and techcrunch.com. On this panel every one of the eight has zero http:// subresources to upgrade, so the directive is insurance against a future edit, not a fix for a present fault. The New York Times puts it first of 13 directives; Cloudflare puts it last of 14, at the end of a 1,959-character header.

Two of the eight, arstechnica.com and techcrunch.com, also send block-all-mixed-content. The Mixed Content specification has a section for it under the heading "Obsolescences": "An earlier version of this specification defined the block-all-mixed-content CSP directive. It is now obsolete, because all mixed content is now blocked if it can't be autoupgraded." The same paragraph keeps the other directive alive: "upgrade-insecure-requests … is not obsolete because it allows developers to upgrade blockable content." Sending both is harmless. It is also a date stamp on when that policy was last read through.

One policy on the panel goes the other way. gitlab.com's meta CSP lists http: as an allowed scheme in default-src, script-src, style-src and img-src. That does not create mixed content; the browser's mixed content rules run regardless of what the policy permits. It means the policy would not be the thing that caught an http:// script if one were ever added.

Why the browser, not the site, is the reason this number is zero

Chrome stopped treating an insecure image as a warning and started rewriting it. The plan, published on 2019-10-03, was that "mixed audio and video resources will be autoupgraded to https://, and Chrome will block them by default if they fail to load over https://" in Chrome 80, with images to follow (Chromium Blog, No More Mixed Messages About HTTPS, read 2026-09-12). The image step slipped; the post's own update says "delayed until at least Chrome 84", and the Chrome Platform Status entry for "Autoupgrade Image Mixed Content" records it as enabled by default in milestone 86 (read 2026-09-12). Scripts, stylesheets and frames were already blocked outright before any of that.

The specification now describes the web that resulted. Content is either "upgradeable" — image, video and audio requests, which the browser rewrites to https:// and drops if that fails — or "blockable", which is everything else. There is one catch worth copying down: the upgradeable category "does not include img elements that use srcset or picture", because the imageset destination was defined as blockable before upgrades existed, and "the decision was to not upgrade any content that was previously defined as blockable" (W3C Mixed Content, same document). An http:// candidate inside a srcset is blocked, not upgraded. On this panel 6,907 of the 8,631 upgradeable-type URLs came from srcset attributes, so that carve-out is most of the category, not a footnote.

A padlock in the address bar is a promise about the chain, not the lock. One http:// link in the chain, and the browser either replaces it or cuts it.

Google Search does not use the phrase at all

We looked for a Search-side rule and did not find one. The Search Console HTTPS report lists six reasons an HTTPS URL is not the indexed one — "HTTP marked with canonical tag", "HTTPS has invalid certificate", "Sitemap points to HTTP", "HTTPS has redirect", "HTTPS URL is roboted" and "HTTPS not evaluated" — and mixed content is not among them (HTTPS report, read 2026-09-12). The page experience guidance asks one question about the subject, "Are your pages served in a secure fashion?", and stops there. The JavaScript SEO basics page says Google Search "runs JavaScript with an evergreen version of Chromium" (Last updated 2026-03-04), which is the browser whose behaviour is described above; whether Google's renderer applies the same upgrade-and-block rules to an http:// stylesheet is not something we could find written down, and we did not test it. If a blocked stylesheet or script changes what the renderer sees, the place to look is the rendered HTML in URL Inspection, not this survey.

What this means for you

If your own site is a few years old, the front page is the wrong place to look; the residue lives in old posts and in CSS. Run the first command above against your five oldest URLs, then decide on the header.

• Send Content-Security-Policy: upgrade-insecure-requests once, at the edge, if any part of the site was ever served over HTTP. It costs one header and turns a future http:// image into an https:// request instead of a broken one.
• Fix http:// inside srcset by hand. The browser will not upgrade those; it blocks them.
• Check that every host you upgrade to actually answers on 443. The specification is explicit that a failed upgrade has "no fallback".
• Do not add block-all-mixed-content to a new policy. The specification calls it obsolete, and the browser already does what it asked for.
• Do not expect the directive to fix http:// hyperlinks to other sites. "Links to third-party sites will not be upgraded", per the same specification; a link is not a subresource.

If the resource you are upgrading is one an AI crawler needs — a stylesheet that hides nothing, a script that renders the text — check afterwards that the crawler can still reach it with the AI crawler accessibility check. The unsafe-inline half of the same CSP is a separate survey: unsafe-inline on 27 homepages.

Common questions

How did you measure this?

One curl request per homepage on 2026-09-12, HTTP/2, desktop Chrome user agent, redirects followed, compressed transfer, headers and body both saved. A Python HTML parser then read every fetch-triggering attribute and every link, sorted the URLs by scheme, and read the CSP from the header or the meta tag. Every number above was recomputed from the saved files by a script; nothing was typed in by hand. A second pass followed the four http:// link targets.

What does "mixed content: the page at was loaded over HTTPS but requested an insecure" mean?

It is the browser console telling you which line of your HTML or CSS asked for an http:// resource, and what it did about it. The message ends in one of two ways: the request was upgraded (images, audio, video) or it was blocked (scripts, stylesheets, frames, fetches, and anything inside srcset). Either way the fix is the same edit: change the scheme, or remove the scheme so the URL inherits the page's.

Does mixed content affect SEO?

Not by any Google Search document we could find on 2026-09-12. The HTTPS report checks whether the indexed URL is HTTPS, not what the page loads. What a blocked stylesheet or script does to Google's renderer is the only plausible route, and we have not measured it; if your site has a blocked script that builds the page, that is a rendering problem first, not a "mixed content" one.

Is upgrade-insecure-requests enough on its own?

For your own page's subresources, yes, provided every upgraded host answers over HTTPS; there is no fallback if one does not. It does not touch links to other sites, and it does not fix a canonical or sitemap that says http://, which is a Search Console matter, not a browser one.

Why did 27 large sites end up at zero?

We did not ask them, so this is a limitation of the survey rather than a finding. What the data shows is only the end state: no http:// in any fetched URL, HSTS on 25 of 27, and eight sites keeping the upgrade directive on even though they have nothing left to upgrade.