Why AdMob Can't Verify Your app-ads.txt: The Fix-It Walkthrough

AdMob says your app-ads.txt isn't verified, but the file is there and looks fine. Eight breakage patterns, ranked by frequency, with the fix for each.

Why AdMob Can't Verify Your app-ads.txt: The Fix-It Walkthrough

Your app-ads.txt file is at the right URL. It opens in your browser. The Google line is right there. AdMob still says it is not verified. The file is doing nothing for you.

This is one of the most common AdMob frustrations because the file looks fine from a developer's perspective. Open it in a browser, the text is there, you can read it. AdMob's crawler is a different reader though, and the gap between "I can see it" and "AdMob's crawler can verify it" comes down to about eight specific patterns.

This article walks through what AdMob is actually checking, the eight breakages in the order they show up in practice, how to test what AdMob's crawler sees so you do not have to wait 72 hours to know if your fix worked, and a short note on the related problem where the file verifies but ads still do not serve.

If you want the fastest self-check before reading further, paste your developer-website URL into the free AdMob Approval Checker. It runs all eight verification checks against the file Google would crawl and tells you which patterns apply, with the recommended fix per pattern.

What AdMob is actually checking

AdMob's verification path has four steps. Each step has to succeed for the file to be considered verified. The breakage patterns below all map to a failure in one of these four steps, so understanding the path helps you triage:

  1. Read the developer-website URL from your store listing. AdMob pulls this from your Play Store or App Store listing. Whatever URL is there is the apex domain AdMob expects to host your app-ads.txt.
  2. Fetch the file at {developer-website-apex-domain}/app-ads.txt. Note the apex domain part. AdMob does not follow you to a subdomain like www. or blog. unless your store listing URL itself uses that subdomain.
  3. Confirm the response is served as text/plain, no redirects, valid UTF-8. Anything else and the crawler gives up.
  4. Parse the file, find a DIRECT entry for google.com with a publisher ID that matches your AdMob account.

If any of the four steps fail, AdMob marks the file unverified. The rest of this article is a tour of how each step can break.

The 8 things that actually break verification

Issue 1: The developer-website URL on your store listing points to the wrong domain

This is the single most common breakage. The Play Store and App Store let you put any URL in the developer-website field, including a marketing landing page on a different domain than where you actually host app-ads.txt. AdMob crawls the URL you listed. If the URL is https://my-app-landing.com and your app-ads.txt lives at https://my-real-domain.com/app-ads.txt, AdMob never finds it.

The fix: open Play Console > Grow > Store presence > Main store listing > Developer contact details > Website (or App Store Connect > App Information > Marketing URL or Support URL on the iOS side). Confirm the URL there is the same apex domain that hosts your app-ads.txt. If you have to choose between marketing site and ad-serving site, host the app-ads.txt on the marketing site, because that is what the world treats as your developer website anyway.

Issue 2: Subdomain mismatch

Closely related to Issue 1. If your developer-website URL is https://www.my-domain.com, AdMob looks for app-ads.txt at https://www.my-domain.com/app-ads.txt. Not at https://my-domain.com/app-ads.txt. AdMob follows the URL you listed exactly. It does not collapse www. or follow redirects between apex and www. consistently.

The fix: pick one host and stick to it. Either list the apex domain in your store and host app-ads.txt at the apex, or list www. in your store and host the file under www.. The redirect-from-apex-to-www trick that works for browsers does not always work for AdMob's crawler (see Issue 7 below).

Issue 3: Wrong Content-Type header

When AdMob's crawler fetches the file, the server has to return Content-Type: text/plain. If the server returns text/html (which static hosts sometimes do for files without a recognized extension on certain configurations), the crawler treats it as HTML and bails. Same if the response has no Content-Type at all.

The fix: check it with curl -I (the testing section below shows how). If the Content-Type is wrong, the fix depends on your hosting. Most static hosts (Netlify, Vercel, Cloudflare Pages, GitHub Pages) serve .txt files as text/plain automatically. If you are on a custom server or a CMS, you may need to add a MIME-type rule. WordPress plugins occasionally inject HTML wrappers around .txt files. Disable any plugin that touches static-file serving.

Issue 4: File saved with BOM or non-UTF-8 encoding

This one is sneaky because the file opens fine in a browser. The byte order mark (BOM) or non-UTF-8 byte sequences at the start of the file cause AdMob's parser to fail on the first line. The most common cause: the file was written or pasted from Microsoft Word, Notes, or another editor that adds invisible encoding metadata.

