ads.txt vs app-ads.txt: What’s the Difference

ads.txt vs app-ads.txt is a comparison between two closely related standards that solve the same basic problem in different advertising environments. Both allow publishers to publicly declare which advertising systems and seller accounts are authorized to sell their inventory, but ads.txt primarily applies to web inventory while app-ads.txt extends the model to applications distributed through mobile, connected TV and other app ecosystems.

The distinction matters because publishing the right seller record in the wrong file does not automatically authorize the inventory you intended to cover.

At the simplest level:

Website advertising inventory
→ ads.txt

Mobile app advertising inventory
→ app-ads.txt

Connected TV app inventory
→ app-ads.txt

Website + application inventory
→ potentially both

The files can contain nearly identical seller records. What changes is the inventory being represented and, particularly for apps, how advertising systems discover the domain responsible for publishing the authorization file.

This guide explains how ads.txt and app-ads.txt differ, what their records mean, where each file belongs, how app-store discovery works, when a WordPress site might need one or both, and how to verify that the correct file is actually being served.

What is ads.txt?

ads.txt stands for Authorized Digital Sellers.

It is an IAB Tech Lab specification designed to increase transparency in programmatic advertising by allowing publishers to publicly identify the companies they authorize to sell their digital inventory.

The official IAB Tech Lab ads.txt documentation describes the standard as a mechanism for publishers and distributors to declare authorized sellers publicly, helping buyers distinguish legitimate seller relationships from counterfeit or misrepresented inventory.

For ordinary website inventory, the authorization file is normally exposed at a predictable root-level URL:

https://example.com/ads.txt

If you are implementing the file on WordPress rather than comparing the standards, start with How to Set Up ads.txt for WordPress.

What is app-ads.txt?

app-ads.txt is the application-focused extension of the Authorized Digital Sellers model.

IAB Tech Lab explains that app-ads.txt extends the original standard to applications distributed through mobile app stores, connected television app stores and other application distribution channels.

The official IAB Tech Lab Authorized Digital Sellers resource maintains documentation for both ads.txt and app-ads.txt as related supply-chain validation standards.

The basic purpose remains the same:

publisher declares authorized sellers
↓
buyers retrieve the declaration
↓
seller account is checked
↓
unauthorized or misrepresented inventory
can be identified more easily

The important difference is that an application does not naturally expose a website-style root URL from which buyers can simply request /ads.txt.

The short answer: ads.txt vs app-ads.txt

Characteristic	ads.txt	app-ads.txt
Primary purpose	Authorized sellers for web inventory	Authorized sellers for app inventory
Typical inventory	Desktop and mobile web	Mobile apps and CTV apps
Typical public path	/ads.txt	/app-ads.txt
Published on	Publisher domain	Developer website domain
Discovery starts from	Website domain	App listing and developer website relationship
Seller-record structure	Authorized Digital Sellers records	Closely related Authorized Digital Sellers records
Can be served from WordPress	Yes	Yes
Needed because a website is responsive	Web inventory can use ads.txt	No

Why was app-ads.txt created?

The original ads.txt model maps naturally to the web.

If inventory originates from:

example.com

a buyer can inspect:

example.com/ads.txt

The domain serving the inventory also provides the public authorization record.

Applications make this more complicated.

A mobile app might instead be identified by:

com.example.weather

or an app-store identifier.

Neither is a normal web hostname where a crawler can request:

/ads.txt

IAB Tech Lab therefore extended the model with app-ads.txt. Its app-ads.txt final release documentation explains that the standard was created to support mobile app, OTT and other application inventory.

How ads.txt discovery works

For normal website inventory, the relationship is comparatively direct:

publisher website
↓
publisher domain
↓
/ads.txt

If the website is:

https://example.com/

the relevant file can be:

https://example.com/ads.txt

Google’s AdSense ads.txt guide similarly instructs publishers to make the file available from the root directory of the site.

If you already configured the file but are unsure what WordPress, your CDN or the web server is actually returning, use How to Check if Your ads.txt File Is Being Served Correctly.

How app-ads.txt discovery works

Applications require an additional relationship.

A simplified discovery path is:

application
↓
app-store listing
↓
developer website
↓
developer domain
↓
/app-ads.txt

Google’s AdMob app-ads.txt setup documentation explains that the application must be registered in Google Play or Apple’s App Store and that its store details need to include a developer website so AdMob can determine the domain associated with the application.

The developer website is not a cosmetic field

For app-ads.txt, the developer website helps establish ownership and discovery.

Suppose an application listing identifies:

https://developer-example.com/

as its developer website.

The corresponding app-ads.txt resource can then be exposed as:

https://developer-example.com/app-ads.txt

Google’s app-ads.txt FAQ specifically states that the file should be hosted in the root directory of the developer website.

Do not put the complete app-ads.txt URL in the store listing

For AdMob, the app-store listing points to the developer website rather than directly to:

https://example.com/app-ads.txt

The advertising platform derives the expected app-ads.txt location from the developer website relationship.

This is a major conceptual difference from ordinary website inventory.

The two files can contain identical-looking records

A standard seller record may look like:

google.com, pub-0000000000000000, DIRECT, f08c47fec0942fa0

You could potentially encounter that exact line in:

/ads.txt

and:

/app-ads.txt

The syntax alone therefore does not tell you which type of inventory is being authorized.

The file location and inventory context matter.

Understanding an Authorized Digital Sellers record

A typical record contains several comma-separated fields:

advertising-system-domain,
publisher-account-id,
relationship,
certification-authority-id

For example:

google.com, pub-0000000000000000, DIRECT, f08c47fec0942fa0

The exact values should come from the advertising platform or monetization partner.

The IAB Tech Lab specification resources should be treated as the authoritative reference for the standard itself.

Field 1: advertising system domain

The first field identifies the advertising system.

For example:

google.com

This is not necessarily the domain where your ads are visually hosted. It identifies the advertising system participating in the seller declaration.

Field 2: publisher or seller account ID

The second field identifies the account within that advertising system:

pub-0000000000000000

Using the wrong ID can cause a technically valid file to authorize the wrong account.

Google’s AdSense documentation instructs publishers to copy the account-specific record supplied by AdSense rather than constructing it from memory.

Field 3: DIRECT or RESELLER

The third field describes the seller relationship.

DIRECT

indicates that the publisher directly controls the account identified in the advertising system.

A record using:

RESELLER

represents a different relationship in which another entity is authorized to sell the inventory through the specified account.

Do not change one into the other because one looks more desirable. The relationship should reflect the actual supply arrangement defined by the partner.

Field 4: certification authority ID

A fourth field can identify the certification authority associated with the advertising system.

For Google’s commonly supplied record, this appears as:

f08c47fec0942fa0

Again, use the record provided by the platform rather than reconstructing values manually.

ads.txt 1.1 adds additional transparency mechanisms

The standard has evolved beyond the original seller-line format.

IAB Tech Lab’s current ads.txt resources document ads.txt 1.1 and its additional mechanisms such as OWNERDOMAIN and MANAGERDOMAIN, designed to provide more transparency around ownership and inventory-management relationships.

This is another reason not to treat a years-old ads.txt tutorial as the permanent specification. Ad-tech standards, apparently unconvinced that four comma-separated fields were enough excitement, continue to evolve.

What does DIRECT mean in practice?

Suppose your website has its own advertising account and the platform supplies:

ad-system.example, 123456, DIRECT

The declaration tells buyers that the publisher has a direct relationship with that seller account.

The same conceptual relationship can appear in ads.txt or app-ads.txt depending on the inventory being authorized.

What does RESELLER mean in practice?

A monetization partner may supply additional records representing reseller relationships:

another-system.example, 78910, RESELLER

These entries should not be removed simply because you do not recognize the account identifier.

Publishers using managed advertising services may legitimately receive multiple reseller records from their monetization partner.

Never invent seller records

If a partner provides:

example-exchange.com, 84722, RESELLER, abc123

do not change it to:

example-exchange.com, YOUR-DOMAIN, DIRECT

because that format feels more intuitive.

Seller records represent actual advertising relationships, not descriptive labels.

Do I need ads.txt for a WordPress website?

