# Auditing Your ads.txt Before a Programmatic Buyer Asks About It

ads.txt and app-ads.txt are the IAB Tech Lab&#39;s way of letting publishers publicly declare which ad exchanges are authorized to sell their inventory. Done wrong, DSPs drop you from auctions. Here&#39;s how to audit both files, what each line means, and how the jwatte.com ads.txt Audit tool spots the common mistakes.

Author: J.A. Watte
Published: April 24, 2026
Source: https://jwatte.com/blog/blog-tool-ads-txt-audit/

---

If you run programmatic advertising on a website, your **ads.txt** file is the first thing a DSP (Demand-Side Platform) checks before it bids on your inventory. If the file is missing, malformed, or lists an exchange that is not authorized for your account, the DSP will not bid. You will see it as "nobody is buying my inventory lately", not as an error. Debugging it means reading a plain-text file most people forget exists.

The [ads.txt / app-ads.txt Audit](/tools/ads-txt-audit/) tool pulls your `/ads.txt` and `/app-ads.txt` from the domain you enter, parses every line, and flags the common mistakes. Here's what it's looking for and why each one matters.

## What ads.txt actually is

The IAB Tech Lab introduced ads.txt in 2017 as a response to domain spoofing, where fraudsters sold ad impressions on fake copies of premium publishers. If the New York Times publishes an ads.txt saying "only these exchanges are authorized to sell my inventory," any DSP can verify in one HTTP request whether the inventory it's about to buy is legitimate.

The file lives at the root: `https://yourdomain.com/ads.txt`. Plain text. One record per line. The format per record:

```
<exchange_domain>, <publisher_id>, <relationship>, <cert_authority_id>
```

- `exchange_domain`, e.g. `google.com`, `openx.com`, `indexexchange.com`
- `publisher_id`, your account ID with that exchange
- `relationship`, either `DIRECT` (you hold the account) or `RESELLER` (an authorized SSP sells on your behalf)
- `cert_authority_id`, optional TAG-ID for extra authentication

One app-specific sibling exists for mobile apps: **app-ads.txt**, referenced from each app's app-store listing. Same format.

## What the tool checks

Paste a domain. The tool fetches both files and reports:

**Presence checks.** Is `/ads.txt` there at all? Returning 200? Is `/app-ads.txt` served (only needed if you have published mobile apps)?

**Line-level validation.** Every record is parsed and checked:

- Does each record have at least 3 fields?
- Is the relationship token exactly `DIRECT` or `RESELLER` (case-insensitive, but nothing else is accepted)?
- Are there duplicate records (same exchange + pub ID + relationship)?
- Are there malformed lines that would cause an exchange to skip the entire block?
- Are comment lines (`# ...`) used correctly?

**Semantic flags.** Beyond the spec:

- Records with `RESELLER` but no corresponding `DIRECT`, a common sign someone added an SSP without ever linking it through the authorized seller chain.
- Exchange domains that no longer exist (consolidation in the SSP space means files often reference dead entities).
- Missing TAG-ID fields on exchanges that require them (Google's guidance, for one, now expects the 16-character TAG-ID on every Google record).

**AI fix prompt.** If issues are found, the tool generates a prompt you can paste into Claude or ChatGPT alongside your file. The model produces a corrected `ads.txt` with a change log.

## The two patterns that cause most "nobody's bidding" problems

**Pattern 1, stale records.** An SSP you worked with three years ago is still in the file. The SSP either shut down, merged, or your account got closed. DSPs that hit a dead record may downgrade the trust score of the whole file. Audit quarterly.

**Pattern 2, missing resellers.** Your primary SSP (say, Google AdX) resells your inventory through secondary partners. Every one of those partners needs a `RESELLER` line in your ads.txt with the right publisher ID. If AdX tells you "add these four lines," add all four. A partial list means only some of your inventory is auction-eligible.

## Where this sits in the stack

The ads.txt Audit tool is one of the technical-trust checks in the audit suite. Pair it with:

- [**.well-known Audit**](/tools/well-known-audit/), covers `security.txt`, `humans.txt`, `ai.txt`, `agent-card.json`, and other machine-readable identity files
- [**DNS / Email Auth Audit**](/tools/dns-email-audit/), SPF, DKIM, DMARC, CAA, MX records
- [**Security Headers**](/tools/security-headers-audit/), HSTS, CSP, X-Frame-Options

Together they cover the "does this domain look legit to every automated system that checks" surface. Ad exchanges, email providers, AI crawlers, and security scanners all read one or more of these files before granting trust. Publishers who run monetization-critical programmatic stacks should re-run the ads.txt audit monthly and after every SSP onboarding.

---

*This post is informational, not legal or financial advice. The IAB Tech Lab's ads.txt spec is the authoritative reference; when in doubt, consult [iabtechlab.com/ads-txt](https://iabtechlab.com/ads-txt/).*


---

Canonical HTML: https://jwatte.com/blog/blog-tool-ads-txt-audit/
RSS: https://jwatte.com/feed.xml
JSON Feed: https://jwatte.com/feed.json
Hero image: https://jwatte.com/images/blog-tool-ads-txt-audit.webp