The fix: open the file in a developer-grade editor (VS Code, Sublime, or anything that shows the encoding in the status bar). Make sure it shows "UTF-8" with no "with BOM" qualifier. If you see "UTF-8 with BOM" or any other encoding, re-save as plain UTF-8. On a unix command line, file app-ads.txt will tell you the encoding; expected output is something like "ASCII text" or "UTF-8 Unicode text" with no BOM mention.

Issue 5: Publisher ID in the file does not match your AdMob account

You correctly added a DIRECT line for google.com. The publisher ID is pub-1234567890123456. AdMob still says not verified. Reason: that publisher ID does not match the AdMob account you are trying to verify. This happens most often when developers have multiple Google accounts, copied the publisher ID from an old AdSense account, or have two AdMob accounts and used the wrong one's ID.

The fix: log into the AdMob account you are trying to verify, go to Account settings > Publisher ID. Copy the exact value. The format is pub- followed by 16 digits. Compare against what is in your app-ads.txt line. They must match exactly.

Issue 6: Comma vs space separator, or trailing whitespace

The IAB spec for app-ads.txt is strict: each line is domain, publisher-id, relationship, optional-cert-id, separated by commas. Spaces around the commas are fine, but other separators are not. The two most common breakages: someone replaced commas with spaces (looks the same to humans, fatal to the parser), or there is trailing whitespace, a Windows line ending (\r\n), or other invisible characters.

The fix: validate the line format. The canonical Google line is:

google.com, pub-XXXXXXXXXXXXXXXX, DIRECT, f08c47fec0942fa0

Replace pub-XXXXXXXXXXXXXXXX with your actual publisher ID. The cert ID f08c47fec0942fa0 is Google's TAG ID and is the same for everyone. Make sure you have commas (not spaces), no extra characters at the end, and Unix line endings if possible.

Issue 7: Redirect chain breaks the crawler

Your developer-website URL is https://my-domain.com. The server redirects to https://www.my-domain.com. The redirect target's /app-ads.txt works fine, but AdMob's crawler does not always follow the redirect. The verification fails.

This is the second-most-common subdomain breakage. Redirect chains, especially across protocol or host changes (http to https, apex to www, one domain to another), are not reliably followed by AdMob's crawler. They will be followed by your browser, which is why this issue is so easy to miss.

The fix: host the file at the URL AdMob fetches directly, with no redirect chain in the way. If you list https://my-domain.com in your store, the file has to be at https://my-domain.com/app-ads.txt and that URL has to return 200 without redirecting.

Issue 8: Cloudflare or CDN serving a cached old version

You updated the file. You can see the new version in your browser. AdMob is still verifying against the old version, or AdMob says unverified even though the file you see has the correct content.

This is a CDN caching issue. Cloudflare and similar CDNs cache .txt files aggressively. After you update the file at the origin, the CDN may continue serving the old version for hours. AdMob's crawler hits the CDN, gets the old file, and verifies against that.

The fix: purge the cache after every app-ads.txt update. In Cloudflare, this is Dashboard > Caching > Configuration > Purge Everything, or use the API to purge just the app-ads.txt path. After purging, wait a minute or two for cache propagation, then re-test using the curl command in the next section.

How to test what AdMob's crawler actually sees

Browser tests are misleading because your browser follows redirects, handles encoding, and respects different headers than AdMob's crawler does. The reliable way to test is from the command line with curl, simulating what the crawler does.

Here is the five-step test that confirms your file is verifiable before you wait the 24-72 hours for AdMob to re-crawl:

Step 1: Run curl -I against your app-ads.txt URL

curl -I https://your-developer-website.com/app-ads.txt

The -I flag returns just the response headers. Check the first line of the response.

Step 2: Confirm the response is HTTP/2 200 (or HTTP/1.1 200)

If you see 301, 302, 307, or 308, you have a redirect (Issue 7). If you see 404, the file is not where AdMob expects it (Issues 1 or 2). If you see 200, the file is reachable at the right path.

Step 3: Confirm Content-Type is text/plain

Look for a content-type: text/plain header in the response. If it says text/html or anything else, you have Issue 3. If it says text/plain; charset=utf-8, that is fine, the charset suffix is allowed.

Step 4: Spoof your user-agent as Googlebot and re-test

Some CDNs and servers serve different content to bots than to browsers. Run:

curl -I -A "AdsBot-Google" https://your-developer-website.com/app-ads.txt

The headers should be identical to Step 2. If they differ, your server is doing user-agent sniffing and you need to disable it for AdsBot or for static file paths.

Step 5: After confirming all the above, wait 24-72 hours and re-verify in the AdMob console

