A Broken-Link Check Counts 404s. The Resource That Breaks Your Padlock Returns 200.

A broken-link checker performs a specific task: it examines the hyperlinks on a webpage, retrieves the content of each link, and marks any links that yield error responses - 4xx, 5xx, timeouts, or connections that never establish. This provides a valuable answer to a pertinent question: which links point to something that doesn't exist.

Running a comprehensive scan yields a green report and a reasonable assurance that the webpage is in good health. Nevertheless, the statement "every link resolves" and "this page works in a browser" are not synonymous claims, and the difference between them lies in a resource class, a status-code check is structurally incapable of discerning.

The resource most prone to visibly breaking an HTTPS webpage does not 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 based on their HTTP status passes it seamlessly. The 200 that still breaks the page.

When a webpage served over https:// incorporates a subresource over plaintext http:// - an image, a script, a stylesheet, or an iframe - that constitutes mixed content. The subresource is typically fine: request it directly and it returns a healthy 200. Nothing is broken in the conventional sense that a link checker implies. The break occurs in the browser, on the security boundary, and it hinges on the type of resource: active mixed content - a script, a stylesheet link, or an iframe over http:// - is outright blocked.

The browser refuses to load it on a secure page. A blocked script leads to the dependent JavaScript silently not executing; a blocked stylesheet results in the page rendering without styling. Neither scenario triggers a 404. The file was reachable, the browser merely refuses to use it. Passive mixed content - an img, video, or audio over http:// - modern browsers attempt to automatically upgrade to https://, and if that secure version doesn't exist, they block it too.

Irrespective of the outcome, the padlock loses its pristine appearance: the address bar transitions to "Not fully secure," and for blocked cases, you encounter a missing image on a page whose image URL returns a perfectly good 200 over http. Thus, the failure is both real and user-visible - a dead script, an unstyled page, a broken image, a downgraded padlock - yet invisible to any tool that determines "broken" by fetching a URL and examining its status code.

The URL is not broken. The combination of a secure page and an insecure subresource is. Why it remains undetected silently. Mixed content is seldom typified intentionally. It infiltrates your site on a timeline beyond your control: A third-party embed - an analytics snippet, a chat widget, an ad tag, an old badge - hardcodes an http:// script URL.

A Content Delivery Network (CDN) or asset host is referenced with an absolute http:// URL that endures a change to HTTPS because nothing ever refreshes it to identify the issue. A protocol migration shifts the site to HTTPS but leaves absolute http:// URLs embedded in content, a theme, or a database field. A Content-Security-Policy (CSP) that initially allowed upgrade-insecure-requests gets relaxed to accommodate one stubborn widget, and every previously-upgraded subresource quietly reverts.

Each of these scenarios transmits green through a broken-link check, because each URL responds with a 200. How to actually detect it. Mixed content is identified by analyzing the protocol of the subresources that a secure page loads, rather than the status of its links: The browser console serves as the definitive source: it logs warnings for every upgraded or blocked resource, and the padlock's site-information panel indicates that the page is not fully secure.

This method catches resources injected by client-side JavaScript, which a static scan of the served HTML cannot detect. Content Security Policy (CSP) transforms it into a signal you don't have to visually inspect: Content-Security-Policy-Report-Only: block-all-mixed-content (or reporting directives) will flag every insecure subresource without disrupting functionality, enabling you to identify them before enforcing them.

A checker that examines subresource protocols - not just link statuses - can identify these instances in a single pass. The free broken-links checker accomplishes both tasks in one scan: it traverses the page's hyperlinks and reports the ones that return an error status, time out, or fail to connect, and separately, it reads the page's images, scripts, stylesheets, and iframes.

It flags every subresource loaded over http:// on an https:// page as mixed content, complete with the exact insecure URLs. However, resources injected later by client-side JavaScript still necessitate monitoring through the browser console. Nonetheless, the majority of real mixed-content issues stem from hardcoded http:// embeds in the served HTML.

These are precisely the ones addressed by the checker. No sign-up, one page at a time. What a link check is designed for - and what to scrutinize beyond it. A broken-link check is not the wrong tool; it's a narrowly focused one. Dead outbound links, a deleted product page still linked from your navigation, a 5xx response on a resource you own - all genuine, all warranting attention, and all what a status check is intended for.

However, do not interpret "every link resolves" as "this page is fine over HTTPS." The combination of a secure page and an insecure subresource constitutes a problem that exceeds what a status code can address. Once the links are resolved, the questions a status code cannot answer are: Does any http:// subresource load on an https:// page?

(Mixed content - the padlock and the blocked script break.) Does the page's sitemap reference URLs that are actually reachable? (A sitemap listing dead 'loc' entries misroutes crawlers, and this is another aspect that a superficial check of visible links overlooks.) The concise version: a broken-link check evaluates URLs based on their status code, and mixed content represents the failure that renders a perfect status code ineffective - a 200 resource that the browser obstructs, on a secure page whose padlock gradually downgrades.

After confirming the links, verify whether any of them are insecure subresources on a secure page. The outcome remains unchanged. A redeployment that reintroduces an old widget, a CDN swap, or a relaxed CSP to accommodate a new integration each reintroduces an http:// subresource that responds with a 200 and passes the subsequent link check, just as it did in the previous iteration. Merlonix crawls your site on a scheduled basis to identify and report these issues.