🌐 Website Liveness Check: one verdict per domain, with the evidence

Give a list of domains and get, for each one, whether the company's website is live, stale, a placeholder, redirected elsewhere, parked, expired or dead, with a 0 to 100 score and the exact reason. $0.001 a domain, for lead lists and CRM hygiene, investors watching a portfolio, research teams and agencies. It is the whois alternative and domain status checker that answers in bulk: a verdict per domain instead of a registration record you still have to interpret.

Around the verdict comes what the check saw on the way. Where the domain lands and how many hops it took, whether it has mail and who runs it, the registrar and the registration dates, the certificate and the hosting. Then the tech on the page, the structured organization data and social profile links the site publishes, its links to pricing, about, careers and contact pages, and, when the landing page says so, the sentence announcing an acquisition or a rebrand. Try it now with the prefilled input: a live site, a same-name migration, a parking host and a URL.

Deterministic rules over public sources: DNS, one homepage fetch, one TLS handshake, the registry's own RDAP server, robots.txt, and archive.org for history. No browser, no proxies, no login, no AI model. Every verdict carries its reason and the raw facts, so you can disagree with it.

What you get

• ✅ A verdict you can act on. LIVE, LIVE_STALE, PLACEHOLDER, REDIRECTED_AWAY, PARKED, EXPIRED, DEAD_UNREACHABLE or DEAD_DNS, a score, and a one-line reason such as "redirects to parking host (sedo.com)" or "migrated to notion.com (same name)".
• ✅ Mail facts for list cleaning. MX present, the email provider (Google Workspace, Microsoft 365, Proofpoint, Zoho and 40 more), SPF present, DMARC policy.
• ✅ Registration facts from the registry. Registrar, creation date and domain age, expiry date and days to expiry, status codes, name servers, DNSSEC. Straight from RDAP, no WHOIS parsing, no registrant contact data.
• ✅ A page profile without a browser. Title, description, language, favicon, hosting or CDN, CMS and framework and analytics and marketing tools (about 70 fingerprints), the site's JSON-LD organization record (name, logo, founding date, address, official profiles) and its LinkedIn, X, Facebook, Instagram, GitHub, YouTube and Crunchbase links.
• ✅ Change alerts on a schedule. Monitor mode keeps the previous run's verdicts and flags every domain whose state, redirect, certificate or mail changed, plus registrations expiring within 30 days.
• ✅ Archive history. First capture, last capture, years online, and the last time the site actually returned a page. A site that loads today but last worked years ago is a zombie, and this is how you see it.
• ✅ Priced per domain. $0.001 per domain checked, $0.003 per domain with an archive record. Cleaning a list of 5,000 leads costs $5.

👥 Who uses website liveness checks?

• 📧 Lead lists and CRM hygiene. Drop the dead, parked and redirected domains and the ones without mail before a campaign. One run over the list, filter on the verdict and has_mx.
• 💸 Investors and portfolio teams. Which company went dark, got parked, or now redirects to an acquirer, with the acquisition notice quoted from the page. Run the portfolio weekly in monitor mode.
• 📊 Research and data teams. Domain age, first archive capture, years online and last-worked date as firmographic fields, in bulk, from the registry and the archive rather than a data broker.
• 🏷️ Domain investors and brand teams. Parked, expired, expiring within 30 days, registrar, status codes, name servers.
• 🧑‍💻 Agencies and developers. Hosting, CMS, analytics tags, certificate state, which AI crawlers robots.txt blocks, the sitemap URL.
• 🤖 AI agents and pipelines. Structured JSON per domain, callable from the Apify API, the MCP server and the Python and JavaScript clients. Events only, so it is eligible for agentic payment.

⬇️ Input: a mode and a list of domains

{
  "mode": "check",
  "domains": ["stripe.com", "notion.so", "sedo.com", "https://www.checkpoint.com/"]
}

