ads.txt and sellers.json: a practical checklist for publishers

Most ads.txt files grow by copy and paste. A new partner sends a block of lines, someone adds them, and nobody removes anything when a partnership ends. The result usually still works, but it is rarely accurate. This guide explains what each part of the file means, how buyers check it against sellers.json, and how to keep it correct without breaking demand you still rely on.

What ads.txt is and what it protects against

ads.txt (Authorized Digital Sellers) is a standard published by the IAB Tech Lab. It is a plain text file at the root of your domain that lists which advertising systems, and which accounts within them, are allowed to sell your inventory.

It exists to make domain spoofing harder. Without it, anyone could send bid requests claiming to be your site and collect money meant for you. With it, a buyer can check whether the account selling an impression is one you have publicly authorized. Many buyers will not bid on inventory from an unauthorized seller at all.

ads.txt does not prove an impression is valid, and it does not control who can buy. It only states who may sell.

How to read a line

Each record has three required fields and one optional field, separated by commas:

1. The domain of the advertising system (the SSP or exchange), not your own domain.
2. Your seller or publisher account ID on that system.
3. The relationship: DIRECT or RESELLER.
4. Optionally, the certification authority ID for that advertising system (in practice, its TAG ID).

An illustrative example, using placeholder values only:

# Contracted directly with Example SSP
example-ssp.com, pub-0000000000000000, DIRECT, 0a0a0a0a0a0a0a0a

# Example SSP inventory sold through Example Partner's account
example-ssp.com, 00000, RESELLER

Lines starting with # are comments and are ignored by crawlers. Use them to note which partner a block belongs to and when it was added.

DIRECT vs RESELLER, and why the label matters

DIRECT means you, the publisher, directly control the account named in the line. You signed up with that system, and payments come to you from it.

RESELLER means you have authorized another company to control that account and sell your inventory through it. Ad networks, header bidding partners and managed services usually give you RESELLER lines.

Buyers use the label as a signal of how many intermediaries sit between them and you. If a reseller's account is marked DIRECT, it misrepresents the path, and when buyers cross-check it against sellers.json the line will not match what the advertising system reports. Some buyers treat that mismatch as a reason to reduce or stop bidding on that path. Copy the label exactly as the partner gives it, and ask them if it looks wrong.

Common errors

• Typos. A misspelled advertising system domain or a single wrong digit in an account ID makes the line useless. It will not match anything.
• Stale lines. Lines from partners you no longer work with still authorize those accounts to sell your inventory.
• Duplicates. The same line pasted twice, or the same account listed as both DIRECT and RESELLER. Duplicates are usually harmless but make the file harder to audit.
• Wrong relationship. See the section above.
• Wrong location. The file must be at the root, for example https://example.com/ads.txt, not in a subfolder.
• Redirects. The specification allows limited redirects, but chains, redirects to another domain, or redirects to a login or error page are common reasons crawlers fail. Serving the file directly with a 200 status is the safest setup.
• Wrong content type. The file should be served as text/plain. Some CMS plugins and CDNs serve it as HTML or wrap it in a page template.
• Subdomains. Crawlers read the file on the root domain. If ads run on a subdomain that needs its own file, declare it in the root file with SUBDOMAIN=sub.example.com and publish an ads.txt on that subdomain.

What sellers.json is

ads.txt is published by you. sellers.json is published by each advertising system, at the root of its own domain, and lists the sellers it works with.

Each entry includes a seller_id and a seller_type:

• PUBLISHER: the seller owns the inventory and is paid directly.
• INTERMEDIARY: the seller resells inventory it does not own.
• BOTH: the account is used in both ways.

Entries usually also include a name and business domain, though sellers can be marked confidential, in which case those details are omitted.

How buyers cross-check the two

A buyer takes the advertising system domain and account ID from your ads.txt line, finds that system's sellers.json, and looks up the ID. They then compare what they find with what your file says.

If the ID is missing from sellers.json, or the types disagree, ask the partner. Sometimes their sellers.json is out of date; sometimes your line is.

The SupplyChain object (schain), briefly

The SupplyChain object is part of the bid request. It lists each company that handled the request, as a sequence of nodes, each naming an advertising system and a seller ID. A buyer can check every node against that system's sellers.json and the first node against your ads.txt. The three together let a buyer trace a request from your site to the exchange. You do not edit schain yourself, but errors in your ads.txt or a partner's sellers.json show up as broken chains.

Mobile and CTV apps use a parallel file, app-ads.txt, with the same line format.

OWNERDOMAIN and MANAGERDOMAIN

Version 1.1 of the ads.txt specification added two optional variables.

OWNERDOMAIN states the business domain of the company that owns the site. It helps buyers match your site to the business named in sellers.json entries for your DIRECT accounts, which matters when the site domain and the company domain differ.

MANAGERDOMAIN states the business domain of a primary or exclusive partner that manages monetization of the site on your behalf. Only add it if such an arrangement exists, and agree on it with that partner first.

OWNERDOMAIN=example-media.com
MANAGERDOMAIN=example-partner.com

A monthly checklist

1. Open your ads.txt in a browser at the root domain. Confirm it loads directly, returns a 200 status, and displays as plain text.
2. Check any declared subdomains the same way.
3. List every partner currently paying you. Every line should belong to one of them. Flag lines that do not.
4. For each DIRECT line, look up the ID in that system's sellers.json. Confirm it exists and shows your business.
5. Spot-check RESELLER lines the same way, starting with your largest partners.
6. Look for duplicates, typos and lines with inconsistent labels.
7. Compare with your partners' current required lines. Some publish them in their dashboards; others send them on request.
8. Check warnings in your ad server or SSP dashboards about unauthorized or missing ads.txt lines.
9. Record what you checked and what you changed in your change log.

How to clean up safely

Removing a line stops that account from being authorized for your inventory, so a careless cleanup can cut off demand you still use. Work slowly.

• Save a dated copy of the current file before any change.
• For each line you plan to remove, confirm with the partner it belongs to that it is no longer needed. Ask in writing.
• Treat lines you cannot attribute with caution. Ask your active partners whether any of them relies on it before removing it.
• Make changes in small batches, then watch revenue by partner for the following days.
• Keep a change log: date, line, change, reason and who confirmed it. It turns the next review into a quick diff rather than a reconstruction.

When to get a second pair of eyes

A review is worth considering when your file has grown past what you can attribute line by line, when partners report mismatches you cannot explain, or when you are changing your monetization setup and want the file to match it. An independent reviewer can trace each line to a partner and a sellers.json entry without a commercial stake in which lines stay. If that would help, you can discuss your website with PubOS.