How to set up ads.txt for WordPress is mostly a matter of publishing the correct Authorized Digital Sellers records at one very specific public URL: https://example.com/ads.txt. The concept is simple, but WordPress, hosting configurations, redirects, physical files, plugins, CDNs and incorrect publisher IDs can turn a four-field text record into a surprisingly effective source of confusion.
An ads.txt file allows a publisher to publicly declare which advertising systems and seller accounts are authorized to sell its web advertising inventory.
For example, a Google AdSense publisher might be instructed to publish a record similar to:
google.com, pub-0000000000000000, DIRECT, f08c47fec0942fa0
The important part is not merely creating a text file with that name. The correct records must be published at the correct domain, remain publicly accessible to advertising crawlers and accurately represent the accounts authorized to sell your inventory.
This guide covers the complete WordPress setup, including how ads.txt works, where to obtain your records, physical and virtual implementation methods, AdSense configuration, multiple advertising networks, subdomains, redirects, HTTP status codes, robots.txt conflicts, caching, troubleshooting and ongoing maintenance.
What is ads.txt?
ads.txt stands for Authorized Digital Sellers.
It is an advertising-industry standard developed by IAB Tech Lab that allows publishers to declare which advertising systems are authorized to sell their digital advertising inventory.
The official IAB Tech Lab ads.txt documentation describes the standard as part of the broader supply-chain transparency system used to reduce unauthorized and counterfeit advertising inventory.
A publisher exposes the declaration through a predictable URL:
https://example.com/ads.txt
Advertising systems and buyers can retrieve that resource and compare the seller accounts declared by the publisher with information appearing in the advertising supply chain.
What problem does ads.txt solve?
Programmatic advertising involves multiple participants.
A simplified supply chain might look like:
Publisher
↓
Advertising platform
↓
Exchange / intermediary
↓
Buyer
↓
Advertiser
Without an independent declaration from the publisher, a buyer has less information for determining whether a particular seller is actually authorized to represent that inventory.
Ads.txt gives the publisher a public place to say:
These seller accounts are authorized
to sell advertising inventory for this domain.
Google’s official AdSense ads.txt guide describes the system as a way to give publishers more control over who may sell their inventory and help buyers identify counterfeit inventory.
Is ads.txt required for WordPress?
WordPress itself does not require ads.txt.
The requirement comes from your advertising relationships, not your content management system.
A WordPress website with no programmatic advertising may have no reason to publish an ads.txt file.
A WordPress publisher using AdSense, Google Ad Manager or another advertising platform participating in the Authorized Digital Sellers ecosystem may need or strongly benefit from one.
Google currently describes ads.txt as not mandatory for AdSense, but highly recommended. Always follow the current instructions supplied by the advertising platforms you actually use.
ads.txt is for web advertising inventory
One important distinction is that ads.txt primarily applies to website advertising inventory.
If you operate a mobile or connected TV application, you may instead need app-ads.txt.
The distinction is covered in detail in ads.txt vs app-ads.txt: What’s the Difference?.
A responsive WordPress site does not become app inventory merely because someone visits it from a smartphone:
WordPress website on desktop
→ web inventory
→ ads.txt
WordPress website in mobile browser
→ web inventory
→ ads.txt
native mobile application
→ app inventory
→ app-ads.txt
Where must ads.txt be located?
For a normal website, ads.txt needs to be publicly available from the relevant root domain:
https://example.com/ads.txt
Google’s AdSense setup documentation instructs publishers to upload the file to the root directory of the site.
These are not equivalent:
Correct:
https://example.com/ads.txt
Not the normal root location:
https://example.com/wp-content/uploads/ads.txt
https://example.com/files/ads.txt
https://example.com/advertising/ads.txt
https://example.com/ads/ads.txt
What does an ads.txt record look like?
A common Google record looks like:
google.com, pub-0000000000000000, DIRECT, f08c47fec0942fa0
Do not copy that example literally into your production site. The publisher ID shown above is a placeholder.
Your advertising platform should provide the exact record you need.
The four main fields in an ads.txt record
A seller declaration generally follows this structure:
advertising-system-domain,
publisher-account-id,
relationship,
certification-authority-id
Understanding these fields helps you recognize obvious mistakes before publishing them.
1. Advertising system domain
The first field identifies the advertising system.
For Google seller accounts:
google.com
This value should come from the advertising provider. Do not replace it with your own website domain.
2. Publisher account ID
The second field identifies your seller or publisher account within the advertising system.
For example:
pub-1234567890123456
Google’s ads.txt FAQ explains where AdSense and Google Ad Manager publishers can find their publisher IDs and specifies the expected pub- format.
3. DIRECT or RESELLER
The third field represents the seller relationship.
DIRECT
means the publisher directly controls the account identified in the advertising system.
A declaration containing:
RESELLER
represents a reseller relationship.
These values are not labels to choose according to preference. They describe actual commercial relationships.
4. Certification authority ID
The optional fourth field identifies a certification authority associated with the advertising system.
The commonly supplied Google record includes:
f08c47fec0942fa0
Again, use the value supplied by the platform rather than attempting to construct the record manually.
Where do you get your ads.txt records?
The safest source is the advertising platform itself.
Do not copy an ads.txt record from another website merely because that site uses the same ad network.
Account identifiers are often publisher-specific.
For AdSense, Google’s current workflow is documented in the official ads.txt guide.
In AdSense, the platform can provide the ads.txt snippet containing your own publisher ID.
Setting up ads.txt for Google AdSense
For an AdSense site, the workflow is conceptually:
AdSense account
↓
Sites
↓
select website
↓
ads.txt setup / warning
↓
copy provided record
↓
publish at /ads.txt
↓
verify public URL
↓
wait for AdSense to recrawl
Google currently provides an account-specific snippet similar to:
google.com, pub-0000000000000000, DIRECT, f08c47fec0942fa0
Your actual pub- value must match the publisher ID associated with your account.
Do not confuse the AdSense client ID with the ads.txt publisher ID format
Advertising code embedded in HTML may contain identifiers in a format such as:
ca-pub-1234567890123456
The ads.txt declaration uses the publisher identifier in the format supplied for ads.txt:
pub-1234567890123456
Google’s ads.txt FAQ explicitly notes that product-specific prefixes such as ca- should not be included in the seller declaration.
Method 1: create a physical ads.txt file
The traditional method is to create an actual plain-text file named:
ads.txt
and place it in the website’s document root.
A common WordPress installation might look like:
public_html/
├── ads.txt
├── index.php
├── wp-admin/
├── wp-content/
├── wp-includes/
└── wp-config.php
The exact directory name depends on your hosting environment.
It might be called:
public_html
htdocs
httpdocs
www
web
public
or something else entirely.
Creating the file
Use a plain-text editor and create:
ads.txt
Add the exact seller records supplied by your advertising partners:
google.com, pub-1234567890123456, DIRECT, f08c47fec0942fa0
Save the file as plain text.
Do not create:
ads.txt.html
ads.txt.rtf
ads.txt.docx
ads.txt.pdf
Human software remains impressively capable of turning four comma-separated values into a formatted document nobody asked for. Plain text avoids that problem.
Avoid rich-text editors
Google specifically recommends using a plain-text editor and warns that rich-text editors can introduce additional formatting data or invalid characters.
The company’s ads.txt crawling documentation recommends checking for formatting mistakes, unnecessary whitespace, extra commas and invalid UTF-8 characters.
Upload ads.txt to the WordPress root
You can upload the physical file through:
- your hosting control panel;
- SFTP;
- SSH;
- a deployment process;
- a suitable server-side file management tool.
If you already use TheOneWP for controlled filesystem operations, the File Manager is relevant when inspecting files within the WordPress environment.
Whichever method you use, the public result should be:
https://example.com/ads.txt
Method 2: serve ads.txt virtually through WordPress
A physical file is not the only option.
WordPress can also serve an ads.txt resource dynamically through a plugin or custom implementation.
Conceptually:
request:
GET /ads.txt
↓
WordPress routing
↓
plugin or custom handler
↓
plain-text response
This allows administrators to manage the seller declarations from the WordPress backend rather than modifying files on the server manually.
Using TheOneWP to manage ads.txt
TheOneWP Ads.txt & App-ads.txt Editor provides dedicated editors for both ads.txt and app-ads.txt.
The two resources remain separate because they represent different advertising inventory contexts.
The public endpoints are:
/ads.txt
/app-ads.txt
For the distinction between them, see ads.txt vs app-ads.txt: What’s the Difference?.
Physical files and virtual files can conflict
This is one of the most important WordPress-specific details.
Suppose you have:
/public_html/ads.txt
and also activate a plugin that attempts to generate:
https://example.com/ads.txt
virtually.
Depending on the web-server configuration, the physical file can be served before the request ever reaches WordPress.
The result is:
WordPress editor
→ new ads.txt content
public /ads.txt
→ old physical file
The administrator changes the file repeatedly, clears caches, stares suspiciously at the browser and achieves absolutely nothing because WordPress never receives the request.
Why the physical file usually wins
Many WordPress rewrite configurations effectively behave like this:
request arrives
↓
does requested physical file exist?
↓
YES → serve physical file
NO → pass request to WordPress
This same architecture affects other virtual root resources. The concept is explained in detail in WordPress’s Virtual robots.txt vs. a Physical File.
Do not run two ads.txt managers simultaneously
If your advertising plugin, monetization service and utility plugin can all generate ads.txt, choose one authoritative implementation.
A clean configuration should look like:
one public URL
+
one authoritative content source
+
one maintained seller list
not:
physical file
+
plugin A
+
plugin B
+
hosting feature
+
CDN rule
+
nobody remembers which one is live
How to verify that ads.txt is live
After publishing the file, open:
https://example.com/ads.txt
You should see the expected plain-text records.
Google explicitly recommends checking the public URL after publishing the file.
For a complete verification process, see How to Check if Your ads.txt File Is Being Served Correctly.
Do not stop at “I can see the file”
Seeing text in a browser proves only part of the implementation.
You should also verify:
- the correct hostname;
- the HTTP status;
- the final URL after redirects;
- the expected seller records;
- the correct publisher IDs;
- valid formatting;
- crawler accessibility;
- HTTP and HTTPS behavior;
- robots.txt rules;
- cache freshness.
Check the HTTP status code
A correctly served ads.txt resource should normally return:
HTTP/2 200
or the equivalent:
HTTP/1.1 200 OK
Google’s crawler troubleshooting documentation explicitly recommends ensuring that ads.txt returns HTTP 200 OK.
Test with curl
If you have terminal access, a simple request can reveal considerably more than the browser:
curl -I https://example.com/ads.txt
You might see:
HTTP/2 200
content-type: text/plain
cache-control: public, max-age=3600
To inspect the actual body:
curl https://example.com/ads.txt
Follow redirects during testing
To inspect the final response when redirects are involved:
curl -L https://example.com/ads.txt
And for headers:
curl -I -L https://example.com/ads.txt
This can reveal whether the resource is unexpectedly moving through:
http → https
non-www → www
www → non-www
maintenance page
login page
homepage
404 handler
HTTP and HTTPS both matter
Google’s ads.txt crawler attempts to retrieve ads.txt through both HTTP and HTTPS.
The official crawling guide recommends making the file reachable through both protocols, using appropriate redirects where necessary.
A normal modern configuration might be:
http://example.com/ads.txt
↓ 301
https://example.com/ads.txt
↓ 200
That is very different from:
http://example.com/ads.txt
↓ 404
www and non-www matter too
Suppose your canonical website is:
https://www.example.com/
but the root-domain request:
https://example.com/ads.txt
returns a 404.
Google’s crawling documentation explains that root-domain discovery needs to reach the correct ads.txt resource, including through redirects where appropriate.
A sensible configuration may therefore be:
https://example.com/ads.txt
↓
https://www.example.com/ads.txt
↓
200 OK
Check redirect rules carefully
WordPress sites often accumulate redirects through:
- hosting configuration;
.htaccess;- Nginx rules;
- Cloudflare;
- SEO plugins;
- redirect plugins;
- custom code.
The TheOneWP Redirect Manager can help centralize intentional WordPress redirects, but server- and CDN-level redirects must still be inspected separately.
Make sure robots.txt does not block ads.txt crawling
Ads.txt and robots.txt are different standards, but robots.txt can still affect whether crawlers are permitted to request the ads.txt URL.
Google specifically lists robots.txt blocking as something to check when troubleshooting ads.txt crawling.
For example, a poorly considered rule affecting the resource could interfere with discovery.
For the broader crawler configuration, see What Is robots.txt, and Why Does It Matter for SEO?.
ads.txt is not robots.txt
The names are similar because apparently the internet decided that several unrelated machine-readable root files should all end in .txt.
Their jobs are completely different:
robots.txt
→ crawler access instructions
ads.txt
→ authorized sellers for web advertising inventory
If you need to manage crawler rules from WordPress, that is the job of something such as the Robots.txt Editor, not the ads.txt editor.
ads.txt is not an XML sitemap
An XML sitemap has another purpose again:
ads.txt
→ advertising authorization
robots.txt
→ crawler instructions
XML sitemap
→ URL discovery for search engines
For that part of WordPress infrastructure, see What Is an XML Sitemap, and Why Does It Matter?.
What if you use multiple advertising networks?
An ads.txt file can contain multiple seller records.
For example:
google.com, pub-1234567890123456, DIRECT, f08c47fec0942fa0
example-exchange.com, 45821, DIRECT, abc123
another-network.example, 98374, RESELLER, def456
The actual values must come from the corresponding advertising partners.
Google’s AdSense guide explicitly notes that publishers using another ad network can add that network’s information to the same ads.txt file.
Do not overwrite existing seller records blindly
Suppose your existing file contains:
network-a.example, 1234, DIRECT
network-b.example, 5678, RESELLER
and AdSense gives you:
google.com, pub-1234567890123456, DIRECT, f08c47fec0942fa0
You generally add the new authorized seller declaration rather than replacing the entire file without understanding what the existing entries represent:
network-a.example, 1234, DIRECT
network-b.example, 5678, RESELLER
google.com, pub-1234567890123456, DIRECT, f08c47fec0942fa0
What if your ad management company gives you dozens of records?
Managed monetization providers may supply many DIRECT and RESELLER entries.
That is not automatically an error.
The important question is whether the provider has instructed you to authorize those relationships.
Do not remove records simply because you do not personally recognize every exchange name.
Conversely, do not retain abandoned records forever simply because nobody wants to touch the file.
Comments in ads.txt
The ads.txt specification supports comments, allowing publishers or tools to make a file easier to maintain.
However, operational files are usually easier to audit when unnecessary commentary is kept to a minimum and seller declarations remain easy to compare with provider documentation.
ads.txt 1.1 and OWNERDOMAIN
The ads.txt specification has evolved.
IAB Tech Lab’s current Authorized Digital Sellers documentation includes ads.txt 1.1, which introduced additional declarations designed to improve supply-chain transparency.
One is:
OWNERDOMAIN=example.com
This can identify the business domain that owns the advertising inventory.
Do not add newer directives merely because they exist. Implement them according to the current specification and the needs of your advertising setup.
MANAGERDOMAIN
Ads.txt 1.1 also introduced MANAGERDOMAIN, which can be used to identify a company exclusively managing monetization for the inventory under the conditions defined by the specification.
Again, this describes a real relationship. It should not be invented as decorative metadata.
Subdomains and ads.txt
Subdomains require additional attention.
Google’s ads.txt FAQ explains that ads.txt files on subdomains can be crawled when the relationship is referenced from the root domain using the appropriate subdomain= declaration.
For example, a root-domain ads.txt file may contain a declaration identifying a relevant subdomain.
If your monetization architecture relies on subdomains, follow the current ads.txt specification and your advertising platform’s guidance rather than assuming each hostname is discovered independently.
WordPress Multisite
WordPress Multisite deserves special attention because the logical sites in the network may not map cleanly to one filesystem root.
A network could use:
example.com
site-a.example.com
site-b.example.com
or:
example.com/site-a/
example.com/site-b/
Ads.txt is domain-oriented, not WordPress-site-ID-oriented.
Determine which domains actually represent monetized inventory and which public ads.txt resource advertising systems are expected to retrieve.
Do not assume a subdirectory site gets its own root ads.txt
If WordPress is installed at:
https://example.com/blog/
that does not automatically mean the relevant location becomes:
https://example.com/blog/ads.txt
The standard works from the applicable domain relationship. Confirm the correct root-domain implementation for your advertising setup.
CDN caching can make ads.txt appear stale
If a CDN caches:
/ads.txt
you may update the origin while the public request still returns the old version.
A troubleshooting sequence should therefore include:
edit ads.txt
↓
save
↓
purge relevant cache
↓
request public URL
↓
inspect returned content
Do not assume that clearing the WordPress page cache automatically purges a CDN cache for a root-level text resource.
Server caching can cause the same problem
Caching may occur at several layers:
browser
↓
CDN
↓
reverse proxy
↓
server cache
↓
WordPress cache
↓
application
If the public file is stale, identify which layer actually owns the cached response.
Check the Content-Type
A plain-text ads.txt response will commonly use a content type such as:
Content-Type: text/plain
The critical point is that the endpoint should return the actual ads.txt content rather than a normal HTML WordPress page.
If the response begins with:
<!doctype html>
<html>
you should investigate what WordPress or the server is actually returning.
Do not create a normal WordPress page called ads.txt
A page with the slug:
ads.txt
is not necessarily equivalent to an ads.txt endpoint.
A normal page template may include:
<html>
<head>
...
</head>
<body>
...
</body>
</html>
Ads.txt is a machine-readable text resource, not an article wearing a suspiciously technical slug.
Check for security rules blocking the file
Security tools, WAF rules and server configurations can block unusual paths or requests.
Test the public endpoint without assuming that a successful WordPress admin save means anonymous crawlers can retrieve it.
A public ads.txt resource should not require:
login
cookie consent
session authentication
HTTP Basic Auth
JavaScript execution
for ordinary crawler access.
Maintenance mode can interfere with ads.txt
If a staging or production site enters maintenance mode, verify whether root-level technical resources remain accessible.
A configuration that converts every request into:
503 Service Unavailable
may also affect ads.txt retrieval.
Temporary interruptions happen, but persistent blocking can prevent advertising systems from validating the file.
What if ads.txt returns 404?
A 404 Not Found means the requested resource is not being served from that URL.
Check:
- whether the file exists;
- whether the plugin generating it is active;
- whether rewrite rules are working;
- whether the hostname is correct;
- whether HTTP redirects correctly to HTTPS;
- whether www and non-www resolve consistently;
- whether a CDN is returning a cached error.
The full serving audit is covered in How to Check if Your ads.txt File Is Being Served Correctly.
What if ads.txt returns 403?
A 403 Forbidden indicates that the resource exists or the request reaches a handler, but access is being denied.
Possible causes include:
- filesystem permissions;
- web-server access rules;
- security plugins;
- WAF configuration;
- IP restrictions;
- authentication requirements.
Inspect the server and security layers rather than repeatedly editing the seller records.
What if ads.txt returns 500?
A 500 response indicates a server-side failure.
If ads.txt is generated virtually through WordPress, investigate:
- PHP errors;
- plugin conflicts;
- rewrite handlers;
- server logs;
- recent code changes.
If the physical file is supposed to be served directly, a 500 response suggests the request may be interacting with server rules rather than simply returning the static resource.
What if the browser shows the homepage?
If:
https://example.com/ads.txt
returns the homepage, a catch-all redirect or rewrite may be swallowing the request.
Inspect:
WordPress redirects
.htaccess
Nginx configuration
CDN redirects
404-to-home plugins
custom rewrite code
The Redirect Manager is useful for WordPress-managed redirects, while server and CDN rules must be checked at their respective layers.
What if the file is correct but AdSense still shows an error?
First, do not immediately rebuild everything.
Google states that ads.txt changes can take a few days to appear in AdSense and that sites making relatively few ad requests may take up to a month.
The current AdSense troubleshooting documentation recommends waiting for the crawler to process recent changes before assuming that the implementation failed.
Ask AdSense to check for updates
Google’s current ads.txt workflow includes an option to check for updates from the site’s ads.txt status inside AdSense.
This does not eliminate crawl and processing delays, but it gives you a platform-side way to request another status check after correcting the file.
Check that your publisher ID is present
One of the most common problems is simply that the correct publisher ID is missing.
For example, your public file may contain:
google.com, pub-1111111111111111, DIRECT, f08c47fec0942fa0
while your actual AdSense account uses:
pub-2222222222222222
The syntax is valid. The authorization is not the one your account needs.
Multiple Google accounts require separate records
Google’s ads.txt FAQ explains that if a publisher monetizes through multiple Ad Manager or AdSense accounts, the appropriate publisher IDs should be represented separately.
For example:
google.com, pub-1111111111111111, DIRECT, f08c47fec0942fa0
google.com, pub-2222222222222222, DIRECT, f08c47fec0942fa0
Only add accounts that actually participate in the site’s monetization.
Do not copy ads.txt from another domain
Consider two sites:
site-a.example
site-b.example
Even if both use AdSense, they may belong to different publisher accounts or monetization arrangements.
Copying the entire file from one site to another without reviewing the seller relationships can authorize the wrong accounts.
Do not blindly copy a competitor’s file
An ads.txt file is public, which makes it easy to inspect.
Public does not mean reusable.
Another publisher’s file describes that publisher’s advertising relationships, not yours.
Do not remove RESELLER records just because they look unfamiliar
A managed monetization provider may legitimately ask you to publish reseller relationships.
If you are unsure why a record exists, ask the provider before deleting it.
The correct cleanup process is:
identify record
↓
identify responsible provider
↓
confirm whether relationship remains active
↓
retain or remove accordingly
Remove obsolete records deliberately
The opposite problem is keeping every seller declaration forever.
If you stop working with a monetization provider, review the records it supplied.
An ads.txt file should represent current authorized seller relationships, not the archaeological history of every ad company the site has ever encountered.
Maintain a source for each record
For larger files, keep an internal record of why each seller line exists.
For example:
google.com, pub-123..., DIRECT, ...
Source: Google AdSense
network-a.example, 4455, RESELLER, ...
Source: Monetization Partner A
network-b.example, 8877, DIRECT, ...
Source: Direct contract with Network B
This makes future audits substantially safer.
Do not put secrets in ads.txt
The file is intentionally public.
Anyone can request:
https://example.com/ads.txt
Never place:
- passwords;
- API keys;
- private account credentials;
- internal notes containing secrets;
- authentication tokens.
Publisher identifiers intended by the advertising standard are public declarations, not authentication credentials.
Does ads.txt affect SEO?
Ads.txt is not an SEO ranking file.
Its primary purpose is advertising supply-chain transparency.
Do not confuse it with:
robots.txt, which communicates crawler-access rules, or XML sitemaps, which help search engines discover URLs.
All three can exist on the same WordPress site, but they solve unrelated problems.
Should ads.txt be included in an XML sitemap?
No normal SEO benefit comes from treating ads.txt as a webpage to be indexed through an XML sitemap.
An XML sitemap exists to communicate URLs relevant to search discovery.
The XML sitemap guide explains what those files are actually intended to contain.
Should ads.txt be indexed by Google Search?
Search indexing and ads.txt crawling are separate concerns.
The important requirement for advertising systems is that the appropriate crawler can retrieve and parse the resource according to the relevant ads.txt rules.
Do not optimize ads.txt as though it were a search landing page.
Back up the existing file before replacing it
If a production site already has ads.txt, preserve the current content before making substantial changes.
A simple backup might be:
ads.txt.backup-2026-09-21
stored somewhere that is not accidentally exposed as the authoritative public file.
The objective is to preserve a rollback point while keeping only one live /ads.txt resource.
Changing from a physical file to TheOneWP
If you want to move from a physical ads.txt file to TheOneWP Ads.txt & App-ads.txt Editor, use a controlled migration:
- copy the existing ads.txt content;
- identify every seller record and its source;
- paste the validated content into the TheOneWP ads.txt editor;
- save the configuration;
- remove or rename the conflicting physical
ads.txtfile; - clear relevant caches;
- request
/ads.txtpublicly; - compare the returned content with the expected seller list;
- verify the HTTP status;
- monitor the advertising platform’s status.
Changing from a virtual file to a physical file
The reverse migration should be equally deliberate:
export current content
↓
create physical ads.txt
↓
upload to document root
↓
disable virtual ads.txt handler
↓
clear caches
↓
verify public endpoint
The important principle is always the same: one authoritative implementation.
Check ads.txt after a hosting migration
Website migrations can silently change:
- document roots;
- rewrite behavior;
- HTTP-to-HTTPS redirects;
- www redirects;
- filesystem contents;
- CDN configuration;
- virtual endpoint behavior.
Ads.txt should therefore be included in the post-migration technical checklist.
Check ads.txt after changing domain
If a website moves from:
old-example.com
to:
new-example.com
do not assume the advertising platform automatically understands every aspect of the change.
Review the platform’s site configuration and make sure the relevant ads.txt resource exists on the domain that now represents the advertising inventory.
Check ads.txt after changing monetization providers
A monetization migration may change several seller records at once.
Before deleting the old configuration:
export current ads.txt
↓
obtain new provider records
↓
map records to providers
↓
confirm transition timing
↓
publish updated file
↓
verify endpoint
↓
monitor platform status
Check ads.txt after changing CDN or security services
A new CDN or WAF can change the behavior of a previously working endpoint.
After infrastructure changes, test:
https://example.com/ads.txt
http://example.com/ads.txt
https://www.example.com/ads.txt
http://www.example.com/ads.txt
where those hostname variations are relevant to your domain configuration.
Use the public response as the source of truth
The WordPress database may contain the right content.
The plugin editor may show the right content.
The physical file may contain the right content.
None of those observations proves that the internet receives the right content.
The definitive operational test is the public request:
GET https://example.com/ads.txt
This principle is why the verification steps in How to Check if Your ads.txt File Is Being Served Correctly matter after every implementation change.
Practical WordPress ads.txt setup workflow
- Confirm that your advertising platform uses ads.txt.
- Obtain the exact seller records from the platform.
- Identify your correct publisher account IDs.
- Audit whether
/ads.txtalready exists. - Determine whether the existing resource is physical or virtual.
- Back up any existing seller records.
- Choose one authoritative management method.
- If using a physical file, create a plain-text
ads.txt. - If using WordPress, configure Ads.txt & App-ads.txt Editor or another suitable implementation.
- Preserve legitimate existing seller records.
- Add the new authorized seller records.
- Verify DIRECT and RESELLER values.
- Verify publisher IDs.
- Publish the resource.
- Clear WordPress caches where relevant.
- Purge CDN or reverse-proxy caches where relevant.
- Open the public
/ads.txtURL. - Check the HTTP status.
- Check HTTP-to-HTTPS behavior.
- Check www and non-www behavior.
- Check robots.txt for crawler restrictions.
- Confirm that no physical file is overriding a virtual implementation.
- Compare the live seller list with your expected configuration.
- Wait for the advertising platform to recrawl the resource.
- Monitor the platform’s ads.txt status.
Common ads.txt mistakes in WordPress
- Creating
ads.txt.txtbecause the operating system hides extensions. - Uploading the file to
/wp-content/uploads/instead of the required root location. - Creating a normal WordPress page called ads.txt.
- Using a rich-text editor that inserts invalid formatting.
- Copying another publisher’s seller records.
- Using the wrong Google publisher ID.
- Keeping
ca-in a Google ads.txt publisher identifier when the supplied ads.txt record requirespub-. - Changing RESELLER to DIRECT without justification.
- Deleting legitimate reseller records.
- Keeping obsolete seller records indefinitely.
- Running multiple plugins that all attempt to manage ads.txt.
- Leaving an old physical file in place while configuring a virtual editor.
- Forgetting to purge CDN caches.
- Returning a 404, 403 or 500 response.
- Redirecting ads.txt to the homepage.
- Blocking the resource through robots.txt.
- Ignoring HTTP and HTTPS differences.
- Ignoring www and non-www behavior.
- Expecting AdSense to recognize a change immediately.
- Confusing ads.txt with app-ads.txt.
Final ads.txt audit checklist
/ads.txtexists at the correct domain.- The resource is publicly accessible.
- The final response is the expected plain-text seller list.
- The response returns HTTP 200 after valid redirects.
- HTTP and HTTPS resolve appropriately.
- www and non-www behavior is intentional.
- The correct publisher IDs are present.
- Every DIRECT declaration represents a direct relationship.
- Every RESELLER declaration represents a legitimate reseller relationship.
- Records supplied by active advertising partners are preserved.
- Obsolete relationships have been reviewed.
- No unrelated secrets are present.
- No WordPress page template wraps the file in HTML.
- No stale physical file overrides the intended virtual endpoint.
- No competing plugin controls the same URL.
- CDN caches contain the current version.
- robots.txt does not unintentionally block the relevant crawler.
- The advertising platform has been given time to recrawl the file.
- The ads.txt status is monitored after changes.
- The file is reviewed whenever monetization providers change.
Related guides
- ads.txt vs app-ads.txt: What’s the Difference?
- 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 provides separate WordPress editors for web and application Authorized Digital Sellers declarations, allowing the resources to be managed without manually maintaining root-level physical files.
File Manager can help administrators inspect files in the WordPress environment when determining whether a physical resource is present.
Robots.txt Editor manages crawler directives independently from advertising seller authorization.
Redirect Manager provides control over WordPress-managed redirects, useful when auditing unexpected routing around technical endpoints.
Final recommendation
Setting up ads.txt for WordPress correctly requires three things to agree:
correct seller records
+
correct public location
+
correct live HTTP response
Start by obtaining the seller records directly from AdSense, Ad Manager or your other advertising partners. Do not construct account identifiers from memory and do not copy another publisher’s file.
Then choose one implementation method. A physical ads.txt file is simple and independent of WordPress. A virtual implementation such as TheOneWP Ads.txt & App-ads.txt Editor makes the content easier to manage from the WordPress backend. Either approach can work, but competing implementations should not control the same endpoint.
Finally, verify the public result rather than trusting the configuration screen. Request /ads.txt, inspect the returned seller records, check the HTTP status, test redirects and confirm that advertising crawlers are not being blocked.
If the public endpoint is correct but AdSense has not updated immediately, allow time for recrawling. Google notes that ads.txt changes can take several days to appear and may take longer on sites with relatively few ad requests.
Once the file is working, treat it as part of the site’s advertising infrastructure. Review it whenever publisher accounts, monetization providers, domains, hosting, CDN configuration or WordPress ads.txt management change.

