From LinuxReviews
Jump to navigationJump to search

ads.txt is a web standard for verifying that website publishers have a connection with advertisement exchanges. It is a very plain text-file which lists an advertisement service or exchange followed by a ID number at that exchange and either the word "DIRECT" or "RESELLER" depending on the publishers relationship with the service which is listed.

The "ads" part of "ads.txt" stands for "Authorized Digital Sellers".

The Problem Ads.txt Tries To Solve

The Methbot Operation[1] was a larger advertisement fraud operation out of Russia where advertisement space on large well-known websites was sold without the knowledge or consent of those actually owning those websites. The advertisements were obviously never shown on the sites the advertisers paid for. Instead, the advertisers got their advertisement placed on bogus sites. The fraudsters sent a lot of traffic from botnets.


The Methbot operation generated 300 million video advertisements per day. These advertisement views were sold on an array of more than 6000 "premium" domains the fraudsters did not own. The Methbot operation alone generated an estimated 3 to 5 million USD per day. It was just one of the bigger advertisement fraud operations; there appears to be a whole lot of blatant fraud going on in the advertisement space.

The ads.txt standard initiative from IAB Technology Laboratory aims to address the kind of common and rampant fraud where A sells advertisement space on B's sites to C who believes the advertisements will be placed at publisher B when they in reality show up at A's low-quality botnet-traffic-driven website.


The ads.txt should, like a robots.txt file, be a simple text file and it should be placed in the root / of all domains and sub-domains.

The actual format is a line-by-line list of advertisement service or exchange comma-separated with the publisher ID at that service comma-separated with either "DIRECT" or "RESELLER" comma-separated with the listed third party's "certified" ID (optional).

IABTechLab's specification[2] lists the format as

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

with the following fields as valid:

field 1 Domain name of the advertising system
field 2 Publisher’s Account ID
field 3 Type of Account/ Relationship
field 4 Certification Authority ID (Optional)

However, an alternative format is also supported: <VARIABLE>=<VALUE> - with the supported variables being CONTACT and SUBDOMAIN. Do note that = is the only valid separator when a variable is used (CONTACT=you@yourmail.tld).

Our ads.txt file can be found at It is currently holds one short one-liner for Google's Adsense service:, pub-7707288103057160, DIRECT, f08c47fec0942fa0 

Here we have google's domain, our publisher ID, the word DIRECT and Google's ID number. Our particular example is a bit peculiar since Google's actually reselling advertisement space (so "RESELLER" seems more logical than "DIRECT") - but that's the line they encourage.

Larger sites have an ads.txt which is pages long. is a good example of how it looks when a site is serving ads from hundreds of different agents and exchanges.

The optional forth field, "Certification Authority ID", is a ID provided by the "Trustworthy Accountability Group" (aka TAG). This "independent" group is essentially Google's parent company Alphabet.

Does It Work?

Advertisement exchanges and software for "programmatic marketing" (automatic bidding on advertisement space) does check for a /ads.txt. There will be a lot of requests for this file if you are using any kind of advertisement exchange or provider and a lot of web crawlers will check for one even if you are serving zero advertisements on your site.

  • If scammer A tries to sell advertisement space on website B
  • AND website B has a ads.txt file which does not list the advertisement exchange scammer A is trying to sell space through
  • OR the ID number scammer A is using at that exchange is wrong
  • AND the service or those using the service bothers to check ads.txt

..then the fraud is revealed and scammer A gets no sale. Website B will, in theory, get more revenue since advertisements meant to be sold to that site is more likely to get sold to that site. Advertisers get their ads placed on a real site visited by real people instead of bogus sites with botnet traffic. Everyone wins - in theory: ads.txt is only useful if everyone in the supply chain bothers to actually check and verify it's contents.

You should have a /ads.txt

You should have a /ads.txt file on your webserver even if if you are not serving advertisements and you do not list any exchanges or services in it. That prevents fraudsters from re-selling advertisement space on your site through the bigger exchanges. It has the side-benefit of there not being a lot of 404's for ads.txt in your logs.

Unsolved Issues

The ads.txt standard does not solve advertisement fraud. Operators of low-quality sites with mainly botnet traffic can make ads.txt files just as easy as operators of legitimate sites with human visitors. They can't pretend to be re-selling on legitimate sites if everyone uses ads.txt files but scammers gonna scam and ads.txt files simply require scammers to change the way they run their fraud operations. If you are advertising on a site in Norway and 90% of it's traffic is coming from China and the Ukraine then something is probably not the way it is supposed to be.