Check links for rot

What causes link rot

Links die for mundane reasons: sites shut down when hosting bills stop being paid, companies get acquired and fold their blogs, CMS migrations rename every URL without redirects, articles get paywalled or quietly unpublished, and whole domains lapse and get bought by squatters. The scale is bigger than intuition suggests — studies of link rot repeatedly find that roughly a quarter or more of links from a decade ago no longer lead anywhere. Any bookmark collection older than a few years contains dead links; the only question is how many.

How the checker works

The requests are made from Marqly's server, not from your browser — and that is not a design preference, it is the only way to get honest results. Browsers enforce CORS: a script on this page is not allowed to read response statuses from other domains, so a purely client-side checker would report most healthy links as failures. Instead, the URLs you paste go to Marqly's own server on Cloudflare's infrastructure, which fetches each one and returns its status. Per URL, the server:

• sends a HEAD request first — headers only, no page body — under a declared user agent (MarqlyLinkChecker/1.0) that identifies the checker and links back to this page;
• retries with GET if the server refuses HEAD (status 405 or 501) — some sites simply don't implement HEAD;
• follows redirects hop by hop, up to eight, so the "redirects to" column shows the final destination rather than the first hop;
• gives up after about six seconds on a link that won't answer, reporting it as unreachable instead of hanging the whole batch;
• runs all URLs in the batch in parallel, which is why 25 links usually come back within seconds.

Only ordinary public web addresses are accepted — http or https on the standard ports, with no embedded credentials, and never private or internal hosts. That keeps the free tool from being pointed at machines it has no business touching; it also means intranet links cannot be checked here, by design.

How to use it

1. Gather URLs — from a document, or from your bookmarks: export them and pull the links out as a searchable list with the bookmark file viewer.
2. Paste them above, one per line, up to 25 per run.
3. Press Check links and wait for the results table.
4. Read each row: the verdict (live, gone, redirected, or "needs a human check"), a ✓/✗ for whether the server answered successfully, and the final URL when the link redirected.
5. Act: delete or replace the 404/410s, verify the ambiguous ones in your own browser, and check where a redirect now lands — a link that ends on the site's homepage has usually lost its article even though nothing "failed".

How to read the results

• 200-range — alive. A ✓ means the server answered successfully.
• Redirects — the page moved; the "redirects to" column shows where it landed. Usually harmless (http→https, www changes), but a redirect to a homepage often means the article itself is gone.
• 404 / 410 — reliably dead. The server is alive and says the page is not.
• 403, 429, 999 — ambiguous. Many sites reject automated checkers while serving humans fine. Verify these in your browser before deleting anything.
• Unreachable — no HTTP response at all: dead domain, downed server, or a timeout. Almost always genuinely gone.

HTTP status reference

The verdict in the results table comes from this mapping — the same logic you can audit in any browser's developer tools:

When to run a link audit

• Before republishing or recycling old content — a newsletter resending a five-year-old post with dead citations looks worse than the news it carries.
• After any CMS migration — yours or someone else's: the URLs in your bookmarks and notes may now point at a site that renamed everything.
• When pruning a bookmarks folder — delete the confirmed-dead first; the file shrinks fastest and syncs less junk.
• While verifying references in research or a reading list — a 404 on a citation is worth knowing before you build on it.
• Before migrating your whole library — see the browser-bookmarks migration guide; a duplicate sweep with the duplicate bookmark finder and a dead-link pass with this tool are the two cheap wins.

Privacy: what is sent, what is stored

What is sent: the URLs you paste, from your browser to Marqly's server, and from there to each target site carrying the checker's user agent. Nothing else from your machine or session travels with them. What is stored: nothing that identifies you — there is no account, no history, no saved batch; the response comes back marked no-store and the only counters kept are edge rate limits that stop scripts hammering the tool. Two practical consequences: the sites you check will see a request from Cloudflare's infrastructure, so do not paste URLs whose access is itself sensitive; and private or internal addresses cannot be checked here at all, because they are refused before any request is made.

Honest limits

This tool checks up to 25 URLs per run — paste more and the extras are skipped and counted, not silently ignored. The cap exists because every URL is a real request from our server: unbounded batches invite exactly the scripted abuse that would make the tool slow for everyone else. There is no account and no daily quota, so a bigger list is simply more batches. It reports what the server said at this moment, which is not always the truth about content: a page can return 200 while its text has been replaced by a domain-parking ad ("soft 404s" are undetectable from status codes alone). For auditing a whole bookmarks export, pull the URLs out first with thebookmark file viewer and feed them through in batches.

• Slow sites look dead. The ~6-second timeout means a laggy but living page can come back "unreachable" — rerun before believing it.
• Bot walls look dead. A 403 or 999 is the site rejecting a robot, not refusing the page; verify those by hand.
• JavaScript-rendered pages answer before they render. A checker sees the HTTP response, not what your browser eventually paints.
• Living links die tomorrow. Status is a snapshot of this moment; a saved library is worth re-auditing every few months.
• Push too hard and you'll be paused. If you fire batch after batch quickly, the per-IP rate limit answers "too many requests" — wait a minute and continue.

The deeper fix for rotting bookmarks

A link checker tells you a page died; it can't tell you what the page said. That's the argument for saving more than the URL: Marqly attaches an AI summary to your saves, so a dead link in your library still carries its content's gist — andsemantic search still finds it by meaning.

Traditional bookmark tools only store the raw URL and title (see how we compare in ourMarqly vs Raindrop breakdown). With theMarqly browser extension, pages are summarized, AI-tagged, and indexed at the moment of saving so link rot never wipes out your knowledge. Your data stays yours either way; seecan I export my data.

Related tools and guides

• Remove double-saved links before you audit — duplicates make the batch twice as long for no reason.
• Open your bookmarks export as a searchable table to pull URLs for checking.
• Switching browsers? The migration walkthrough covers export, cleanup, and import end to end.
• A read-it-later setup that keeps summaries is the structural answer to link rot.
• How to organize bookmarks so a dead link costs you one entry, not a whole folder's worth of trust.
• Marqly's free plan — get started and save the next ten links with a summary attached.