Key Takeaways

• Keep your ads.txt file lean and accurate. A clean file with 30 verified lines outperforms a bloated file with 300 questionable ones. DSPs evaluate file quality, not just individual entries.
• Cross-verify every entry against sellers.json. Syntax validation is table stakes. The real test is whether your entries match what SSPs report in their sellers.json files. 24% fail this check.
• Treat ads.txt as a living document, not a one-time setup. Monthly reviews with quarterly deep audits prevent the drift that silently erodes revenue over time.
• Label DIRECT and RESELLER correctly. SPO algorithms prefer direct supply paths. Mislabeling a direct relationship as RESELLER costs you premium demand.
• Monitor for unauthorized changes. Your ads.txt file is a public file on your server. Unauthorized modifications, whether from hacked accounts or rogue plugins, can redirect your revenue.

---

ads.txt Best Practices for Publishers in 2025

ads.txt has been around since 2017. Most publishers have one. But here's the thing: having an ads.txt file and having an optimized ads.txt file aren't the same thing at all. The ecosystem has evolved, and the practices that worked five years ago now leave money on the table.

DSPs have gotten way more sophisticated. Supply path optimization algorithms now evaluate the full authorization chain, not just whether a line exists. sellers.json cross-verification has become standard. And buyers increasingly filter out inventory from publishers with messy, bloated, or inaccurate files (which is honestly kind of wild when you see how many publishers still run bloated files).

This guide pulls together the practices that matter most today, based on current DSP behavior, IAB Tech Lab standards, and patterns we've observed across 120K+ publisher domains.

Practice 1: Keep Your File Lean

Bigger isn't better. A bloated ads.txt file signals that the publisher isn't actively managing their supply chain, and the IAB Tech Lab has explicitly warned that overly large files create problems for DSP crawlers and can result in incomplete parsing.

What lean looks like:

• 20-50 lines for most mid-size publishers
• Every line represents an active, revenue-generating relationship
• No duplicate entries with slight variations
• No entries from partners you stopped working with months ago

Signs your file is bloated:

• 100+ lines without a corresponding 100+ active SSP relationships
• Entries for SSPs you can't identify without research
• Multiple entries for the same SSP with different account IDs (and you don't know which is current)
• Lines added by a previous ad ops team that nobody has verified since

Audit your file and remove everything you can't confirm is active. If you're unsure about a line, check with the partner. If the partner doesn't respond or the relationship is dormant, remove it. You can always add it back.

Practice 2: Validate Against sellers.json, Not Just Syntax

Most publishers who validate their ads.txt check for syntax errors: correct format, commas in the right places, DIRECT/RESELLER in uppercase. This catches obvious mistakes but misses the deeper problem.

The real validation is cross-referencing each entry against the SSP's sellers.json file. This checks:

• Does the account ID exist in the SSP's sellers.json? If not, the SSP doesn't recognize that account. Your entry is pointing to nothing.
• Does the seller_type match your relationship claim? If your ads.txt says DIRECT but sellers.json shows that account as an INTERMEDIARY, the authorization chain breaks.
• Does the domain field match your domain? For DIRECT entries, the SSP's sellers.json should show your domain as the account holder. A domain mismatch means the DSP can't confirm you authorized the sale.

BeamFlow's cross-verification of 120K+ domains found that 24% of ads.txt entries fail sellers.json verification. These are entries that pass syntax checks but fail the test that actually matters to DSPs.

Run sellers.json cross-verification at least quarterly. Fix every mismatch. Pay special attention to DIRECT entries, where the verification is strictest.

Practice 3: Get Your Entries Directly From SSPs

Never construct ads.txt entries manually. Never copy them from another publisher's file. Never guess at account IDs based on what you see in reporting dashboards.

The correct workflow:

1. Log into the SSP's publisher portal. Navigate to the account settings or ads.txt section.
2. Copy the pre-formatted line they provide. Most major SSPs (Google, PubMatic, Index Exchange, Magnite) offer a ready-to-copy ads.txt snippet.
3. If no snippet exists, ask your account manager. Request the exact exchange domain, account ID, relationship type, and TAG-ID in ads.txt format.
4. Paste the entry as-is into your plain text editor. Don't modify it.

SSPs know their own exchange domains and TAG-IDs. They know your account ID. Let them tell you the correct entry. The most common ads.txt error, wrong account IDs, happens when publishers try to find the ID themselves and grab the wrong number from a dashboard.

Practice 4: Use Comments for Documentation

The ads.txt spec supports comments using the # character. Use them. Future-you (and your colleagues) will thank you.

text
# Direct SSP relationships - verified 2025-01-15
google.com, pub-1234567890123456, DIRECT, f08c47fec0942fa0
rubiconproject.com, 18020, DIRECT, 0bfd66d529a55807

# Header bidding via [Partner Name] - added 2024-11-01
appnexus.com, 3703, RESELLER, f5ab79cb980f11d1
openx.com, 537149485, RESELLER, 6a698e2ec38604c6

# Test partner - trial ends 2025-03-01
sovrn.com, 257611, RESELLER, fafdf38b16bf6b2b

Comments help with:

• Tracking when entries were added or last verified. Dates make quarterly audits faster.
• Identifying who owns RESELLER relationships. When a monetization partner provides RESELLER entries, note which partner provided them. If you switch partners, you know which lines to remove.
• Flagging temporary entries. Trial periods, test integrations, and seasonal partners can be tagged with expiration notes.

Practice 5: Label Relationship Types Accurately

DIRECT means you hold the account and receive payment from the SSP. RESELLER means an intermediary holds the account. The label isn't a judgment call. It's a factual claim that DSPs verify against sellers.json.

Why accuracy matters for SPO: DSPs running supply path optimization prefer shorter paths. A DIRECT entry means one hop from publisher to exchange. A RESELLER entry means at least two hops. When a DSP has both paths to the same inventory, it'll typically choose the DIRECT path, offering better CPMs for the publisher.

The expensive mistake: Labeling a DIRECT relationship as RESELLER tells DSPs that an intermediary exists. SPO algorithms deprioritize the path. You lose premium demand you should be getting. The reverse, labeling RESELLER as DIRECT, causes hard verification failures because the sellers.json check won't match.

For every entry, answer one question: "Does the payment come directly from this SSP to my company?" If yes, DIRECT. If payment goes through anyone else first, RESELLER. Always uppercase.

Practice 6: Maintain a Master Spreadsheet

Your ads.txt file is the output. Your master spreadsheet is the source of truth. Track:

| SSP | Exchange Domain | Account ID | Type | TAG-ID | Partner/Contact | Date Added | Last Verified |

|-----|----------------|------------|------|--------|----------------|------------|---------------|

| Google | google.com | pub-123... | DIRECT | f08c47... | Direct | 2024-06 | 2025-01 |

| AppNexus | appnexus.com | 3703 | RESELLER | f5ab79... | [Partner Name] | 2024-11 | 2025-01 |

This spreadsheet makes audits trivial. During quarterly reviews, go row by row: Is this relationship still active? Has the partner confirmed the account ID is current? When was it last verified against sellers.json?

The spreadsheet also provides an audit trail. If a line disappears from your ads.txt unexpectedly, the spreadsheet shows what should be there. If someone questions why a certain SSP is listed, the spreadsheet shows who requested it and when.

Practice 7: Monitor for Unauthorized Changes

Your ads.txt is a publicly writable file on your server (writable by anyone with server access). This makes it a target:

• Hacked hosting accounts can modify ads.txt to inject unauthorized seller lines, redirecting your revenue to fraudsters.
• Rogue plugins or scripts might overwrite or append to your ads.txt.
• Disgruntled employees or contractors with server access can modify the file.
• SSP-provided redirect solutions that auto-manage your file could introduce entries you didn't approve.

Monitoring practices:

• Set up file change alerts. Your hosting control panel, a monitoring service, or a simple cron job that diffs the file against a known-good version.
• Use version control (Git) for your ads.txt file. Every change is tracked with a timestamp and author.
• Review your file after any server maintenance, plugin updates, or CMS upgrades.
• If you use a redirect-based ads.txt management service, periodically verify that the generated file contains only entries you authorized.

Practice 8: Ensure File Accessibility

An ads.txt that exists but can't be crawled is useless. Regularly verify:

• HTTP 200 response. Not 301, not 403, not 404. A clean 200 at https://yourdomain.com/ads.txt.
• text/plain content type. Not text/html. Not application/octet-stream.
• No authentication barriers. No login walls, no CDN challenge pages, no CAPTCHA.
• Minimal redirects. One redirect (HTTP to HTTPS) is fine. Five redirects aren't.
• robots.txt allows access. Verify your robots.txt doesn't block the /ads.txt path.
• SSL certificate valid. An expired or misconfigured certificate prevents crawlers from fetching over HTTPS.

Check accessibility monthly. Test from outside your network (DSP crawlers come from external IPs). Use curl -I https://yourdomain.com/ads.txt to verify headers.

Practice 9: Coordinate ads.txt Updates With Ad Server Changes

The number one cause of missing entries: someone adds a new SSP to the ad server but nobody updates ads.txt. The number one cause of stale entries: someone removes an SSP from the ad server but nobody updates ads.txt.

Build ads.txt into your ad operations workflow:

• New partner onboarding: The ticket that configures the ad server adapter should include an ads.txt update step. The ticket doesn't close until both are done.
• Partner offboarding: Removing an SSP from the ad server triggers removal from ads.txt.
• Platform migrations: When switching ad servers, monetization platforms, or header bidding solutions, map every SSP change to corresponding ads.txt changes.

This sounds obvious. In practice, ad server changes and ads.txt changes are often handled by different people, on different timelines, sometimes in different departments. Bridging that gap prevents the most common ads.txt failures.

Practice 10: Use Automated Scanning Tools

Manual verification works for small files and low frequency. As your file grows or your update cadence increases, automation becomes essential.

What automated scanning provides:

• Syntax validation across every line
• sellers.json cross-verification against live SSP data
• Change detection when entries are added, removed, or modified
• Accessibility monitoring to ensure DSPs can always reach the file
• Mismatch alerts when SSPs update their sellers.json in ways that affect your entries

BeamFlow's scanner provides a free health score and line-by-line verification status. For publishers managing multiple domains or dozens of SSP relationships, continuous monitoring catches problems the day they appear rather than at the next quarterly review.

Frequently Asked Questions

How many ads.txt entries is too many?

There's no hard limit, but files with 100+ lines warrant scrutiny. If you genuinely have 100+ active SSP relationships, the file size is justified. If your file grew to 100+ lines through accumulation without cleanup, it's overdue for an audit. The IAB has flagged overly large files as a common problem.

Should I include entries for SSPs I'm testing?

Yes, add them immediately. Even during a trial, DSPs need to verify the SSP's authority to sell your inventory. Without the ads.txt entry, the trial partner's performance data will be unreliable because DSP-verified bids will be blocked. Just tag the entry with a comment noting the trial period.

Do I need ads.txt if I only use one ad network?

Yes. Even with a single partner, ads.txt protects you from domain spoofing. Without it, anyone could claim to sell your inventory. Some DSPs also require ads.txt verification as a baseline, meaning missing the file could reduce demand even from your single partner.

Can ads.txt help me get higher CPMs?

Indirectly, yes. A clean, fully verified ads.txt file gives buyers confidence. Buyers bid more aggressively on inventory they can fully verify. The CPM improvement comes from increased competition (more buyers willing to bid) rather than a direct price increase.

What is the relationship between ads.txt and app-ads.txt?

app-ads.txt serves the same purpose as ads.txt but for mobile app inventory. The format is identical. The difference is hosting: app-ads.txt is hosted on the app developer's website (specified in the app store listing), not on the domain where ads appear. If you publish both web content and mobile apps, you may need both files.