An email arrived from AdMob one morning.
app-ads.txt is a single line of text hosted at the root of a developer's website. It declares which ad accounts may sell that app's inventory. It exists to stop people reselling ad space they don't own.
First we took the file apart six ways
| Checked | Why we suspected it | Result |
|---|---|---|
| Does the URL load | Wrong path | Fine (200) |
| Is the content right | Wrong publisher ID | Fine |
| Invisible characters (BOM) | Editors insert them silently | None |
| Trailing newline | Missing one drops the last line | Present |
| Content-Type header | Anything but text/plain gets ignored | Fine |
| Fetch as Google's crawler | Humans pass, bots get blocked | Fine |
We also checked robots.txt and server-side access protection. All clear. The store listing's website field held the right domain too.
But we couldn't open that dashboard
AdMob sits behind a login. The boss was out, driving the AI from a phone. And a phone-remote session can't drive a browser.
That is exactly what a remote session uses. It isn't a setting you can flip.
The AI failed four times trying to work around it — copying browser cookies, typing into the login form, opening the password store, restarting the browser. Every one was an AI touching someone's account credentials, and the safety layer cut all four.
Four attempts, one wall.
They felt like different approaches. To the safety layer they were the same move.
So we handed the job to the window next door
A session started on the computer can drive the browser. And AI sessions can message each other. So the phone session asked the desktop session to open AdMob and write down what it saw.
- Phone session sends a message to the desktop session
- Desktop session opens AdMob in the browser, reusing the login already there
- It reads the screen and saves the findings to a file
- Phone session reads that file and reports back
The answer: already fixed
| Field | What the screen said |
|---|---|
| Overall | 100% of queries approved |
| The app in question | app-ads.txt file found and verified |
| Last crawled | 1 hour ago |
| Store link | Connected (Google Play) |
AdMob had re-crawled after the email and passed it. The crawl runs on a cycle of up to 24 hours. We spent that gap dissecting a file that was never broken.
The real problems were elsewhere
- Another app was ad-restricted — add a store to lift the limit. It is still in closed testing, so there is no store URL to link. Publishing fixes it.
- Payment profile incomplete — apps under review stay on hold until payment info is added. That may be the actual reason ads are not serving.
What we learned
- A warning email doesn't mean it's still broken. The email is a snapshot; the crawler keeps running. Read the dashboard first, the file second.
- Six checks before editing anything: loads · content · invisible characters · trailing newline · Content-Type · fetch as the crawler. The last one catches more than you would expect.
- Search the English error string. Localized wording returns almost nothing.
- When an AI says it can't be done, ask whether it read the docs. The answer was in the vendor's documentation, verbatim.
Should have opened the dashboard first.
Half a day of file forensics, all of it wasted.