Every page-type or classification vendor will tell you their data is accurate. The only way to know whether that's true for your use case is to test it yourself, on the free 100-domain sample, before a contract is on the table. This guide is that test plan: what "verified" actually means operationally, which metrics matter, which don't, and exactly how to spot-check the sample against reality in under an hour.
Any classification vendor can say a URL is "verified." What that word means in practice varies enormously — from "a human clicked it once" to "an automated pipeline traced the site's own link structure and confirmed the destination" — and the difference matters enormously for a security control that's about to decide what an autonomous agent can and can't reach.
This distinction is easy to skip past in a sales conversation, because "verified" sounds precise regardless of what's actually behind it. A vendor whose "verification" is a human spot-checking a handful of top-1000 domains once, months ago, and a vendor whose classification pipeline traces the live link structure of every domain and re-derives the page-type map from what it actually finds are making very different claims, even though both might use the identical word on a landing page. You cannot tell these apart by reading marketing copy. You can tell them apart in about an hour with a free sample and a browser, which is the entire point of this guide.
A verified URL is a link discovered by tracing a domain's actual, live link structure — not a guessed or templated path — that was individually fetched and classified by a multi-stage pipeline into one of the 28 page types. An absent page type on a domain marked found: true is a verified negative: the pipeline checked and found no such page, not a gap the pipeline never got to. Both claims are testable against the sample, and the procedure below tests both.
Open a sample of the login, checkout, or pricing URLs listed for domains you recognize. Do they land on the page the row claims? This is the single most important check and the easiest to run yourself.
Pick a domain where a page type you'd expect (say, pricing on a SaaS product) is missing from the row. Check the live site: does it genuinely lack that page, or does it have one the classification missed?
Sites restructure. Ask what refresh cadence applies to your licensed tier or API plan, and whether a re-verification cycle is already in progress for newer page types — see the honest coverage note on action types below.
The question that isn't worth spending your evaluation time on: an aggregate "accuracy percentage" claimed by any vendor, including this one, without a methodology you can independently reproduce. A single top-line number invites exactly the kind of cherry-picking that makes it meaningless — test the specific domains and page types your own agents will actually touch, and treat aggregate accuracy claims from any classification vendor as a marketing number until you've verified a sample yourself.
Most bad buying decisions on classification data don't come from skipping evaluation entirely — they come from an evaluation that looks thorough but tests the wrong thing.
Only checking domains you already trust. Verifying the login URL for a handful of top-100 global brands tells you almost nothing about the long tail, which is exactly where a policy guessing paths instead of using verified URLs fails most often. Deliberately include a few domains you don't recognize in your spot-check, precisely because those are the cases a lower-quality classification pipeline is most likely to get wrong.
Testing only the page types you care about most. If your policy leans heavily on login and checkout denial, it's tempting to only verify those two page types and skip the rest. But if your policy also uses IAB or filtering categories as a condition — as the annotated schema in the policy file guide does — a category error can silently break a rule you never thought to test, in either direction: an over-broad allow or an over-broad deny.
Evaluating once and never again. A page-type database is not a static artifact; it is refreshed on a cycle, and coverage of newer page types like the eight action types genuinely changes over time as records are re-verified. An evaluation from months ago tells you what quality looked like months ago. Re-run at least the fast spot-check whenever a decision is actually riding on current coverage.
Confusing "the vendor's own dashboard says X% coverage" with an independent check. A coverage statistic reported by the vendor's own tooling, however accurate, is not the same evidence as opening the URLs yourself. It may well be correct — but the entire reason to run a five-minute manual check against a handful of domains you know is that it doesn't depend on trusting the reporting layer at all.
Mix well-known domains you can verify from memory with a few you don't recognize, so you're not only testing the cases the vendor had the most incentive to get right.
Confirm the URL loads and actually is the claimed page type — a login form for login, an actual pricing table for pricing, and so on. Note any mismatch.
Visit the live site and look for that page type yourself. If the site clearly has one and the row doesn't list it, that's a coverage gap worth asking the vendor about directly.
Do the IAB category, web-filtering category, language, and country fields match what you'd expect for each domain? These matter as much as page types if your policy conditions combine them, as in the policy schema guide.
Signup, password_reset, cart, checkout, upload, post_create, comment, and subscribe ship with the current reclassification cycle and aren't yet on every record. Use the sample to see the real, current proportion rather than assuming full coverage.
Load the CSV into the check function from the implementation guide and confirm your allow/deny/flag rules produce the split you expect on real rows before testing against a paid plan or licensed database at scale.
This sketch loads the sample CSV and reports basic coverage statistics — how many domains carry each page type, and what share of rows include at least one action-type key. It's illustrative only, meant to run in a few seconds against the 100-row sample as a starting point for your own evaluation script.
Run this before and after any refresh cycle you're evaluating, and compare the action-type percentage over time if you're deciding whether to wait for fuller coverage of the eight newer page types or start integrating now against the twenty that have been stable throughout.
| Column | What to check it against |
|---|---|
page_types | Open each listed URL directly. It should load and visibly be the claimed page type, not a redirect to an unrelated page or a 404. |
num_distinct_page_types | Should equal the count of types actually listed in page_types for that row — a basic internal-consistency check worth automating first. |
language | Compare against the visible language of the site's main pages, especially for domains serving multiple locales. |
IAB v2 / v3 Tier 1–4 | Does the assigned category match what you'd call the site if you were categorizing it yourself? Spot-check a few domains outside the obvious categories (news, e-commerce) where classification is harder. |
Web Filtering Category | Compare against the IAB category for the same row — they should tell a consistent story about what kind of site this is, even though they're two different taxonomies. |
OpenPageRank, popularity rank groups | These should roughly track your own intuition about how well-known each domain is; wildly inverted rankings for domains you know well are worth flagging. |
None of these checks require special tooling — a spreadsheet, a browser, and the willingness to actually click through rows rather than skim them is the entire evaluation stack. The point isn't to build an elaborate audit; it's to replace "the vendor says it's accurate" with "I opened twenty rows and it held up," which is a categorically stronger basis for a purchasing decision.
The point of testing the sample isn't just confidence — it should change what you buy, not merely whether you buy.
If your spot-check holds up cleanly and your integration is a prototype or a workload where an external network call per lookup is acceptable, the self-serve lookup API is the fastest path from here, starting at $99/month for 90,000 lookups. If your evaluation surfaces a latency or data-residency requirement — an agent gateway that can't tolerate a network round-trip per navigation decision, or a deployment that can't call out to a third-party API at all — the same verified data is available as an on-premise database license, starting at $14,999 one-time for the 10M-domain tier, with an optional 30%-of-license-price annual refresh. Both delivery modes return the identical schema you just tested, so the evaluation you ran against the free sample carries over directly regardless of which one you choose. Full tier and volume details are on the pricing page.
One evaluation-driven decision worth making explicitly before you buy: if your policy depends heavily on the eight newer action-type page types, check the sample's current coverage of them (step 5 in the procedure above) and decide whether to integrate now against the stable original twenty and layer in action types as re-verification proceeds, or wait for broader action-type coverage first. Either is a reasonable choice — the point is making it based on what you actually measured, not on an assumption either way.
The DseWiki hijack ran for roughly seven weeks on a wiki with legacy HTTP-GET write endpoints — a coverage gap in whatever traffic monitoring existed at the time went unnoticed for that entire window. Our analysis shows the same pattern applies to policy data quality: a page-type database nobody spot-checked against real domains is a database whose gaps you discover the same way, after the fact. Verifying coverage yourself, on the free sample, before it's load-bearing is the cheap version of that lesson.
Would your agents have been stopped? Check the incident analysis Read the DseWiki hijack analysisThe honest fine print — the same two assumptions we publish, plus two operational ones
Turn the fields you just verified into allow, deny, and flag rules with the annotated schema.
Architecture for caching and serving this data at scale once you trust it.
Why verifying the identity-group page types specifically deserves the most scrutiny.
If your evaluation also needs to cover domain-level risk rather than page-level classification — whether a whole site should be reachable at all, independent of which page type on it — the same spot-check discipline applies to aitoolsblocklist.com's domain categories, which answer a related but distinct question about the same URL.
Download the free 100-domain sample and work through the six-step procedure above before you evaluate anything else.
