How We Verify Vendor Pages (and What We Ignore)

Every number on ViaReviews is supposed to answer two questions: where did it come from, and when was it captured. If we cannot answer both, the number does not belong on a product page as a fact.

This article explains the verification process in detail — what we capture, how we capture it, what we do when a page fails, and the cases where the honest answer is "unknown". It is also an invitation to audit us: every product page links back to its source data, and the methodology page explains how the score uses it.

Why this process exists

Weight-loss products are sold through pages that change constantly. Prices move with promotions, refund terms hide behind support widgets, ingredients are listed in images, and some offers are different depending on the visitor's country, device or traffic source. Copying a number from another review site would be faster and less useful; the copy inherits the other site's mistakes and cannot be dated.

So we verify against the source itself. The rule is simple: if it is not documented on an official page or returned by an official network API, it is not stated as fact. The page shows "unknown" instead. That is not a failure of the product; it is a limit of the evidence.

What we capture

For every published product, we aim to record:

• Name and brand — as written on the official page, cleaned of marketing prefixes.
• Official URL — the vendor's product page, not an affiliate redirect.
• Affiliate URL — the tracked link used for the call-to-action, kept separate from the data.
• Price and currency — the published single-purchase price. If only bundle pricing is shown, we record the smallest published per-unit price and note the context rather than pretending it is a single-bottle price.
• Refund window — the money-back term stated by the vendor, in days. A missing term is "unknown", not zero days and not a guess.
• Form and type — capsules, powder, tea, drops, digital program.
• Ingredients — only names actually published. A proprietary blend with no ingredient list is recorded as "not disclosed".
• Pros, cons and best-for — editorial summaries tied to documented features, not to promises.
• Goals — the buyer goals a product is documented for (for example, appetite or digestion), used by the quiz and best-of pages.
• Red flags — auto-ship clauses, missing refund terms, fake countdowns, disease claims, undisclosed subscriptions.
• Reviews — sourced vendor testimonials with the source URL and capture date, labelled as customer statements rather than clinical evidence.
• Source URL and capture date — the two fields that make the rest auditable.

We do not record a "rating" as if it were a laboratory result. If a rating appears, it comes from a documented source and is labelled accordingly.

The pipeline, step by step

1. Discover the product

Products enter the catalog from the owner's affiliate links, an official network API, or a manual research queue. The affiliate link is the commercial path; it is never used as the data source for price or refund terms. The official page is.

2. Fetch the page

We use server-side HTTP with a normal user agent, a timeout and rate limiting. We respect robots.txt for pages we are allowed to fetch. We do not use a real browser, which has an important consequence: anything that only appears after client-side JavaScript may be invisible to us.

3. Parse only what is published

The parser looks for structured and semi-structured signals: page title, JSON-LD or embedded product data, price strings, refund language, ingredient headings, and network product IDs. It does not "fill in" a price from a similar product or infer a refund window from a competitor.

4. Normalize carefully

Prices are converted to a numeric amount and a currency. "From $49" is not the same as "$49"; "3 bottles for $147" is not the same as "$49 per bottle" unless the math is explicit. When the offer is ambiguous, we keep the ambiguity in the note and avoid a false precision.

5. Store the source and the date

Each record keeps the official URL and a capture timestamp. The timestamp is stored in UTC so daily snapshots and price-history charts do not drift with server time zones. When a product page says "verified [date]", that date comes from this field.

6. Snapshot daily

A daily pipeline captures the current price, refund term, marketplace gravity and rating where available. It writes one snapshot per product per day and flags meaningful changes — around ±5% for price and ±10% for gravity — so a price movement does not silently rewrite history. The product page can then show a trend instead of a single number.

7. Run quality gates

Before data is treated as healthy, it passes through checks for missing required fields, stale capture dates, duplicate slugs, category mismatches, price outliers, broken official URLs and empty goals where a goal is expected. Critical issues block a "green" quality report; warnings are visible in the admin quality page. A product can be published with an unknown price, but it cannot be presented as if the price were known.

8. Publish with provenance

The product page and its legitimacy analysis render the values that passed the gates, with the source and capture date. Reviews carry their own source and date. The score is computed from those values, not from the sales copy.

What "unknown" means

"We don't know" is a valid data point. We use it when:

• the price is hidden behind JavaScript or a checkout flow we cannot access;
• the page blocks our verifier or returns an error;
• the offer is bundle-only and no honest per-unit price can be calculated;
• the refund terms are not stated, or are contradicted between the page and the checkout;
• the ingredient list is an image or a proprietary blend with no names.

On product pages, a price of 0 or a refund of 0 is displayed as unknown, not as "free" or "no refunds". That distinction matters: a missing policy is a reason for caution, not proof that the vendor refuses refunds.

