Get paged when a link on your site breaks.
A one-time crawl finds the broken links you have today. But the link that costs you is the one that breaks months after launch — a vendor page that 404s, a deleted post, an http:// asset that trips the padlock. Merlonix re-crawls your site on a schedule and alerts you the moment a new one appears.
How it works
01
Turn it on for an asset
Enable broken-link monitoring on any Team, Agency, or Compliance asset. Set the crawl root, or we use the asset URL. No AI, no headless browser — plain HTML fetches through our SSRF-guarded crawler.
02
We crawl on a weekly cadence
Each week Merlonix BFS-crawls your same-origin pages from the root, bounded by hard page, depth, and link-check caps so it stays fast and cheap. If a site is larger than the cap, the run is marked truncated — never silently cut short.
03
We diff against your last crawl
We compare this crawl to the previous one. A link that used to resolve and now 404s, an http:// asset that just appeared on an https:// page, a sitemap that went bad — those are the NEW findings that matter, not the whole list every week.
04
You get an alert on what changed
A newly-broken link or newly-appeared mixed-content issue pages you with a warning naming the URL and the page it was found on; when a previously-broken finding is fixed, it clears. The full finding list is in the asset dashboard with a CSV export.
What we find
Three deterministic finding kinds, re-checked every week.
We crawl the same links a good one-time checker does — then keep crawling, so a link that quietly breaks becomes an alert instead of a complaint from a client.
Why continuous beats a one-time crawl
Catch the link that breaks after launch
The broken link that costs you is rarely the one you shipped — it is the vendor page that 404s months later, the blog post a client deletes, the checkout subdomain a migration orphans. A one-time crawl at launch cannot see that; a weekly re-crawl does.
Mixed content that breaks the padlock
A single http:// asset dropped onto an https:// page trips a browser security warning and can silently fail to load. We flag every mixed-content reference so an editor mistake or a stale embed does not quietly degrade trust on a client site.
One panel with the rest of your monitoring
A new broken link lands in the same alert stream and asset detail as your SSL expiry, DNS, TLS posture, and uptime checks — reaching the same person, the same way, as everything else you watch. No separate crawler tool to log into.
What we promise — and what we don’t
We crawl your links. We’re precise about the bounds.
Merlonix breadth-first crawls your same-origin pages on a weekly cadence, bounded by hard page, depth, and link-check caps — a run larger than the cap is marked truncated, never silently cut short. It is deterministic (no LLM, no headless browser), and it is informational— the finding count is not folded into a pass/fail score. We tell you, week over week, exactly which link broke and on which page; fixing it — the link, the asset reference, or the sitemap — lives on your side.
Common questions
How is this different from a one-time broken-link crawler?
A one-time crawler (Screaming Frog, the W3C link checker, an Ahrefs audit) tells you which links are broken at the moment you run it. Merlonix re-crawls your site on a weekly cadence and alerts you when a NEW broken link, mixed-content resource, or sitemap error appears since the last crawl — the regression a one-time audit run at launch can never catch. No general uptime monitor crawls your internal links at all.
What exactly do you detect?
Three deterministic finding kinds. Broken links: a link target that returns a non-2xx/3xx status, times out, or fails with a network error. Mixed content: an http:// subresource (image, script, stylesheet) referenced from an https:// page. Sitemap errors: a referenced sitemap that is unreachable, malformed, or whose listed URLs are unreachable.
How much of my site do you crawl?
A breadth-first crawl of your same-origin HTML pages from the root (or a crawl root you set), bounded by hard caps on pages, depth, and total link checks so a run stays fast and inexpensive. If your site is larger than the cap, the run is marked truncated so you always know the crawl was bounded — it is never silently cut short. There is no LLM and no headless browser; these are plain HTML fetches.
When does it alert me?
On the delta between crawls. When a finding class that was not present in your previous crawl appears — a link that newly broke, mixed content that newly showed up — you get a warning alert naming the URL and the page it was found on. When a previously-reported finding is resolved, it clears. A one-off transient fetch failure is recorded as a finding for that run, not escalated as a site-wide outage.
Does the finding count affect a pass/fail score?
No. Broken-link monitoring is informational: the findings and the delta alerts stand on their own and are not folded into any aggregate health or compliance score. The full per-finding list (the broken URLs, the source pages) is available in the asset dashboard with a CSV export to hand to a client or a developer.
Which plans include it?
Broken-link monitoring is a paid value-add available on the Team, Agency, and Compliance plans, enabled per asset. See the pricing page for the plan that fits the number of assets you want to watch.
Stop finding out from a client.
Turn on broken-link monitoring and get paged the week a link breaks — in the same place as the rest of your monitoring. Start the full-workspace trial — 14 days, no card.