If your WordPress site sells or monetizes web advertising inventory through platforms that participate in the ads.txt ecosystem, ads.txt is the relevant resource.

Google describes ads.txt as highly recommended for AdSense publishers because it helps buyers identify authorized inventory and helps publishers control who may represent their inventory.

The practical WordPress implementation is covered in How to Set Up ads.txt for WordPress.

Do I need app-ads.txt because my WordPress site gets mobile traffic?

No.

A responsive website viewed from a phone remains web inventory.

For example:

WordPress page viewed in Chrome on Android
→ web inventory

WordPress page viewed in Safari on iPhone
→ web inventory

native Android application
→ app inventory

native iOS application
→ app inventory

App-ads.txt does not mean “ads viewed on mobile.”

It refers to advertising inventory associated with applications.

Desktop web and mobile web both belong to the web side

IAB Tech Lab’s app-ads.txt publisher guidance distinguishes the app ecosystem from the desktop and mobile web inventory addressed by ads.txt.

The official IAB Tech Lab app-ads.txt publisher advisory explains that app-ads.txt extends Authorized Digital Sellers into the application ecosystem.

Do I need app-ads.txt for a mobile application?

If the application contains advertising inventory sold through participating advertising platforms, app-ads.txt is the relevant authorization mechanism.

For Google AdMob, Google states that app-ads.txt allows developers to declare which ad sources are authorized to sell their app inventory.

See Google’s official explanation of app-ads.txt for the AdMob-specific implementation.

What about connected TV applications?

App-ads.txt is not limited to smartphones.

IAB Tech Lab explicitly describes the specification as supporting applications distributed through connected television app stores and other application distribution channels.

That means:

website
→ ads.txt

mobile application
→ app-ads.txt

CTV application
→ app-ads.txt

What about a Progressive Web App?

A Progressive Web App can look and behave like an installed application from the user’s perspective, but that alone does not determine which Authorized Digital Sellers mechanism applies.

If the inventory is ordinary web inventory served from your website, ads.txt remains the relevant mechanism.

If you distribute and monetize inventory through an application ecosystem where a platform requires app-ads.txt, follow that platform’s requirements.

Do not create app-ads.txt merely because WordPress has been configured as a PWA.

Can the same domain serve both files?

Yes.

A domain can expose:

https://example.com/ads.txt
https://example.com/app-ads.txt

This can make perfect sense when the company operates both web properties and monetized applications.

TheOneWP Ads.txt & App-ads.txt Editor handles the two resources independently for exactly this reason.

The files are independent resources

Publishing:

/ads.txt

does not automatically publish:

/app-ads.txt

and a seller declared in one should not be assumed to be declared in the other.

The inventory and business relationships may overlap, but the files remain distinct.

Can ads.txt and app-ads.txt contain the same entries?

Yes.

If the same seller relationship is valid for both web and application inventory, the files may contain identical lines.

For example:

/ads.txt

google.com, pub-0000000000000000, DIRECT, f08c47fec0942fa0

and:

/app-ads.txt

google.com, pub-0000000000000000, DIRECT, f08c47fec0942fa0

may both be appropriate if the platform specifically instructs you to publish those declarations.

But do not simply copy one file into the other

Your web monetization relationships could be:

Network A
Network B
Network C

while your app relationships could be:

Network A
Network D
Network E

Automatically synchronizing the files could therefore create inaccurate authorization records.

Where does ads.txt belong?

The expected public location is normally the relevant site’s root:

https://example.com/ads.txt

Not:

https://example.com/wp-content/uploads/ads.txt
https://example.com/files/ads.txt
https://example.com/advertising/ads.txt

The IAB specification defines the standardized access method, while Google’s AdSense implementation guide likewise instructs publishers to place the resource in the root directory.

Where does app-ads.txt belong?

If an app-store listing identifies:

https://example.com/

as the developer website, the expected app-ads.txt resource is typically:

https://example.com/app-ads.txt

Google documents this directly in both its app-ads.txt setup guide and app-ads.txt FAQ.

What if the app has no developer website?

For AdMob, that is a problem because the developer website provides the relationship needed to discover the file.

Google instructs developers without a suitable website to create one before implementing app-ads.txt and also documents alternative hosting options such as Firebase Hosting.

The important part is not WordPress specifically.

It is having a valid developer domain that the app-store listing exposes and from which the file can be retrieved.

Can WordPress be the developer website?

Absolutely.

Suppose your company website runs WordPress:

https://example.com/

and your Google Play or Apple App Store listing identifies that domain as the developer website.

The same WordPress domain can serve:

https://example.com/app-ads.txt

WordPress core does not provide a dedicated app-ads.txt editor, so you need either a physical file or a mechanism capable of serving that resource correctly.

Physical ads.txt files

The conventional approach is to place an actual file in the site’s document root.

Conceptually:

public_html/
├── index.php
├── wp-admin/
├── wp-content/
├── wp-includes/
└── ads.txt

The web server sees the physical file and returns it directly.

Virtual ads.txt files

A WordPress plugin can instead intercept:

/ads.txt

and return dynamically stored content as plain text.

The public URL remains the same:

https://example.com/ads.txt

This concept is similar to other virtual resources generated through WordPress. For a detailed explanation of physical-file precedence versus application-generated output, see WordPress’s Virtual robots.txt vs. a Physical File.

Why physical-file precedence matters

Typical WordPress server configurations route requests through WordPress only when a matching physical resource does not already exist.

Conceptually:

request /ads.txt
↓
does physical ads.txt exist?
↓
YES
↓
web server serves it
↓
WordPress virtual handler never runs

This can produce a particularly confusing failure mode.

You can edit one file while visitors receive another

Imagine a plugin reports:

ads.txt saved successfully

but:

https://example.com/ads.txt

still shows an old seller list.

The editor may be working perfectly while an old physical file takes precedence.

The same architectural issue is covered in WordPress’s Virtual robots.txt vs. a Physical File, because the underlying web-server behavior is closely related.

How TheOneWP handles ads.txt and app-ads.txt

Ads.txt & App-ads.txt Editor provides separate editors for the two resources inside WordPress.

The module serves:

/ads.txt
/app-ads.txt

virtually through dedicated rewrite rules rather than requiring administrators to maintain physical files manually.

The content is stored separately

The module treats the resources independently:

ads.txt content
→ dedicated WordPress option
→ /ads.txt

app-ads.txt content
→ dedicated WordPress option
→ /app-ads.txt

This prevents the assumption that web and application seller relationships must always be identical.

Physical-file conflicts are detected

If an actual ads.txt or app-ads.txt file already exists in the WordPress root, the module detects it and prevents the virtual editor from pretending to control a URL that the server is actually handling itself.

That distinction between physical and generated resources is also why understanding What Is robots.txt, and Why Does It Matter for SEO? can be useful when working with WordPress-level virtual files.

ads.txt is not robots.txt

Both are root-level text resources, but they communicate with completely different systems.

robots.txt
→ crawler access instructions

ads.txt
→ authorized sellers for web advertising

app-ads.txt
→ authorized sellers for app advertising

The Robots Exclusion Protocol itself is unrelated to Authorized Digital Sellers.

For WordPress crawler configuration, see What Is robots.txt, and Why Does It Matter for SEO? and the TheOneWP Robots.txt Editor.

ads.txt is not an XML sitemap either

An XML sitemap serves another completely separate purpose:

XML sitemap
→ helps search engines discover URLs

robots.txt
→ communicates crawler access rules

ads.txt
→ declares authorized web ad sellers

app-ads.txt
→ declares authorized app ad sellers

For the sitemap side of WordPress discoverability, see What Is an XML Sitemap, and Why Does It Matter? and the TheOneWP XML Sitemap module.

Why the distinction between these root files matters

A WordPress installation can expose several machine-readable resources:

/robots.txt
/ads.txt
/app-ads.txt
/wp-sitemap.xml
/sitemap_index.xml
...

They may all look like technical files intended for automated clients, but each belongs to a different protocol and has different semantics.

Never paste directives from one format into another simply because they all happen to live near the domain root.

ads.txt and HTTP redirects

Redirect behavior matters because crawlers need to reach the intended resource.

If:

https://example.com/ads.txt