Field	What it does
mode	check (verdict and evidence per domain), history (the archive.org record per domain), monitor (check mode with a changes list per domain since the previous run).
domains	One per line: a domain, a website URL or an email address (the domain part is used). Each entry may also be an object with domain, an optional name (the company's name, checked against the page) and its own mode, so one run can mix checks and history. Up to 10,000 per run.
registration	Registrar, dates, status codes, name servers and DNSSEC from RDAP (default on). Off saves one request per domain.
profile	Email provider and SPF/DMARC, hosting, tech, meta, organization record and social links (default on).
links	The homepage's links to pricing, about, team, contact, careers, docs, blog, press, terms and privacy pages (default on).
only_states	Keep only rows with these verdicts, for example PARKED and DEAD_DNS. Every domain is still checked and charged.
changes_only	Monitor mode: push only the domains that changed (and every domain on the first run).

An empty entry, a string that is not a domain, an IP address, or a reserved name like example.com is rejected before any paid step, as an uncharged error item, and the run still ends normally.

⬆️ Output: one dataset item per domain

Every item carries type, the query it came from, and charged.

type	Charged	Contents
domain	once (domain_check), whatever the verdict	the verdict and the evidence
history	once (domain_history), when the archive knows the domain	first and last capture, years online, last time it worked
error	never	an error code and a message

Every error item is free, and its code says which stage refused it:

Where it comes from	Codes
Your input, before any call	invalid_input (not a domain, a URL or an email address, an IP address, a reserved name, or an entry that is neither a string nor an object with domain), empty_query, unknown_mode
The domain check service	could_not_observe items, whose error carries the service's own reason (our resolver failed its canary check, the per-domain deadline passed, the fetch was refused), plus rate_limited, unauthorized, upstream_error, api_error
The connection	timeout (no answer within 290 seconds for a chunk of 25 domains), unreachable

A could_not_observe item is the third state: not live, not dead, not observed. It is never counted as a verdict and never charged.

The flat columns of a domain item, from the prefilled input:

domain	state	score	reason	final_domain	email_provider	registrar	domain_created	cert_issuer	hosting_hint
stripe.com	LIVE	100	up with real content		Google Workspace	SafeNames Ltd.	1995-09-08	DigiCert Inc
notion.so	LIVE	85	migrated to notion.com (same name)	notion.com		(unavailable: .so has no RDAP)		Google Trust Services	Cloudflare
sedo.com	PARKED	10	redirects to parking host (sedo.com)		Google Workspace	World4You Internet Services	1998-09-09	Sectigo Limited	Cloudflare
checkpoint.com	LIVE	100	up with real content		Microsoft 365	Domain The Net Technologies Ltd.	1994-03-29	GlobalSign nv-sa	Amazon CloudFront

Under the flat columns sit the nested objects. The checkpoint.com item, trimmed:

{
  "type": "domain", "query": "https://www.checkpoint.com/", "domain": "checkpoint.com", "charged": true,
  "verdict": {"state": "LIVE", "score": 100, "reason": "up with real content"},
  "reachability": {"reachable": true, "http_status": 200, "final_url": "https://www.checkpoint.com/",
    "redirected_off_domain": false, "redirect_chain": [{"url": "https://checkpoint.com", "status": 301}, {"url": "https://www.checkpoint.com/", "status": 200}],
    "response_ms": 611, "server": "nginx", "bot_challenge": false, "javascript_shell": false},
  "dns": {"resolves": true, "a_records": ["13.33.153.38", "13.33.153.102"], "nameservers": ["dns1.p01.nsone.net", "dns2.p01.nsone.net"],
    "has_mx": true, "mx_hosts": ["checkpoint-com.mail.protection.outlook.com"], "email_provider": "Microsoft 365", "spf_present": true, "dmarc_policy": "reject"},
  "registration": {"available": true, "registrar": "Domain The Net Technologies Ltd.", "created": "1994-03-29", "expires": "2027-03-30",
    "domain_age_days": 11851, "days_to_expiry": 203, "status": ["client delete prohibited", "client transfer prohibited"], "dnssec": true},
  "certificate": {"issuer": "GlobalSign nv-sa", "issued_days_ago": 83, "expires": "2027-01-02", "expired": false, "valid_for_host": true},
  "page": {"title": "Check Point Software: Leader in Cyber Security Solutions", "language": "en-us", "content_length": 6213, "company_name_on_page": null,
    "description": "Check Point Software Technologies Ltd. is a leading provider of cyber security solutions...", "favicon_url": "https://www.checkpoint.com/wp-content/uploads/favicon.ico"},
  "organization": {"name": "Check Point Software Technologies Ltd.", "legal_name": "Check Point Software Technologies Ltd.", "founding_date": "1993",
    "address": "5 Shlomo Kaplan Street, Tel Aviv, 6789212, IL", "logo": "https://www.checkpoint.com/wp-content/uploads/check-point-logo-600x450-1.png"},
  "social": {"linkedin": "https://www.linkedin.com/company/check-point-software-technologies", "x": "https://x.com/checkpointsw",
    "youtube": "https://www.youtube.com/user/CPGlobal", "instagram": "https://www.instagram.com/checkpointsoftware"},
  "tech": {"cms": ["WordPress"], "framework": ["jQuery", "Bootstrap"], "analytics": ["Google Tag Manager"], "marketing": ["Drift"], "other": ["OneTrust", "X-Powered-By: WP Engine"]},
  "hosting": {"cdn_or_host": "Amazon CloudFront", "server": "nginx", "dns_host": "NS1"},
  "robots": {"fetched": true, "allows_us": true, "ai_crawlers_blocked": [], "sitemap_urls": ["https://www.checkpoint.com/sitemap.xml"]},
  "links": {"about_url": "https://www.checkpoint.com/about-us/", "careers_url": "https://careers.checkpoint.com/", "contact_url": "https://www.checkpoint.com/contact-us/", "...": "17 named slots"},
  "transition_notice": null
}

A history item for the same domain:

{"type": "history", "domain": "checkpoint.com", "charged": true, "match_status": "found",
 "first_capture": "1996-12-03", "last_capture": "2026-09-02", "monthly_captures": 308,
 "last_ok_capture": "2026-06-01", "years_online": 29.7, "last_worked_years_ago": 0.3}

🚦 The verdicts

The rules run top to bottom. The first match wins, and the reason names the rule.

State	Score	Meaning
DEAD_DNS	0	the name does not resolve. When the registry confirms it, the reason adds "and is not registered".
EXPIRED	5	the registration date has passed.
PARKED	10	a parking name server, a redirect to a domain marketplace, or for-sale text on the page.
DEAD_UNREACHABLE	5 to 10	resolves but nothing answers, or the homepage is a 404.
REDIRECTED_AWAY	50	lands on a different-name domain. The destination is recorded, the cause is not guessed. Look at transition_notice.
PLACEHOLDER	40	answers with a "coming soon" page or almost no text.
LIVE_STALE	60	real content, but an old certificate and no change since the previous observation (monitor mode).
LIVE	70 to 100	real content and upkeep. 70 when the server blocks bots or shows a challenge page and we assume it is alive, 85 for a same-name migration or a JavaScript shell, 100 with a fresh certificate.

🔁 Monitor mode

Run the same list on a schedule with mode: monitor. The Actor keeps the previous run's verdicts in a key-value store of its own and each domain item carries changed, changes, previous_state and previous_seen_at. The first run marks every item first_run: true. Set changes_only to push only what changed.

Six things are reported as a change:

Change	What it says
state: LIVE -> PARKED	the verdict moved, in either direction
redirect: none -> acquirer.com	the domain now lands somewhere else, or stopped doing so
certificate expired	the certificate was valid on the previous run and is expired now
mail records gone	the domain had MX records on the previous run and has none now
stopped answering	the site answered on the previous run and does not now
homepage title changed	the title changed while the verdict stayed the same, which is how a quiet rebrand or a takeover page shows up

On top of those, a registration expiring within 30 days is added to changes as registration expires in N days.

Run monitor mode from a saved task. The baseline lives in a named key-value store, domain-check-monitor-<task id>, in your own account. A run started without a task has no task id, so it uses domain-check-monitor-default, and two schedules started that way share one store and report each other's changes. Save the input as a task, schedule the task, and each list keeps its own baseline.

💰 Pricing

Event	Price	When
domain_check	$0.001	once per domain observed, whatever the verdict. The check is the work.
domain_history	$0.003	once per domain the archive knows. A domain with no archive costs nothing.
Actor start	$0.00005	once per run
rejected input, a domain we could not observe, a rate limit, an upstream failure	$0	never

Worked examples, event charges only. The Actor start adds $0.00005 a run, which does not move any figure here: a list of 5,000 leads, $5. A 200-company portfolio watched weekly, $0.20 a week. One domain with its history, $0.004. 50,000 domains with history, $200.

⚠️ Limits, stated plainly

• Homepage only. No crawling, no JavaScript rendering, no login, no CAPTCHA solving. A site that blocks bots is reported as LIVE with a score of 70 and the reason says so. A robots.txt that disallows us is honoured: the page is not read and the verdict says "assumed live, page not read".
• Registration facts come only from TLDs whose registry runs RDAP. .il and .so come back unavailable with the reason, and so do a few others.
• Archive history depends on archive.org having captured the site. New or small sites may have none, and that costs nothing.
• A verdict is an observation at check time. LIVE_STALE needs a second observation (monitor mode) or the history's last_worked_years_ago.
• Up to 10,000 domains per run, 25 checked per call to the service, 20 in flight, 25 seconds per domain. A domain that does not complete inside that is could_not_observe, uncharged.
• When our own resolver fails its canary check, every domain in that call is could_not_observe rather than dead. Absence of observation is not a finding.

🔎 How the check works

1. The input is read as a domain, a website URL or an email address, and reduced to the domain. An IP address, a reserved name and anything that is not a domain is rejected before any paid step.
2. DNS is resolved: A records, name servers, MX and the email provider behind them, SPF and DMARC.
3. The homepage is fetched once, following redirects, and the redirect chain, the final URL, the status, the response time, the title and the page text are recorded. robots.txt is read first and honoured.
4. The TLS certificate is read from the handshake, and the registry's own RDAP server is asked for registrar, dates, status codes, name servers and DNSSEC. Registrant contact fields are never read.
5. The verdict rules run top to bottom over those facts and the first match wins, so the reason on every row names the rule that fired. In history mode archive.org's public API supplies first capture, last capture, years online and the last time the site actually returned a page.
6. Nothing is estimated and no language model is involved. A domain the check could not observe is could_not_observe, never a verdict, and never charged.

🔐 Data, licences and privacy

• Public sources only. DNS, one homepage fetch with an honest user agent, one TLS handshake, the registry's own RDAP server and archive.org's public API. No browser, no proxies, no login, no CAPTCHA solving, and robots.txt is honoured.
• RDAP, not WHOIS scraping. Registration facts come from the registries' public RDAP successor to WHOIS, and registrant contact fields are never read, so no personal data comes back with them.
• Pass-through. Every domain is observed at the moment of the run and passed through to your run's dataset, under your account's retention settings. Operational logs keep the query, timing and the billing outcome, which is what running and billing the service needs.
• Your baseline stays yours. Monitor mode keeps the previous run's verdicts in a named key-value store in your own Apify account, one per saved task, and nothing else.
• Not personal data. The check reads a company's public homepage and a registry's public record. It does not read personal pages, mailboxes or registrant contacts.

⏱️ How long does a run take?

Check and monitor entries go to the service 25 at a time, history entries 3 at a time because archive.org answers in 12 to 17 seconds per domain. Each call has a 290 second wall-clock deadline in the Actor, and the calls run one after another, so a bulk domain check of 5,000 leads is 200 calls and finishes in well under an hour. A single domain answers in a few seconds.

🔌 Website liveness API, clients and integrations

Run the Actor from the Apify Console, from the Apify API, from the Python or JavaScript client, from the Apify MCP server, or from Make, Zapier and n8n through the Apify integrations. Save the input as a task, schedule the task, and set a webhook on run completion to pull only the changed domains into your own system.

from apify_client import ApifyClient

client = ApifyClient("<YOUR_API_TOKEN>")
run = client.actor("pvalyou/website-liveness-check").call(run_input={
    "mode": "check",
    "domains": ["stripe.com", "notion.so", "sedo.com",
                {"domain": "checkpoint.com", "name": "Check Point"}],
    "links": False,
})
for item in client.dataset(run["defaultDatasetId"]).iterate_items():
    print(item["type"], item.get("domain"), item.get("state"), item.get("score"),
          item.get("reason"), item.get("has_mx"), item.get("charged"))

🔗 Works well with

The same input, a company domain, opens our other Actors: Company Enrichment API for firmographics, classification and funding, Job Postings for the open roles from the company's own job board, Patent Lookup for its patents by applicant, Company Registry Lookup for its registry record, and LinkedIn Person Enrichment for its people. Together they turn a list of domains into a company profile without a data broker.

❓ FAQ

Is this legal?

Yes. The check reads what a browser reads on a public homepage, once, with an honest user agent, and honours robots.txt. Registration facts come from RDAP, the registries' public successor to WHOIS, and registrant contact fields are never read. Archive history comes from archive.org's public API at its published pace. There is no login, no bypass and no personal data.

Is this a WHOIS lookup?

It is the part of a WHOIS lookup you can act on, plus the page itself. Registrar, creation date, domain age, expiry date, days to expiry, status codes, name servers and DNSSEC come from RDAP, the registries' own successor to WHOIS. As a whois alternative it adds the verdict: the domain resolves, answers, and is a real site rather than a parked page.

How do I clean a lead list in bulk?

Run the list in check mode, then drop every row whose state is DEAD_DNS, DEAD_UNREACHABLE, EXPIRED or PARKED, and every row with has_mx: false if you are about to email it. only_states does the filtering for you. Dead domain finding, parked domain detection and email domain validation are the same run.

Why is a domain that obviously works marked PLACEHOLDER?

Its homepage sends almost no text and no sign of a JavaScript application. Give the company's name in the entry: company_name_on_page then tells you whether the page is about that company at all.

Why does a live site have no registration facts?

Its TLD has no RDAP server. The answer says unavailable with no_rdap_for_tld rather than guessing.

Can it tell me why a domain redirects to another company?

It records the destination and, when the landing page announces an acquisition, merger or rebrand, quotes that sentence in transition_notice. It does not infer a cause the page does not state.

Does it read JavaScript-rendered pages?

No. It recognises the application shell and marks the site LIVE (score 85). Tech hints, links and the organization record still come from the HTML the server sends.

Can I use it from code?

Yes: the Apify API, the Python and JavaScript clients, and the MCP server. Each entry may be an object with domain, name and mode. See the snippet above.

💬 Support and feedback

Found a domain with a verdict you disagree with, an email provider or a technology we did not recognise, or a TLD whose registration facts you need? Open an issue on this Actor's page with the domain and what you expected. The reason and the raw facts are on every row, so a report with the row attached is the fastest way to a fix.

📝 Changelog

• 0.1 First public release: check, history and monitor modes, eight verdicts with a 0 to 100 score, registration facts from RDAP, email provider and SPF/DMARC, certificate, hosting, technology fingerprints, organization record and social links, archive history, two priced events.