Meilleurs outils pour vérifier les fichiers ads.txt

ads.txt signifie Authorized Digital Sellers (Vendeurs Numériques Autorisés). C'est un fichier texte brut hébergé à la racine de votre domaine - `yourdomain.com/ads.txt` - qui répertorie chaque ad exchange, réseau et plateforme côté offre (SSP) autorisés à vendre l'inventaire publicitaire de votre site. L'IAB Tech Lab a introduit la norme en 2017 spécifiquement pour lutter contre l'usurpation de domaine : une forme de fraude publicitaire où des acteurs malveillants vendent de l'inventaire en prétendant provenir d'un domaine d'éditeur premium qu'ils ne possèdent pas.

Quand une plateforme côté demande (DSP) ou un annonceur place une enchère programmatique, son système consulte le fichier ads.txt de l'éditeur avant de dépenser. Si l'entité vendeuse listée dans la requête d'enchère n'apparaît pas dans le fichier ads.txt, l'acheteur saute l'enchère entièrement ou applique une décote significative. Un fichier manquant, une entrée mal configurée ou un enregistrement obsolète se traduisent directement par des fill rates plus faibles et des CPM effectifs réduits.

Le format de ligne de ads.txt

Chaque ligne d'un fichier ads.txt valide suit un format précis à quatre champs. Comprendre la structure est essentiel pour repérer les erreurs - la plupart des problèmes de validation proviennent de lignes s'écartant de ce motif exact.

# Format: domain, publisher-account-id, account-type, authority-id
# account-type must be DIRECT or RESELLER
# authority-id (TAG-ID) is optional but strongly recommended

google.com, pub-0000000000000000, DIRECT, f08c47fec0942fa0
appnexus.com, 1234, RESELLER, f5ab79cb980f11d1
openx.com, 540191398, RESELLER, 6a698e965929

# Lines starting with # are comments - ignored by parsers
# [email protected]
# SUBDOMAIN=sub.yourdomain.com

• domain : Le domaine racine du système publicitaire (p. ex. `google.com`, pas `ads.google.com`).
• publisher-account-id : Votre identifiant de compte ou d'éditeur auprès de ce réseau publicitaire.
• account-type : Soit `DIRECT` (vous avez un contrat direct) soit `RESELLER` (vendu via un intermédiaire).
• authority-id : Le TAG-ID ou Seller Account ID, facultatif mais recommandé, du Trustworthy Accountability Group. L'omettre réduit la confiance des acheteurs.

L'application d'ads.txt par l'écosystème programmatique n'est pas uniforme - les DSP traitent différemment les fichiers invalides, ce qui rend l'impact sur les revenus difficile à prévoir et facile à manquer tant que les CPM ne chutent pas de façon visible. Comprendre comment les acheteurs réagissent aux erreurs explique pourquoi vérifier régulièrement ads.txt en vaut la peine.

Comment les DSP réagissent aux problèmes ads.txt

• Fichier manquant (404) : La plupart des grands DSP traitent un ads.txt manquant comme un « inventaire non vérifié ». Certains sautent l'enchère entièrement ; d'autres enchérissent à un prix plancher fortement décoté.
• Format de ligne invalide : Les lignes au nombre de champs erroné ou au type de compte invalide sont silencieusement ignorées - l'entrée est traitée comme si elle n'existait pas.
• Divergence DIRECT vs RESELLER : Si un réseau vend en DIRECT mais que votre fichier le liste en RESELLER (ou inversement), les acheteurs signalent la divergence et réduisent leur confiance dans l'inventaire.
• authority-id manquant : Le programme TAG Certified Channels exige des authority-ids. Les acheteurs appliquant la certification TAG ignorent les entrées sans.
• Redirection vers l'accueil : Une redirection 301 ou 302 de /ads.txt vers la page d'accueil est traitée comme un fichier manquant par la plupart des crawlers.

Les acheteurs de publicité numérique peuvent utiliser ads.txt pour déterminer si une opportunité d'achat média est autorisée par l'éditeur et si les revendeurs sont permis de vendre l'inventaire de l'éditeur.

Google AdSense et les avertissements ads.txt

Google AdSense est particulièrement strict sur l'application d'ads.txt. Si votre ID éditeur AdSense n'est pas correctement listé dans votre fichier ads.txt, AdSense affiche un avertissement dans le tableau de bord et peut réduire la diffusion sur vos emplacements approuvés. L'entrée AdSense requise suit ce format exact : `google.com, pub-XXXXXXXXXXXXXXXXX, DIRECT, f08c47fec0942fa0`. L'authority-id `f08c47fec0942fa0` est le TAG-ID fixe de Google - il doit apparaître exactement tel qu'écrit.

Vérifier ads.txt exige deux vérifications distinctes : l'accessibilité (le fichier est-il atteignable à la bonne URL ?) et la validité (chaque ligne est-elle correctement formatée ?). Les deux contrôles sont rapides et peuvent être réalisés en moins de deux minutes avec les bons outils.

La plupart des problèmes ads.txt relèvent d'un petit nombre de schémas récurrents. Chacun a une cause précise et une correction précise - une fois que vous savez quoi chercher, leur résolution prend des minutes.

Mauvais comptage de champs

L'erreur la plus courante est une ligne avec un nombre erroné de champs séparés par des virgules. Chaque ligne doit comporter exactement trois champs requis (domaine, account-id, account-type) et un champ facultatif (authority-id). Les lignes à deux champs (domaine et account-id seulement) et celles à cinq champs (champs supplémentaires ajoutés par des erreurs de copier-coller) échouent toutes deux à la validation. Vérifiez chaque ligne signalée par votre validateur - le problème vient souvent d'une virgule parasite ou d'une virgule manquante d'une édition manuelle.

Valeur de type de compte invalide

Le champ account-type n'accepte que deux valeurs : `DIRECT` et `RESELLER`. Les parseurs insensibles à la casse acceptent `direct` et `reseller`, mais la spécification IAB recommande les majuscules. Toute autre valeur - `DIRECT/RESELLER`, `Partner`, `Network` ou un vide - échoue à la validation et la ligne est entièrement ignorée par les parseurs conformes. Revoyez chaque ligne signalée et corrigez la valeur exactement en `DIRECT` ou `RESELLER` selon votre relation contractuelle avec ce réseau.

Fichier servi depuis le mauvais chemin ou avec le mauvais Content-Type

Le fichier ads.txt doit être accessible exactement à `votredomaine.com/ads.txt` - ni `/ads.txt.php`, ni `/ads-txt`, ni un chemin de sous-répertoire. Le serveur doit renvoyer un statut `200 OK` avec un `Content-Type` de `text/plain`. Certaines plateformes d'hébergement servent les fichiers `.txt` en `application/octet-stream`, ce que certains crawlers rejettent. Utilisez le validateur Robots en parallèle de votre contrôle ads.txt - si robots.txt présente des problèmes d'accessibilité similaires, vous avez probablement un problème de configuration serveur touchant tous les fichiers `.txt` à la racine.

Caractères cachés et problèmes d'encodage

Un problème ads.txt particulièrement difficile tient aux lignes qui paraissent correctes visuellement mais échouent au parsing car elles contiennent des caractères Unicode cachés - espaces insécables, espaces de largeur nulle ou guillemets typographiques - introduits en copiant depuis un PDF, un document Word ou un courriel en texte enrichi. La plupart des éditeurs de texte n'affichent pas ces caractères. Si une ligne échoue à la validation sans erreur de format évidente, retapez-la manuellement plutôt que de copier-coller. L'outil de réparation Unicode et d'encodage peut retirer les caractères Unicode invisibles du texte collé avant que vous ne le placiez dans votre fichier ads.txt.

ads.txt a été conçu pour les éditeurs web. L'écosystème publicitaire programmatique a étendu la norme à deux spécifications apparentées : app-ads.txt pour l'inventaire des applications mobiles, et sellers.json pour la transparence de la chaîne d'offre. Comprendre les trois formats vous aide à dresser un tableau d'autorisation complet.

app-ads.txt pour les éditeurs d'applications mobiles

Les développeurs d'applications mobiles utilisent app-ads.txt à la place d'ads.txt. Le format du fichier est identique - la même structure de ligne à quatre champs, les mêmes types de compte DIRECT/RESELLER, le même champ authority-id. La différence réside dans la découverte : pour les apps, les plateformes publicitaires recherchent l'URL du site du développeur depuis la fiche App Store ou Google Play et vérifient la présence d'un app-ads.txt à la racine de ce domaine. Vous hébergez app-ads.txt sur votre site de développeur, pas dans l'application elle-même. Utilisez le validateur app-ads.txt pour contrôler l'autorisation de l'inventaire mobile avec les mêmes règles de validation.

sellers.json - le complément de la chaîne d'offre

sellers.json est le complément d'ads.txt vu de l'autre côté : les réseaux publicitaires et SSP publient un fichier sellers.json sur leur propre domaine, listant tous les éditeurs (vendeurs) qu'ils représentent. Un acheteur peut recouper votre entrée RESELLER ads.txt avec le sellers.json du SSP pour vérifier que la chaîne d'offre est légitime. Bien que vous ne créiez pas sellers.json en tant qu'éditeur, le comprendre explique pourquoi avoir des authority-ids corrects dans votre ads.txt importe - ils servent à rapprocher vos entrées des enregistrements sellers.json.

Une vérification ponctuelle d'ads.txt ne suffit pas - les entrées des réseaux changent, de nouveaux partenaires sont intégrés, et l'accessibilité du fichier peut rompre après des mises à jour serveur ou CMS. Mettre en place une routine de surveillance légère prévient les pertes de revenus silencieuses entre les audits manuels.

Avertissements du tableau de bord Google AdSense

Le tableau de bord AdSense affiche un bandeau d'avertissement ads.txt si votre ID éditeur manque dans votre fichier ads.txt ou si le fichier n'est pas accessible. Consultez le tableau de bord AdSense après toute migration de serveur, mise à jour CMS ou changement de `.htaccess` - ce sont les trois événements les plus courants qui cassent l'accessibilité d'ads.txt sans que l'éditeur s'en aperçoive. L'avertissement apparaît dans la section « Compte » des paramètres AdSense.

Notifications des partenaires programmatiques

La plupart des grands SSP et réseaux publicitaires envoient des notifications par courriel quand leurs entrées ads.txt requises changent. Abonnez-vous aux notifications de mise à jour du portail éditeur de chaque partenaire si disponible. Quand un partenaire met à jour son domaine ou son authority-id, il accorde généralement une fenêtre de migration de 30 à 90 jours avant que les anciennes entrées ne soient plus honorées - mais seuls les éditeurs qui surveillent repéreront le changement à temps.

Flux d'audit technique

Intégrez la validation ads.txt à votre audit technique SEO trimestriel aux côtés de robots.txt, de la validation du sitemap et des contrôles de balises canoniques. Utilisez l'explicateur de conflits de règles robots.txt pour vérifier qu'aucune règle robots.txt ne bloque accidentellement les crawlers des plateformes publicitaires, et le validateur de sitemap pour contrôler la santé du sitemap dans la même session. Ces fichiers résident au même niveau racine du serveur et subissent souvent les mêmes événements de mauvaise configuration.

Suivre ces pratiques garde votre fichier ads.txt exact, accessible et efficace - maximisant l'éligibilité aux enchères tout en protégeant votre inventaire des revendeurs non autorisés.

Gardez le fichier léger et à jour

Retirez les entrées des réseaux publicitaires avec lesquels vous ne travaillez plus. Un ads.txt surdimensionné avec des dizaines d'entrées inactives ne nuit pas directement aux revenus, mais il augmente la surface d'erreurs et complique l'audit du fichier. Quand vous vous désengagez d'un réseau, retirez leurs entrées en même temps que leurs tags publicitaires de vos pages - traitez les deux comme partie d'un même processus de désengagement.

Utilisez toujours les authority-ids quand disponibles

Le TAG authority-id (aussi appelé TAG-ID ou Seller Account ID) est techniquement facultatif dans la spécification ads.txt, mais les grands DSP préfèrent les entrées qui l'incluent. Il permet aux acheteurs de vérifier toute la chaîne d'offre, de l'éditeur à la plateforme, via le recoupement sellers.json. Chaque grand réseau publie son authority-id dans sa documentation éditeur - incluez-le dans chaque entrée où il est disponible.

• Une entrée par ligne : Ne combinez jamais plusieurs réseaux sur une seule ligne - chaque relation de vendeur autorisé obtient sa propre ligne.
• Validez avant chaque envoi : Exécutez le validateur ads.txt sur le fichier avant l'envoi pour attraper les erreurs introduites pendant l'édition.
• Utilisez l'encodage UTF-8 sans BOM : Enregistrez le fichier en UTF-8 simple. Un BOM (Byte Order Mark) au début du fichier peut casser le parsing chez certains crawlers publicitaires.
• Pas d'espaces en fin de ligne : Beaucoup d'éditeurs de texte ajoutent des espaces invisibles en fin de ligne. Ils peuvent provoquer des échecs de parsing par ligne dans les validateurs stricts.
• Gestion de versions pour votre ads.txt : Gardez ads.txt dans le dépôt de gestion de versions de votre site. Un historique git vous permet de tracer exactement quand une entrée a été ajoutée ou retirée si les revenus chutent de façon inattendue.