unexpectedly redirects to:

/login/
/homepage/
/404/
/maintenance/

your public configuration may not be usable as intended.

When debugging WordPress URL behavior generally, the TheOneWP Redirect Manager can help keep deliberate redirects separate from accidental routing behavior.

Check the final response, not only the WordPress setting

A configuration panel tells you what WordPress believes it has saved.

The public HTTP response tells you what advertising crawlers can actually retrieve.

Those are not always the same thing.

After every important change, verify the live resource as described in How to Check if Your ads.txt File Is Being Served Correctly.

What should you verify?

At minimum, check:

• the expected URL exists;
• the response is not an HTML error page;
• the expected seller records appear;
• the publisher ID is correct;
• DIRECT and RESELLER values match partner instructions;
• there is no unexpected authentication requirement;
• there is no stale physical file;
• redirects are not sending the crawler somewhere unrelated.

A browser test is useful but not the whole audit

Opening:

https://example.com/ads.txt

in a browser is a useful first test.

Google’s AdSense documentation specifically recommends checking the public URL after publishing the file.

But a visible response does not prove that every seller record is correct.

Check seller IDs separately

Suppose the file contains:

google.com, pub-1111111111111111, DIRECT, f08c47fec0942fa0

but your actual account requires:

google.com, pub-2222222222222222, DIRECT, f08c47fec0942fa0

The URL can return HTTP 200 and still contain the wrong authorization.

Delivery validation and business-data validation are separate tasks.

Ad platforms may not reflect changes immediately

Publishing a correct file does not mean the platform dashboard will update the same second.

Google’s AdSense ads.txt guide notes that status changes can take time to propagate after the file is updated.

Similarly, app-ads.txt must be crawled and verified by the relevant advertising system.

Troubleshooting ads.txt

Google maintains a dedicated ads.txt troubleshooting guide covering common issues such as missing files, missing publisher IDs and situations where AdSense has not yet recognized a published file.

For WordPress-specific serving problems, combine that platform guidance with TheOneWP’s ads.txt serving checklist.

Troubleshooting app-ads.txt

App-ads.txt adds another failure layer because the application-to-domain relationship also has to work.

Google’s AdMob app-ads.txt troubleshooting documentation covers problems including incorrect publisher IDs, malformed entries, incorrect domains and discovery problems.

A correct app-ads.txt file can still fail discovery

Imagine:

https://example.com/app-ads.txt
→ correct

app-store developer website
→ another-example.com

The file itself may be perfectly formatted, but the advertising system may be looking at a different developer domain.

For apps, therefore, verify both:

file correctness
+
store-to-developer-domain relationship

ads.txt and sellers.json are related but different

The Authorized Digital Sellers ecosystem includes other supply-chain transparency mechanisms.

sellers.json is one important example.

IAB Tech Lab’s sellers.json documentation explains that sellers.json enables buyers to discover the identities of entities that are direct sellers or intermediaries in the sale of digital advertising.

A simplified distinction is:

ads.txt / app-ads.txt

Publisher side:
"These seller accounts are authorized
to sell my inventory."


sellers.json

Advertising-system side:
"These are the entities represented
by seller accounts in my system."

Supply-chain validation works across multiple signals

Ads.txt is useful precisely because it does not have to carry every piece of supply-chain identity information itself.

IAB Tech Lab’s Transparency Center includes supply-chain datasets and validation resources involving ads.txt, app-ads.txt and sellers.json.

Does ads.txt prevent all advertising fraud?

No.

It addresses a specific problem: publicly declaring authorized seller relationships.

It does not replace:

• advertising-platform security;
• seller identity mechanisms;
• bid-request supply-chain information;
• publisher account security;
• fraud-detection systems;
• contractual controls.

It should be treated as one component of supply-chain transparency.

Is ads.txt mandatory?

The answer depends on what “mandatory” means in your environment.

The IAB standard is not a universal requirement for every website on the internet.

Google currently describes ads.txt as not mandatory for AdSense but highly recommended because it gives publishers greater control over authorized sellers and can help buyers identify counterfeit inventory.

Always follow the current requirements of the monetization platforms you actually use.