Why some vendor pages fail verification

The failures are predictable:

• Cloudflare and bot protection. Some pages refuse datacenter traffic, even with a normal browser user agent.
• JavaScript-only pricing. A price that appears only after a script runs is not reliably capturable without a real browser.
• Geo-pricing and A/B tests. The same URL can show different prices by country or experiment. We record what the page served and note the limitation rather than claiming a universal price.
• Expired, parked or hijacked domains. A page that no longer represents the product is not a source.
• Fake countdowns and scarcity. A timer next to a price is a promotional device; we record the promotion as promotional, not as a permanent price.
• Bundle math. "Buy 6, get 3 free" is not a single-bottle price. We avoid converting it unless the per-unit math is explicit.
• Contradictory terms. If the sales page says "365-day guarantee" but the checkout says "unopened only, 30 days", the contradiction itself is a red flag worth recording.

When a page fails, the product can remain published with unknown fields, or stay in draft until the data can be verified. We do not fill gaps with plausible numbers.

What we ignore

• Marketing claims as data. "Melts 62 lbs of deadly fat" is a claim, not a measurement. It may be recorded as a red flag if it is an unsupported disease or fat-loss claim.
• Other review sites and blogs. We do not copy a price or refund term from a third party. If we cannot verify it at the source, it stays unknown.
• Invented reviews. Vendor testimonials are published as sourced customer statements, never as independent studies. We do not generate reviews or aggregate ratings to fill a page.
• Affiliate pressure. The commission on a product does not change its captured data or its score. The link is tracked separately from the evidence.
• Unverifiable "lab tested" badges. Without a lab, a certificate or a batch number, the claim is marketing.

How the data affects the score

The SiftScore is a documented formula, not an editor's opinion. Missing data is handled neutrally rather than punished as if it were bad; transparency is rewarded when a vendor discloses the formula. A product with a missing refund policy can still score on other components, but its legitimacy verdict moves toward caution because the commercial terms are not verifiable.

You can read the exact formula and a worked example on the methodology page. The important part for this article is the direction of causality: the score follows the data, not the other way around.

Corrections and changes

Vendors change prices, bundles and policies. When that happens:

1. The daily snapshot records the new value and flags the change.
2. The product page shows the new captured value with its date.
3. A material contradiction (for example, a deleted refund policy) is recorded as a red flag or triggers a review.
4. Anyone can report an error through the contact page. Vendor correction requests are welcome; we verify them against the source, not against the request itself.

We do not silently rewrite history. Snapshots and capture dates exist so a reader can see that a value changed and when.

How to audit us

You do not have to trust the process; you can check it:

• Open any product page, such as All Day Slimming Tea, and compare the displayed price and refund term with the official page.
• Check the capture date and the source link.
• Read the legitimacy analysis for the red-flag checklist.
• Compare two products side by side in the comparison tool.
• Read the methodology and the buying guides, including how to choose a supplement and refund policies.

If a number is wrong, tell us. A correction with a source is more valuable than a perfect-looking page.

FAQ

Why do some products show "unknown" for price or refund?

Because the value was not documented on an official page we could verify. We prefer an honest gap to a plausible guess. The product can still be evaluated on ingredients, red flags and sourced reviews.

Do you copy data from other review sites?

No. We verify against the vendor page or an official network API. Copying would inherit another site's mistakes and could not be dated to our own capture.

How often is the data refreshed?

A daily pipeline captures snapshots and flags significant changes. The product page shows the latest captured value and date; a stale value is visible as stale, not silently rewritten.

Why can a price change between two visits?

Promotions, geo-pricing and A/B tests can change what a page serves. We record what we captured at the time and note the limitation. A price is a snapshot, not a permanent contract.

Do affiliate commissions influence the data or the score?

No. The affiliate link is tracked separately from the evidence. The score is computed from documented data and the published formula; a higher commission does not raise a score.

What is a red flag in your data?

Examples include a missing refund policy, an auto-ship clause, a fake countdown, a disease claim, an undisclosed subscription or a contradiction between the sales page and the checkout. Each flag is tied to what was observed.

Bottom line

Verification is less exciting than marketing and more useful. Our promise is narrow and testable: every displayed data point has a source and a capture date, missing data says "unknown", and the score follows the evidence. When a vendor page cannot be verified, we say so — and we would rather lose a data point than invent one.

Related

• SiftScore methodology
• How to choose a weight-loss supplement
• Refund policies explained
• Weight-loss category

Last reviewed by the ViaReviews Research Team on 2026-11-06. This article describes our editorial process; it is not medical advice.