Originally published on the Merlonix blog.
A broken-link checker does one well-defined thing: it walks the <a href> links on a page, fetches each target, and flags the ones that come back wrong — a 4xx, a 5xx, a timeout, a connection that never opens. That answers a real question: which links point at something that isn't there. Run a clean scan and you get a green report and a reasonable feeling that the page is healthy.
But "every link resolves" and "this page works in a browser" are not the same claim, and the gap between them is a resource class a status-code check is structurally blind to. The resource most likely to visibly break an HTTPS page doesn't fail with a status at all. It returns 200. It's mixed content — an http:// subresource loaded by an https:// page — and because the resource genuinely exists, a checker that grades links on their HTTP status waves it straight through.
The 200 that still breaks the page
When a page served over https:// pulls in a subresource over plaintext http:// — an image, a script, a stylesheet, an iframe — that's mixed content. The subresource itself is usually fine: request it directly and it's a healthy 200. Nothing is "broken" in the sense a link checker means. The break happens in the browser, on the security boundary, and it depends on what kind of resource it is:
