What the checker does
It requests /app-ads.txt on the developer website's host over HTTPS, then HTTP, then on the
registrable domain, and parses every line with the same rules our crawler applies to every app we track.
A line looks like google.com, pub-1234567890, DIRECT, f08c47fec0942fa0: the ad system, your
account there, the relationship and an optional certification ID. Variables such as
OWNERDOMAIN=example.com sit on lines of their own.
Then it does the step most validators skip: each account is looked up in the sellers.json of the network the line names. A perfectly formatted line can still be useless if the account was closed, mistyped or belongs to someone else, and that is what buyers check. The format itself is covered in What is app-ads.txt.
Reading the verdict on each line
- Authorised
- The network lists the account with the type the line declares, and for a DIRECT line the seller's domain is yours. Nothing to do.
- Listed, owner unconfirmed
- The account exists with the right type, but sellers.json gives no domain or someone else's. Adding OWNERDOMAIN=yourdomain.com often clears it; a parent company's domain is expected.
- Not in sellers.json
- The network does not list the account. Ask your account manager for the current ID, or delete the line if the partnership ended.
- Wrong seller type
- DIRECT on an intermediary's account, or RESELLER on a publisher's. Fix the label, or ask the network to fix its listing.
- Confidential seller
- The account exists but its owner is hidden. Fine for your own confidential account; ask about a reseller you do not recognise.
- No sellers.json data
- We hold no readable sellers.json for that network, so nobody can verify the line.
Fix lines that do not parse before anything else: buyers ignore them entirely, whatever they say. When you
ask a network for a corrected line, ask for the exact line they expect, because the ID in your dashboard is
not always the one they publish. Then publish the file as text/plain and run a live check here.
When the file is the problem
Many failures happen before any line is read. The store page lists one website and the file sits on another, or on a subpage; crawlers only look at the root of the host on the listing. Single-page apps and some site builders answer every unknown path with the home page, which crawlers read as "no app-ads.txt". Firewalls that challenge non-browser clients hide the file from every verifier at once. When something on our side stopped the read, such as a challenge or a timeout, the checker says "could not verify" rather than "missing".
Our crawl · 13 October 2026 Of 832,662 developer websites checked, 141,578 served an app-ads.txt, 477,636 had none, 113,872 answered with something that is not an app-ads.txt and 99,576 could not be read. Each case and its fix