ads.txt-Validator
Fügen Sie den Inhalt Ihrer ads.txt ein, um die Syntax sofort zu prüfen. Validiert die Felder DOMAIN, PUBLISHER_ID und RELATIONSHIP (DIRECT/RESELLER) zeilenweise und hilft Ihnen, die Datei korrekt einzurichten, die vor unautorisiertem Weiterverkauf von Werbeinventar (Domain-Spoofing) schützt.
Tipps
- Das Grundformat besteht aus 3 Feldern – DOMAIN, PUBLISHER_ID und RELATIONSHIP – mit einem optionalen vierten Feld für die ID der Zertifizierungsstelle. Zählen Sie die Kommas, um zu prüfen, dass keines fehlt oder zu viel ist.
- RELATIONSHIP akzeptiert nur
DIRECT(der Seitenbetreiber hat einen direkten Vertrag) oderRESELLER(Verkauf über einen Wiederverkäufer). Die Schreibweise ist laut Spezifikation nicht case-sensitiv, üblich ist jedoch Großschreibung. - Zeilen, die mit
#beginnen, werden als Kommentare ignoriert. Variablen-Direktiven wieCONTACT=oderOWNERDOMAIN=helfen Werbesystemen beim Abgleich Ihres Kontos. - Die ads.txt muss im Domain-Root gehostet werden (
https://example.com/ads.txt). In einem Unterverzeichnis wird sie von Werbesystemen und Crawlern nicht erkannt. - Für mobile Apps gibt es eine ergänzende Spezifikation namens
app-ads.txt. Wer Werbeinventar sowohl über eine Website als auch über eine App verkauft, muss beide Dateien hosten.
Häufig gestellte Fragen
DIRECT bedeutet, dass der Seitenbetreiber einen direkten Vertrag mit dem Werbesystem hat und die Berechtigung zum Verkauf dieses Inventars besitzt. RESELLER wird verwendet, wenn ein Wiederverkäufer (z. B. ein Werbenetzwerk) das Inventar im Auftrag des Betreibers mit delegierter Berechtigung verkauft. Wird ein Werbeplatz über mehrere Werbesysteme verkauft, muss jede Beziehung korrekt einzeln aufgeführt werden.SUBDOMAIN=-Direktive, mit der bestimmte Subdomains auf eine separate Datei verweisen können.
Übrigens – Warum es ads.txt gibt: ein Branchenstandard gegen die „Fälschung" von Werbeinventar
ads.txt (Authorized Digital Sellers) ist eine 2017 vom IAB Tech Lab entwickelte Spezifikation. Damals war die programmatische Werbung von sogenanntem „Domain-Spoofing" geplagt: Betrüger kopierten und verkauften ohne Erlaubnis das Werbeinventar seriöser Publisher weiter. Werbetreibende glaubten, auf einer Premium-Seite zu bieten, doch ihre Anzeigen landeten auf völlig unabhängigen, minderwertigen Seiten – was das Vertrauen von Werbetreibenden und Publishern gleichermaßen untergrub.
Der Mechanismus ist simpel: Ein Publisher veröffentlicht im Root-Verzeichnis seiner Domain als Klartextdatei, welche Werbesysteme er zum Verkauf seines Inventars autorisiert hat. Werbeeinkaufssysteme rufen diese Datei ab, um zu prüfen, ob das Inventar, auf das sie bieten, tatsächlich über einen von dieser Domain offiziell freigegebenen Kanal verkauft wird. Da das Design so einfach ist, sind die Einführungskosten gering – innerhalb weniger Jahre übernahm die Mehrheit der großen Werbesysteme und Publisher diesen Branchenstandard.
Auch Google AdSense fördert seit 2019 die Einführung von ads.txt, und Seiten ohne korrekte Konfiguration kann ein Teil der Anzeigenauslieferung eingeschränkt werden. Für eine Website, deren Geschäftsmodell auf Werbeeinnahmen basiert, ist ads.txt keine bloße Empfehlung, sondern faktisch eine notwendige Einstellung zum Schutz dieser Einnahmen.
Als ergänzende Spezifikationen hat das IAB Tech Lab außerdem app-ads.txt für mobile Apps sowie sellers.json, das Verkäuferinformationen auf Seiten der Werbesysteme veröffentlicht, entwickelt. Zusammen ermöglichen sie Werbetreibenden, entlang der gesamten Lieferkette zu überprüfen, wer welches Inventar unter welcher Beziehung verkauft.