Guides

app-ads.txt Best Practices for App Publishers

The complete best practices guide for app-ads.txt in 2025. From initial setup to ongoing maintenance, mediation coverage, and sellers.json verification.

B
BeamFlow Team
BeamFlow Team
February 9, 2026
8 min read
app-ads.txt Best Practices for App Publishers

Key Takeaways

  • Cover every network in your mediation stack. The most common app-ads.txt gap is missing entries for secondary ad networks. If a network serves ads in your app, it needs an entry. No exceptions.
  • Keep the file lean and accurate. Every entry should represent an active, revenue-generating relationship. Remove networks you're no longer using. Dead entries aren't harmless, they're maintenance liability.
  • Match your app store metadata perfectly. The developer URL in your app store listing must exactly match where app-ads.txt is hosted. A www mismatch or a wrong subdomain breaks the chain.
  • Cross-verify against sellers.json quarterly. Your entries can be syntactically correct and still fail verification if the ad network changed their sellers.json without telling you.
  • Update the same day you change mediation. Adding or removing an ad network from your waterfall should trigger an immediate app-ads.txt update. Make it part of the same workflow.

---

app-ads.txt Best Practices for App Publishers

If you've set up app-ads.txt, you're already ahead of 76% of app publishers. But setup is the beginning, not the end. The difference between "having app-ads.txt" and "having optimized app-ads.txt" is the difference between partial verification and maximum demand.

The practices in this guide come from patterns we've observed across thousands of app publishers: what the top-performing apps do differently, where common apps fall short, and what changes produce the biggest CPM improvements.

Practice 1: Cover Your Entire Mediation Stack

This is the single highest-impact practice. Every ad network that serves ads in your app needs an entry in your app-ads.txt file. Not just your primary network. All of them.

How to audit your coverage:

  1. Open your mediation dashboard (AdMob Mediation, AppLovin MAX, ironSource LevelPlay, etc.)
  2. List every active ad network in your waterfall or bidding configuration
  3. For each network, verify you have the corresponding entry in your app-ads.txt
  4. If any are missing, log into that network's dashboard and get their app-ads.txt entry

Common mediation networks to check:

  • Google AdMob
  • AppLovin
  • Unity Ads (including ironSource)
  • Meta Audience Network
  • InMobi
  • Chartboost
  • Vungle (Liftoff)
  • Pangle (TikTok)
  • Mintegral
  • AdColony (Digital Turbine)

Missing even one network means that network's bid requests fail verification. DSPs see it as unauthorized. The network shows poor performance in your mediation dashboard, but the problem isn't the network. It's the missing authorization.

Practice 2: Get Entries From Official Sources

Never construct app-ads.txt entries manually. Never copy from another developer's file. Never guess at account IDs.

The correct workflow for each network:

  1. Log into the network's publisher dashboard
  2. Navigate to the app-ads.txt or ads.txt section (most networks have a dedicated section)
  3. Copy the pre-formatted entry they provide
  4. Paste it into your file as-is

Pre-formatted entries eliminate the most common error: wrong account IDs. The network knows your publisher ID. They know their exchange domain. They know the correct TAG-ID. Let their system generate the entry.

If a network doesn't provide a pre-formatted entry in their dashboard, email your account manager and ask for it explicitly.

Practice 3: Verify Your App Store to File Chain

The verification chain has four links. Test each one:

Link 1: App store listing has a developer URL. Visit your app's public store page and verify the developer website link is visible and points to the right domain.

Link 2: Developer URL resolves correctly. Click the developer website link. Does it load your website? Or does it 404, redirect to the wrong place, or hit an error?

Link 3: app-ads.txt is accessible at the root. Append /app-ads.txt to the developer URL. Do you see the raw text content of your file?

Link 4: Content type is correct. Run curl -I https://your-developer-url.com/app-ads.txt and verify Content-Type: text/plain and HTTP 200.

Test this chain monthly. Any change to your website hosting, SSL certificate, or CDN configuration can break it.

Practice 4: One File for All Apps

If you publish multiple apps, they should all point to the same developer website URL in their app store listings. Your single app-ads.txt file on that domain covers all apps.

This simplifies maintenance dramatically. Instead of managing separate files for each app, you maintain one file that includes entries for every ad network used across your entire app portfolio.

The only exception: If you run different developer entities (different company names, different developer accounts) that point to different websites, each website needs its own file. But within a single developer entity, one file covers everything.

Practice 5: Label DIRECT and RESELLER Accurately

The relationship type isn't a judgment call. It's a factual claim about payment structure.

DIRECT: The ad network pays you directly. You have an account in your name. Revenue from that network shows up in your bank account from that network, not from an intermediary.

RESELLER: Revenue from that network comes to you through another entity. Common in mediation setups where the mediation platform holds the network accounts.

