Ask which of the 28 page types gets looked up most across real agent traffic and the answer is not close: pricing. This reference explains why the pricing lookup dominates real-world call volume, how a single verified pricing URL is recorded per domain, and how to handle the country and currency variants a canonical pricing page often hides behind.
Most page types are needed by a subset of agents doing a specific job: login matters to an agent that authenticates, careers matters to a recruiting-sourcing agent, status matters to an uptime-monitoring agent. Pricing is different. It sits at the intersection of nearly every task an agent is asked to do when it evaluates a company at all — competitive research, procurement, market sizing, sales enablement, investment screening — because the price a company charges is close to the first fact anyone evaluating it wants to know.
That breadth of use is what makes pricing the single highest-volume lookup across real deployments of this dataset, ahead of every other page type by a wide margin. An agent built specifically to monitor status pages will call the API constantly, but only ever for the domains it was configured to watch. An agent built to research vendors, on the other hand, calls pricing on every single domain it looks at, because pricing is relevant to essentially any vendor evaluation task regardless of industry, size, or the specific question the agent was asked to answer.
Illustrative ordering of relative lookup frequency across typical multi-agent deployments, not a published usage statistic. The pattern — pricing well ahead of task-specific page types — is consistent across the use cases in the Related pages section below.
The lookup-cost argument sharpens the case further. An agent without a verified URL has to reach a pricing page the slow way: fetch the homepage, parse the navigation, guess that "Pricing" or "Plans" is the right link text, follow it, and hope the destination did not require a second hop through a regional gateway or a marketing redirect first. That is easily three to five fetches and several thousand tokens of HTML to parse, for a single fact. A verified pricing URL turns the same task into one deterministic request. Multiply that by the domain count in a typical procurement or competitive-intelligence run — tens or hundreds of vendors in a single research pass — and the saved steps compound into the difference between a task that finishes in seconds and one that spends a meaningful fraction of its token budget just finding the page it actually needed to read.
The Commerce group of the 28 page types includes both pricing and product, and the two get confused often enough to be worth separating explicitly. They answer different questions, and a policy or a research agent that conflates them will end up reading the wrong page for the task at hand.
pricing answers "what does this cost, and what do the tiers include." It is the plans-and-cost page: a comparison of tiers, a monthly or annual price, feature checklists per tier, and often a self-serve signup or contact-sales call to action. product answers a different question — "what does this do." It is the feature or capability page: what the software or service actually is, its core functionality, screenshots or demos, without necessarily stating a price at all. A SaaS company's /features page is product; its /pricing page is pricing, even though both are reachable from the same top-level navigation and both get classified as commerce-adjacent read types.
For a research agent, the distinction determines which page actually answers the question it was asked. A procurement agent tasked with comparing vendor cost needs pricing; a market-research agent cataloguing what a set of competitors' products actually do needs product. Both are read-only allow types under nearly every agent policy, so the risk classification is identical — the reason to keep them separate in the schema is accuracy of retrieval, not access control.
Not every pricing page states a number. Enterprise software, custom manufacturing, and B2B services commonly publish a pricing page that lists tiers or feature comparisons but replaces the price itself with "contact sales" or "request a quote." This is still classified as pricing, and the distinction matters for anyone building a policy or a scraping-avoidance argument around this dataset.
The page type describes what the page is for — the domain's designated location for cost and plan information — not what specific data happens to be published there on a given day. A verified pricing entry on an enterprise vendor's domain is exactly as useful to a procurement agent as a self-serve SaaS pricing page with numbers on it: in both cases, the agent has been pointed to the right page instead of having to guess, and what it finds there (a number, a range, or a form) is a fact about that page's content, not about whether the page type classification was correct. Note also that the contact-sales call to action on a custom-quote pricing page is itself typically a contact page type in its own right when it leads to a dedicated form — two page types, two verified URLs, on the same domain.
A lookup's page_types object returns exactly one pricing URL per domain when a dedicated pricing page exists — the domain's canonical, primary pricing entry point, verified live the same way every other page type is. It is not an array of every locale variant the site might serve; it is the one URL you would land on by clicking "Pricing" from the domain's main navigation.
This single-URL design mirrors every other page type in the schema — see the full response schema on the API docs page — and keeps the record simple: one canonical entry per domain, with locale and currency handling left to the page itself and to the agent's own navigation logic once it arrives there.
A meaningful share of pricing pages are not static: they detect the visitor's location and adjust currency, or offer a locale switcher that leads to a country-specific path. The database records the canonical entry point; what happens after that is a navigation question, not a database field, and it splits into two cases with very different handling.
Same-domain locale paths — a country or language segment inserted into the path, like /uk/pricing or /en-au/pricing — stay on the domain that was already checked and verified. There is no new policy question here: the page type is still pricing, the domain is still the one your lookup covered, and the agent can proceed exactly as it would on the canonical URL.
Cross-domain locale redirects — a country-code top-level domain swap, like a .com pricing page redirecting to a .de or .co.uk variant of the same brand — are a genuine domain change. The new domain needs its own lookup and its own verdict before the agent proceeds, exactly as covered in the redirect-handling guidance in the implementation guide: a URL that was checked and allowed does not stay allowed through a hop to a different domain, regardless of how closely related the two brands are.
Currency-only changes — a query parameter or a client-side toggle that swaps $ for € without changing the path or domain at all — involve no policy question whatsoever, since neither the domain nor the page type has changed. The overwhelming majority of "locale variance" an agent will actually encounter on pricing pages falls into this no-op category or the same-domain-path category above; genuine cross-domain locale redirects are the minority case, but the one worth building a re-check into your integration for, since it is the one where skipping the re-check would mean trusting a domain your policy never actually evaluated.
Pricing is one of the more volatile page types in the vocabulary. A legal or about page can go years without a URL change; a pricing page tends to move whenever a company restructures plans, runs a redesign, launches a new tier, or migrates its marketing site — all of which happen on a much shorter cycle than most corporate content.
This is a practical reason, not just a general one, to treat pricing as a candidate for the optional monthly refresh add-on on database licenses (30% of the license price per year, covered on the pricing page). A one-time snapshot is frozen at purchase-date accuracy; a pricing URL that was correct on delivery day can 404 or silently redirect to an unrelated page within months as a vendor restructures its plans. For API-plan subscribers this is less of a concern — each lookup hits the live, continuously maintained database rather than a static snapshot — which is one reason procurement and competitive-intelligence workloads that check pricing constantly often start on an API plan rather than a database license.
Every lookup that returns a pricing URL also returns the domain's IAB content category (from the 700+-category taxonomy), its web-filtering category (from the 59-category taxonomy), and its Open PageRank popularity score in the same response — at no extra cost per lookup. For a market-research or competitive-intelligence agent, that combination turns a single-purpose pricing lookup into a filterable dataset.
A market-sizing agent tasked with cataloguing pricing across a software vertical, for example, can use the IAB category to scope which domains to even bother checking, then pull the verified pricing URL only for domains that match — rather than checking pricing indiscriminately across a popularity-ranked domain list and filtering afterward. An agent comparing enterprise vendors against consumer ones can weight the popularity rank alongside the pricing lookup to distinguish an established player's published pricing from an unranked or very new domain's, without a second API call or a separate categorization service. This is the same "richer record at the same price" argument made on the pricing page's taxonomy section: three taxonomies in one lookup, pricing included, rather than a single-purpose price-finder that leaves the categorization work to a separate tool.
The 2026 incidents that got agents into trouble — the Hugging Face breach, the DseWiki hijack, the JFrog Artifactory covert channel, and account takeovers across four services — all involved agents reaching write or credential surfaces, never a read-only page like pricing. That distinction is the point of a page-type map: an agent can be given free rein on pricing, documentation, and blog pages while every write and credential surface stays denied by default, without needing a separate rule for each site.
The 2026 agent incidents, prevented Read the DseWiki hijack caseThe honest fine print — the same two assumptions we publish, plus two operational ones
Vendor pricing lookups without ever risking a checkout click.
Verified pricing URLs instead of re-crawling a domain to find the page again.
Docs and pricing pages watched together for plan and positioning changes.
Pricing alongside leadership and case-study pages as research targets.
The commerce page type on the other end of the risk spectrum from pricing.
Request and response shape for pulling pricing at scale on the Pro plan.
Where a read-safe type like pricing fits inside the full enforcement model.
The 100M+ domain filtering database from the same team, for human-facing traffic.
100 domains, each with its verified pricing entry alongside the rest of the page-type map.
