WPGEARED2.0.
Advertising Operations

How to Fix an ads.txt Warning in WordPress

Published Updated WPGeared
Share Report:

An ads.txt warning usually means an advertising platform cannot find the seller record it expects at your domain, or the record it found does not match your account. The fix is not to paste a publisher ID from a tutorial. The only safe source for the required line is your own advertising account or the ad network that authorized it.

Google describes ads.txt as a way for publishers to identify the systems authorized to sell their inventory. Its current AdSense ads.txt guide explains where to copy the account-specific record and notes that status changes may take time after publication.

Before changing the file

  1. Open the warning inside the provider account. Confirm the affected domain and copy the exact record shown there.
  2. Check the current public file. Visit https://example.com/ads.txt in a private browser window. Save its existing contents before replacing anything.
  3. Identify what currently owns the route. A WordPress ad plugin, a dedicated ads.txt plugin, the host, a CDN rule, or a physical file can all produce the same URL. Editing two layers creates confusing results.
  4. Take a current backup. A text-file change is small, but plugin or server changes should still have a rollback path.

Understand the record you are publishing

An AdSense record normally follows this shape:

google.com, pub-0000000000000000, DIRECT, f08c47fec0942fa0

The placeholder publisher ID above is not usable. Replace the entire example with the line copied from your own account. Other exchanges and supply-side platforms provide their own records, one per line. Do not delete valid records for active partners just because AdSense asks for an additional line.

Method 1: publish through the WordPress layer that already manages ads

This is usually the lowest-risk option when an existing ad-management plugin already exposes an ads.txt editor.

  1. Open that plugin's ads.txt or inventory settings.
  2. Paste the exact provider record on its own line.
  3. Save the setting and clear the WordPress page cache.
  4. Purge any host or CDN cache for /ads.txt.
  5. Open the public URL again and confirm the saved line appears exactly once.

If two plugins can manage ads.txt, choose one owner and disable the duplicate feature. A virtual WordPress response can also conflict with a physical file in the web root, so verify the public result rather than assuming the last editor you used controls it.

Method 2: publish a plain file at the domain root

Use this route when the host gives you file access and no WordPress feature already controls the endpoint.

  1. Create a UTF-8 plain-text file named exactly ads.txt.
  2. Add the account-specific record and any other currently authorized seller records.
  3. Upload the file to the document root that serves the domain, normally the same directory that contains wp-admin, wp-content, and wp-includes.
  4. Request https://example.com/ads.txt and confirm it returns the text file, not a WordPress 404 page, HTML template, login screen, or security challenge.

The important location is the public root URL, not simply a folder named after the domain in a hosting panel. Staging sites, add-on domains, reverse proxies, and headless frontends can point to a different document root.

Verification checklist

  • The final URL is the correct canonical domain and loads over HTTPS.
  • The response is publicly available without a cookie, login, geographic exception, or JavaScript challenge.
  • The publisher ID exactly matches the ID shown in the provider account.
  • The file contains plain records, not HTML generated by a theme or page builder.
  • A CDN or security product is not returning an older cached version.
  • The same seller record is not duplicated with conflicting relationship values.

After these checks, use the provider's recheck control if one is available. Google's guide says the AdSense status can take several days to update, and low-request sites can take longer. A delayed dashboard message does not by itself mean the public file is still wrong.

If the warning remains

Inspect the actual HTTP response before installing another plugin. A command-line check makes redirects and response headers visible:

curl -I https://example.com/ads.txt
curl https://example.com/ads.txt

Look for redirect loops, a non-success status, a cached body, or a firewall challenge. Also confirm whether the advertising account expects the root domain, a subdomain, or both. Google's ads.txt FAQ covers WordPress ownership, subdomain declarations, and record structure.

The durable fix is simple: one clear owner for the route, records copied from active provider accounts, a public response that can be crawled, and a written note showing where the file is maintained.