Broken Link Checker — Find 404s, Dead Links & Redirect Issues
Pricing
from $1.00 / 1,000 link checkeds
Broken Link Checker — Find 404s, Dead Links & Redirect Issues
Check links from a website crawl, URL list, or sitemap at $0.001 per link. Receive HTTP status, redirect chains, response timing, source pages, anchor text, and diagnostic classes for SEO quality assurance and site migrations.
Pricing
from $1.00 / 1,000 link checkeds
Rating
0.0
(0)
Developer
Khadin Akbar
Maintained by CommunityActor stats
0
Bookmarked
131
Total users
56
Monthly active users
3 hours ago
Last modified
Categories
Security
Limited permissionsShare
What is Broken Link Checker?
Turn a website crawl, direct URL list, or sitemap into a source-linked link health dataset for SEO teams, content operators, migration leads, developers, and AI agents. Each checked URL can include HTTP status, final URL, redirect path, response time, diagnostic classification, source page, anchor text, link type, and collection time, with downloadable dataset and report outputs. Give it a website, a URL list or a sitemap and it tells you which links return 404s, server errors, timeouts or long redirect chains, and which pages link to them.
Cost at a glance: $0.001 per unique link checked ($1 per 1,000 links) plus a $0.00005 start fee, no subscription. That is one Link checked event per unique URL verified, plus one Actor start event per run, with Apify platform usage included. maxLinksToCheck caps the number of link events. See the Pricing tab for current prices.
Best fit for this Actor
- Choose crawl mode when the starting point is a website and the goal is to discover and verify links within a controlled page scope.
- Choose list mode when URLs already exist in a spreadsheet, deployment manifest, or quality-assurance queue.
- Choose sitemap mode when the sitemap is the canonical inventory for a technical SEO review.
- After prioritizing important pages, pair this Actor with the Website Uptime Monitor for recurring HTTP, SSL, content, and response-time observations.
From a site migration to a repair queue
A migration lead starts with the production sitemap and requests a complete checked-link inventory. The Actor follows redirects, records timing, and associates discovered URLs with their source pages and anchor text. The lead then groups records by classification, routes high-value pages into a repair queue, and carries sourceUrl, allSources, and redirectChain into each ticket so the team can act without repeating discovery work.
Quick start input
{"mode": "sitemap","startUrl": "https://example.com/sitemap.xml","maxLinksToCheck": 100,"onlyReportBroken": false,"checkExternalLinks": true}
For a curated inventory, set mode to list and provide full URLs through urls. For site discovery, set mode to crawl and use maxPages to define the page scope.
Input reference
| Field | Type | What it controls |
|---|---|---|
mode | string | URL sourcing through crawl, list, or sitemap workflow. |
startUrl | string | Website start page or sitemap URL. |
urls | array | Full URLs for direct list verification. |
maxPages | integer | Page-discovery cap in crawl mode. |
maxLinksToCheck | integer | Stable cap on unique URL checks and primary event charges. |
checkExternalLinks | boolean | Includes links that point to other domains. |
checkAssets | boolean | Includes images, scripts, stylesheets, and frames. |
onlyReportBroken | boolean | Chooses a focused repair dataset or a complete checked-link inventory. |
slowThresholdMs | integer | Response-time threshold for the slow classification. |
requestTimeoutMs, maxConcurrency | integer | Request timing and parallelism controls. |
What data you receive
One dataset row represents one normalized URL check. The Actor also creates a summary and an HTML report for review and sharing.
| Field group | Useful fields |
|---|---|
| URL outcome | url, finalUrl, status, statusText, classification, isBroken |
| Discovery context | sourceUrl, anchorText, linkType, allSources |
| Redirects | hops, redirectChain |
| Request evidence | method, durationMs, checkedAt |
| Diagnostic detail | Structured transport context when a request yields a diagnostic |
{"url": "https://example.com/old-page","finalUrl": "https://example.com/new-page","status": 200,"statusText": "OK","classification": "redirect_chain","isBroken": false,"sourceUrl": "https://example.com/resources","anchorText": "Product guide","linkType": "a","method": "GET","hops": 2,"redirectChain": [{ "status": 301, "from": "https://example.com/old-page", "to": "https://example.com/archive" },{ "status": 302, "from": "https://example.com/archive", "to": "https://example.com/new-page" }],"durationMs": 420,"checkedAt": "2026-06-02T09:00:00.000Z"}
Use through the API
curl -X POST "https://api.apify.com/v2/acts/khadinakbar~broken-link-checker/runs" \-H "Authorization: Bearer $APIFY_TOKEN" \-H "Content-Type: application/json" \-d '{"mode": "sitemap","startUrl": "https://example.com/sitemap.xml","maxLinksToCheck": 100,"onlyReportBroken": false}'
Read the default dataset for URL-level records. The default key-value store also exposes the summary and HTML report through the Actor output links. The OUTPUT record and summary-report include topBrokenLinks: the broken URLs referenced by the most pages, with the pages that link to them, so you can fix the highest-impact links first.
Use with AI agents through Apify MCP
Audit this sitemap for link health. Return URL, final URL, HTTP status, classification, redirect path, response time, source page, and anchor text. Read the dataset and summary after completion, group the repair queue by classification and source page, preserve provenance, and keep the check scope within the supplied link cap.
For predictable agent behavior, state the sourcing mode, include the canonical start point, request a complete inventory when comparison matters, and ask the agent to cite sourceUrl beside each recommended action. maxLinksToCheck makes scope and cost explicit.
Connect the workflow
Use the Website Uptime Monitor after a technical SEO audit when selected URLs need recurring health observations. Pass the priority url values into its startUrls input for HTTP, SSL, content, and response-time monitoring.
Pricing
This Actor uses Pay per event with Apify platform usage included. Open the live Pricing tab for current event details, and use maxPages, maxLinksToCheck, and Apify run cost controls to keep the audit aligned with your budget.
| Audit | Events charged |
|---|---|
| List mode with 40 URLs | 40 × Link checked + 1 × Actor start |
Crawl of 50 pages that finds 1,200 unique links, maxLinksToCheck: 500 | 500 × Link checked + 1 × Actor start |
| Sitemap with 300 URLs | 300 × Link checked + 1 × Actor start |
onlyReportBroken changes which rows are saved, not how many links are checked, so the event count follows the number of unique links verified.
Best results
- Use sitemap mode when the sitemap is a maintained source of canonical pages.
- Use crawl mode with a focused
maxPagesvalue when source-page and anchor discovery are central to the audit. - Keep
onlyReportBrokendisabled for before-and-after migration comparisons that need the complete inventory. - Preserve
sourceUrl,allSources,redirectChain, andcheckedAtin downstream repair and verification workflows.
FAQ
Which results count as broken?
HTTP 4xx responses (except 403 and 429, which are reported as blocked), 5xx responses, timeouts, DNS errors, refused connections, SSL errors and redirect loops are marked isBroken: true. Slow responses (over slowThresholdMs) and long redirect chains are reported with their own classification so you can review them separately.
Why do some links show blocked (403 or 429)?
Some sites refuse automated requests or rate-limit them. Those links usually work in a browser. Review them by hand, lower maxConcurrency, or route requests through proxyConfiguration.
How do I check only my own domain?
Set checkExternalLinks to false. Crawl mode then verifies only same-site links.
Does sitemap mode support sitemap index files?
Yes. Point startUrl at a sitemap or sitemap index; nested sitemaps are read up to the maxLinksToCheck cap.
How long does an audit take?
Most audits of a few hundred links finish in under a minute. If a large crawl gets close to the run timeout, the Actor stops early, keeps every result already checked, and ends with a PARTIAL outcome and a note in OUTPUT. Raise the timeout or lower maxPages / maxLinksToCheck to cover everything.
Can I schedule a weekly audit?
Yes. Save your input as an Apify task and add a schedule. Compare topBrokenLinks and totalBroken between runs to track progress.
How do I export the results?
Download the dataset as CSV, JSON or Excel from the run page, or open report.html in the key-value store for a shareable overview.
Can AI agents run it?
Yes. Call khadinakbar/broken-link-checker through Apify MCP or the API and read the dataset plus the OUTPUT record.
Builder's note
I built the output around both the checked URL and the pages that reference it because I found that a status alone rarely tells a content team where to make the change. Capturing anchor text, link type, multiple sources, redirect history, and timing turns a raw HTTP observation into a repair-ready record.
Responsible use
Check websites and URLs you are authorized to assess, use considerate concurrency, and follow applicable laws, site terms, and your organization's security and quality-assurance policies.
Call over HTTP
Use this Actor's actual Endpoints URL with an Apify bearer token. GET /check?url=https%3A%2F%2Fexample.com supports one public target. POST /check accepts urls, mode=list, maxLinksToCheck, onlyReportBroken, slowThresholdMs, requestTimeoutMs, maxConcurrency, maxRedirects, userAgent and proxyConfiguration, plus optional maxCostUsd. Results and a summary are returned directly. Website crawling, sitemap discovery, HTML reports and persistent bulk exports remain available through normal runs.
Existing prices, free-user limits, paid features, normal run defaults and included platform usage are unchanged. One link-checked costs $0.001 per completed URL measurement, including a healthy link hidden by onlyReportBroken. A completed DNS, TLS, timeout or HTTP failure measurement can be a useful broken-link result. The output filter changes visible records, not the checked-link billing unit. No extra manual startup charge is added per HTTP request.
HEAD verification, one GET fallback for ambiguous HEAD responses, status, original classifications, redirects, response times, failure classes and source metadata are preserved. HTTP retains the existing limits, including up to 10,000 checked URLs, 100 concurrent checks and 30 redirects, subject to the synchronous work bounds below.
maxCostUsd is checked before source or proxy work against the maximum planned unique checks after maxLinksToCheck. It caps result events for that HTTP request; it does not enforce a user/day quota or read a Console-wide allowance. Readiness and input/budget rejections charge no result event. Completed validated units are attributed to the Apify request ID and charged before delivery. Unconfirmed billing withholds results; do not automatically retry an uncertain charge. Partial useful work returns HTTP206 with complete records and explicit counts.
HTTP accepts two isolated request workers per instance, 1 MiB input, 20 MiB cumulative decoded source transfer and 2 MiB complete output. Oversized complete output is withheld before result billing. New work stops after 180 seconds and each worker has a 240-second hard deadline. Use a normal run for long or large work. These are HTTP transport bounds and do not change free or paid batch limits. Idle instances can scale down, so later calls may cold-start.
Caller inputs, page content, results and credentials are not saved in shared Dataset/KV or general service logs. Only operational aggregates remain. HTTP does not create a caller-specific run, stored export or history entry; use normal runs for those features. No browser, login or new paid data provider was added. Optional Apify/custom proxy costs can still apply within existing included platform usage. Public HTTP(S) targets without URL credentials are required; private IPs, unsafe DNS answers and redirects are rejected. A configured proxy remains a separate resolver trust boundary.
Normal-run billing records pending effects before charging or saving, retains an accepted final spending-cap unit and stops on ambiguous effects without automatic replay. Concurrent source checks reserve remaining event capacity before verification. Healthy filtered observations still contribute to totalChecked and billing; a non-billable summary row and existing HTML report remain available. These safeguards do not promise distributed exactly-once delivery or final invoice settlement.