Is app-ads.txt mandatory?

Requirements depend on the advertising platform and application ecosystem.

For AdMob, Google’s current documentation strongly directs app publishers to implement app-ads.txt and warns that failure to do so can affect advertising revenue.

Check the current requirements of each monetization provider rather than assuming that one platform’s policy applies universally.

Example 1: WordPress publisher with AdSense

Suppose:

example-news.com
→ WordPress website
→ display advertising
→ no mobile application

The relevant file is:

https://example-news.com/ads.txt

The publisher can follow How to Set Up ads.txt for WordPress and then verify the live response with How to Check if Your ads.txt File Is Being Served Correctly.

Example 2: mobile app developer using AdMob

Suppose:

Example Weather
→ Android application
→ iOS application
→ AdMob monetization

developer website:
https://exampleweather.com/

The relevant application resource is:

https://exampleweather.com/app-ads.txt

The developer should also verify that the correct website is exposed through the applicable app-store listing according to Google’s app-ads.txt setup instructions.

Example 3: website plus mobile application

Suppose a publisher operates:

example.com
→ monetized WordPress news website

Example News
→ monetized Android and iOS apps

The domain may legitimately expose both:

https://example.com/ads.txt
https://example.com/app-ads.txt

The two resources should be maintained independently according to the seller relationships for each inventory type.

Example 4: WordPress developer website with no web advertising

Suppose:

examplegames.com
→ WordPress company website
→ no display advertising

Example Racing
→ monetized mobile game

The site may need:

/app-ads.txt

without needing:

/ads.txt

The CMS does not determine the requirement. The advertising inventory does.

Example 5: responsive WordPress site only

Suppose a WordPress magazine receives 80% of its traffic from smartphones but has no native app.

That does not create an app-ads.txt requirement by itself.

The inventory remains web inventory, even when rendered on a mobile screen.

Example 6: CTV application

Suppose a publisher operates an advertising-supported connected TV application.

IAB Tech Lab explicitly includes connected TV application distribution in the app-ads.txt model.

The appropriate authorization mechanism therefore belongs on the application side of the distinction rather than ordinary website ads.txt.

Common mistake: using ads.txt for app inventory

Publishing all app seller records only in:

/ads.txt

does not automatically provide the app-ads.txt resource used for application inventory discovery.

Common mistake: assuming app-ads.txt replaces ads.txt

It does not.

App-ads.txt extends the model to apps rather than superseding the web standard.

Common mistake: creating app-ads.txt because the site is mobile-friendly

Responsive design is irrelevant to this distinction.

A mobile browser still consumes web inventory.

Common mistake: putting the file in WordPress uploads

This:

/wp-content/uploads/2026/09/ads.txt

is not equivalent to:

/ads.txt

For a standard WordPress setup, use the correct root-level resource as described in the complete ads.txt setup guide.

Common mistake: publishing a WordPress page named ads.txt

A normal WordPress page can render:

<html>
<head>...</head>
<body>
    seller records
</body>
</html>

That is not the same implementation as serving the expected text resource.

Use a real or correctly generated text endpoint.

Common mistake: leaving an old physical file in place

If you switch to a virtual editor but leave:

/public_html/ads.txt

on disk, the physical file may continue winning before WordPress receives the request.

This is the same architectural principle explained in WordPress’s Virtual robots.txt vs. a Physical File.

Common mistake: copying ads.txt into app-ads.txt automatically

The files can share records, but they represent different inventory contexts.

Synchronize only the records that actually apply to both.

Common mistake: using the wrong publisher ID

A correctly formatted line with the wrong account identifier is still wrong.

Copy account-specific values from your advertising provider.

Common mistake: guessing DIRECT or RESELLER

These values describe real seller relationships.

They are not preferences or quality labels.

Common mistake: ignoring app-store configuration

For app-ads.txt, publishing the file is only part of the process.

The developer website relationship must also allow the advertising platform to discover the correct domain.

Common mistake: expecting immediate verification

Advertising platforms crawl these files periodically.

Your public file may be correct before the provider dashboard reflects the change.

Common mistake: treating ads.txt as access control

Ads.txt does not technically prevent someone from requesting a page or displaying content.

