What Is ads.txt? A Publisher Setup Guide

What is ads.txt? In short, it is a public text file that a publisher posts on its own domain to list which companies are authorized to sell the site's ad inventory. The name stands for Authorized Digital Sellers. IAB Tech Lab defined the file, and systems that buy ads look at it to filter out unauthorized sellers.

This guide covers the file's structure, setup, common errors and an audit habit. We wrote the technical details according to version 1.1 of the IAB Tech Lab specification. Because the specification can change over time, check the current version before you implement anything.

What Is ads.txt and Which Problem It Solves

In programmatic selling, an ad can reach your site through several systems in a chain. It is not always clear who is really selling on your behalf. Fake sellers can make it look as if they sell your domain's inventory, and an advertiser may believe the space is yours.

The ads.txt file reduces that uncertainty. In it, the publisher declares which accounts at which systems belong to it or to parties it has authorized. When a sell request arrives, the buying system checks this list and may not trust a seller that is missing from it.

Problems the file addresses:

• The risk of unauthorized parties selling inventory under your site's name.
• Ad buyers being unable to verify the right seller.
• The publisher's need to keep its own sales channels visible and auditable.

The file is not an SEO tool; its purpose is transparency in the ad supply chain. If you wonder how programmatic selling differs from direct selling, see our article on direct ad buying versus programmatic.

File Structure and Fields

ads.txt is a plain text file, and each line is one record. Records are made of comma-separated fields. According to the specification, the fields are written in this order:

1. Domain of the advertising system: The canonical domain of the ad system or exchange the seller uses.
2. Publisher account ID: The identifier of your account, or the account of the party you authorized, at that system.
3. Relationship type: One of DIRECT or RESELLER.
4. Certification authority ID: An optional fourth field. The specification notes that this field may be deprecated in a future version.

With placeholders, a line looks like this: ad-system.example, ACCOUNT-ID, DIRECT, CERTIFICATION-ID. The domain and the IDs here are made up; in your own file you replace them with the details your ad partner gives you.

The file may also contain comments. Lines starting with # are ignored, and anything after a # in the middle of a line is treated as a comment too. Comments are useful for noting why a record was added.

Besides records, there are variable lines in the form VARIABLE=VALUE. The specification defines variables such as CONTACT, SUBDOMAIN, INVENTORYPARTNERDOMAIN, OWNERDOMAIN and MANAGERDOMAIN. Most of them are optional or recommended depending on the case.

Direct and Reseller Relationships

The relationship field carries the most important information in the file: who controls this account?

• DIRECT: The publisher directly controls the account in the second field. There is usually a direct business contract with the ad system.
• RESELLER: The publisher has authorized another party to control the account. That party may resell the inventory.

According to the specification this field is read case-insensitively, so direct and DIRECT are treated the same. The specification also says other values may be added in the future.

Imagine a small news site that manages its ad revenue through an intermediary company, and the intermediary uses its own account independently of the site. In this fictional case the intermediary's account is written as RESELLER, and the account at an ad system the site contracts with directly is written as DIRECT. Wrong labeling makes buyers read the chain incorrectly.

The sellers.json file also helps in understanding the chain. The specification notes that certification IDs are superseded by the identifiers in sellers.json. In other words, ads.txt is the publisher-side list, while sellers.json is the ad system's own seller list, and reading them together makes the chain clearer.

Setup: Where and How to Upload It

The file goes at the /ads.txt path of your site's root domain. The specification defines the root domain as the public suffix plus one label. For example, if your domain is example-site.example, the file is published at example-site.example/ads.txt.

Setup steps:

1. Create a file named ads.txt in a plain text editor and write the records line by line.
2. Upload it to the root of your web server so that the address is /ads.txt directly under your domain.
3. Make sure the server serves the file with a Content-Type: text/plain header. The specification says other content types may be treated as an error and the content ignored.
4. Open the address in a browser and check that the text is readable.

If both HTTP and HTTPS are reachable, the specification prefers the data from HTTPS, so use HTTPS on your site. If you use redirects, be careful: 301, 302 and 307 redirects within the root domain are followed, while only a single redirect to a destination outside the root domain is allowed.

For subdomains, the root file can point to a subdomain with the SUBDOMAIN variable. If that subdomain has its own file, only the systems in that file are authorized there. If you use a different sales setup on a subdomain, consider this route; otherwise no extra file is needed.

Care When Adding and Updating Entries

Adding a record may look simple, but each line effectively authorizes someone to sell your inventory. Check before you add.

• Build the line only from the information your ad partner gives you in writing.
• Copy the account ID without changing a single character. It must match the value used in transactions.
• Make sure fields contain no spaces, tabs or commas.
• Write the relationship type correctly and note in a comment why the line was added.

