Approbation AdSense

ads.txt expliqué : format, emplacement et erreurs courantes

Pourquoi ads.txt existe, comment les acheteurs le lisent, un fichier commenté pour 3 réseaux, et 6 contrôles dans l'ordre quand AdSense ne le trouve pas.

Une main qui signe un document avec un stylo
Photo: Tima Miroshnichenko sur Pexels

Un fichier ads.txt tient en quelques lignes, et c’est un logiciel que vous ne verrez jamais qui les lit. Avant qu’un système d’achat publicitaire dépense de l’argent sur l’une de vos pages, il peut récupérer ce fichier et vérifier que le vendeur qui lui fait face est bien l’un de ceux que vous avez autorisés. Un site sans fichier, ou avec un fichier cassé, ne donne rien à vérifier à un acheteur prudent.

Pourquoi ce fichier existe, et ce qu’en font les acheteurs

Le problème visé est l’usurpation de domaine. Quelqu’un vend de l’espace publicitaire en se faisant passer pour votre site, les annonceurs paient l’imposteur, vous ne gagnez rien, et votre nom se retrouve associé à un trafic que vous n’avez jamais servi. La norme ads.txt, maintenue par l’IAB Tech Lab, répond par une liste publique : le propriétaire du site publie, à la racine du domaine, les sociétés autorisées à vendre son inventaire. Le système d’un acheteur récupère https://votredomaine/ads.txt et compare le vendeur, l’identifiant de compte et la relation indiqués dans la requête reçue avec vos lignes. Une divergence est une raison d’ignorer la requête. La rigueur de chaque acheteur reste son choix, et une requête ignorée ne s’annonce pas.

Pour AdSense, Google décrit le fichier et la ligne exacte à publier pour lui. Il précise aussi que les changements mettent de quelques jours à environ un mois à être pris en compte, selon votre trafic. Le fichier ne figure pas parmi les conditions d’éligibilité que liste Google : ne retardez donc pas votre première candidature pour lui, car les pages qui décident de l’approbation sont décrites dans le guide sur les pages indispensables à l’approbation AdSense. Ajoutez ads.txt dès que votre compte vous donne un identifiant d’éditeur.

DIRECT, RESELLER et ce que « autorisé » veut dire

Chaque ligne autorise un compte vendeur sur un système publicitaire, et le troisième champ dit quelle est votre relation avec ce compte. DIRECT signifie que vous détenez le compte vous-même et que le système publicitaire vous paie. RESELLER signifie que le compte appartient à quelqu’un d’autre, une agence ou un gestionnaire publicitaire, que vous avez autorisé à vendre votre espace. L’identifiant d’une ligne RESELLER est le sien, et c’est lui qui vous le donne. Le format champ par champ, le quatrième champ facultatif et les variables sont expliqués sur la page du vérificateur ads.txt ; nous nous en tenons ici à l’usage du fichier.

L’erreur classique est une ligne pour laquelle vous n’avez aucun contrat. Certains marquent toutes les lignes DIRECT parce que cela paraît plus solide, d’autres collent une longue liste de lignes RESELLER trouvée sur un forum. Dans les deux cas, ils autorisent des vendeurs avec lesquels ils n’ont jamais travaillé. Chaque ligne de votre fichier doit remonter à un partenaire qui vous l’a remise.

Un fichier pour trois réseaux, ligne par ligne

Voici un fichier complet pour un site qui vend via AdSense, via un second réseau où il détient son propre compte, et via une agence qui revend sur un troisième. Tous les identifiants sont fictifs. La ligne Google garde le véritable identifiant d’autorité de certification de Google et un identifiant d’éditeur à zéro, et les domaines en .example sont réservés : ils ne peuvent pas exister.

# ads.txt pour example.com (tous les identifiants sont fictifs)
CONTACT=ads@example.com                                       # adresse publique pour les questions sur ce fichier
google.com, pub-0000000000000000, DIRECT, f08c47fec0942fa0   # AdSense : notre propre compte, payé par Google
network-a.example, 11111, DIRECT                              # second réseau : notre propre compte là aussi
network-b.example, 22222, RESELLER                            # une agence vend notre espace via son compte sur le réseau B

Les commentaires après # sont permis sur n’importe quelle ligne : vous pouvez donc expliquer chaque entrée et dater le fichier. La ligne Google est celle qu’il faut écrire à l’identique. L’identifiant d’éditeur est pub- suivi de 16 chiffres, sans le préfixe ca- que vous voyez dans le code publicitaire, et le dernier champ est l’identifiant d’autorité de certification de Google, f08c47fec0942fa0. L’ordre des lignes n’a pas d’importance. Les doublons font désordre, et notre vérificateur les signale.

Prenez chaque ligne chez le partenaire à qui elle appartient, jamais dans une liste copiée. Et rappelez-vous que le fichier est public : n’importe qui peut lire la liste de vos partenaires, donc l’adresse CONTACT devrait être une adresse de fonction plutôt que votre boîte personnelle.

Emplacement, sous-domaines et redirections

Le fichier se trouve à la racine de votre domaine, à l’adresse https://votredomaine/ads.txt. Il doit répondre 200 en texte brut, en UTF-8 sans marque d’ordre des octets (BOM), et ne doit pas être une page HTML. Sur un site statique, déposez-le dans le dossier servi à la racine. Si une application monopage ou une règle fourre-tout répond index.html à tout chemin inconnu, ajoutez une correspondance exacte pour que la requête atteigne le vrai fichier, ou échoue franchement :

location = /ads.txt {
    default_type text/plain;
    try_files $uri =404;
}

Les systèmes cherchent le fichier sur le domaine racine. Un sous-domaine n’a son propre fichier que si le fichier racine le déclare par une ligne SUBDOMAIN : par défaut, un seul fichier couvre donc tout le site. Les redirections sont l’autre piège. Servez le fichier directement depuis votre propre domaine quand vous le pouvez : certains systèmes n’acceptent que les redirections au sein du même domaine racine, et notre vérificateur suit jusqu’à 6 redirections et vous montre la chaîne rencontrée. L’équivalent pour mobile, app-ads.txt, est un fichier distinct pour les applications, publié sur le site du développeur indiqué dans la boutique d’applications.

Faire évoluer le fichier quand votre configuration change

Traitez ads.txt comme un élément de la configuration du site, pas comme un envoi unique. Gardez-en une copie dans le projet qui construit le site : un redéploiement qui remplace la racine web supprimera un fichier qui n’avait jamais été déposé qu’à la main. Suivez ensuite la même routine à chaque changement.

Quand vous ajoutez un réseau, demandez au partenaire ses lignes exactes, ajoutez-les avec un commentaire daté, vérifiez le résultat avec le vérificateur, et seulement ensuite activez ses annonces. Google indique que sa propre ligne peut mettre de quelques jours à un mois à être prise en compte, et les autres acheteurs fixent leur propre rythme sans vous le dire : les lignes doivent donc figurer dans le fichier avant que vous en ayez besoin. Quand vous cessez de travailler avec un partenaire, retirez ses lignes une fois ses dernières annonces diffusées : une ligne périmée continue d’autoriser un vendeur avec qui vous ne travaillez plus. Quand vous changez d’hébergeur ou de système de gestion de contenu, récupérez de nouveau le fichier dans les minutes qui suivent le basculement, pour vérifier qu’il est bien servi. Quand vous ajoutez un sous-domaine ou un second domaine, rappelez-vous que le fichier appartient à un domaine : un nouveau domaine a besoin de son propre fichier, et un sous-domaine de la ligne SUBDOMAIN décrite plus haut.

Quand AdSense dit qu’il ne trouve pas ads.txt

Parcourez cette liste dans l’ordre et arrêtez-vous au premier contrôle qui échoue. Chacun écarte une cause que le suivant ne peut pas voir.

  1. Récupérez le fichier comme un inconnu. Lancez curl -sI https://example.com/ads.txt. Vous attendez un statut 200 et un content-type à text/plain. Un 404 signifie que le fichier n’est pas à la racine. Un 200 avec text/html signifie qu’une route fourre-tout répond à la place de votre fichier.
  2. Vérifiez l’hôte. Le fichier doit être accessible sur le domaine racine du site que vous avez ajouté à AdSense. Si votre site vit sur un sous-domaine, la racine a besoin d’une ligne SUBDOMAIN ou du fichier lui-même.
  3. Vérifiez le chemin jusqu’au fichier. Lancez le vérificateur ads.txt pour voir la chaîne de redirections. Regardez ensuite dans le journal de votre serveur les codes renvoyés aux robots de Google : un pare-feu, une règle de CDN ou une extension de sécurité qui bloque les robots inconnus peut leur répondre 403 alors que le fichier s’affiche très bien dans votre navigateur.
  4. Vérifiez le robots.txt. Une règle Disallow qui correspond à /ads.txt, directement ou par un motif, arrête un robot qui respecte le fichier. Le testeur de robots.txt montre la règle décisive, et notre guide sur les erreurs de robots.txt liste les causes habituelles.
  5. Vérifiez le contenu. Le vérificateur signale une marque d’ordre des octets en première ligne, du HTML là où il faut du texte, un identifiant d’éditeur qui n’est pas pub- suivi de 16 chiffres, et une ligne Google sans quatrième champ.
  6. Attendez. Si les contrôles 1 à 5 passent et que vous avez modifié le fichier il y a moins d’un mois, ne touchez à rien. La fourchette de Google va de plusieurs jours à environ un mois, selon votre trafic. Nous ne connaissons aucun moyen de l’accélérer, et rien ne laisse penser que de nouvelles modifications y aideraient. Si plus d’un mois a passé et que tout ce qui précède est en ordre, apportez la sortie de curl et le rapport du vérificateur aux canaux d’aide de Google.

Sources

Qui est derrière ce site

GreenlightMySite est tenu par Stéphane Cardon, ingénieur réseaux et cybersécurité. Nous écrivons à partir de vrais sites passés par de vraies candidatures, et chaque affirmation technique est soit liée à une source primaire, soit mesurée avec nos propres outils.

À propos · Politique éditoriale · LinkedIn