Ads.txt and Sellers.json Explained: Setup for Publishers
By Theaimart ADX ·
4 minute read · AI-assisted technical review
Set up ads.txt, understand DIRECT and RESELLER, and verify seller IDs against sellers.json. Includes safe examples, deployment checks and troubleshooting.
What ads.txt and sellers.json each do
To set up ads.txt, publish the authorized advertising-system and seller-account records for your website at its root ads.txt location, then verify that buyers can retrieve them. Sellers.json is published by advertising systems to identify the sellers associated with their account IDs. A normal website publisher does not copy an exchange's sellers.json onto its own domain as a substitute.
This guide follows IAB Tech Lab ads.txt resources and sellers.json resources, reviewed on 12 November 2026. The specification links now point into Tech Lab's supply-chain-validation repository. Use the current specification and your actual account instructions when implementing.
Understand the record before copying a line
An ads.txt seller record contains the advertising-system domain, seller account ID, relationship and an optional certification-authority ID. DIRECT means the publisher directly controls the account identified in that system. RESELLER means another entity controls the account and has authorization to resell the inventory.
DIRECT does not simply mean the brand advertiser buys directly from the website. Likewise, the seller ID is not necessarily the publisher's public business name. Match the exact account identifier supplied by the authorized partner.
| Field | Purpose | Common mistake |
|---|---|---|
| Advertising-system domain | Identifies the relevant system | Using the publisher's domain or a tag CDN |
| Seller account ID | Identifies the account in that system | Copying another site's ID |
| DIRECT or RESELLER | Describes control of the account | Marking every partner DIRECT |
| Certification ID when supplied | Identifies a certified system entry | Inventing an ID or using unrelated account data |
An illustrative ads.txt file
The records below use reserved example domains and invented IDs. They demonstrate the structure only and must not be pasted into a live authorization file. Obtain real entries from the partners you actually authorize.
Publish the production file at https://your-domain.example/ads.txt using actual domain and account values. Serve plain UTF-8 text with a successful response and no login, JavaScript challenge or HTML error body. Confirm behavior through the public edge/CDN, not only the source repository.
For subdomains and delegated arrangements, follow the current specification's discovery and redirect rules. Do not assume that placing a file on an unrelated hostname authorizes every site in an organization.
text ·
# Illustrative only: replace with verified partner records
exchange.example, publisher-account-123, DIRECT
reseller.example, reseller-account-456, RESELLERVerify sellers.json at the advertising system
Find the seller record at the advertising system's published sellers.json location and compare its seller_id with the ads.txt account entry. Inspect seller type and disclosed identity as applicable. A confidential record has different visibility from a fully disclosed one; do not invent missing identity data.
The system, seller and supply-chain records should describe the same commercial path. Ads.txt identifies authorized accounts, sellers.json describes sellers and the SupplyChain object describes participants in the transaction. They are related transparency mechanisms, not three copies of the same file.
The IAB implementation guide illustrates these relationships, including ownership and management concepts. Review current specification requirements before adopting optional or newer fields.
Validate the deployed response
Fetch the file anonymously and inspect the status, final URL, content type and body. Check for a cached older version, a theme-generated HTML page or a security challenge. Do not consider a browser download alone proof that every buyer has refreshed its cache.
Confirm exact IDs and duplicate lines, then ask partners to validate the account mapping. Keep a dated copy of approved changes. If a partner's provided line conflicts with the contract or known account owner, resolve that discrepancy before publishing it.
The absence of an immediate dashboard change does not automatically mean the file failed. Crawlers can refresh on different schedules. Use documented partner diagnostics and allow the relevant processing interval.
Maintain authorization during provider changes
Assign an owner for updates. Add only verified active relationships, review partner change requests and remove retired authorization after the agreed transition. A copied block containing hundreds of unrelated sellers increases the scope of authorization without proving useful demand.
Preserve a rollback copy and document why entries were added or removed. During a migration, coordinate file changes with the actual serving path so valid demand is not unintentionally removed or obsolete partners left authorized indefinitely.
For Theaimart ADX, obtain verified account instructions through publisher onboarding and review availability. This article does not invent an ADX exchange domain, seller ID or certified seller relationship.
Troubleshoot the right layer
A correct file with the wrong account ID is still wrong. A valid ID served behind a 403 can remain inaccessible. A reachable ads.txt cannot repair an unsupported creative, consent configuration or inactive demand account.
For an auction implementation, use the Prebid guide. For choosing the auction model, use header bidding versus waterfall. Authorization records support those systems but do not implement them.
Frequently asked questions
Does ads.txt stop all ad fraud? No; it addresses authorization transparency, not every invalid-traffic or creative problem. Does it guarantee higher RPM? No. Do mobile apps use the same file? App inventory has app-ads.txt and its own discovery requirements; do not substitute website instructions blindly. Should I list every possible partner? Authorize actual reviewed relationships.