Frequently asked questions

How many pages or links does it check?

There's no fixed page limit — it keeps crawling and following internal links until it's checked everything it can find, or until it hits your plan's link limit (100 free, more with a paid tier for that check). Internal safety caps on depth and page count exist just to stop a runaway crawl on a huge site, but they're set high enough that they rarely matter in practice.

Why does it show a link as broken when it works fine in my browser?

A small number of sites block automated requests even though they load normally for a real visitor. If a link you know works shows up as broken, it's worth double-checking it directly before assuming it's an actual problem. Redirects aren't treated as broken on their own — the report shows where a redirected link ends up.

Does it check anything besides broken links?

Yes — while crawling, it also flags pages missing a title tag and mixed content (an http:// image, script, or stylesheet loaded on an https:// page). These show up in a separate "Other site health notes" section on the results page.

Does it check links behind a login?

No — it can only see what a normal visitor without an account can see, the same as anyone landing on the page from a search result or a shared link.

Can I stop a check partway through?

Yes — use the Stop button on the results page. Whatever was found up to that point stays visible.

Can I export or share a report?

Both. Download a finished report as CSV, Excel, or PDF, or copy a stable link straight from the results page to send someone the live report instead.

Do I need an account?

No — checking a link never requires signing in. If you do sign in (with email or Google), your account page keeps a history of your checks, stats, and payment record, and future checks made while signed in get linked to it automatically.

Can I get notified instead of waiting for a check to finish?

Yes — enter an email on the results page while a check is still running, and you'll get a one-time email when it's done. That's separate from monitoring (below), which is recurring.

Can it keep checking a site over time?

Yes — from a finished check's results page, set up monitoring with an email and a weekly or monthly frequency. You'll only get an email when something new breaks compared to the last check, not a repeat report every time nothing's changed. Every alert includes a one-click unsubscribe link.

Is there a cost to use this?

The first 100 links checked in any single check are free. If a site has more links than that, you can unlock the rest for that same check — pricing scales with how many more links there are, from $5 for up to 500 links total, up to $99 for unlimited. It's a one-time unlock for that specific check, not a subscription.

What counts as a broken link?

A link that returns an error status (like a 404 'not found' or 403 'forbidden') or fails to respond at all when checked.

Does it correctly handle HEAD vs GET?

Yes. Each link is checked with a HEAD request first, since it's cheaper. If HEAD reports an error, we confirm with a real GET before calling the link broken — some servers handle HEAD incorrectly, and skipping this step would produce false positives.

How does it classify 403/429 responses?

No special handling — any status code 400 or above, including 403 and 429, is reported as broken with the exact code shown. We deliberately don't auto-suppress these, since a 403 can be either a genuinely broken permission issue or a site blocking automated traffic, and collapsing that distinction risks hiding real problems. To reduce false positives from basic bot-blocking specifically, checks are made with a standard browser User-Agent rather than an identifiable bot string — this doesn't defeat real bot protection, it just avoids tripping the naive kind.

Does it retry transient failures?

Yes — one automatic retry on network-level failures (timeout, DNS resolution failure, connection reset) before a link or page is reported as failed, for both the initial page fetch and each individual link check. Actual HTTP error responses (a 500 or 404) are trusted on the first attempt and aren't retried.

How does it handle 301/302/307/308 chains?

It detects that a redirect occurred, records the first hop's destination, then follows the rest of the chain (up to 5 hops) to determine the final resolved status. It doesn't currently record every intermediate hop — the report shows where a link first redirects to and its final status, not a full hop-by-hop chain.

Does it follow canonical URLs?

No — <link rel="canonical"> isn't currently parsed or factored into crawling or link-checking.

Does it normalize URL fragments?

Yes. The #fragment portion of a URL is stripped before deciding whether something's already been visited or checked, so /page#section-1 and /page#section-2 are treated as the same URL. Pure fragment-only links (href="#top") are skipped entirely, since they're same-page anchors, not real navigation.

Does it detect links inside JavaScript-generated content?

No, and this is worth being upfront about. The crawler fetches and parses raw HTML — it doesn't execute JavaScript or use a headless browser. Content or links injected client-side by a JS framework after page load (common in single-page apps) won't be seen. Server-rendered or static HTML, including most WordPress, Webflow, and similar CMS-driven sites, is fully covered.

Does it parse <a>, <img>, <script>, <link>, <iframe>, etc.?

<a href> is what's actually checked for brokenness. Separately, each page is passively scanned for <img src>, <script src>, <link rel="stylesheet" href>, and <iframe src> — but only for one specific signal: mixed content (an http:// resource loaded on an https:// page). Those resource URLs aren't themselves checked for brokenness, only for that.

How does it handle nofollow?

It doesn't currently distinguish it — a link's rel attribute (nofollow, sponsored, ugc, etc.) isn't inspected. Every <a href> is checked for brokenness and, if internal, considered for further crawling, regardless of its rel value.

Does it respect robots.txt?

No, not currently. This is an intentional gap, not an unknown one — it's fine for checking a site you own, but means it isn't appropriate to point at a third-party site without their knowledge.

How aggressively does it crawl?

Deliberately gently — one request at a time, strictly sequential, never concurrent. There's no burst of simultaneous requests hitting a target site at any point.

What's the concurrency/rate limit?

Concurrency is effectively 1 — there's no parallel fetching in the first place, so there's nothing separate to rate-limit. Each request has an 8-second timeout. There's no configurable per-domain throttle exposed, since global concurrency already caps it at one request in flight at a time.

How does it prevent crawling traps?

Primarily with hard ceilings rather than trap-pattern detection: a maximum of 3,000 pages and 5 levels of depth per crawl, and each crawl is separately capped by its plan's link limit. Already-visited URLs aren't re-fetched. What isn't detected is near-duplicate trap patterns specifically — an infinitely paginated calendar or session-ID query parameters generating endless unique URLs would each be treated as distinct and could consume crawl budget before the page ceiling kicks in. The hard ceiling is what ultimately stops a runaway crawl.

Does it detect soft 404s?

No — classification is based purely on HTTP status code. A page that returns 200 OK but displays a "Page Not Found" message to a human visitor is reported as working. Genuine soft-404 detection requires content-pattern analysis, which isn't implemented.

How does it distinguish a genuinely dead external site from a bot-blocking response?

It doesn't, automatically — both currently surface as broken with whatever status or error came back. False positives from basic bot-blocking are reduced, not eliminated, by using a standard browser User-Agent and by skipping known social-share-intent link patterns (Twitter/X, Reddit, Facebook, LinkedIn, Pinterest, Telegram share URLs) that are guaranteed to misbehave for any automated tool. Beyond that, a person still needs to judge a suspicious-looking result for themselves.

How good is its duplicate URL normalization?

Basic — normalization is fragment-stripping only. Trailing slashes, query parameter ordering, host casing, and www vs non-www aren't treated as equivalent, so /about and /about/ (or differently-ordered query strings) are treated as two distinct URLs even if they resolve to the same content. This is the area most likely to inflate a page or link count on a site with inconsistent internal linking.

What exactly counts toward the "links checked" limit?

Every <a href> link is counted once per occurrence — if the same URL appears as a link on 10 different pages (a common footer or nav link, for example), it counts 10 times toward the link limit, even though the live status check for that URL is only actually performed once and cached for the rest. Excluded entirely: mailto:, tel:, javascript:, and pure same-page #fragment links (never queued to begin with), and recognized social share-intent URLs (also filtered before being queued). A site with a large repeated nav or footer can use up free-tier link-checks faster than its number of genuinely distinct URLs would suggest.