Check HTTP status, redirect chains, and response timing on a known URL list

Bulk URL Status Checker processes lists of URLs you already have and records HTTP status codes, redirect chains, final destinations, response times, and severity flags. It is live HTTP QA for migration, SEO, and site operations — not a DNS lookup, not short-link expansion, and not an Internet Archive availability check.

From $8.00 per 1,000 results

Open Bulk URL Status Checker on Apify

Live HTTP status QA, not DNS, short-link expansion, or archive lookup

Use this page when you already have URLs and need status codes, redirect chains, timing, and broken-URL findings. Use DNS Propagation Checker for public A/MX/NS records on hostnames. Use Short URL Resolver & Scraper to expand bit.ly, t.co, and custom shorteners. Use Wayback Machine Bulk Checker to check Internet Archive cache availability.

Bulk URL Status Checker DNS Propagation Checker Short URL Resolver & Scraper Wayback Machine Bulk Checker
Intent HTTP status, redirect-chain, timing, and broken-URL QA on a known list Audit worldwide nameserver and record propagation Expand short/obfuscated links and log the HTTP hop path Verify Internet Archive cache availability and closest snapshots
Input Known page URLs in urls (max 1000) Hostnames in domains (max 200) Shortened URLs in urls (max 1000) URLs in urls (max 500)
What it reads Live HTTP(S) responses for those URLs; it does not crawl pages Public DNS via Node.js dns.Resolver Server-side HTTP redirects on short links Wayback Machine available endpoint
Primary output Status code, final URL, redirect chain, response time, severity Resolved values, TTL, resolver identity, consistency flags Final URL, hop chain, loop and HTTPS-downgrade flags Availability plus closest snapshot URL and timestamp when present
Not this job DNS records, shortener expansion, archive snapshots, HTML crawl HTTP status of page URLs Status QA of a known (already expanded) URL list Live HTTP status of current pages

The live schema description also names content type and SSL validity as check surfaces. The published README output field list does not include those names. Treat content type and SSL as schema-described checks, not as documented dataset columns.

Use cases

The published README positions the Actor for Site QA & Content Intelligence workflows: provide focused source inputs, keep the first run small, and expand only after the output shape is useful. Each emitted row includes source context, timestamps, and fields designed for monitoring, QA, research, or workflow handoff.

Store Quickstart: start with a small URL list as the source step. Confirm status and redirect findings, then send the same URLs to the linked broken-link, content, or indexability report actor named in the README.

How is Bulk URL Status Checker different from DNS Propagation Checker, Short URL Resolver, and Wayback Machine Bulk Checker?

This Actor checks a known URL list for HTTP status, redirect chains, response timing, and broken URL findings. Required input is urls (maximum 1000). It does not crawl pages to discover links. DNS Propagation Checker queries public DNS for hostnames in domains (maximum 200) and does not fetch HTTP(S) HTML. Short URL Resolver & Scraper expands shortened or obfuscated links and logs the hop path; it is unshortening, not a status-QA pass over a known list. Wayback Machine Bulk Checker queries the Internet Archive available endpoint for historical cache availability (maximum 500 URLs) and does not check live HTTP status. Use this Actor for live HTTP QA on URLs you already have.

Does this Actor crawl pages to find broken links?

No. The live input schema states this Actor does not crawl pages. Pass known URLs in urls. For crawl or page-level broken-link discovery from source HTML, the schema points to Broken Link Checker. README handoff names for the same URL set are Site QA Broken Link Report Scraper, Site QA Content Report Scraper, and Site QA Indexability AI Crawler Report Scraper. Those are downstream report paths, not this Actor and not extra landings on this site.

The README “Run the next report” section treats this Actor as the source step. A paid report/export handoff is produced by those linked report actors, not by adding more raw status rows here.

What input is required?

urls is required: known URLs to check (maximum 1000 per run). Optional live schema fields are concurrency (integer, default 10), timeoutMs (integer, default 10000), followRedirects (boolean, default true), delivery (dataset or webhook, default dataset), webhookUrl (required when delivery is webhook), and dryRun (boolean, default false). additionalProperties is false. The published input schema does not include includeHealthyRows, maxChargeUsd, maxRedirects, or crawl-related aliases.

