Why a network lists a site that isn’t running its ads

Every ad network publishes a sellers.json listing the publishers it represents. Cross-check those lists against what the publishers themselves declare and a large fraction does not match — the network names the site, the site names nothing.

Across the 38,758 relationships we index, 7,101 are like that: 18% listed by one side only. This is normal. Understanding why is the difference between reading a network’s roster usefully and reading it wrong in either direction.

1. Reselling — the relationship never appears under that name

Managed networks sell inventory through upstream exchanges. When a network adds its demand stack to a publisher’s ads.txt, what appears is exchange domains under seats belonging to the network — not the network’s own domain.

So a publisher can be a fully live, entirely happy customer of a network whose name appears nowhere in their file. This surprises publishers as much as it surprises researchers: people open their own ads.txt expecting to see their network and do not find it. Nothing is wrong. The mechanics are set out in ads.txt and sellers.json explained.

2. Shared seats — the ids do not line up

Sometimes both parties name each other and the account ids still do not match, because the publisher is placed under a shared or house seat rather than issued its own. We classify these separately, and across the index 255 relationships resolve this way.

They are not evenly distributed. Ezoic alone accounts for 49 of them — a structural fact about how that network operates rather than anything to do with the publishers. It is why a naive ads.txt check reports a failure for that network when the relationship is real, and it is covered in how to get into AdPushup.

3. Unreadable publisher files

A meaningful number of sites serve no ads.txt at all, serve it behind a redirect, return HTML instead of plain text, or block the crawlers that fetch it. From outside, all of those look identical to a site that has never heard of the network.

This is absence of evidence rather than evidence of absence, and it is the cause we can do least about. It is also, incidentally, a real cost to those publishers: buyers enforce these files, so a site whose ads.txt cannot be read is losing bids as well as confounding researchers.

4. Stale entries — the one that actually misleads

The publisher left. The network never removed them. Their entry sits in the seller file indefinitely, indistinguishable from a live relationship to anyone reading only that file.

This is the cause that matters, for two reasons. It is common — pruning is nobody’s priority and there is a mild incentive not to do it, since a longer roster looks better. And it is the one that turns a network’s published list into a misleading document rather than an incomplete one.

It is also the reason any index built from sellers.json alone quietly becomes fiction. A record that is not re-read stops describing the present, and nothing announces the moment it stops.

How we tell them apart

Imperfectly, and we say so. Our classification does what the public record supports:

The last row is the important one

We only apply it where the absence is genuinely informative: networks whose live publishers essentially always leave a detectable trace, so that its absence means something. On a network that routinely sells through intermediaries, no trace tells you nothing and we do not pretend otherwise.

That is why the counts are concentrated on a few networks rather than spread evenly: Mediavine carries 564 of them. It is not that this network is worse at pruning than the others — it is that on this network we can actually tell.

What to do with a one-sided listing

If you are evaluating a network, treat its published roster as a set of leads rather than a set of facts, and verify the specific names it cites to you. The twenty-minute method is in how to verify an ad network’s publisher claims, along with the confirmation rate for every network we track.

If you are a publisher and you have found yourself listed by a network you do not work with, it is almost certainly a stale entry from a past relationship, and they will generally remove it if you ask. If you never had a relationship at all, that is worth pursuing more firmly — your inventory is being offered by someone you did not authorise, which is precisely what these files exist to prevent.

Every figure on this page is read from our own index when the page is built, and refreshes on a weekly cycle — so the numbers move as the data does. Method and evidence rules: coverage & method.