Most independent publishers wrote their ads.txt file once, pasted in whatever lines their ad network sent over, and never opened it again. That was fine in 2018. It is quietly expensive now, because buyers have started treating the file as a signal about the publisher rather than a box to tick.

The file turns nine this year. It has been revised four times in that window, and the most useful revision is the one almost nobody acted on.

Timeline showing ads.txt versions: 1.0 in June 2017, 1.0.1 in September 2017, 1.0.3 in March 2021, 1.1 in August 2022, and the specifications moving to GitHub by 2026
Figure by AdNativo, built from the IAB Tech Lab ads.txt release history.

What the file is actually doing

An ads.txt file is a public list of the companies allowed to sell advertising on your domain. A buyer sees inventory offered as yours, fetches yourdomain.com/ads.txt, and checks whether the seller offering it appears on your list. If it does not, the sensible buyer assumes the inventory is counterfeit and bids nothing.

That is the whole mechanism. It is not a security feature and it does not stop anyone doing anything. It is a list that buyers read, which is exactly why an out of date list costs money rather than merely looking untidy.

Diagram breaking a single ads.txt line into four labelled fields: the advertising system domain, the seller ID, the relationship, and the optional certification ID
Figure by AdNativo. Field definitions follow the IAB Tech Lab ads.txt specification, version 1.1.

Mistake one: the lines you never took out

This is the common one, and it is the one worth fixing first. You tried a network in 2022, it did not work out, you removed the tag from your site. The ads.txt line stayed.

Now your file tells every buyer in the market that a company you have no relationship with is authorised to sell you. If someone does sell counterfeit inventory under that name, your file says it was legitimate. Buyers who audit supply paths notice files full of authorisations that no longer correspond to anything, and they draw the obvious conclusion about how carefully the site is run.

Go through your file line by line. If you cannot say who a line is for and roughly what it earns you, it should not be there.

Mistake two: DIRECT where it should say RESELLER

The third field on each line is a single word and people get it wrong constantly, usually because DIRECT sounds better.

It is not a quality rating. It describes who pays you. DIRECT means you hold an account with that advertising system and the money comes to you from them. RESELLER means somebody sits in the middle, sells on your behalf, and pays you out of what they collect.

Side by side diagram. On the left, a DIRECT relationship where the site connects straight to the advertising system. On the right, a RESELLER relationship where a network sits between the site and the advertising system
Figure by AdNativo. Relationship values follow the IAB Tech Lab ads.txt specification.

Anyone working through a network, including through us, is a reseller relationship. Our own line reads adnativo.com, your-seller-id, RESELLER, and it would be a false statement if it said anything else. A file claiming a dozen direct relationships that a buyer can see are not direct is worse than a file with one honest reseller line on it.

Mistake three: no OWNERDOMAIN at all

Version 1.1 of the spec landed in August 2022 and added two fields that sit at the top of the file rather than in the seller list. Most independent publishers have never written either one.

OWNERDOMAIN names the business that owns the site. In the IAB's wording, it "should list the business domain of the owner of the site that is being monetized", and it appears once per file. If you operate several sites through one company, every file points at the same owner domain, and a buyer can see at a glance that the network of sites is one business rather than a coincidence.

Diagram of the OWNERDOMAIN and MANAGERDOMAIN declarations, with a highlighted warning that a manager must exclusively represent the majority of a publisher's supply in the stated geography
Figure by AdNativo, following IAB Tech Lab guidance on the two fields.

Adding OWNERDOMAIN takes ten seconds and there is no reason not to.

MANAGERDOMAIN is the one to be careful with

MANAGERDOMAIN looks like the field you would use to name your ad network, and that is usually a mistake. The IAB attaches a real condition to it: a manager must "exclusively represent a majority of the supply of the underlying publisher for the specified geography". You get one entry per country, or a single global entry.

So if you run three partners against the same inventory, none of them belongs in MANAGERDOMAIN. It is for a sales house that genuinely handles the majority of your supply in a market, not for whichever partner you happen to like.

Worth saying plainly, since we are an ad network writing this: do not put us in MANAGERDOMAIN. We do not ask for exclusivity, which is the whole point of working with us, and that is precisely what disqualifies us from that field. A RESELLER line in the seller list is the correct and honest way to declare us.

What is coming, and whether you need to care yet

In March 2026, Brian O'Kelley of Scope3 published a proposed successor called adagents.json, arguing that the flat list cannot express how inventory is really sold. His framing was that "the future of supply-chain transparency is not a slightly longer text file".

The proposal swaps the binary DIRECT and RESELLER distinction for three delegation types, and hangs extra scope on each authorisation: which placements it covers, which countries it applies to, and the dates between which it is valid. Some of that is aimed at connected television, where one publisher can be selling the same inventory through several paths at once. Some of it is aimed at software that buys without a person involved and therefore cannot infer anything.

Comparison showing the flat ads.txt list on the left and the proposed adagents.json structure on the right, with delegation type, placement identifiers, countries, and validity dates
Figure by AdNativo. Field names from the adagents.json specification published at agenticadvertising.org on 30 March 2026.

Should you do anything about it this month? No. It is a proposal, not a standard, and nothing is reading it on a small publisher's domain today. What it tells you is the direction of travel, which is towards buyers wanting more detail about your supply rather than less. A publisher whose ads.txt is already accurate will find that direction easy. A publisher with eleven stale lines will not.

The specifications themselves, ads.txt and app-ads.txt and sellers.json, now live on GitHub rather than as PDFs on the IAB site, which at least makes it easier to see what changed and when.

Fifteen minutes, this week

  1. Open yourdomain.com/ads.txt in a browser. If it returns a 404, that is your entire problem and nothing else on this list matters yet.
  2. Delete every line belonging to a partner you no longer work with.
  3. Check the third field on each remaining line. DIRECT only where that system pays you directly.
  4. Add OWNERDOMAIN=yourcompany.com at the top.
  5. Leave MANAGERDOMAIN alone unless one partner genuinely and exclusively represents most of your inventory in a market.
  6. Check the file again after any partner change. This is the step everyone skips.

None of this will double your revenue. It removes a reason for buyers to discount you, which is a different and less exciting kind of win, and it compounds quietly as more buyers audit supply paths.

How we handle it

We generate the exact line each publisher needs, then fetch the live file and check it is actually there, because an instruction sent by email is not evidence of anything. If the line goes missing later, which happens whenever a site gets migrated or a plugin rewrites the file, the check catches it rather than waiting for revenue to drop. We also publish our own sellers.json, so a buyer can follow the chain in both directions.

If you run an independent site and want a straight answer about what your inventory is worth, you can apply as a publisher or read how we work with publishers first. We take a look at the site before saying yes, which is part of why the answer means something.