Field Type Default Notes
urls string[] required Known URLs to check (max 1000). Schema prefill: https://example.com, https://example.com/about, https://httpstat.us/404, https://httpstat.us/301
concurrency integer 10 Maximum parallel requests. Higher is faster and may trigger rate limits. Schema has no min/max.
timeoutMs integer 10000 Request timeout in milliseconds. Schema has no min/max.
followRedirects boolean true If true, follows redirects and reports the chain. If false, reports the first response.
delivery string dataset dataset or webhook
webhookUrl string — Required when delivery is webhook
dryRun boolean false Skip dataset writes and webhook delivery; local output/result.json is still written

The README Migration QA example sends includeHealthyRows: false. That field is not in the live schema. Do not send it.

Published Store Quickstart / small URL batch (schema-valid):

{
  "urls": [
    "https://example.com",
    "https://example.com/docs"
  ],
  "followRedirects": true,
  "delivery": "dataset",
  "dryRun": false
}

Published Store example run input:

{
  "urls": [
    "https://google.com",
    "https://github.com",
    "https://httpstat.us/404",
    "https://httpstat.us/301",
    "https://example.com"
  ],
  "concurrency": 3,
  "timeoutMs": 10000,
  "followRedirects": true,
  "delivery": "dataset",
  "dryRun": false
}

Published README webhook status report (schema-valid):

{
  "urls": [
    "https://example.com/pricing"
  ],
  "delivery": "webhook",
  "webhookUrl": "https://example.com/webhook",
  "dryRun": false
}

Keep the first run small. Raise concurrency only with reasonable settings against infrastructure you are allowed to check. The README compliance notes: use for migration QA, SEO, and site operations; do not use aggressive settings against third-party infrastructure; do not use provider emblems or wording that implies approval by an upstream data provider.

Run Bulk URL Status Checker on Apify

What does a result row contain?

The published README output field list is rowType, url, statusCode, finalUrl, redirectChain, responseMs, severity, warnings, and fetchedAt. The published raw status sample wraps rows in a meta object (actorName, actorTitle, bundle, fetchedAt, totalRows). The sample row is rowType url_health_finding with url, statusCode, finalUrl, responseMs, severity, fetchedAt, and actorName; redirectChain is in the field list and not shown on that sample row. warnings appears on the sample as a top-level array. The sample is a README illustration, not a live coverage guarantee.

Published README raw status sample:

{
  "meta": {
    "actorName": "bulk-url-health-checker",
    "actorTitle": "Bulk URL Status Checker",
    "bundle": "Site QA & Content Intelligence Pack",
    "fetchedAt": "2026-05-06T00:00:00.000Z",
    "totalRows": 1
  },
  "rows": [
    {
      "actorName": "bulk-url-health-checker",
      "rowType": "url_health_finding",
      "url": "https://example.com/missing",
      "statusCode": 404,
      "finalUrl": "https://example.com/missing",
      "responseMs": 240,
      "severity": "error",
      "fetchedAt": "2026-05-06T00:00:00.000Z"
    }
  ],
  "warnings": []
}

README rows also include source URLs, fetch timestamps, warnings when a source is partial, and stable IDs when the workflow supports recurring change detection. The README “Value path output preview” sample is a downstream url_health_report from site-qa-broken-link-report-scraper, not this Actor’s status row.

How do dataset, webhook, and dry-run delivery work?

Non-dry-run runs always write canonical URL-level dataset rows first. delivery defaults to dataset. Set delivery to webhook and provide webhookUrl to POST one full payload only after dataset/PPE output succeeds and dryRun is false. dryRun true skips dataset writes and webhook delivery; local output/result.json is still written. The default dataset is the billable surface. Dry runs, validation-only runs, missing-key warnings, and unchanged recurring polls should not write payable default-dataset rows.

The README states healthy no-issue batches can be held out of the default dataset when configured. The live input schema does not publish an includeHealthyRows field.

How is Bulk URL Status Checker priced?

Billing is pay per event. The published Store card is from $8.00 per 1,000 results. Live Store events are Actor Start at $0.001 (charged when the Actor starts; number of events depends on Actor memory, one event per GB, minimum one event) and result at $0.008 (single result in the default dataset). The README pricing section matches those figures: $0.001 actor start and $0.008 per emitted URL finding row. You are not charged extra for Apify platform usage beyond the included platform usage on the pricing page. Platform usage is listed as included.

From $8.00 per 1,000 results ($0.001 Actor Start + $0.008 per default-dataset result)

See Bulk URL Status Checker pricing on Apify

Limits to keep in mind

Open Bulk URL Status Checker on Apify

Related pages