Audit ads.txt seller accounts after an ad partner change

Compare partner accounts with the public ads.txt file

An ads.txt file can load perfectly and still omit the account selling your ads. After changing ad providers, compare the publicly accessible file with the exact seller accounts your current partners use. Checking that the address opens is only half the job.

Ads.txt is a text file at your website’s root, usually yourdomain.com/ads.txt. It identifies the advertising systems and seller accounts you authorize. Google’s AdSense and Ad Manager products use account-specific entries; Google says publishers using multiple accounts need a separate entry for each. (Google ads.txt FAQ ↗)

A successful HTTP 200 response means the server delivered something successfully. It does not prove that the response contains the correct text. A cached copy, meaning an older response stored for faster delivery, can survive an otherwise successful provider change.

Example: replacing an ad provider

During a provider handover, start with the accounts each active partner says it uses for your publication. Compare that list with the public file, line by line. Here is a fictional entry, not a line to paste into your own file:

example-ad-system.example, 123, DIRECT

The first field names the advertising system; 123 identifies the seller account in that system. DIRECT describes a direct relationship with that system and an account the publisher controls. RESELLER identifies an account controlled by another authorized seller. The same number at a different advertising system is not the same account. Obtain the real entry from the partner rather than adapting this example.

Confirm the approved accounts and the file visitors receive

Save the approved account list and the public ads.txt response after the change. Retrieve it through the normal public address, including its cache, rather than inspecting only the file in your content-management system. Check that the response is plain text containing the approved entries.

Have the outgoing and incoming providers explain which accounts remain active during the transition. An unexplained old line needs investigation before removal: another active partner may still depend on it. A missing new account needs its exact approved entry, followed by another public-file check.

Keep a handover record that another person can check

Set up a change log with one row per seller account. Include the ad system, account identifier, relationship, partner who supplied it, and the date that partner confirmed it. Keep the previous public file and a copy of the new response. When sales change later, the two copies let you distinguish a file change from a partner that stopped bidding or a separate change to the page. An unexplained revenue change is a reason to inspect those records, not to restore every old line automatically.

An example of a staggered migration

Suppose the old provider stops placing new ads on Monday but is still reconciling Sunday’s delivery, and the new provider confirms its accounts on Tuesday. Ask each partner when its authorization is needed for live selling. Keep payment reconciliation separate from that answer: an unpaid balance does not by itself tell you whether the old seller still needs to be authorized. Record the exact answer for each account rather than using one date for the whole file.

Before making the switch, pick a page on which the new partner should actually sell. Verify the public file and then inspect a real request or the partner’s account status. If the new partner sees the record but is still missing from the auction, the next investigation is the page or integration. Re-editing the authorization file would address the wrong layer.