ads.txt Explained: Format, Placement and Common Errors

An ads.txt file is a few lines long, and software you will never see reads it. Before an ad-buying system spends money on one of your pages, it can fetch this file and check that the seller in front of it is one you authorized. A site with no file, or a broken one, gives a cautious buyer nothing to check against.

Why the file exists, and what buyers do with it

The problem it addresses is domain spoofing. Someone sells ad space while claiming to be your site, advertisers pay the impostor, you earn nothing, and your name ends up attached to traffic you never served. The ads.txt standard, maintained by the IAB Tech Lab, answers with a public list: the site owner publishes, at the root of the domain, the companies authorized to sell its inventory. A buyer’s system fetches https://yourdomain/ads.txt and compares the seller, the account ID and the relationship in the request it received with your lines. A mismatch is a reason to skip the request. How strictly a given buyer enforces this is the buyer’s decision, and a skipped request does not announce itself.

For AdSense, Google describes the file and the exact Google line to publish. It also says that changes take from a few days to about a month to be picked up, depending on your traffic. The file is not among the eligibility requirements Google lists, so do not hold back your first application for it: the pages that decide approval are covered in important pages for AdSense approval. Add ads.txt as soon as your account gives you a publisher ID.

DIRECT, RESELLER and what “authorized” means

Each line authorizes one seller account at one ad system, and the third field says how you stand to that account. DIRECT means you hold the account yourself and the ad system pays you. RESELLER means the account belongs to someone else, such as an agency or an ad manager, whom you have authorized to sell your space. The ID on a RESELLER line is theirs, and they give it to you. The field-by-field format, the optional fourth field and the variables are explained on the ads.txt checker page, so here we stay with how to use the file.

The classic error is a line you do not have a contract for. Some people mark every line DIRECT because it looks stronger, others paste a long list of RESELLER lines found in a forum. Both authorize sellers you have never dealt with. Every line in your file should trace back to a partner who gave it to you.

A file for three ad networks, line by line

This is a complete file for a site that sells through AdSense, through a second network where it holds its own account, and through an agency that resells on a third. Every ID is a placeholder. The Google line keeps Google’s real certification authority ID and a zero publisher ID, and .example domains are reserved and cannot exist.

# ads.txt for example.com (every ID is a placeholder)
CONTACT=ads@example.com                                       # public address for questions about this file
google.com, pub-0000000000000000, DIRECT, f08c47fec0942fa0   # AdSense: our own account, paid by Google
network-a.example, 11111, DIRECT                              # second network: our own account there too
network-b.example, 22222, RESELLER                            # an agency sells our space through its account on network B

The comments after # are allowed on any line, so you can explain each entry and date the file. The Google line is the one to get exactly right. The publisher ID is pub- followed by 16 digits, without the ca- prefix you see in the ad code, and the last field is Google’s certification authority ID, f08c47fec0942fa0. The order of lines does not matter. Duplicates are untidy, and our checker warns about them.

Take every line from the partner that owns it, never from a copied list. And remember that the file is public: anyone can read the list of your partners, so the CONTACT address should be a role address rather than your personal mailbox.

Placement, subdomains and redirects

The file lives at the root of your domain, at https://yourdomain/ads.txt. It must answer 200 with plain text, in UTF-8 without a byte order mark, and it must not be an HTML page. On a static site, put it in the folder that is served at the root. If a single-page application or a catch-all rule answers every unknown path with index.html, add an exact match so the request reaches the real file or fails honestly:

location = /ads.txt {
    default_type text/plain;
    try_files $uri =404;
}

Systems look for the file on the root domain. A subdomain has its own file only if the root file declares it with a SUBDOMAIN line, so by default one file covers the whole site. Redirects are the other trap. Serve the file directly from your own domain when you can: some systems accept only redirects within the same root domain, and our checker follows up to 6 redirects and shows you the chain it met. The mobile equivalent, app-ads.txt, is a separate file for apps, published on the developer website listed in the app store.

Changing the file as your setup changes

Treat ads.txt as part of the site’s configuration, not as a one-off upload. Keep a copy in the same project that builds the site, because a redeploy that replaces the web root will delete a file that was only ever uploaded by hand. Then follow the same routine each time something changes.

When you add a network, ask the partner for its exact lines, add them with a dated comment, check the result with the checker, and only then switch its ads on. Google says its own line can take days to a month to be picked up, and other buyers set their own pace without telling you, so lines belong in the file before you need them. When you stop working with a partner, remove its lines once its last ads have run: a stale line keeps authorizing a seller you no longer deal with. When you move host or change content management system, request the file again within minutes of the switch. When you add a subdomain or a second domain, remember that the file belongs to a domain: a new domain needs its own file, and a subdomain needs the SUBDOMAIN line described above.

When AdSense says it cannot find ads.txt

Work down this list in order and stop at the first check that fails. Each one rules out a cause the next one cannot see.

1. Fetch the file as a stranger. Run curl -sI https://example.com/ads.txt. You want a 200 status and a content-type of text/plain. A 404 means the file is not at the root. A 200 with text/html means a catch-all route is answering instead of your file.
2. Check the host. The file must be reachable on the root domain of the site you added to AdSense. If your site lives on a subdomain, the root needs a SUBDOMAIN line or the file itself.
3. Check the path to the file. Run the ads.txt checker for the redirect chain. Then look at your server log for the codes sent to Google’s crawlers: a firewall, CDN rule or security plugin that blocks unfamiliar crawlers can answer 403 to them while the file loads fine in your browser.
4. Check robots.txt. A Disallow that matches /ads.txt, directly or through a pattern, stops a crawler that obeys the file. The robots.txt tester shows the deciding rule, and our guide to robots.txt mistakes lists the usual causes.
5. Check the content. The checker flags a byte order mark on the first line, HTML where text should be, a publisher ID that is not pub- plus 16 digits, and a Google line without the fourth field.
6. Wait. If checks 1 to 5 pass and you changed the file less than a month ago, leave it alone. Google’s range is several days to about a month, depending on your traffic. We know no way to speed it up, and we have no reason to think further edits would. If more than a month has passed and everything above checks out, bring the curl output and the checker report to Google’s help channels.