AdMob's crawler runs on its own schedule and can take up to 72 hours to pick up a fix. There is no manual re-trigger. If after 72 hours the file still shows unverified and your curl tests all pass, the issue is most likely Issue 5 (publisher ID mismatch) or something AdMob-account-specific that needs a manual recheck via support.

When AdMob says verified but ads still do not serve

A subtle related problem: AdMob's console confirms your app-ads.txt is verified, the file is correct, the publisher ID matches. Ads still do not serve to your app.

This is a different problem. app-ads.txt verification is a gate, not the only gate. After verification you can still hit any of these:

  • Account is in the 30-day ad-serving limit. New AdMob accounts have a throttled serving window where ads are limited regardless of integration quality. This resolves automatically after the window ends and the account passes traffic-quality review.
  • Ad units are misconfigured. Wrong unit type for the format you are requesting, ad unit ID typo, or the ad unit was created under a different AdMob account.
  • SDK integration issue. Test ad unit IDs left in the production build, mediation adapters out of sync, missing initialization callback. The free Mediation SDK Checker catches the most common SDK-version-pairing issues.
  • Invalid traffic flag on the account. A separate suspension condition that overrides verification. See the AdMob rejection reasons guide for Pattern 4 details.

So if your file is verified but ads do not serve, the problem is downstream of app-ads.txt. Different diagnostic, different fix.

TL;DR + verification checklist

The fast version:

  1. Confirm your store listing's developer-website URL matches the apex domain where you host app-ads.txt. Same subdomain, no redirect.
  2. Run curl -I -A "AdsBot-Google" https://your-domain.com/app-ads.txt. Confirm 200 status, content-type: text/plain, no redirect.
  3. Open the file in a developer editor and confirm UTF-8 encoding with no BOM.
  4. Confirm the google.com line uses commas (not spaces), has your exact AdMob publisher ID, and has no trailing characters.
  5. If you are behind Cloudflare or a CDN, purge the cache.
  6. Wait 24-72 hours after any change for AdMob to re-crawl. There is no manual re-trigger.

If you want a tool that runs all of this in one shot, the free AdMob Approval Checker covers the full verification path plus the rest of the AdMob approval checks.

Frequently asked questions

How long does AdMob take to verify app-ads.txt?

Typically 24-72 hours after a successful file change. There is no manual re-trigger; AdMob's crawler runs on its own schedule. If you see the file as unverified for more than 72 hours and your curl tests all pass, the most likely remaining cause is a publisher-ID mismatch.

Can I have multiple lines for google.com in app-ads.txt?

Yes. If you run multiple AdMob accounts (covering different apps or business entities), you can list a separate DIRECT line per publisher ID. AdMob verifies against the line that matches the account you are trying to verify from.

Does my developer-website URL need to match my app-ads.txt domain exactly?

Yes, at the apex-domain level. If the developer-website URL is https://my-domain.com, the file has to be at https://my-domain.com/app-ads.txt. If the URL includes www., the file has to be on www. too. AdMob does not collapse subdomain differences.

Why does AdMob's "Test your app-ads.txt" tool say verified, but the account still is not approved?

app-ads.txt verification is one of several gates. The account can still fail content review, traffic-quality review, sign-up verification, or be in the 30-day ad-serving limit window. See the AdMob rejection reasons guide for the full list of patterns that block ad serving even after verification.

Should I use ads.txt or app-ads.txt for my mobile app?

app-ads.txt is the IAB Tech Lab spec for mobile apps. ads.txt is for web inventory only. If your developer website also runs ads, you have both files (ads.txt for the web side, app-ads.txt for the apps). They are different files at different paths and AdMob looks for app-ads.txt specifically when verifying an app.

What if I am using a third-party site builder (Wix, Squarespace) that will not let me add app-ads.txt?

Most site builders now allow uploading arbitrary files to the root, but some do not. Workarounds: register a separate domain you control, point your store listing's developer-website URL there, and host app-ads.txt at the root of that domain. The site itself can stay on the third-party builder.

Is the AdMob Approval Checker the same as Google's app-ads.txt verification?

Different. The AdMob console's tool tells you whether AdMob has verified your file. The AdMob Approval Checker runs the same checks Google's crawler would run before you submit, so you can pre-flight every breakage pattern in this article and fix issues before AdMob ever sees them. Useful when you want to verify a fix without waiting 24-72 hours.

If you fixed everything in this article and your file still will not verify, the free 30-minute call is the starting point: book a call. Best fit for apps doing $10K+/month in ad revenue, though anyone is welcome to read the guides and run the checkers.