The text file includes separate lines for each exchange or SSP that is authorized to sell your inventory. Each of these lines should contain three pieces of data (plus a fourth optional field), in the format:
<Field #1>, <Field #2>, <Field #3>, <Field #4>
<Field #1>: The canonical domain name of the system where bidders connect. This may be the operational domain of the system, if it’s different than the parent corporate domain, to facilitate WHOIS and reverse IP lookups to establish clear ownership. The SSP or exchange may publish the domain name to use.
For Google seller accounts, the domain name is always
<Field #2>: The publisher identifier associated with the seller or reseller account for the system in field #1. This must contain the same value as that specified in an SSP or exchange transaction (such as OpenRTB bid requests). 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 and click Account Account information.
- In Google Ad Manager: Sign in to Google Ad Manager and 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 monetize through multiple Ad Manager and/or AdSense accounts, you must include a separate row for each account, with its corresponding
Domains/apps hosting an
app-ads.txtfile where the seller’s publisher ID isn’t listed are no longer monetized through Ad Manager, and Google no longer buys ads on such sites/apps.
app-ads.txtfiles to include publisher IDs for each site you want to monetize is recommended. Learn how to update
app-ads.txtin Ad Manager.
<Field #3>: The type of account or relationship. This field should be treated as case-insensitive when interpreting the data.
- A value of '
DIRECT' indicates that the publisher (content owner) directly controls the account indicated in field #2 and has 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.
Google publishers who don't directly control the account indicated in field #2 should specify
'RESELLER'. For example, an Ad Manager account using Scaled Partner Management should specify
'RESELLER'for inventory the account doesn't directly manage.
- A value of '
<Field #4>: (Optional): A unique identifier for the advertising system within a certification authority, which maps to the entity listed in field #1. One certification authority is the Trustworthy Accountability Group (TAG), and the TAG ID would be included here.
For Google seller accounts, the TAG ID is
app-ads.txt files should be hosted in the root domain.
Google uses the content of any
app-ads.txt files hosted on a root domain/app to determine which seller accounts are allowed to serve ads on that domain/app.
Google runs an auction and returns a winning ad for requests on sites where an
app-ads.txt file exists with a correctly listed publisher identifier. If the identifier in the file is incorrect, an auction is not run for that request.
New and updated
app-ads.txt files are detected automatically, but changes may take up to 48 hours.
app-ads.txtfile is hosted on a subdomain?
Google crawls and enforces ads.txt and app-ads.txt files placed on subdomains, where one exists, and is referenced from the ads.txt file on the root domain.
In Ad Manager, the ads.txt management tool does not yet show a list of crawled subdomains.
app-ads.txtcrawled and distributed?
Every domain that Ad Manager receives ad requests from is crawled at least once a day. A snapshot of all crawled data is compiled at least once a day, and that snapshot is subsequently distributed to all ad servers.
Ad Manager displays the last fetched ads.txt/app-ads.txt version. Note that it might take additional time until the displayed ads.txt/app-ads.txt crawl result is distributed to the ad servers.
Google supports a single HTTP redirect to a destination outside the original root domain (for example, example1.com/ads.txt re-directs to example2.com/ads.txt). See the IAB update.
Multiple redirects are also supported, as long as each redirect location remains within the original root domain. For example:
Contact your CMS provider who should provide you with the facility to host an
app-ads.txt file on your behalf.
app-ads.txtfile posted on my domain?
A domain may have an
app-ads.txt file posted but may still show in the Ad Manager
app-ads.txt management tool with a status of "no ads.txt found". This may happen due to an incorrect
app-ads.txt implementation or other crawl-related reasons. Learn more about how to ensure your
app-ads.txt files can be crawled.
Here are some reasons why the URL in a bid request may be blank or empty:
- One of your root domains may be missing an
app-ads.txtfile. Google uses the
app-ads.txtfile on a domain to verify that a publisher is authorized to monetize the domains sent to buyers in a bid request. If the
app-ads.txtfile for a domain is missing, bid requests may include a blank or empty URL.
You should upload an
app-ads.txtfile to each domain individually. Review Admin Ads.txt management to confirm that an
app-ads.txtfile has been uploaded to each of your domains.
- There could be an implementation error if an
app-ads.txtfile has been posted on a domain but it isn’t detected in Ad Manager. Learn more about
app-ads.txtmanagement in Ad Manager and ensuring your
app-ads.txtfiles can be crawled
- There may be a problem with the way the ‘page_url’ override attribute of the Google Publisher Tag or passbacks are implemented. This may result in an invalid overridden URL value being passed in ad requests to DFP and a blank or empty URL in bid requests received by buyers.
Here are some reasons why the "Ads.txt" page might list a domain name that you don't recognize:
- Your ad code is nested within multiple iframes or you're using an ad server, yield manager, or other Supply-Side Platform (SSP) that embeds your ad code in iframes. If your ad code is nested within an iframe, we are not able to determine the correct site information for an ad request. This can happen when your page includes an iframe that points at another URL on your site containing the tag to be shown.
Sites that serve the contents of your site from their own domain. For example, Google cached search results, Google Accelerated Mobile Pages (AMP) Cache, and Google Translate may retrieve your content, then serve it from a Google domain, without iframes.
Web pages forwarded in email clients.
Duplication (in other words, copy and pasting) of content from one publisher to another.
Suggested actions for unrecognized domains:
- If your ad code is nested within multiple iframes, you may need to pass the URL of the page that users are browsing.
- If you're using an ad server, yield manager, or other Supply-Side Platform (SSP) and you see unrecognized domains, contact the SSP's account management team and ask them the best way to ensure that the correct site information is passed in your ad requests.
app-ads.txtfile for WordPress?
Consider using a plugin to create your
app-ads.txt file in WordPress. If you already use a plugin to place ads, it might include a feature to create your ads.txt file. This search can help you get started.
app-ads.txtfile for Blogger?
See the Blogger Help Center for instructions.