app-ads.txt and ads.txt for Streaming Publishers: A Setup Guide

Why these files exist

Programmatic advertising lets buyers purchase ad impressions from thousands of publishers through exchanges and networks. That openness made it possible for fraudsters to pretend to sell inventory from well-known apps and sites — a practice called domain or app spoofing. Buyers paid for ads in a famous app that were never shown there.

The IAB Tech Lab created ads.txt (Authorized Digital Sellers) for websites and later app-ads.txt for apps. Each publisher publishes a list of the ad systems and account IDs allowed to sell its inventory. Buyers and exchanges crawl the list and ignore offers from sellers that are not on it. Many ad networks now limit or stop serving ads to apps whose app-ads.txt is missing or does not include them, because unverified inventory earns less and carries more risk.

How a crawler finds your app-ads.txt

A website’s ads.txt is easy to find: it lives at the root of the site, for example example.com/ads.txt. Apps do not have a domain of their own, so app-ads.txt uses an indirection. The crawler looks up your app in the App Store or Google Play, reads the developer website URL from the store listing, and fetches /app-ads.txt from the root of that website’s domain.

That means three things have to line up:

• The developer website field in App Store Connect and in Play Console contains a URL on a domain you control.
• That domain serves a file at /app-ads.txt, at the root, not in a subfolder such as /apps/app-ads.txt.
• The file contains a line for each ad network that sells your app inventory, with your publisher account ID for that network.

If your listing says www.example.com, make sure the file is reachable on both www.example.com and example.com, or that one redirects cleanly to the other on the same domain. Ad networks document their own crawler behavior; when in doubt, serve the file on the exact host that appears in the listing and on the bare domain.

The record format

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

1. The domain of the advertising system, such as google.com for Google AdMob and AdSense.
2. Your publisher account ID within that system. For Google this is the pub- identifier shown in your AdMob or AdSense account.
3. The relationship: DIRECT if you hold the account and sell through it yourself, RESELLER if an intermediary sells on your behalf.
4. Optionally, the certification authority ID of the ad system, such as the TAG-ID f08c47fec0942fa0 that Google publishes for its line.

A typical Google line looks like: google.com, pub-0000000000000000, DIRECT, f08c47fec0942fa0 — with your own publisher ID. Each additional ad network or mediation partner provides its own lines, which you append. Lines starting with # are comments; use them to note which partner each block belongs to and when it was added.

If your AdMob and AdSense accounts are the same Google account, they share one publisher ID, and the same line works in both ads.txt (for the website) and app-ads.txt (for the apps). Always copy the exact line from the ad network’s console rather than retyping it; a single wrong digit makes the line useless.

Hosting mistakes that break verification

Most verification failures we see are not about the content of the file but about how it is served.

• The file returns a web page instead of text. Single-page applications often answer every unknown path with index.html, so /app-ads.txt returns HTML with status 200. The crawler reads garbage. Serve the real file with Content-Type text/plain.
• The file returns 404 because it was added to the repository but not to the build output, or because a reverse proxy routes only known pages.
• A redirect sends the crawler to a different domain, a login page, or a consent banner. Keep the file directly reachable without cookies or JavaScript.
• The store listing still points to an old domain or to a social media page, so the crawler never looks at your real site.
• The file is served with a byte-order mark or unusual encoding. Plain ASCII or UTF-8 without BOM is safest.

After publishing, request the file the way a crawler would — a plain HTTP GET without cookies — and check the status code, content type, and body. Then check the ad network console. Google AdMob shows an app-ads.txt status per app; crawls can take a day or more to pick up a change, so do not rush to edit the file again if it does not update immediately.

Connected TV and multiple apps

Connected TV platforms such as Roku, Fire TV, Android TV and smart TV stores participate in the same scheme. Each app store listing has its own developer URL, and the crawler uses it the same way. If you publish many apps under one developer account — for example, white-label apps for several channels — they can all point to the same developer website, and one app-ads.txt file covers them all, as long as every ad network account used by any of those apps is listed.

For operators who publish apps on behalf of clients, decide who owns the developer website. If the app is listed under the client’s developer account with the client’s website, the client must host the file. If it is listed under your account, you host it and must keep it current for every client’s ad partners.

Websites: ads.txt and sellers.json

If your streaming service also has a website with display or video ads, the same idea applies with ads.txt at the root of that site. Many teams host both files on the same corporate domain: ads.txt for the website’s inventory and app-ads.txt for the apps.

On the other side of the transaction, ad systems publish sellers.json, which lists the publishers they represent. Buyers cross-check the two: your ads.txt says a network is authorized to sell for you, and the network’s sellers.json says you are one of its sellers. You do not host sellers.json yourself, but your business details in each network’s account feed it, so keep the legal name and domain accurate there too.

Keep the files current

An app-ads.txt file decays as partners change. Old lines for networks you no longer use are not harmful in themselves, but they widen the list of companies that could claim to sell your inventory. Missing lines for new partners cost revenue immediately.

1. Keep the files in version control alongside the website, so every change is reviewed and dated.
2. Add a step to the ad partner onboarding checklist: copy the partner’s lines into app-ads.txt and deploy before launching the partnership.
3. Remove lines when a partnership ends.
4. Check the network consoles monthly for verification warnings, and check the store listings after any domain change.

Two short text files will not make your ads more relevant or your content better, but without them a growing share of ad demand simply will not bid. For ad-supported streaming, they are part of the minimum setup.