app-ads.txt is one small plain-text file that decides whether ad platforms accept the answer to a single question: who is authorised to sell the ad inventory in your app? It is the app-store sibling of the web's ads.txt, and AdMob — along with most major ad networks — uses it to tie a published app back to the publisher account that genuinely owns its inventory. Publishing the file is a ten-minute job. Getting it verified is where most developers stall, because the failure is silent: no error, no email, just an app that never receives the verified status its file was supposed to earn.

This checklist follows the order the work actually happens in, using the steps published in Google's own AdMob Help: stand up a developer website, link it in your store listing, publish app-ads.txt at the domain root, confirm the URL resolves in a browser, let the AdMob crawler find it, read the verification status, and keep the file current. The one rule underneath all of it: the domain, the listing and the publisher ID have to describe the same real publisher.


1. What app-ads.txt actually is

The file is defined by the IAB Tech Lab as the app-ecosystem extension of ads.txt. Its purpose is simple and defensive: instead of buyers trusting a bid request that claims to come from your app, they can check a public, publisher-controlled list of who is allowed to sell that inventory. Sellers who are not on the list can be filtered out, which is what makes spoofed apps and unauthorised reselling harder to monetise.

For AdMob specifically, the file is how Google confirms that the publisher account requesting monetisation matches the developer behind the store listing. A correctly published file earns a verified status in your AdMob account; a missing or malformed one leaves your apps unverified, even while ads keep serving. That gap is the whole reason this checklist exists.

2. Prerequisite — a developer website, linked to your store listing

AdMob does not guess your domain. It reads the developer website from your app's store listing and derives the hostname from it. If that field is empty — or points at a social page, a parked domain, or a form-builder URL — there is nothing for the crawler to resolve, and no amount of file-publishing will help.

If you do not yet have a site that lets you upload a file at the root, that is not a blocker — Firebase Hosting is a documented option for publishing an app-ads.txt file.

3. Step 1 — publish the file at the domain root

The file must be reachable at the root of the hostname derived from your listing, in the form:

https://<hostname>/app-ads.txt
http://<hostname>/app-ads.txt

"Root" means immediately after the top-level domain — for example.com the file lives at example.com/app-ads.txt, not inside a project subfolder. Before you do anything else, open that URL in a browser. If the file content displays, the crawler is very likely to find it; if the browser shows a login wall, a JavaScript shell, or a download prompt, fix that first.

4. Step 2 — the publisher ID and the exact line format

Each line names one authorised seller, in the format the IAB specification requires:

<ad system domain>, <publisher account ID>, <relationship>, <certification authority ID>

The Google line uses your AdMob publisher ID (the pub-… value found in your account) as the account ID, DIRECT as the relationship, and Google's TAG certification authority ID:

google.com, pub-0000000000000000, DIRECT, f08c47fec0942fa0

You do not have to assemble this by hand. AdMob provides a personalised code snippet that already contains your publisher ID, and getting that ID included and formatted correctly is an explicit requirement for verification. Create the file as plain text (Notepad, TextEdit, or any text editor — not a rich-text document), paste the snippet, and add a line for every other ad network you work with; each network publishes its own app-ads.txt information. A file that does not follow the IAB format will not verify, regardless of how valid your ID is.

5. Step 3 — understand how the AdMob crawler looks for the file

The crawler builds its URL from the hostname of the developer website in your listing, then climbs in a defined order. Knowing the rules prevents a whole class of "but my file is right there" mysteries.

6. Step 4 — wait for the crawl, and request one if you must

AdMob routinely crawls your latest file, and it can take up to 24 hours to crawl and verify. If you are waiting on a freshly published file, you can ask for a faster look:

  1. Sign in to AdMob, open Apps, then View all apps.
  2. Open the app-ads.txt page and expand the row for the app you want to check.
  3. Click Check for updates.

Two details tame impatience here. A manual re-crawl updates the status for every app that shares the same app-ads.txt file, so you rarely need to request per app. And the button is sometimes unavailable — when it is, routine crawling still runs, so wait the 24 hours rather than re-editing the file repeatedly.

7. Step 5 — read the verification status, and troubleshoot from it

The app-ads.txt page in AdMob shows the status and the crawl details for each app. Treat that page as the single source of truth rather than a screenshot from last week. If the file was not found or not verified, the status details point at the cause, and Google publishes a dedicated troubleshooting path.

The most common causes, in order: the store listing's developer website field is empty or unusable; the file sits at a path instead of the root; the publisher ID is missing or malformed; the crawler is blocked by robots.txt; or the listing was changed so recently that AdMob has not yet re-read it.

8. The app-ads.txt verification checklist

Run these twelve checks in order. Every one of them maps to a rule above, and every one of them is something the crawler will implicitly judge.

  1. A developer website exists and you control its domain.
  2. That URL is listed in the store listing — Play developer website, or App Store marketing URL — and visible in the app's support area.
  3. app-ads.txt sits at the domain root, as https://<hostname>/app-ads.txt.
  4. The URL displays the file content directly in a browser.
  5. The file is plain text, not a formatted document or an image.
  6. Your AdMob publisher ID is present, in the correct IAB line format, with the Google line included.
  7. Every other ad network you use has its own added line.
  8. The file is reachable at the root or first-level subdomain the crawler actually checks — not only at a deeper subdomain.
  9. robots.txt allows the AdMob crawler.
  10. If you changed the listing website, you have allowed up to 24 hours for AdMob to detect it.
  11. You have requested Check for updates if you need a faster crawl, then waited the 24-hour window.
  12. You re-check the status whenever your seller list changes, and keep the file current.

9. Where KappS fits in

app-ads.txt is one link in a longer chain that decides whether a monetised app actually gets paid: the developer account, the payments profile, the tax information, and the publisher identity all have to line up. KappS helps developers prepare and submit compliant material across that chain, so that a verification step — app-ads.txt, identity, or tax — does not quietly hold up revenue later. In practice that means checking the listing, the domain and the publisher ID describe the same genuine publisher, and fixing the mismatches before a crawler or a reviewer finds them.

What we do not do is manufacture authorisation. app-ads.txt exists precisely to expose publishers who are not who they claim to be; listing a seller you have no right to represent is fraud, it puts the account and its payouts at risk, and it is not a service we offer. The only durable way to pass verification is to be the real publisher behind the app.

Sources (Google official documentation): AdMob Help — Set up an app-ads.txt file for your app; Understand app-ads.txt file statuses; Troubleshoot app-ads.txt issues; About the content crawler (support.google.com/admob). IAB Tech Lab — app-ads.txt specification.