How to find out which ad network a website uses

Every site running display advertising leaves a public trail. Not in an analytics tool or a paid database — in two plain text files that the advertising industry obliges both sides to publish. Once you know they exist, identifying a site’s ad network stops being guesswork.

This is exactly how this site is built: 38,758 network–site relationships across 39,459 sites, assembled entirely from records the networks and the publishers put on the open web themselves.

Method 1: read the site’s ads.txt

Add /ads.txt to any domain — example.com/ads.txt — and if the site sells advertising programmatically, you will usually get a text file. It is the publisher’s own declaration of who is allowed to sell its inventory. Each line looks roughly like this:

google.com, pub-1234567890123456, RESELLER, f08c47fec0942fa0

The first field is the advertising system, the second is the account id the publisher has with it, and the third says whether that partner owns the inventory (DIRECT) or resells it (RESELLER). A managed ad network almost always adds a large block of lines at once, so the network running a site is usually visible as a cluster of entries appearing together.

The catch is that the network’s own domain often does not appear. Networks sell through upstream exchanges, so a site monetised by a managed partner may show hundreds of lines naming exchanges and not one line naming the network you are looking for. Reading ads.txt alone tells you which exchanges touch the inventory, not who manages it.

Method 2: check the network’s sellers.json

The same transparency rules run in the other direction. Ad systems publish a sellers.json at their root — network.com/sellers.json — listing the sellers they represent, each with the account id that matches the ads.txt side. This is the network’s own statement of its publisher roster.

Searching a network’s sellers.json for a domain answers the question directly: if the network lists the site, the network is claiming the relationship. This is the file that makes a comprehensive index possible at all — you can enumerate a network’s entire publisher list from one URL.

Method 3: look at what the page actually loads

The files describe the paperwork; the page source shows what is running right now. View source on the homepage and search for script tags from ad domains. Managed networks load a recognisable wrapper — a script from their own host, or in some cases the whole site served through their proxy, which is how Ezoic sites behave.

Script evidence is the strongest signal of the three because it is present-tense. It is also the narrowest: some networks load through generic exchange endpoints that identify nobody, and a site running ads only below the fold or only for logged-out visitors can look empty on a casual look.

Putting the three together

No single source is sufficient, which is the whole reason this site cross-checks them. The standard we hold every relationship to is that both parties independently say the same thing:

Of the 38,758 relationships indexed here, 30,287 are confirmed by both sides. The gap between that figure and the total is not error — it is the honest size of the industry’s one-sided paperwork, and it is the reason a single-source answer is so often wrong.

The shortcut

If you would rather not read files: every site we have indexed has a page here showing each detected network, the evidence behind the match, and when it was first and last seen. Search for a domain from the home page, or browse every network we track to see its full publisher list.

Doing this at scale

If you want to check many sites rather than one, the practical order is:

• Start from sellers.json, not from the sites — one fetch per network gives you the network’s entire claimed roster.
• Fetch each site’s ads.txt and look for the account ids the network published for that specific domain, matched tolerantly for formatting but never loosely.
• Fall back to homepage script detection for sites with no readable ads.txt, and expire a detection when two consecutive re-crawls stop seeing it.
• Re-read everything on a schedule. Both files change without notice, and a stale index is indistinguishable from a wrong one.

The full set of rules we apply, including how managed networks are matched through exchange seats, is written up on the coverage & method page.

A worked example

Take any recipe blog. Open /ads.txt and you will typically find several hundred lines: Google, then a long tail of exchanges — Rubicon, Index Exchange, PubMatic, Sovrn and so on. None of those is the answer. They are the demand partners, and almost every monetised site in the world names most of them.

What identifies the manager is the pattern. A managed network adds its whole demand stack in one block, with its own seller ids, and those ids will appear in that network’s sellers.json against this exact domain. So the test is not “is this network named in the file” but “does this network’s own file name this site, under an account id the site’s file also carries”. Two documents, one agreement.

Where that fails — no ads.txt, or a network that never appears under its own name — the homepage settles it. Load the page, look at the network requests, and see whose host the ad code comes from. If the site is served through a network’s proxy, as Ezoic sites are, that is visible too.

Why the quick answers are usually wrong

Most tools that claim to identify a site’s ad network do one of two things. They read ads.txt and report every advertising system named in it, which produces a list of thirty exchanges and no answer. Or they read one network’s sellers.json and report a match, which cannot distinguish a live partnership from a listing left behind three years ago.

The cross-check is the whole difficulty, and it is why we re-read both sides on a schedule rather than building an index once. A record that is not re-read is a record that quietly becomes fiction.

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.