app-ads.txt for Google Play Apps, Step by Step
Set the developer website, write the right lines, host the file at your domain root and get AdMob to verify it.
6 min read · Updated
Advertisers who buy space in your app want proof that they are paying you, not someone pretending to be you. app-ads.txt is how they check. It is a small text file on your own website that lists every ad company allowed to sell your inventory, and buyers compare each bid request against it.
If the file is missing or wrong, some buyers simply stop bidding. AdMob also flags the app, and many developers only notice after their eCPM has slipped for weeks. The fix usually takes an afternoon, but the details trip people up: the right website field, the exact host and the exact lines.
This guide covers the Google Play side from start to finish. Store consoles rename their menus from time to time, so if a label here does not match your screen, look for the nearest equivalent and confirm it in the official documentation.
What app-ads.txt does
The standard comes from the IAB Tech Lab, which also maintains ads.txt for websites. The idea is the same in both: you publish a public list of authorised sellers, and anyone in the supply chain can read it. The IAB Tech Lab ads.txt page hosts the specification, including the app version.
For an app, the trust chain runs like this. The store listing names a developer website. A crawler visits that website and reads /app-ads.txt from its root. When a bid request says "this impression is from app X, sold by network Y under account Z", the buyer checks whether that combination appears in your file. If it does, the impression is authorised. If not, it may be treated as unverified, which usually means fewer bids or none.
That is why app-ads.txt is about revenue as much as tidiness. Unverified supply competes for a smaller pool of buyers, and a thinner auction lowers your eCPM. Our eCPM explainer shows how that feeds through to your reports.
Set the developer website in Play Console
Crawlers do not guess where your file lives. They read the website from your Play listing. In Play Console it sits with your store listing contact details, in the store presence or store settings area, next to your contact email. Enter the full URL of a site you control, such as https://example.com.
A few practical points:
- Use a domain you own and plan to keep. A free page on a website builder's shared domain usually cannot host a file at the root.
- Avoid deep paths. Crawlers take the host from the URL and look at the root, so
https://example.com/apps/my-gamestill sends them tohttps://example.com/app-ads.txt. - Keep it consistent. If one developer account publishes several apps, pointing them all at the same domain lets one file cover every app.
Once saved, the website appears on your public Play listing, and that public listing is what crawlers read. Check the live page, not only the console. The Play Console overview links to Google's current help pages if the menu has moved.
The file format, line by line
app-ads.txt is plain text with one record per line. Each record has up to four comma-separated fields:
| Field | What it holds | Example |
|---|---|---|
| Ad system domain | The network's own domain | google.com |
| Account ID | Your publisher ID with that network | pub-0000000000000000 |
| Relationship | DIRECT if you hold the account, RESELLER if a partner sells for you | DIRECT |
| Certification ID | Optional ID for the ad system from the TAG registry | f08c47fec0942fa0 |
An AdMob record therefore looks like this, with your own publisher ID in place of the zeros:
google.com, pub-0000000000000000, DIRECT, f08c47fec0942fa0
Copy the line from your AdMob account rather than typing it, since a single wrong digit breaks the match. Lines starting with # are comments and are ignored, which is handy for labelling which network each block belongs to.
If you use mediation, every network that sells your inventory needs its own lines. AppLovin MAX, LevelPlay and other mediation platforms publish their partners' lines in their dashboards or documentation. Add the full set for each partner you have switched on, and remove blocks for networks you have turned off. The mediation guide explains why each extra bidder matters.
Where and how to host it
The file must be reachable at exactly https://yourdomain.com/app-ads.txt. Check these points before you ask any network to verify:
- It returns a 200 status code, not a 404 or a login page.
- It is served as plain text, ideally with a text/plain content type, not wrapped in an HTML template.
- It loads over HTTPS without certificate warnings, and plain HTTP either redirects to HTTPS or serves the same file.
- Redirects are short and stay on your domain. Crawlers generally follow a simple redirect, but long chains or hops to another domain can fail.
- Nothing blocks bots. Some security plugins and firewalls challenge unfamiliar visitors, which stops crawlers cold.
If your listed URL uses a www host, make sure the file loads on both the www host and the bare domain. That covers the different ways crawlers resolve the root.
On a static host, put the file in the public root folder. On WordPress, upload it to the site root or use a plugin that serves it. Then open the URL in a private browser window to see what the public sees.
Verifying in AdMob
AdMob checks app-ads.txt for apps that are linked to their store listing. An app that has not been linked cannot be verified, so link it in the app settings first.
In AdMob, open your apps and look for the app-ads.txt tab or status. It shows whether the file was found and whether your publisher ID appears in it. After you upload or fix the file, you can usually ask AdMob to check again. The AdMob help centre has the current steps.
How long crawling takes
Crawling is not instant. AdMob usually needs up to a day or so to recheck after a change, and other networks and buyers run their own crawlers on their own timetables. Allow a few days before the whole supply chain sees a new file.
The lag works both ways. If you break the file during a website redesign, buyers may keep their cached copy for a short while, then drop your inventory once they recrawl. Treat app-ads.txt as part of your site and check it after every migration, theme change or hosting move.
Common errors and fixes
- File not found. Usually a wrong path, a typo in the website field, or a site that redirects /app-ads.txt to the home page.
- Publisher ID missing. The file exists but your line is absent or mistyped. Paste it again from your account.
- Old domain read. The Play listing still shows a previous website. Update the field and wait for the listing and crawlers to refresh.
- Blocked crawler. A firewall or bot-protection service returns a challenge page. Let the file through.
- Hidden characters. Word processors add smart quotes and formatting. Edit in a plain text editor and save as UTF-8.
- Wider account problems. Verification issues can sit alongside serving limits. Our guide to why ad accounts get limited covers the other causes.
What it is worth to you
app-ads.txt does not raise your rates on its own. It stops you losing buyers who refuse unverified supply. In our benchmark tables, a Tier 1 Android interstitial on AdMob sits around $8.00 eCPM and a rewarded video around $12.00, so losing even part of the demand on full-screen formats costs real money. Try your own numbers in the AdMob revenue calculator or the home calculator, and see the mobile eCPM benchmarks for the full table.
If you also ship on iOS, the steps are similar but the listing fields differ: see app-ads.txt for the Apple App Store. For other Android stores, read app-ads.txt on Amazon, Samsung and Huawei.