How many company websites publish a contact address?

Anyone selling a lead list quotes a match rate. Almost nobody publishes the denominator, so here it is: of 400 domains drawn from a public ranking, 16.2% yielded an email address. A third published no contact of any kind despite the site being up, and 12% no longer resolve at all.

If you are planning outbound against a domain list, that is the number to plan against — not the one on the pricing page.

What we measured

400 domains, sampled 3 September 2026 from the Tranco top-1M list, 100 from each of four rank bands: 1k–10k, 10k–100k, 100k–500k and 500k–1M. The sample is drawn with a fixed seed so it reproduces exactly.

Each domain got the same treatment: fetch the homepage, then the contact, about, imprint and legal pages, and record every email, phone number and social profile published on them. Placeholder addresses were filtered and addresses on other domains were kept separate. No proxy, one pass, no retries.

The result

Two thirds of the sample (267 of 400) was reachable at all. Of those, only 51.3% published any contact. The rest are running a website with no published route to reach them, which is a deliberate choice rather than an oversight — the contact form is the route they chose to offer.

A contact is usually not an email

The most useful correction here is that “has contact details” and “has an email address” are very different populations.

Social profiles are the most reliably published thing on a company website, because the footer links appear on every page. Email is the least. Fewer than half of the domains that publish something publish an address, which is how 34.2% with contacts becomes 16.2% with email.

Among the 65 domains with an email, the split is close to even: 24 published only role addresses, 27 only personal ones, and 14 both. A list that merges those two columns has destroyed the distinction that decides how you may contact each one — see role emails vs personal.

62 of the 137 also carried an address on a different domain, typically the agency that built the site. Merged into the company’s contacts, those are wrong rows that look right.

By rank band

The most-visited band is the worst to work with: 8% yielded an email against 17–20% everywhere else, and it refuses automated clients at twice the rate. That direction is intuitive — the largest sites have the most to gain from a support queue and the most bot traffic to defend against — but the size of the gap is worth knowing before you assume enterprise targets are the easy ones.

With 100 domains per band the differences between the three lower bands are inside the noise. The gap between the top band and the rest is not.

Why the failure codes are split

A single “unreachable” would have covered 133 of these rows, and it would have been useless. These five outcomes want opposite responses:

• 12% do not resolve. Delete them. They will never work.
• 13% are up and refuse crawlers. The company exists and is contactable by hand; the automated route is closed.
• 3.2% timed out and 1.5% returned 5xx. Worth exactly one retry.
• 1.2% failed on TLS, usually an expired certificate. A real signal about the company, not about your tooling.

Collapsing those into one number tells you your list is 33% bad without telling you which third to delete, which to retry and which to work by hand. We shipped that conflation ourselves until this measurement forced the split.

Limitations

Tranco is a popularity ranking, not a business directory. It is reproducible and public, which is why it is used here, but it over-represents media, infrastructure and platform domains and under-represents the small regional businesses that make up most outbound lists. A sample of local service companies would very likely publish contacts at a higher rate. Do not read 16.2% as the rate for your list.

The sample includes domains that were never company websites. Eleven of the 400 are DNS, CDN or hosting infrastructure. They are counted as measured rather than removed, because deciding what counts as a company is exactly the judgement that makes a benchmark unfalsifiable.

One pass, no retries, no proxy. A patient crawler with retries would recover some of the 3.2% that timed out. It would not change the two large categories.

“Refuses automated clients” is measured with one client. A different fetch strategy shifts that 13% somewhat. It does not move the 32.5% that are reachable and publish nothing, which is the finding that matters.

Published is not the same as contactable, and neither is the same as lawful to contact. A role address is a company contact point; a personal one is personal data under GDPR whether or not it sits on a public page. This page counts what exists; it is not advice about what you may do with it.

One measurement, one date. This has been run once, on 3 September 2026. Treat it as a first reading rather than a trend.

FAQ

Why is the match rate so much lower than the vendors quote?

Because vendors usually quote the rate among domains where they found something, and often count a guessed info@ as a find. This counts every domain submitted, including the dead ones and the ones that publish only a form. Both numbers can be honest; they answer different questions.

Is a 16% email rate bad?

It is the rate for this sample, and it is a reason to size a list by its expected yield rather than its row count. If you need 500 reachable companies, a list of 500 domains will not get you there.

What about the 32.5% that publish nothing?

They are reachable and have chosen not to publish an address. The contact form is usually there, and it converts better than an address they deliberately withheld. Treat that group as a different channel rather than a failure.

Can I reproduce this?

Yes, and that is the point of using Tranco with a fixed seed. Take the top-1M list, sample 100 domains from each of the four bands with seed 20260903, and run them. The absolute numbers will drift as sites change; the shape should hold.

Will you re-run it?

Yes. A number with one date on it is a starting point, and a stale benchmark on this site is a bug.