Why this matters for apps specifically: In app monetization, the DIRECT/RESELLER distinction can be nuanced. If you integrated the AppLovin SDK directly and AppLovin pays you directly, that's DIRECT. If AppLovin demand comes to your app only through the AdMob mediation adapter and AdMob handles the payment, some configurations treat that as RESELLER.

When in doubt, check with the ad network. Ask: "Does payment come directly from you to our company, or through our mediation partner?" The answer determines the label.

Practice 6: Keep the File Clean

Remove entries for ad networks you no longer use. A clean file with 10 accurate entries is better than a bloated file with 30 entries where 20 are stale.

Cleanup triggers:

  • You removed an ad network from your mediation waterfall
  • An ad network shut down or was acquired (verify new entries needed)
  • You switched mediation platforms (old platform's entries may no longer apply)
  • An ad network changed their exchange domain

Add comments for documentation:

text
# Direct SDK integrations - verified Feb 2025 google.com, pub-1234567890123456, DIRECT, f08c47fec0942fa0 applovin.com, abc123, DIRECT # Via AppLovin MAX mediation - updated Feb 2025 unity.com, 445566, RESELLER, aaa111bbb222 inmobi.com, 998877, RESELLER, 83e75a7ae333ca9d

Comments make quarterly reviews faster and help anyone who inherits the file understand what's there and why.

Practice 7: Cross-Verify Against sellers.json

Syntax validation only catches formatting errors. The real test is whether your entries match what each ad network reports in their sellers.json file.

For each DIRECT entry, verify:

  • The account ID exists in the network's sellers.json
  • The seller_type is "PUBLISHER" (not "INTERMEDIARY")
  • The domain field matches your developer website domain

For each RESELLER entry, verify:

  • The account ID exists in the network's sellers.json
  • The entry is associated with the correct intermediary

Run this cross-verification quarterly. Ad networks update their sellers.json without notifying publishers. An entry that verified perfectly in January might fail in March because the network reclassified your account.

BeamFlow's scanner automates this cross-verification, checking every entry against live sellers.json data.

Practice 8: Update With Every Mediation Change

The app-ads.txt update should be part of the same operational workflow as the mediation change. Not a separate task for "later." Not something you'll "get to next week."

Adding a new network to mediation:

  1. Configure the SDK and adapter
  2. Add the network's app-ads.txt entry
  3. Deploy the updated file
  4. Verify the entry is accessible

Removing a network from mediation:

  1. Disable the adapter in mediation
  2. Remove the network's app-ads.txt entry
  3. Deploy the updated file

Changing mediation platforms entirely:

  1. Map all network entries from the old platform to the new platform
  2. Add new entries, remove old ones
  3. Verify DIRECT/RESELLER labels are correct for the new platform configuration

If the mediation change and the app-ads.txt change don't happen together, one will be forgotten. Build the habit of treating them as inseparable.

Practice 9: Monitor for Hosting Issues

Your app-ads.txt can go from accessible to inaccessible without you knowing:

  • SSL certificate expires
  • Website hosting lapses
  • CDN configuration changes
  • A website redesign accidentally removes the file

Set up monitoring for the /app-ads.txt endpoint on your developer website. Even a basic uptime monitor that checks for HTTP 200 on that URL catches most hosting failures.

For more thorough monitoring, use a service that also checks content type, content accuracy, and sellers.json cross-verification.

Practice 10: Test After Every App Store Update

App store metadata changes can inadvertently affect your developer URL:

  • Updating your app's store listing might reset or change the developer URL
  • Migrating to a new developer account could require re-setting the URL
  • App store policy changes might affect how the URL is displayed

After submitting any app store update (new version, metadata change, screenshot update), verify that the developer URL still points to the correct domain and that your app-ads.txt file is still accessible through the chain.

Frequently Asked Questions

How often should I review my app-ads.txt?

Monthly at minimum. With every mediation change immediately. And a deeper cross-verification audit quarterly.

Should I include entries for ad networks I'm testing?

Yes. Even during a trial, the network needs authorization to sell your inventory. Without the entry, the trial runs on unverified demand, which skews performance data. Add the entry when the trial starts and remove it if you decide not to continue.

Do I need different entries for different app formats (banner vs. rewarded video)?

No. app-ads.txt is per-developer, not per-app or per-format. One file with entries for all your ad networks covers all formats across all apps.

What's the biggest mistake you see in app-ads.txt files?

Incomplete mediation coverage. Developers add their primary network (usually AdMob) and miss every other network in their waterfall. Those networks run unverified, showing artificially low performance that leads developers to make bad optimization decisions.

Can my mediation platform manage app-ads.txt for me?

Some platforms offer this feature or are developing it. If your mediation platform provides app-ads.txt management, use it but verify the output. Confirm that the generated file includes all networks, uses correct account IDs, and is accessible at the right URL.

Ready to optimize your ads.txt?

Check your domain's supply chain health instantly, free.

Check Your Domain Free