Loading today’s stories
Build1 distinct publisher2 min readPublished
Mixed content is the failure most likely to break a secure page, and it answers 200, so status-code checkers pass it. A Merlonix post argues the fix is protocol inspection, not more fetching.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
The asymmetry inside mixed content is what makes it expensive to diagnose. A passive resource leaves an artifact: a missing image is something a human notices and reports [4]. Active resources leave nothing in the page. A stylesheet refused on the security boundary renders the page unstyled, and a blocked script means the JavaScript that depended on it silently does not run, with no 404 anywhere to grep for [3]. The ticket arrives as "the form does nothing", and the first thing anyone reads is code that is working correctly.
Nothing in a link checker's design reaches this. It walks `href`, fetches the target, reads the status [1]. The insecure subresource lives in `src` or a stylesheet `link`, it genuinely exists, and it returns 200 [2]. So a status-code tool is not failing at its job here; it is answering a different question and getting graded on this one.
Passive resources also make reproduction unreliable. Browsers attempt the `https://` variant first and only block when that variant is absent [4], which means the same hardcoded `http://` markup renders fine behind an asset host that serves both schemes and breaks behind one that does not [1]. Per the Merlonix post, the padlock stops being clean either way, with the address bar dropping to "Not fully secure" [5].
The post's own tool is candid about its ceiling, and the ceiling matters. It reads the HTML the server sends, so subresources injected later by client-side JavaScript remain visible only in the browser console, where the `Mixed Content:` warnings are logged [9][7]. For a page that mounts its widgets at runtime, the scan's mixed-content coverage of those widgets is zero [2]. That is not an argument against running it. It is an argument for knowing which half of the rendered page it saw, which is the same discipline the post is asking of link checkers.
This is a single source, published by the outfit whose free checker it recommends [9]. The mechanism it describes, though, does not require trust: open a secure page with a hardcoded plaintext script and the console will say so [7].
Ranked by verification strength, evidence, and original report placement.
Mixed content is an http:// subresource loaded by an https:// page; the subresource usually returns a healthy 200 when requested directly, so a checker grading links on HTTP status passes it.
The free broken-links checker described in the post does both halves in one scan: it reports link targets that error or time out, and separately reads the page's <img>, <script>, stylesheet and <iframe> subresources and flags every one loaded over http:// on an https:// page with the exact insecure URLs; it reads the HTML the server sends, so resources injected later by client-side JavaScript still need the browser console.
Every one of the listed mixed-content sources ships green through a broken-link check, because every one of those URLs answers 200.
A broken-link checker walks the <a href> links on a page, fetches each target, and flags the ones that return a 4xx, a 5xx, a timeout, or a connection that never opens.
Active mixed content (a <script>, a stylesheet <link>, or an <iframe> over http://) is blocked outright by the browser on a secure page: the dependent JavaScript silently does not run, or the page renders unstyled, with no 404 anywhere.
Passive mixed content (<img>, <video>, <audio> over http://) is auto-upgraded to https:// by modern browsers, and blocked if the secure version does not exist, leaving a missing image whose http URL returns a good 200.
Follow any of these and your For You feed starts watching them — no settings page required.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Single vendor explainer over well-known browser mechanics
The mechanism claims — active mixed content blocked, passive auto-upgraded then blocked, padlock downgrade, report-only CSP as a discovery path — are specific, internally consistent, and verifiable by anyone with a browser, which supports a moderate score. But the cluster contains exactly one source, authored by the vendor whose product it recommends, with no measurements, no prevalence data, no independent test of the checker, and no corroborating publication.
No adoption signal in the supplied material
The single source contains no release event, deployment, benchmark, usage disclosure, pricing, or licensing datum. It describes a free single-page checker and a scheduled crawling product but gives no users, scan volumes, customers, or dates, so adoption cannot be measured without inventing facts.
Framing outruns a narrow, long-documented mechanism
The underlying mechanics are accurate and the coverage gap in status-code checkers is real, but the headline framing ('a green link report says nothing about whether your page renders') generalizes from one well-understood resource class to whole-page health, and the remedy is presented largely as the vendor's own scan. Modest positive gap: the post itself concedes the scan misses JavaScript-injected subresources and that the vendor-neutral console and CSP paths already exist, which limits how novel or decisive the claimed fix can be.
Vendor-authored post promoting its own checker and monitoring
The single source is explicitly a Merlonix blog post republished on dev.to. Its argument — that status-code link checking is structurally blind and that subresource protocol inspection is required — maps directly onto the feature set of the free checker it advertises, and it closes by pitching scheduled site-wide crawling with alerting. Strong commercial alignment between the claim and the seller, though the post does also point readers to free, vendor-neutral detection via the browser console and report-only CSP.
Clear about what was claimed, thin on independent grounding
Confidence is moderate: the claim set is unambiguous and the browser-behavior portion is stable, widely documented material that a reader can reproduce, so misreading risk is low. It is held down by single-source, single-publisher coverage from an interested party, complete absence of adoption evidence, and no external test of the product claims.
build
A parser you can read beats one you trust: hand-rolling .xlsx to keep a CSP promise1 distinct publisher
build
That "you are listed on Spamhaus" verdict may just be Spamhaus refusing to answer your checker1 distinct publisher
build
SPF and DMARC records that pass every free checker and stop nothing1 distinct publisher
build
Uptime monitoring cannot see the way remote MCP servers actually break1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 24, 2026