Search Evidence Validator

Validate search-result pages before an agent trusts, cites, summarizes, or spends more money on them.

Search Evidence Validator is a machine-consumable Apify Actor that fetches public HTTP(S) pages and returns explicit evidence-quality records. It measures reachability, query relevance, content depth, freshness, and citation readiness; extracts citation metadata and an evidence excerpt; fingerprints the fetched text with SHA-256; and assigns each page ACCEPT, REVIEW, or REJECT.

When an agent should call it

Use this Actor after search or discovery and before expensive downstream work.

A typical machine workflow is:

search/discovery
      ↓
candidate URLs
      ↓
Search Evidence Validator
      ↓
ACCEPT / REVIEW / REJECT + evidence record
      ↓
cite, summarize, buy another tool call, or discard

It is useful when an agent needs to answer questions such as:

• Is this search result actually reachable right now?
• Does the page contain the terms the upstream query was looking for?
• Is the page substantial enough to use as evidence?
• Does it expose a usable title, canonical URL, publication time, and HTTPS source?
• Has the page content changed since a previous run?
• Should downstream work accept, manually review, or reject this source?

It does not replace semantic fact-checking, source-authority judgment, or claim-level verification. It is a deterministic pre-filter and evidence-normalization layer for public web pages.

Input

Provide either urls or richer results objects. Add query when you want query-term relevance scoring.

Up to 20 candidate pages can be processed in one run.

Minimal input

{
  "query": "example domains",
  "urls": [
    "https://www.iana.org/help/example-domains"
  ],
  "maxResults": 1,
  "timeoutMs": 8000
}

Search-provider input

{
  "query": "example domains",
  "results": [
    {
      "url": "https://www.iana.org/help/example-domains",
      "title": "Example Domains",
      "publishedAt": "2017-05-13"
    }
  ],
  "maxResults": 10
}

Supported fields:

Field	Type	Purpose
query	string	Optional upstream query used for relevance scoring.
urls	string[]	Public HTTP(S) URLs.
results	object[]	Search results containing url and optional title / publishedAt.
maxResults	integer	1–20 candidates, default 10.
timeoutMs	integer	Per-page fetch timeout, 1,000–12,000 ms, default 8,000.

Provide at least one URL through urls or results.

Output contract

The default dataset contains one record per processed candidate.

Example from the live acceptance fixture:

{
  "url": "https://www.iana.org/help/example-domains",
  "finalUrl": "https://www.iana.org/help/example-domains",
  "status": 200,
  "title": "Example Domains",
  "canonical": "https://www.iana.org/help/example-domains",
  "wordCount": 158,
  "query": "example domains",
  "matchedQueryTerms": ["example", "domains"],
  "relevanceScore": 1,
  "freshnessScore": 0,
  "depthScore": 0.1756,
  "citationScore": 1,
  "qualityScore": 0.7351,
  "decision": "REVIEW",
  "issues": [],
  "contentSha256": "9ef0c234acc6d8cbf49013291834d2a263696bee76feeef6b5a40f0d526e0d16"
}

Records can also include description, publishedAt, ageDays, an evidence excerpt, and accessedAt.

A failed fetch (network error, timeout, blocked target, redirect limit) produces a REJECT record with qualityScore: 0 and an explicit issue instead of silently disappearing. A page that answers with a non-2xx HTTP status (for example 404 or 503) is still scored and returned with an http_status_<code> issue so the caller can see it, but its decision is always REJECT (the qualityScore is still reported). Neither kind of row is charged (see Pricing). Callers should treat any record whose status is not 2xx as unusable evidence.

Decision contract

The overall score is intentionally inspectable rather than opaque.

30% query relevance
25% reachability / HTTP health
20% content depth
15% citation readiness
10% freshness

Decision thresholds:

Score	Decision
>= 0.75	ACCEPT
>= 0.50 and < 0.75	REVIEW
< 0.50	REJECT

Issues can include signals such as non-2xx status, missing title, thin content, low query relevance, or non-HTTPS transport.

The scoring contract is explicit and repeatable. Freshness naturally changes as a publication ages. contentSha256 is the stable fingerprint for unchanged extracted page text.

Pricing

This Actor is live on Apify with pay per event pricing.

Event	Free / Bronze	Silver	Gold / Platinum / Diamond
validated-page	$0.01005	$0.01003	$0.01001

apify-actor-start costs $0.00005 per charged start unit. Apify charges one start unit per GB of run memory, with a minimum of one. At the default 256 MB, one successfully validated page therefore has event charges of $0.01010 in the Free/Bronze tier. Apify platform usage is included in these event prices; callers are not billed platform usage separately. The configured minimum spending cap of $0.01005 is a run setting, not a promise of the total bill.

The validated-page event is charged only for a page fetched with a 2xx HTTP status, after its scored record has been pushed. This includes 2xx pages that score REVIEW or REJECT for relevance, depth, or citation reasons. Pages that return a non-2xx status (such as 404 or 503) and fetches that fail outright still return diagnostic rows but are not charged validated-page. The run's SUMMARY record reports produced (charged rows) and notCharged (non-2xx and failed-fetch rows). The one-time apify-actor-start event is charged per run regardless of outcome.

The Actor is public, uses LIMITED_PERMISSIONS, and has Standby disabled. As of October 24, 2026 the Apify Store lists it as allowed for Apify agentic payments; see Apify x402 for how that flow works. Eligibility is set by Apify and can change. A successful run or an Actor charge counter does not establish a paid execution by a customer, creator revenue, or margin. The current event prices are also shown in this Actor's Pricing tab.

Machine-facing behavior

The Actor is designed to sit behind search APIs, research agents, RAG ingestion, citation pipelines, procurement agents, and other systems that need a cheap quality gate before committing more tokens or money.

Useful downstream patterns include:

if decision == ACCEPT:
    continue automatically
elif decision == REVIEW:
    require stronger corroboration or a second source
else:
    discard candidate

The SHA-256 fingerprint can also be persisted by a caller to detect whether extracted page text changed between validation runs.

Safety boundaries

Network fetching is intentionally constrained so the Actor cannot be used as a general internal-network probe.

It:

• accepts only HTTP and HTTPS;
• rejects loopback, private, link-local, reserved, carrier-grade NAT, multicast, documentation, and common internal targets;
• blocks internal-style DNS suffixes such as .localhost, .local, .internal, .home, and .lan;
• resolves DNS before connecting and rejects a hostname if any returned address is private;
• pins the request to a validated resolved address;
• revalidates every redirect;
• follows at most three redirects;
• rejects URLs containing credentials;
• forwards no caller-supplied credentials or arbitrary headers;
• limits URLs to 2,048 characters;
• caps fetched response data at 750 KB;
• caps per-page timeout at 12 seconds.

Limits

This Actor validates public HTML-style evidence. It is not a browser renderer, login/session client, CAPTCHA bypasser, private-network scanner, authority-ranking engine, or claim-level truth oracle.

JavaScript-only pages may expose limited text when the initial HTTP response does not contain the rendered content. Use a browser-capable extraction step upstream when rendering is required, then pass the resulting public evidence source through the appropriate verification pipeline.

Live proof

The deployment pipeline requires all of the following before latest is considered healthy:

1. deterministic tests pass;
2. Apify cloud build succeeds;
3. latest is applied;
4. a real Apify cloud run executes against a public fixture;
5. the returned dataset item matches the output contract.

The current production line has passed that gate and is publicly Store-indexed and PPE-monetized. A non-owner paid run, received creator payout, and positive realized margin have not been established here.