A site moves from http:// to https://, every page redirects correctly, and the padlock shows up — except on the one page where a hard-coded http://image URL or an old embed snippet survived the migration untouched. The browser either refuses to load it or shows the page as "not fully secure", and neither shows up unless you check the actual network requests a page makes, not just whether the URL bar says https.

Two different outcomes, not one

• Blocked (active content) — scripts, stylesheets, iframes and form submissions over http:// are refused outright by modern browsers. These are not a warning; the resource simply never loads, which can silently break layout or functionality.
• Flagged (passive content) — images, video, audio and CSS backgrounds over http:// still load, but Chrome and Firefox mark the whole page as not fully secure, which is exactly the kind of signal that quietly erodes trust without an obvious error.

Where these usually come from

Almost always one of three places: an image URL typed directly into old article content before the domain had HTTPS, a third-party embed (a widget, a tracking pixel, an old ad snippet) whose provider never updated their own embed code, or a CSS background image set with an absolute http:// URL in a theme file nobody has touched since before the migration.

How this differs from the Canonicalization Checker

The WWW/HTTPS Canonicalization Checker confirms the page itself redirects to one canonical https:// address. This tool checks what that page then loads once you're on it — a page can pass canonicalization perfectly and still reference http:// resources internally.

Frequently asked

Does mixed content actually hurt SEO?

Not as a direct ranking factor, but it is a real user-trust and functionality problem — and Google has said HTTPS is a (small) ranking signal in the first place, so a page that undermines its own HTTPS defeats the point of having migrated at all.

Why would a resource still load if it's "blocked"?

It won't — "blocked" here means active content the browser refuses outright, not merely discouraged. If a script is listed as blocked, treat it as already broken in production, not as a future risk.

Does this tool send my page anywhere?

No — one request goes to the page itself to read its HTML; everything else runs on that response.