A Domain Is Not a Contact: Turning a Website List into Reachable Leads

The problem nobody states out loud

Scraping a list of company websites is the easy 20%. You ran a Google Maps or directory scrape, you have 2,000 domains, and now you are stuck. A domain is a building, not a person. To act on it you need an address that (a) exists, (b) belongs to someone relevant, and (c) you are allowed to write to. Visiting 2,000 sites by hand to hunt for a contact link is exactly the kind of work that never gets done. This guide is about closing that gap honestly — including the parts the slick "find anyone's email" tools gloss over.

Where emails actually live on a site

The single biggest reason naive scrapers come back empty is that they read only the page you gave them. Business emails are almost never on the homepage. They cluster on a handful of deep pages, and a finder is only as good as how it follows internal links to reach them:

• /contact — the obvious one, but often a form with no address, so it cannot be the only page you check.
• /about and /team (or /people, /staff, /leadership) — where named, role-specific addresses appear: the founder, the head of partnerships.
• /imprint, /impressum or /legal — in Germany, Austria and much of the EU a legal imprint with a real email is mandatory, which makes these pages a reliable goldmine for European targets.
• The footer — a global address (hello@, info@) is frequently tucked into the footer of every page.
• Obfuscated mailto and JS-rendered text — many sites write name [at] domain [dot] com or inject the address via JavaScript to dodge bots, so a finder that only reads raw HTML will miss them.

The takeaway: depth and link-following beat breadth. A crawler that visits the contact, about, team and imprint pages of one domain finds far more than one that scrapes a thousand homepages.

Role addresses vs personal addresses

Not all emails are the same kind of lead, and treating them identically is why a lot of campaigns underperform.

A good enrichment keeps the type alongside the address so you can route them differently: personal addresses into a careful, GDPR-aware sequence; role addresses into a lighter first-touch.

Verification: what it can and cannot tell you

"Verified email" gets sold as a guarantee. It is not one. Verification typically means: the domain has valid MX records (it can receive mail), and an SMTP probe suggested the specific mailbox exists without a hard reject. That is genuinely useful — it strips out the obvious bounces that otherwise tank your sender score. But be honest about its ceiling:

• It does not prove the person still works there. People change jobs; the mailbox lingers or gets reassigned.
• It does not predict the spam filter. A real, deliverable address can still land in a junk folder no one reads.
• Catch-all domains accept everything, so SMTP says "valid" for any address you try — these come back as "accept-all" / "risky", not "valid", and you should treat them as unverified.
• Aggressive SMTP probing can itself get your verifier IP blocked, which is why this is better delegated than home-rolled.

Read verification as "unlikely to bounce", not "will be read and answered". That framing keeps your expectations and your bounce rate honest.

The worked pipeline: domains in, leads out

Here is the actual flow that turns a raw domain column into a list you can hand to a sales sequence.

1. Feed the domains. Pass your list of websites to a contact-finder Actor. One run, no per-site clicking.
2. Crawl deep. The Actor walks contact/about/team/imprint/footer pages and de-obfuscates mailto tricks, returning every address plus where it found it.
3. Classify. Tag each address as role vs personal, and keep the source page — an email from /team is a stronger signal than one from a blog comment.
4. Verify. Run MX + SMTP checks, drop hard-invalids, flag catch-all/risky separately rather than trusting them.
5. Dedupe and route. One contact per company (or per named person), de-duplicated, ready to drop into your CRM or outreach tool.

The crawl-and-extract step is the one you should never build yourself. As an API call it looks like this:

curl -X POST "https://api.apify.com/v2/acts/renzomacar~website-contact-finder/run-sync-get-dataset-items?token=<APIFY_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{
    "websites": ["acme.io", "example-clinic.com", "studio-nord.de"],
    "maxDepth": 2,
    "includePhones": true,
    "includeSocials": true
  }'

maxDepth: 2 is the sweet spot — it reaches the contact and team pages one or two clicks in without crawling the entire blog. Push depth higher only for sprawling sites where the imprint is buried.

Troubleshooting an empty or thin result

When a finder comes back with fewer contacts than you expected, it is almost always one of these:

• Depth too shallow. The address was on /impressum, four clicks deep, and your crawl stopped at depth 1. Raise maxDepth for that batch.
• Contact is a form, not an address. Many modern sites hide the email behind a form. The finder can return the form URL, but there is no address to extract — that company is reachable only via the form or a named person from /team.
• JS-rendered or image emails. Some sites render addresses as images or inject them late via JavaScript. A finder that executes the page catches these; a raw-HTML one does not.
• Catch-all everywhere. You got addresses but verification marked them all "accept-all". That domain accepts any local part; you cannot confirm a specific mailbox, so treat with caution.
• Genuinely no public email. Some businesses publish only a phone or a social profile. That is why pulling includePhones and includeSocials as fallback contact channels is worth it.

Disclosure: links to Apify on this page are affiliate links, marked rel="sponsored". If you create a paid account through them we may earn a commission at no extra cost to you. We recommend Apify because we build and ship Actors on it ourselves, including the Website Contact Finder linked above. Nothing here is legal advice; check the rules that apply to your recipients before sending.