Enriching a lead list means turning a company name into a real contact: who leads the team, what the company does, how to reach them. That information lives on contact, about and leadership pages — three page types a guessing agent finds inconsistently and a login-gated CRM widget can derail entirely. The AI Agent Allowlist resolves those three page types directly per domain, and supplies the metadata to dedupe and rank what comes back.
In plain words: one lookup per company domain returns its contact, about and leadership URLs where they exist, tells the agent when a page type is missing instead of leaving it to guess, and comes with popularity and authority signals to help decide which of two similar-looking domains is the real one. Login and signup pages are flagged deny in the same response, so the agent never treats a customer portal as another contact source.
A wave of 2026 agent incidents ran through account and identity surfaces. Third-party account takeovers, the Hugging Face breach and the DseWiki hijack all involved agents reaching credential pages they should never have touched. A lead enrichment agent walking company sites all day is exposed to exactly that class of page — unless it's told in advance which pages those are.
A lead enrichment agent working a company list runs the same four-stage pattern for every row. The difference between doing it with guessed navigation and doing it with verified page types shows up at every stage, but most acutely at the second and third, where the target page's URL is the least predictable across companies.
The lead record's company name or website field is normalized to a registrable domain, once, before any page-level work starts.
The verified contact URL is fetched directly — a generic phone number or a form, but a real signal of how the company wants to be reached.
About supplies company description and size signals; leadership supplies named executives — the fields a sales record actually needs filled in.
Popularity rank, OpenPageRank and IAB category resolve which of several similarly named domains is the actual company before the record is written back.
Contact pages cluster around a handful of predictable paths. Leadership pages do not. One company calls it "/leadership," another "/about/team," another "/company/executives," another splits it across a press-kit PDF linked from an investor-relations subdomain. A guessing agent tuned on the first pattern will miss the other three entirely — and a scraping approach tuned on all four still has no way to know, for company five, that no such page exists at all and it should stop looking rather than keep guessing new paths.
The practical effect on an enrichment queue is a long tail of records that sit "in progress" indefinitely: not enough of a hit to auto-fill, not a clean miss the pipeline can mark done and move past. Every one of those stuck records represents an agent that spent a fetch or two on a plausible-looking path, found nothing conclusive, and left the field blank without a clear signal to the operator about whether the page genuinely doesn't exist or the agent simply didn't find it.
| Signal | Guess-and-scrape agent | Verified-lookup agent |
|---|---|---|
| Leadership page hit rate across a mixed company list | inconsistent — depends how many URL patterns are hardcoded | whatever the domain actually links, found once |
| Handling of companies with no leadership page | record left blank, ambiguous "not found" vs "not tried" | explicit absent flag, safe to mark done |
| Risk of touching a login-gated staff directory | real — nav links don't distinguish login from directory | none — login page type is known and denied in advance |
| Effort to add a new page type (e.g. careers) later | a new pattern set to build and tune per domain shape | already in the same record, one more field to read |
Filling in a named decision-maker and a current company description before a rep's first outreach, at the volume a manual lookup could never sustain.
Re-enriching a CRM against domains whose leadership changed, catching stale executive names before they end up in an email subject line.
Building a lightweight org picture — who leads a company, what it does, how it's categorized — across a large watchlist without a manual pull per name.
The database sidesteps the guessing entirely: leadership, about and contact are three of the 28 verified page types, discovered by traversing what each domain actually links to rather than matched against a template of common paths. When a company genuinely has no public leadership page, the record says so, and the agent moves to the next enrichment source instead of burning a request on a path that was never going to resolve.
The same lookup also returns whether the domain even has an about page distinct from its homepage — smaller companies often fold "about" content into the homepage itself, and treating that as a miss rather than a signal wastes a fetch checking a page type that was never going to exist as a separate URL.
Lead lists accumulate near-duplicate domains constantly: a legacy domain the company stopped using, a regional site under a slightly different name, a parked domain someone else registered after the original expired. Enrichment agents that trust every domain equally end up writing enriched data against the wrong one, or worse, merging two unrelated companies into one CRM record because their names matched.
The database's popularity rank groups, OpenPageRank and country/language fields give a dedupe pass something to reason with beyond string similarity. A domain with negligible OpenPageRank and no country match against the lead's stated headquarters is a weak candidate even if its name matches closely; a domain with a strong popularity rank, the expected country, and populated leadership and about pages is the stronger candidate even with a looser name match. None of this replaces a human review of ambiguous merges — it narrows the ambiguous cases down to the ones that actually need one.
A concrete pattern: a lead record says "Meridian Analytics," and the resolver finds three live candidates — meridiananalytics.com, meridian-analytics.io, and meridiananalytics.co. Name matching alone treats all three as roughly equal. Pulling the page-type record for each breaks the tie quickly: one has a populated leadership page naming a CEO whose name matches other fields already in the CRM, a mid-tier popularity rank, and a country match; the second returns almost entirely absent page types and negligible OpenPageRank, consistent with a recently registered or parked domain; the third resolves to an unrelated company in a different IAB vertical entirely. The dedupe decision stops being a guess and becomes a short, defensible chain of evidence a human reviewer can check in seconds if the merge is ever questioned.
A lead enrichment agent's entire job is reading public pages a company already publishes for exactly this purpose. It has no legitimate reason to reach a login form, create an account, or submit a newsletter subscription on a prospect's behalf — and every one of those actions maps to a page type this database denies by default. That boundary matters more than it sounds: a staff directory sitting behind a customer-portal login looks, to an under-constrained agent, just like another page to try.
Worth stating plainly: this is not a judgment about whether reaching a customer portal is ever legitimate for some other agent. A support agent working an authenticated session on behalf of a specific customer is a different workload with a different, deliberately granted credential. A lead enrichment agent has no such relationship with the company it is researching, which is exactly why the identity page types stay denied by default for this use case specifically rather than as a blanket rule for every agent everywhere.
A name and a title enrich a record; knowing the domain's IAB vertical, filtering category and audience personas qualifies it. Each domain in the database carries one of 700+ IAB content categories and audience personas describing who the site serves, alongside the page-type map. A sales-intelligence-adjacent enrichment pass can use those fields to route a lead to the right segment automatically — a domain classified in a Healthcare vertical routes differently than one classified in Retail, without a separate industry-lookup step.
Careers and press page types are worth pulling alongside contact, about and leadership, even though they were not the original target: a careers page with open sales or marketing roles is a live buying-signal for some enrichment programs, and a recent press release is often the fastest way to confirm a leadership name is still current rather than pulled from a stale cache.
Consider a mid-size enrichment run: a list of 500 companies pulled from a trade-show scan, most of them mid-market B2B firms with no dedicated enrichment API coverage. A guess-based agent working that list typically resolves contact pages reliably (they're the most standardized page type) but stalls on leadership for a large share of records, because executive pages are the least consistently linked page type on the open web. A verified-lookup agent runs the same 500 domains through one API call each, gets back whatever combination of contact, about and leadership actually exists per company, and hands the operator a queue where every remaining gap is a genuine "this company doesn't publish that," not an artifact of the agent's guessing pattern.
That distinction changes what the operator does next. A genuine gap is a signal to route the lead to a different enrichment source, a manual LinkedIn check, or simply to accept a thinner record. An artifact of bad guessing is just wasted agent time and a false "not found" that a slightly better crawl might have resolved — and there is no way to tell the two apart after the fact unless the underlying source data distinguishes "absent" from "not tried."
Contact, about and leadership URLs resolved directly, with dedupe metadata included. Start with the free sample, then pick a plan.
