Declare authorized sellers with ads.txt
Authorized Digital Sellers, or ads.txt, is an IAB initiative to improve transparency in programmatic advertising. Publishers can create their own ads.txt files to identify who is authorized to sell their inventory. The files are publicly available and crawlable by buyers, third-party vendors, and exchanges.
Use of ads.txt is not mandatory, but is highly recommended. The ads.txt file can help you protect your brand from counterfeit inventory that is intentionally mislabelled as originating from a specific domain, app, or video. Declaring authorized sellers can help you receive more advertiser spend that might have otherwise gone toward counterfeit inventory.
You can now generate content for ads.txt in the DFP UI.
Your ads.txt file should publicly declare the account for each exchange or Supply-Side Platform (SSP) that is authorized to sell your inventory. Create this file as a text (.txt) file and host it at the root level of your domain (for example,
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.
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
<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 Settings Account Account information.
- In DFP: Sign in to DoubleClick for Publishers, then click Admin Global settings to find the publisher ID of your primary Ad Exchange account and any other linked accounts.
- In Ad Exchange: Sign in to your Ad Exchange account, then click Admin Account information.
pub-prefix and the 16-digit numeric code in your declaration. Delete the product-specific prefix (for example,
ca-video-). If you monetize through multiple Ad Exchange 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 Exchange, 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 DFP). If you use Network Partner Management, we recommend working with your network 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 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 Exchange account using Network Partner Management should specify
'RESELLER'for inventory the account doesn't directly manage.
- 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
Example for publishers working with Google products
Ads.txt files from publishers working with Google products should contain lines in the following format, always using
google.com as the domain name. Here are sample lines, based on the format above (watch the video above for detailed information on the values in the file):
google.com, pub-0000000000000000, DIRECT, f08c47fec0942fa0
google.com, pub-0000000000000000, RESELLER, f08c47fec0942fa0
Example for publishers working with other SSPs/exchanges
Example.com publishes an ads.txt file on their web server listing three exchanges as authorized to sell their inventory, and includes Example.com’s seller account IDs within each of those exchanges.
The sample file at
https://example.com/ads.txt could include the following rows:
greenadexchange.com, 12345, DIRECT, AEC242
blueadexchange.com, 4536, DIRECT
silverssp.com, 9675, RESELLER
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 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 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 (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:
How do I set up an ads.txt file for Blogger?
See the Blogger Help Center for instructions.