It is a public authorization declaration consumed by participating advertising systems.

This distinction resembles another common misunderstanding around crawler directives: robots.txt is also a public protocol, not an authentication layer.

A practical ads.txt vs app-ads.txt workflow

1. Identify whether you monetize website inventory, application inventory or both.
2. List every advertising and monetization partner involved.
3. Obtain the official seller records from those partners.
4. Separate web seller relationships from app seller relationships.
5. Use ads.txt for the applicable web inventory.
6. Use app-ads.txt for the applicable application inventory.
7. For apps, verify the developer website shown by the store listing.
8. Publish each file at the correct public location.
9. Check for conflicting physical files if WordPress serves the resource virtually.
10. Open the public URL and inspect the response.
11. Compare seller IDs with the values supplied by each platform.
12. Verify DIRECT and RESELLER relationships.
13. Check for unexpected redirects or authentication.
14. Wait for the advertising platform to recrawl the resource.
15. Review the files whenever your monetization relationships change.

Which file do you need?

Situation	ads.txt	app-ads.txt
WordPress blog with programmatic ads	Relevant	Usually not relevant
Responsive website	Relevant for web inventory	Not because the site is mobile-friendly
Android application	Not for app inventory	Relevant
iOS application	Not for app inventory	Relevant
Connected TV application	Not for app inventory	Relevant
Website and monetized mobile app	Potentially relevant	Potentially relevant
Developer website without web ads	Potentially unnecessary	May still be required for the app
No programmatic advertising	Potentially unnecessary	Potentially unnecessary

Final checklist

• Use ads.txt for applicable web advertising inventory.
• Use app-ads.txt for applicable mobile and connected TV app inventory.
• Do not interpret mobile web traffic as app inventory.
• Do not assume one file automatically covers the other.
• Use seller records supplied by your advertising partners.
• Do not invent publisher IDs.
• Do not guess DIRECT or RESELLER relationships.
• Publish files at the expected root-level location.
• For app-ads.txt, verify the developer website relationship in the app store.
• Keep web and application seller records independently maintainable.
• Check for physical-file conflicts when using WordPress-generated resources.
• Verify the actual public HTTP response after making changes.
• Check platform dashboards after crawlers have had time to revisit the file.
• Remove obsolete records only after confirming that the seller relationship has ended.
• Review both files whenever monetization providers change.

Related guides

• How to Set Up ads.txt for WordPress
• How to Check if Your ads.txt File Is Being Served Correctly
• WordPress’s Virtual robots.txt vs. a Physical File
• What Is robots.txt, and Why Does It Matter for SEO?
• What Is an XML Sitemap, and Why Does It Matter?

Related TheOneWP features

Ads.txt & App-ads.txt Editor manages both advertising authorization resources from WordPress while keeping their content separate and detecting physical-file conflicts.

Robots.txt Editor manages another root-level machine-readable resource, this time for crawler instructions rather than advertising authorization.

XML Sitemap manages machine-readable URL discovery for search engines, illustrating why root-level technical resources need to be treated according to their own protocols rather than as interchangeable text files.

Redirect Manager can help administrators manage intentional URL redirects separately from unexpected routing behavior that may interfere with technical endpoints.

Final answer: ads.txt vs app-ads.txt

The essential difference between ads.txt vs app-ads.txt is the inventory they authorize:

ads.txt
= authorized sellers for website inventory

app-ads.txt
= authorized sellers for application inventory

The two standards share the same broader goal: allowing publishers to publicly declare which seller accounts are authorized to represent their advertising inventory.

The seller records can even look identical.

What changes is the context.

With web inventory, the publisher domain provides the natural location for /ads.txt.

With app inventory, the ecosystem needs to establish a relationship between the application, its store listing and the developer website before retrieving /app-ads.txt.

A WordPress publisher with only a monetized website will therefore usually care about ads.txt. A developer with a monetized mobile or connected TV application will care about app-ads.txt. A company operating both types of inventory may legitimately need both.

And regardless of which file you use, the final test is not whether the WordPress editor says “saved.” It is whether the correct public URL returns the correct seller declarations to the systems that need them.