When updating, consider this: if the line of a partner you no longer work with stays in the file, that partner's account continues to look authorized to sell your inventory. Remove the line when a partnership ends. Keeping a dated change log answers the later question of why a line was there.

The OWNERDOMAIN variable names the business domain that owns the site and is among the recommended fields. Write only the root domain, not a full address. If there are several OWNERDOMAIN lines, only the first is used.

Common ads.txt Errors

Most problems with the file come from small typing mistakes. The most frequent ones:

• Wrong location: The file placed in a subfolder or on the wrong domain.
• Wrong content type: The file served as an HTML page or with a header other than text/plain.
• Broken format: Missing fields, extra commas or a record split across lines. The specification says an obviously corrupted file may be ignored.
• Wrong account ID: Even a one-character mistake makes the record ineffective.
• Stale records: A line left in the file after the partnership ended.
• Redirect problems: Chained redirects, or a second redirect leaving the root domain.
• Empty file: The specification says an empty file should now be ignored because it created ambiguity. If you want to authorize no seller at all, a placeholder line is used.

A Habit of Verification and Monitoring

Setting up the file once and forgetting it leads to errors over time. A few small habits are enough:

1. Update the file whenever you add a new ad partner and record the change.
2. Once a month, open the file in a browser and confirm that the content, content type and address are correct.
3. Check your ad partners' management panels for ads.txt warnings.
4. When you migrate the site or change the domain or HTTPS settings, test that the file is still reachable.

Keeping records matters as well. If you store which line was added for which partner and on which date, cleaning up after a partnership change becomes easy. A website media kit also speeds up the information you give partners. Also, site quality and ad placement affect ad income too; for that, read our article on ad placements that do not hurt user experience.

When you track performance, tying the approach in our guide on measuring banner ad performance to a monthly file check keeps the routine simple.

Does Every Publisher Need ads.txt

The specification does not define the ads.txt file as mandatory; if the file is missing, buyers may treat it as no declarations. In practice, programmatic partners and ad buyers often look for it. So whether you need the file depends on how your site earns ad income.

• A publisher using programmatic ads: The file is very likely needed; always check your partner's own requirements.
• A publisher selling only direct banners: If sales do not run through ad systems, there may be no seller record to authorize.
• A site that shows no ads: The file is not needed.

For publishers selling ad space through Akua, we do not claim that ads.txt is mandatory; it is not a platform requirement. If you sell directly, the steps in our guide to selling ad space on your website matter more. If you also earn programmatic revenue, apply your partner's ads.txt requirements separately.

If you wonder how buying display ads differs from buying paid links, our article on buying ad space: display ads versus backlink marketing helps. Marking paid links with rel=sponsored or nofollow is a separate topic related to Google's link policies; it has nothing to do with ads.txt.

Sample Template: ads.txt Audit Table

The sample template below is an audit table you can use when reviewing your file. Mark the cells according to your own file; the values in the table are placeholders.

Sample template: ads.txt audit table

A fictional use: at the start of the month a publisher opens this table and checks six rows. On noticing that it stopped working with one partner, it removes the related record and notes the date in the table. The file then reflects the site's real partnerships.

Frequently Asked Questions

Is an ads.txt file mandatory?

The specification does not define the file as mandatory; if it is missing, buyers may assume there are no declarations. Even so, programmatic ad partners often ask for it. Check your own partner's requirements.

Where should I place the ads.txt file?

Place it at the /ads.txt path of your site's root domain, as plain text. The server must serve it with a text/plain content type. If the file is placed in a subfolder or at a different address, buying systems may not find it.

What if an unauthorized seller line is added?

A seller with a line in the file appears authorized to sell your inventory. If an unauthorized seller is added, buyers may treat inventory from that seller as offered on your behalf. So add a line only for partners you have verified, and audit the file regularly.

Do subdomains need their own file?

According to the specification the file is published on the root domain. If a subdomain is to have its own file, the root file points to it with the SUBDOMAIN variable. When a subdomain file exists, only the systems in that file are authorized there; otherwise the root file applies.

Do I need ads.txt if I only sell banners directly?

If sales do not run through ad systems, there may be no seller record to authorize. If the same site also earns programmatic revenue, the file may be needed. Check your ad partner's requirements before deciding.

How do I audit ads.txt errors?

Open the file in a browser to check the content and content type, count the fields on each line and compare them with the details from your partners. Watch for ads.txt warnings in your partners' dashboards. Remove the related line when a partnership ends.

Conclusion and Next Step

Though small, ads.txt builds trust in the ad chain: it publicly states who sells on behalf of your site. The right location, the right content type, accurate records from your partners and regular audits are enough to keep the file healthy.

After auditing your file, as a publisher or an advertiser you can browse the available ad spaces. Purchases on the platform move through cart and payment, seller approval, delivery notification and, if needed, a dispute process.