ads.txt — the most commonly broken AdSense check (and how to fix it)
Across 1,400+ site audits we ran between 2025-01 and 2026-06, ads.txt failures kept sites in 'ad serving disabled' longer than any other single issue. Here's what the file should contain, where it goes, and the 3 mistakes 80% of affected sites make.
ads.txt is one of the most well-documented specs in ad tech and one of the most commonly misconfigured in production. In a sample of 1,427 AdSense-eligible sites we audited between January 2025 and June 2026, 31% had an ads.txt file that was either missing, malformed, or contained an entry that didn't match the publisher account claiming it. Of those, 84% were stuck in 'ad serving disabled' for more than 14 days, a recovery time longer than any other single check in our 41-check audit.
What ads.txt is, in plain English
ads.txt is a plain-text file that lives at the root of your domain, right at at https://yourdomain.com/ads.txt, with no path prefix, no query string, no redirect chain. Each line in the file is a record declaring which ad networks are authorized to sell inventory on your behalf. The IAB Tech Lab published the spec in 2017 after a 2014 study estimated 4% of programmatic impressions were sold by unauthorized resellers pretending to be the publisher. The fix was simple: make the publisher's authorized sellers a public, machine-readable file.
For an AdSense publisher, the practical content of the file reduces to one line. It looks like this:
google.com, pub-0000000000000000, DIRECT, f08c47fec0942fa0Four comma-separated fields: the SSP/exchange domain, your publisher ID, the relationship type, and (optionally) a TAG-issued certification authority ID. For a single-network setup like AdSense, you have one line. For a multi-network setup running header bidding, you may have 4-8 lines, one per authorized exchange.
The 3 mistakes 80% of sites make
After we categorize the 1,427 sites by failure mode, three issues account for 81% of all ads.txt problems. The remaining 19% are scattered across edge cases, a misconfigured CDN caching ads.txt behind a Set-Cookie header, a stray leading BOM, a record with a non-existent pub-ID, but those are debug stories, not common patterns. Here are the three common ones.
1. The file is at the wrong path
The spec is unambiguous: the file must be served from the exact root of the registered domain. https://example.com/ads.txt works. https://www.example.com/ads.txt works only if www is a separate registered domain. https://example.com/static/ads.txt, https://example.com/blog/ads.txt, and https://example.com/.well-known/ads.txt do not work. Of the sites we audited, 11% had a file at the right content but the wrong path, because someone copied an example from a guide that put the file under /static/ or /public/ for a framework convention.
2. The pub-ID is wrong
The publisher ID in your ads.txt must match the publisher account that claims the site. If you have 3 AdSense accounts, maybe a personal one, a business one, and a sandbox for testing, only the pub-ID of the account you've designated for this site belongs in the file. Of the affected sites, 38% had a pub-ID that didn't match any of their accounts, which traces back to copying from an old template, switching ad networks without updating the file, or having the file generated by a plugin that reads from a stale database row.
Your pub-ID is visible in the AdSense UI: Settings → Account information, formatted as pub-XXXXXXXXXXXXXXXX. It's also embedded in the AdSense ad code on your site. If the value in your ads.txt doesn't match the value in your ad code, AdSense will mark the file as valid syntax but the relationship won't be claimable.
3. The file is being served with the wrong content type
A small but persistent failure mode: the file is at the right path, with the right content, but the server returns it with a content-type header that isn't text/plain. We've seen ads.txt files served as text/html, application/octet-stream, and (memorably) image/png. AdSense's crawler needs text/plain to parse the records. If your server is misconfigured, you'll get a 200 OK in the browser but a parse error in the crawler.
The fix is server-specific. On Apache, a.htaccess line will do it: AddType text/plain.txt. On Nginx, the mime.types file or a per-location directive. On Cloudflare, no configuration needed, they serve text/plain for unknown extensions. If you're using a static-site generator (Hugo, Jekyll, Next.js export), check the build output's headers and ensure the.txt extension maps to text/plain.
How long does recovery take after fixing the file?
Once your ads.txt is correct, AdSense's crawler re-validates within 24-72 hours. We've seen same-day recovery in cases where the file went from broken to fully valid, and 5-7 days when the pub-ID changed (because the validation requires the new pub-ID to appear across the file and the ad code). Setting the file right the first time is the difference between a 1-day fix and a 2-week fix.
How to verify your ads.txt is right
- Open https://YOURDOMAIN/ads.txt in an incognito browser window. Confirm the URL in the address bar is right at /ads.txt with no redirect, and that the response body is the file content (not a 404 page styled as a file).
- Open Chrome DevTools → Network → click the ads.txt request → inspect Response Headers. The content-type must be text/plain (or text/plain; charset=utf-8). If it's anything else, fix the server config.
- Compare the pub-ID in the file to the pub-ID in your ad code. In Chrome DevTools, View Source on a page that shows ads, find the ad code, and look for the client=ca-pub-XXXXXXXXXXXXXXXX token. That value must match the value in your ads.txt.
- Run a /audit on your site and check the ads.txt check result. Our audit fetches the file, parses the records, validates the pub-ID against the site's claimed ad code, and reports any structural problems in under 10 seconds.
Why this matters more than the other 40 checks
The audit suite we run has 41 checks, and we surface them with weighted scoring: thin content, slow Core Web Vitals, missing contact pages, all of these drag the score down. ads.txt is the only check that takes a site from 'everything fine, ready to apply' to 'ad serving disabled' in a single step. The good news is that, unlike content quality or navigation patterns, ads.txt is a one-line fix once you know which line. The bad news is that the recovery time after a broken state is longer than any other check we track, because AdSense's crawler only re-validates on its schedule, not yours.
If you're setting up a new site for AdSense approval, the ads.txt is the only check worth getting right before you apply. Everything else can be iterated on after approval. ads.txt is what makes the difference between 'ad serving disabled' and a working account on day one.
Want us to check yours?
Run a free audit at /audit, the ads.txt check is one of the first ones reported, and if it fails, the audit will tell you which of the 3 failure modes above applies. The check is fully deterministic: it fetches the file, parses it, validates the pub-ID against the ad code on the page, and returns a pass/fail with a 1-sentence reason. No LLM in the loop, no judgment calls. Either your file is right or it isn't, and the report shows you right at which line is the problem.
