Declare who is authorised to sell your inventory with ads.txt
Authorised 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 authorised. 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 towards that counterfeit inventory.
Here's how to create an ads.txt file to publicly declare that Google is authorised to sell your ad inventory:
- Create a text (.txt) file.
- Include the following line:
google.com, pub-0000000000000000, DIRECT, f08c47fec0942fa0Important: Make sure you replace
pub-0000000000000000with your own publisher ID.
- Host your ads.txt on your root domain (for example, https://example.com/ads.txt).
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.
What information goes in an ads.txt file?
Include a separate line in the file for each authorised 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
<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
- In AdSense: Sign in to your AdSense account, then click Account Account information.
- In Google Ad Manager: Sign in to Google Ad Manager, then click Admin Global settings to find the publisher ID of your primary account and any other linked accounts.
pub-prefix and the 16-digit numeric code in your declaration. Delete the product-specific prefix (for example,
ca-video-). If you monetise 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 monetised through Ad Manager, and Google no longer buys ads on such sites. To prevent impact to your earnings, we recommend that you update your ads txt files to include publisher IDs for each site that you want to monetise (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
- A value of '
RESELLER' indicates that the publisher has authorised 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 that the account doesn't manage directly.
- A value of '
<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
In this video we cover what ads.txt is, why we support this initiative and how to authorise 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?
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 authorised 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 early 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 (e.g. 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:
How do I set up an ads.txt file for Blogger?
See the Blogger Help Centre for instructions.