Data freshness

How product links are checked

Status definitions, request boundaries, scheduling rules and the limits of automated reachability evidence.

Method documentation updated:

What a link check means

A link check records whether a specific external URL appeared reachable at a specific time. It does not verify product authenticity, seller identity, authorization, quality, stock, transaction safety, or future availability.

When the checking store or worker is not ready, products remain unknown. Existing price, title, image, or age is never used to infer a positive link status.

Status definitions

Active
The URL returned a 2xx HTTP response at check time. This does not claim that the product, seller, stock or destination is trustworthy.
Redirected
The URL returned an HTTP redirect. Only the destination hostname is retained for review; the checker does not follow the redirect into an account or checkout flow.
Inactive
The URL returned HTTP 404 or 410 at check time. It may later return, so the result is dated and scheduled for another check.
Unavailable
The host timed out, returned a transient server error, rate limit, or other response that did not support a durable classification.
Blocked
An access policy, bot challenge, login wall, or permission response prevented a reliable result.
Unknown
No current check exists, the URL is invalid or private, or the response cannot support a classification.

Check process

  1. Normalize the HTTP(S) URL and store a SHA-256 hash plus hostname; credentials and fragments are rejected.
  2. Resolve the hostname and refuse loopback, private, link-local and other internal addresses to reduce SSRF risk.
  3. Use a descriptive user agent, an 8-second timeout, at most four concurrent requests overall and at most two for one host.
  4. Prefer HEAD; use one bounded GET only when a host explicitly does not support HEAD. Requests do not send cookies or account credentials.
  5. Record response status, redirect host, method, evidence class and check time without copying response bodies or private content.

Freshness and operational limits

The initial worker processes enabled products in bounded batches, beginning with the oldest product updates. Board eligibility is evaluated separately: at least 80% of a Board's products need an active check within the previous 14 days. Products outside a completed batch remain unknown or keep their last dated status.

Active results are scheduled again after seven days; redirects and blocked results are retried sooner, while transient failures are retried after six hours. Each result is written before the worker moves on, so an interrupted run resumes from durable per-URL checkpoints instead of claiming unverified coverage.

Reports and corrections

Use the product-page report control to flag a broken, redirected, mismatched or potentially unsafe destination. The report collects an enumerated reason, not free-form personal information. For broader concerns, use the contact page.

A later successful HTTP check does not automatically override a substantiated content or rights concern; those require editorial review.