There is a file on your website called ads.txt. It lists the companies allowed to sell advertising on your pages. Buyers read it before they bid, and a buyer can check the declared advertising system, account identifier and relationship. This study does not observe individual bidding decisions.
Your ad network also publishes a list — the sites it sells for.
Both documents are public. Either one can be read by anyone. So they can be checked against each other, which lets a publisher check the relationship from both sides.
We did it for 462 publisher-to-network pairings across 457 reachable domains. One domain can name more than one network. The overall unconfirmed share is 36 / 462 = 7.8%, about one in thirteen pairings; the Mediavine-specific one-in-nine figure refers to 26 / 234 = 11.1%, not to the whole sample.
What we found
426 of 462 matched. The publisher file names a recognized network and the public roster associates a declared account identifier with the same site under the study's matching rules. This is agreement between public records, not an independent identity audit.
36 did not. Broken down:
| What was wrong | Sites |
|---|---|
No ads.txt on the site at all | 20 |
| The file exists but names no ad network | 6 |
| The file names a different network | 5 |
| The file returns a web page, not a text file | 4 |
| A declared account cannot be matched in the provider’s roster | 1 |
The last two show why a successful URL response or a recognizable network name alone is not a complete reconciliation. We did not interview the publishers or measure what they believed about their setup.
The four that return a web page
An ads.txt file has to be plain text. Four of these sites return HTML — usually the site's own "page not found" design, served with a success code instead of an error.
A success status does not make the response a usable publisher declaration. Inspect the returned body as well as the status. We did not measure whether buyers treat this state as worse than a missing file, or what revenue effect it had.
One site in our sample publishes an ads.txt that declares zero seller records. Among the sites with a readable file, the middle one declares 75.
The networks are not the same
Same test, same week, same kind of site:
| Network | Could not be confirmed |
|---|---|
| Raptive | 7 of 225 — 3.1% |
| Mediavine | 26 of 234 — 11.1% |
The remaining three pairings concern Playwire (two) and Freestar (one); these tiny groups are not network-wide estimates.
The observed unconfirmed pairing shares differ by about 3.6 times in this selected historical sample. That is not a measured probability for every current site on either network.
We did not measure why the groups differed. The records do not identify a provider onboarding policy, publisher intent or a causal effect on earnings. Those would need separate evidence.
What this is not
It is not evidence of fraud. A site that cannot be confirmed is a site a buyer cannot verify. It is not evidence that anyone is selling inventory they do not own. Those are different claims and only the first one is measured here.
It is not an independent identity check. We compared declared account IDs with the public network rosters. One declared ID was absent from the matching roster. Public agreement does not prove the legal identity behind an account or that an ad impression was sold through it.
It is not the whole web. These are small, ad-funded content sites on two networks. Publishers with no ad network are not in the frame at all.
Check your own in about a minute
- Open
yoursite.com/ads.txtin a browser. You should see plain text — lines of commas, not a designed page. If you see your website's layout, or a 404 page, that is one of the four failures above. - Check the advertising-system domain and account identifier against your provider's instructions. Brand names and seller domains can differ; Raptive uses identifiers such as
adthrive.comin the study mapping. A familiar company name alone does not establish a matching authorized account. - Check nothing else overwrote it. Some hosts and some plugins generate their own
ads.txtand quietly replace yours. The file at the URL is what counts — not the settings screen that claims to manage it.
Our free seller tool helps inspect the stored public-file reading and supported roster checks. It reports the evidence available; it does not reproduce every buyer's parser or bidding rules.
Why we bothered
The practical question is whether the two public declarations agree under stated rules. That can help a publisher find a missing file, routing error or identifier that needs a provider check. It does not require a claim that no other tool studies the subject.
The related crawler-policy research asks another public-file question. Both studies distinguish a published declaration from the private behavior or intent it cannot observe.
Check this yourself
- The data — all 462 pairings, as a CSV, free to reuse
- Archived with a DOI: 10.5281/zenodo.22280372
The domain is not published. Every field the measurement used is, so you can recompute all of the above; which site each row belongs to cannot be recovered from it.
What the two standards actually contribute
IAB Tech Lab's ads.txt reference describes a publisher's public declaration of authorized digital sellers. Its sellers.json reference describes the seller identities exposed by advertising systems. The documents are related, but they do not make identical claims.
An ads.txt record names an advertising system and an account identifier, with a relationship field. A seller roster gives information about seller accounts. The study checks agreement across supported mappings and identifiers; it does not independently prove every account's legal identity or observe a transaction using it.
Keep the standards version separate from the documentation's update date. The current ads.txt page describes version 1.1 and the owner/manager-domain additions from its earlier release history. A 2026 page update does not mean those fields were invented in 2026.
Those distinctions matter when interpreting a checker. A recognized variable should not be called invalid merely because an older parser did not know it. A supported declaration can still need another source to establish the relationship being investigated.
The frame uses two rosters; the comparison uses six
The sampling code builds the sixteen-thousand-domain frame from Mediavine and Raptive public seller rosters. It then draws five hundred domains with a recorded seed. For the sampled public responses, the reconciliation considers six supported network rosters.
These are two different parts of the method. “Six rosters compared” does not mean the initial domain frame represents six networks equally. Sites absent from both frame rosters cannot enter that draw, even if another network serves them.
A publisher-to-network pairing exists when either the site declaration or a supported roster makes the relevant claim. A domain appearing in more than one relationship can therefore contribute more than one pairing. That explains why the count of relationships exceeds the count of reachable sampled domains.
The forty-three unreachable responses are excluded from the relationship analysis rather than marked as confirmed or unconfirmed. A successful or missing-file response can be classified; a firewall refusal or failed connection does not establish what the site would publish to another client. This distinction prevents a fetch failure from becoming an authorization accusation.
Account matching is more specific than a name search
Suppose a chosen publisher declaration lists a supported system with account example-123. A public roster associating that exact account with the same site provides a supported public match under the method. A roster containing the company name somewhere else is not enough.
If the identifier appears under another domain, that is a different state from an identifier absent from the roster. If the roster names the site but the publisher file never declares that system, that is another direction of disagreement. Keep these categories separate rather than compress them into a red “fraud” result.
The chosen identifier here is explanatory, not a real account or a record from the sample. The point is the structure of the check. Use actual provider instructions for the account lines you should publish; do not paste example identifiers into production.
Domain normalization also needs a stated rule. Case and a leading www can be handled consistently, but an arbitrary similar-looking domain should not become a match. An audit should explain its supported mapping and limitations instead of assume a brand's homepage is always the seller-file host.
A missing file and a missing observation are different
The sample distinguishes a missing ads.txt response from a response the fetch could not read. A 404 provides evidence about that requested path at that time. A timeout or access denial provides evidence about the attempted request, not a complete declaration of the publisher's setup.
A page returned with a success code needs body inspection. Some site routing systems send the designed homepage or error template for an unknown path. Seeing a 200 status in a monitor can therefore miss the relevant content problem.
Check the live root URL after deployment and after cache changes. The plugin setting that claims to generate the file is not the same as the body actually returned to clients. A content deployment, redirect or hosting rule can alter one while the administration screen remains unchanged.
Do not infer a publisher's intention from an empty or unexpected response. A deliberate no-seller declaration, an outdated integration and a routing mistake can require different investigation. The public snapshot alone may not separate them.
Public agreement does not prove an impression was sold
The study does not include bidstream logs, ad requests, transactions or payment records. It cannot establish that an unconfirmed relationship was used, that a buyer refused it or that a publisher lost a particular amount.
Likewise, a confirmed relationship does not certify every aspect of advertising compliance. The content, consent setup, actual ad behavior and account standing remain separate questions. A green match should name the narrow evidence it represents.
This is useful precisely because it is bounded. A publisher can check a concrete public inconsistency and ask the provider to resolve it without claiming to have audited the entire supply chain. A buyer or researcher can decide whether the matching rules answer the question they have.
The historical network comparison is also not a current league table. Different source rosters, sample selection and observation dates can affect the counts. Repeating the study would need the source versions, seed, response classification and parser behavior recorded together.
A practical repair workflow
Start by saving the actual public response, its date, status and content type. Compare it with the provider's current required declaration. Check the exact system domain, account identifier and relationship field rather than add every possible seller line you find online.
If the file is generated by a plugin, host or network service, identify which system owns the final response. Two tools writing the same path can create surprises. Change the intended source, deploy it and inspect the root URL again rather than assume a saved dashboard setting reached the public site.
For a roster discrepancy, ask the provider about the precise identifier and domain association. Keep the question factual and avoid publishing a fraud allegation from a single mismatch. The account may need correction, clarification or a fresh public-file check.
Then retest the narrow issue. Record what changed and what remains unknown. Do not promise an earnings lift because an authorization record now matches; that outcome needs actual revenue evidence. The immediate verified improvement is that the public declarations now agree under the stated checks.
Share the finding with its denominator
Use thirty-six unconfirmed relationships out of four hundred sixty-two, not thirty-six out of the initial five hundred domains. Use the network-specific denominator for a network-specific percentage. Do not attach the one-in-nine subgroup figure to the overall sample.
Keep the missing-response count and historical date visible. A relationship rate from reachable sampled domains is not a census of every publisher. A reproducible CSV supports the classification arithmetic; it does not automatically reveal which anonymous row belongs to an individual site.
For your own check, open the seller tool and inspect the evidence shown. If the result needs account-specific clarification, ask the provider or request a manual review with non-sensitive public details. Keep private account credentials out of the request.
A cached study and a live check have different dates
The measurement code preserves source rosters and sampled responses so classification changes can be reproduced without requesting every site again. That is useful for checking the method, but rerunning the code against those same files does not create a fresh observation of the web.
A live check today can therefore disagree with a historical row without invalidating either observation. The publisher may have repaired the file, changed networks or changed its routing. The roster may also have changed. Compare dates and source versions before deciding which explanation applies.
Keep freshness explicit in the interface and any download. “Recomputed today from September responses” and “fetched today” are different claims. The first supports a reproducible historical result; the second supports a current request outcome. Neither establishes how the files behaved continuously between those dates.
That small distinction prevents a maintenance update from being mistaken for a new sample and makes later improvements easier to verify.