Inventory management

Declare who is authorized to sell your inventory with ads.txt

Authorized Digital Sellers, or ads.txt is an IAB initiative that helps ensure that your digital ad inventory is only sold through sellers (such as AdSense) who you've identified as authorized. Creating your own ads.txt file gives you more control over who's allowed to sell ads on your site and helps prevent counterfeit inventory from being presented to advertisers.

You don't have to use ads.txt, but we recommend that you do. An ads.txt file can help buyers identify counterfeit inventory and help you receive more advertiser spend that might have otherwise gone toward that counterfeit inventory.

Create your own ads.txt file for AdSense

Here's how to create an ads.txt file to publicly declare that Google is authorized to sell your ad inventory:

Create a text (.txt) file.

Include the following line:

google.com, pub-0000000000000000, DIRECT, f08c47fec0942fa0

Important: Make sure you replace pub-0000000000000000 with your own publisher ID.

Here, "root domain" is defined as one level down from the public suffix list, which is how it's defined in the IAB ads.txt specification. For example, "google.co.uk" would be considered a root domain as "co.uk" is on the public suffix list but "maps.google.co.uk" would not be considered a root domain.

These steps describe how to create an ads.txt file for Google AdSense publishers. For other SSPs/exchanges, visit their respective documentation on creating an ads.txt file or contact them.

What information goes in an ads.txt file?

Include a separate line in the file for each authorized seller. Each line in a publisher’s ads.txt list requires three pieces of data (plus a fourth optional field):

<Field #1>, <Field #2>, <Field #3>, <Field #4>

<Field #1>: The domain name of the advertising system (required).

The canonical domain name of the SSP, exchange, header wrapper, etc. system that bidders connect to. This may be the operational domain of the system, if that is different than the parent corporate domain, to facilitate WHOIS and reverse IP lookups to establish clear ownership of the delegate system. Ideally the SSP or exchange publishes a document detailing what domain name to use.

For Google seller accounts, the domain name is always google.com.

<Field #2>: The publisher’s account ID (required).

The identifier associated with the seller or reseller account within the advertising system in field #1. This must contain the same value used in transactions (such as OpenRTB bid requests) in the field specified by the SSP/exchange. Typically, in OpenRTB this is the publisher.id field. For OpenDirect, it is typically the publisher’s organization ID.

For Google seller accounts, use the publisher ID displayed in each account (for example, pub-0000000000000000). To find this ID:

Only include the pub- prefix and the 16-digit numeric code in your declaration. Delete the product-specific prefix (for example, ca- or ca-video-). If you monetize through multiple Ad Manager and/or AdSense accounts, you must include a separate row for each account, with its corresponding pub- code.

Domains where an ads.txt file is posted, but the seller’s publisher ID is not authorized in the file are no longer monetized through Ad Manager, and Google no longer buys ads on such sites. To prevent impact to your earnings, we recommend updating your ads.txt files to include publisher IDs for each site you want to monetize (learn how to update ads.txt in Ad Manager). If you use Scaled Partner Management, we recommend working with your scaled partners to include your publisher ID in their ads.txt files.

<Field #3>: Type of account/relationship (required).

An enumeration of the type of account.

A value of 'DIRECT' indicates that the publisher (content owner) directly controls the account indicated in field #2 on the system in field #1. This tends to mean a direct business contract between the publisher and the advertising system.

Google publishers who directly control the account indicated in field #2 should specify 'DIRECT'.

A value of 'RESELLER' indicates that the publisher has authorized another entity to control the account indicated in field #2 and resell their ad space via the system in field #1. Other types may be added in the future. Note that this field should be treated as case-insensitive when interpreting the data.

Google publishers who do not directly control the account indicated in field #2 should specify 'RESELLER'. For example, an Ad Manager account using Network Partner Management should specify 'RESELLER' for inventory the account doesn't directly manage.

<Field #4>: Certification authority ID (optional).

An ID that uniquely identifies the advertising system within a certification authority (this ID maps to the entity listed in field #1). A current certification authority is the Trustworthy Accountability Group (TAG), and the TAG ID would be included here.

For Google seller accounts, the TAG ID is f08c47fec0942fa0.

In this video we cover what ads.txt is, why we support this initiative and how to authorize Google to sell your ad inventory via the ads.txt file.

Frequently asked questions

I see an alert about my ads.txt file in AdSense. How do I check which of my sites has an incorrect ads.txt file?

If you see an ads.txt alert in your account, you can visit your Sites page to see a list of impacted sites.

I can't place a file on my root domain. What should I do?

You are not required to use ads.txt. However, if an ads.txt file is added to your root domain, make sure you reach out to your webmaster and ask them to add your publisher ID to the file.

How will ads.txt be enforced by Google?

Whenever an ads.txt file is posted on a root domain, Google will use the contents of that file to determine which Google seller accounts will be allowed to serve ads on that root domain.

When you request an ad for a particular site, we will check whether the root domain of that site contains an ads.txt file. If there is no ads.txt file, then there is no additional enforcement. If there is an ads.txt file and your publisher ID is correctly listed then we will run an auction and return the winning ad. If there is an ads.txt file and your publisher ID is not correctly listed, then we will not run an auction for that request.

Our system automatically checks for new and updated ads.txt files. Note that if you update or remove an ads.txt file it may take up to 24 hours for our system to register your changes.

Does Google only support ads.txt files on root domains, or also on subdomains per the September 2017 v1.0.1 ads.txt spec update?

In 2017 Google will only crawl and enforce ads.txt files placed on root domains, ignoring files placed on subdomains. Ensure that sellers authorized for your subdomains are included in the ads.txt file you place on your root domain. We are planning to crawl and enforce ads.txt files placed on subdomains beginning some time in 2018. We will provide further details when this feature is available.

Does Google support redirects per the September 2017 v1.0.1 ads.txt spec update?

Per the ads.txt v1.0.1 specification update, Google supports a single HTTP redirect to a destination outside the original root domain (eg. example1.com/ads.txt re-directs to example2.com/ads.txt).

Multiple redirects are also supported, as long as each redirect location remains within the original root domain. For example: