URL Status Checker API — Bulk HTTP Status, Redirects & Links

Check thousands of URLs in one run and get one flat JSON record per link: the final HTTP status, the redirect chain hop by hop (301 → 302 → 200, with every Location), the final URL, response time, content type, size and server headers, the SSL certificate's expiry and issuer, and a plain isDeadLink flag. Fast HEAD requests with an automatic GET fallback, up to 100 checks in parallel, no proxy traffic unless a connection drops.

Try it in 1 minute:

1. Press Start — the prefilled input checks four public URLs: a plain page, a site that redirects http → https, a URL that answers 404 and a Wikipedia article.
2. A few seconds later the Output tab shows each URL's status, final URL, redirect hops, timing, content type and certificate days left.
3. Download JSON, CSV or Excel, or schedule the run to watch your links every day.

Price: $0.20 per 1,000 checks. A check is complete when the URL answered — with any status, 200 or 404 alike. URLs that cannot be reached at all (DNS failure, timeout, TLS failure, redirect loop) and inputs that are not web addresses are free.

Use it to:

• Find broken links in a sitemap, a content export or a backlink list: every record carries isDeadLink and the real final status.
• Audit redirect chains after a site migration — see every hop, catch loops, relative Locations and chains that are longer than they should be.
• Expand short links and tracking URLs to their final destination without visiting them in a browser.
• Monitor uptime and SSL expiry of your domains on a schedule and alert on sslDaysLeft below 14 or ok: false.
• Feed an AI agent or a spreadsheet structured link health instead of raw HTTP responses.

How it works

1. Every input is normalised (a missing scheme becomes https://, the fragment is dropped) and duplicates are checked once.
2. The URL is requested with HEAD and redirect: manual, so each 3xx answer is recorded as a hop { url, status, location } (relative Locations are resolved against the current URL) and followed, up to Max redirects. The same URL seen twice stops the chain as a redirect loop.
3. When a server refuses HEAD (405, 403, 501) or does not answer it in time, the same URL is asked again with GET; the body is not downloaded.
4. For an https final URL the Actor opens one TLS connection to read the certificate: expiry, days left, issuer, subject, and whether Node's verifier trusts it. A bad certificate is reported (sslValid: false, sslError), never worked around — the HTTP check keeps full TLS verification and comes back FAILED with the TLS error if the handshake fails.
5. A timeout or a dropped connection is tried once more through the Apify proxy (datacenter); the first try always goes out directly, so a normal run costs no proxy traffic.

Checks run up to Parallel checks at a time (default 20). Response times are measured from the Actor's own servers.

Input

Field	What it does
urls	Web addresses to check, one per line. Required.
method	HEAD (default; GET fallback on 405/403/501 or when HEAD hangs) or GET.
followRedirects	Follow and record 3xx hops (default on). Off: the first answer is the result.
checkSsl	Read the certificate of https final URLs (default on).
maxRedirects	Hops before FAILED "too many redirects" (default 10).
timeoutSecs	Per request / per hop (default 20).
userAgent	Optional User-Agent; default highbrow-fame-url-status-checker/1.0 (+https://apify.com/highbrow_fame).
customHeaders	Optional JSON object of extra request headers.
maxConcurrency	Parallel checks (default 20, up to 100).
proxyConfiguration	Used only to retry after a network error; the first try is direct.

Output

One record per distinct URL:

Field	What it is
input, url	The address as given, and as checked
finalUrl, httpStatus, statusText	Where the chain ended and the final answer's code and phrase
ok, isDeadLink	ok: 2xx/3xx final status; isDeadLink: final status ≥ 400 or the check could not be completed
redirectCount, redirects[]	Hops followed, each { url, status, location }
responseMs, firstByteMs	Total time for all hops; time to the first hop's headers
contentType, contentLength, server, lastModified	Headers of the final answer (lastModified ISO 8601)
methodUsed	HEAD or GET (GET also after a fallback)
sslValid, sslValidTo, sslDaysLeft, sslIssuer, sslSubject, sslError	Certificate of the final https host; null when the SSL check is off or the final URL is http
status, error, scrapedAt	OK (answered, charged), FAILED (not reachable, free) or INVALID_INPUT (free), the reason, and when

Example

{
  "input": "http://github.com",
  "url": "http://github.com/",
  "finalUrl": "https://github.com/",
  "httpStatus": 200,
  "statusText": "OK",
  "ok": true,
  "isDeadLink": false,
  "redirectCount": 1,
  "redirects": [
    { "url": "http://github.com/", "status": 301, "location": "https://github.com/" }
  ],
  "responseMs": 412,
  "firstByteMs": 96,
  "contentType": "text/html; charset=utf-8",
  "contentLength": null,
  "server": "GitHub.com",
  "lastModified": null,
  "methodUsed": "HEAD",
  "sslValid": true,
  "sslValidTo": "2027-03-07T23:59:59.000Z",
  "sslDaysLeft": 139,
  "sslIssuer": "Sectigo Limited",
  "sslSubject": "github.com",
  "sslError": null,
  "status": "OK",
  "error": null,
  "scrapedAt": "2026-10-19T12:00:00.000Z"
}

A dead link looks like this: "httpStatus": 404, "ok": false, "isDeadLink": true, "status": "OK" — the check completed, the answer is what you asked for. A host that does not exist looks like this: "httpStatus": null, "isDeadLink": true, "status": "FAILED", "error": "DNS lookup failed: host not found" — free.

FAQ

Is this an official API? No, it's an unofficial API built on public pages — it sends ordinary HTTP requests to the URLs you give it and reports what the servers answer.

Why is a 404 charged? Because it is the result: the whole point of a link checker is finding dead links, and a server that answers 404 (or 410, 500, 403) has completed the check. Only checks that got no answer at all — DNS failure, timeout, TLS handshake failure, redirect loop, too many redirects — are FAILED and free.

HEAD or GET? HEAD is fastest and most servers answer it correctly. Some refuse it (405) or answer it differently from GET; those URLs are retried with GET automatically and methodUsed tells you which one gave the answer. Choose GET when you want every URL checked the way a browser would ask. The body is never downloaded, so contentLength is the server's own Content-Length header (null when it sends none, which is common for compressed HTML).

Does it bypass bot protection? No. A site that answers 403 or a challenge page to automated requests gets exactly that in httpStatus. You can set a browser-like userAgent and customHeaders to see what a visitor gets, but there is no captcha solving or IP rotation to get around a block.

What does the SSL check see? The certificate the final https host presents, verified against Node's trusted roots and the hostname: expiry date, days left, issuer and subject. Expired, self-signed and wrong-name certificates are reported with sslValid: false and the reason; the HTTP check is still made with full verification and is FAILED with the TLS error when the handshake is refused.

Like it? A short review on the Store page helps other people find this Actor. Something missing or broken? Tell us on the Issues tab — we read every one.

Related Actors

• Sitemap Extractor — every URL, date and image from a site's sitemaps
• Domain Checker — WHOIS, DNS and SSL expiry in bulk
• Website Tech Stack Detector — CMS, frameworks and analytics of any site
• PageSpeed Insights API — Lighthouse scores and web vitals
• Markdown Site Crawler — a whole site as clean Markdown