app-ads.txt Explained for App Publishers

If you earn money from ads in your mobile apps, you will meet a small text file called app-ads.txt. It looks trivial, yet missing or malformed files are a frequent cause of reduced ad demand and confusing console warnings. This guide explains what the file does, how to write and host it, the mistakes to avoid, and how to check your status. It is written for publishers, including those with many apps on one domain.

Requirements are maintained by the industry body behind the specification and by each ad platform. Where this article says what a platform expects, verify the details in that platform’s current help pages.

What app-ads.txt is

app-ads.txt is a public text file in which a publisher lists the companies authorised to sell advertising space in its apps. It is the mobile-app counterpart of the ads.txt standard used on websites. Advertisers and the platforms that buy on their behalf can fetch the file and check whether the seller offering an impression is on the publisher’s approved list.

In short: you publish a list of authorised sellers, and buyers use it to confirm they are buying from someone you approved.

Why it exists

Ad fraud often involves someone pretending to sell inventory they do not own, for instance by spoofing an app’s name. Without a way to verify who may sell what, buyers cannot easily tell a real app’s inventory from a fake. The file gives buyers a public, publisher-controlled source of truth. Apps that publish a correct file are generally easier for buyers to trust, which can help your inventory remain eligible for demand. The precise effect on revenue depends on the buyers and platforms involved, so avoid assuming a specific uplift.

How the system finds your file

The connection works like this:

1. Your store listing contains a developer website address.
2. A crawler takes that address and looks for the file at the root of the domain.
3. The crawler reads the lines and records which sellers are authorised.
4. When an ad request arrives from your app, the buyer checks the seller against what was recorded.

Because step one depends on the store listing, the website field in Google Play and in App Store Connect must be filled with a real, working domain, and it must be the domain where you host the file. Check the exact expectations, such as how a subdomain or a path is treated, in your ad platform’s guidance, since crawler behaviour is defined by the specification and the vendors.

Where the file lives

• It must be reachable at the root path of the website domain, named exactly app-ads.txt, for example https://your-domain.example/app-ads.txt.
• It must be a plain text file, served as text, not an HTML page that happens to contain the text.
• It should be reachable over a secure connection, and without login, scripts, or a blocking bot filter.
• Redirects are treated carefully by crawlers. Some redirects are allowed and some are not, so check the specification and your platform’s documentation instead of assuming. The safest setup is a direct response with a success status at the root.

If you run many apps under one brand, list them all in the stores with the same developer website so the one file covers them. If different clients’ apps sit under your account, see the note on client separation in the portfolio checklist.

The line format

Each line describes one authorised seller relationship. It has comma-separated fields:

advertising-system-domain, account-id, relationship, certification-authority-id

A line for Google’s advertising systems looks like this:

google.com, pub-XXXXXXXXXXXXXXXX, DIRECT, f08c47fec0942fa0

Field by field:

• google.com is the domain of the advertising system.
• pub-XXXXXXXXXXXXXXXX stands for your own publisher ID. Replace the X characters with your real publisher ID as shown in your ad account; the example above is a placeholder, not an ID to copy.
• DIRECT means you hold the account yourself. Another allowed value, RESELLER, means the account belongs to a party who resells your inventory.
• f08c47fec0942fa0 is the certification authority ID that Google publishes for its systems. It is the fourth field and is optional in the general standard, but Google documents this exact value for its lines.

Other ad networks publish their own lines. Copy them from the network’s help page or dashboard, because the account IDs and sometimes the certification IDs differ. Do not guess a line, and never use somebody else’s ID.

Lines starting with # are comments. Blank lines are ignored. A few additional variables exist in the specification, such as for naming a contact, but check the current specification before using them.

Mediation

If you run mediation, add the lines for every network that can bid on or serve your impressions, not only your primary one. The mediation provider and each network usually document the lines to add. Missing one of them means that network’s demand may be treated as unauthorised.

Common mistakes

1. Wrong location. Putting the file in a subfolder, in the wrong domain, or on the www host when the store lists the bare domain, or the reverse.
2. The store listing points elsewhere. The website field holds a social page or a link-in-bio service, so crawlers never reach your domain.
3. Typos in the publisher ID. One wrong character breaks the match. Copy from the console.
4. Using the placeholder. Leaving pub-XXXXXXXXXXXXXXXX or similar in the live file.
5. HTML instead of text. A content management system wrapping the file in a page template.
6. Blocked crawlers. A firewall, bot protection, or robots.txt rule preventing access.
7. Wrong relationship. Marking an account as RESELLER when it is DIRECT, or the reverse.
8. Missing networks. Adding Google’s line but forgetting other mediated networks.
9. Stale lines. Leaving lines for networks you no longer use. Remove them to keep the list accurate.
10. Fancy formatting. Smart quotes, stray characters, or unusual encodings copied from a document. Keep to simple text.

How long crawlers take

Crawlers do not fetch your file the moment you upload it. Updates are picked up on the crawler’s schedule, and platforms usually say the process can take a while. Because no reliable duration can be promised, check your ad platform’s help centre for its current guidance, make changes in advance of launches, and avoid repeated edits while you wait. If you changed the store listing’s website, expect a delay for that change as well.

Checking your status in AdMob

The AdMob console reports on app-ads.txt for apps linked to your account. Look in the app-level or account-level sections for an app-ads.txt status or similar notice; the console’s layout changes, so use its help search for the current location. It generally tells you whether the crawler found a file, and whether your publisher ID appears in it. If it flags a problem:

1. Open the file in a browser and confirm it loads as plain text at the root of the domain you gave the store.
2. Compare your line with the one shown in the console character by character.
3. Confirm the store listing’s website field matches the host.
4. Wait for the next crawl, then check again.

Other ad platforms offer comparable checks. Use theirs for their lines.

Maintaining the file

Treat the file as part of your configuration. Store it in version control, review it when you add or drop an ad network, and include it in your regular site checks. Pair it with a stable privacy policy URL on the same domain, since a credible developer site supports both. If your app changes how it handles ad identifiers, update your store disclosures as described in the Data safety guide.

For deadlines and technical shifts that can affect your apps, see our article on the Android 16 target API deadline, and find related material in the publishers hub.