Validador de ads.txt
Pega el contenido de tu ads.txt para comprobar su sintaxis al instante. Valida línea por línea los campos DOMAIN, PUBLISHER_ID y RELATIONSHIP (DIRECT/RESELLER), ayudándote a configurar correctamente el archivo que protege contra la reventa no autorizada de inventario publicitario (domain spoofing).
Consejos
- El formato básico tiene 3 campos: DOMAIN, PUBLISHER_ID y RELATIONSHIP, con un cuarto campo opcional para el ID de la autoridad de certificación. Cuenta las comas para verificar que no falte ni sobre ninguna.
- RELATIONSHIP solo admite
DIRECT(el propietario del sitio tiene un contrato directo) oRESELLER(se vende a través de un revendedor). No distingue mayúsculas de minúsculas, pero el estilo convencional usa mayúsculas. - Las líneas que empiezan con
#se ignoran como comentarios. Añadir directivas de variables comoCONTACT=uOWNERDOMAIN=ayuda a los sistemas publicitarios a verificar tu cuenta. - ads.txt debe alojarse en la raíz del dominio (
https://example.com/ads.txt). Si lo colocas en un subdirectorio, los sistemas publicitarios y los rastreadores no lo reconocerán. - Existe una especificación complementaria para aplicaciones móviles llamada
app-ads.txt. Si vendes inventario publicitario tanto en un sitio web como en una app móvil, necesitas alojar ambos archivos.
Preguntas frecuentes
DIRECT significa que el propietario del sitio tiene un contrato directo con el sistema publicitario y posee la autoridad para vender ese inventario. RESELLER se usa cuando un revendedor (como una red publicitaria) vende el inventario en nombre del propietario, con la autoridad delegada. Si un mismo espacio publicitario se vende a través de varios sistemas, cada relación debe indicarse correctamente por separado.SUBDOMAIN= que permite indicar que un subdominio concreto use un archivo distinto.
A propósito — Por qué existe ads.txt: un estándar de la industria contra la "suplantación" de inventario publicitario
ads.txt (Authorized Digital Sellers) es una especificación creada en 2017 por el IAB Tech Lab. En aquel momento, la publicidad programática estaba plagada del llamado "domain spoofing": estafadores que copiaban y revendían sin autorización el inventario publicitario de editores legítimos. Los anunciantes creían estar pujando por un sitio premium, pero sus anuncios terminaban en páginas de baja calidad sin relación alguna, erosionando la confianza tanto de anunciantes como de editores.
El mecanismo es sencillo: el editor publica, en la raíz de su dominio, un archivo de texto plano con la lista de sistemas publicitarios que ha autorizado a vender su inventario. Los sistemas de compra de publicidad consultan este archivo para verificar si el inventario por el que van a pujar realmente se vende a través de un canal aprobado oficialmente por ese dominio. Al ser un diseño tan simple, el coste de adopción es bajo, y en pocos años la mayoría de los grandes sistemas publicitarios y editores lo adoptaron como estándar de la industria.
Google AdSense también promueve la adopción de ads.txt desde 2019, y los sitios que no lo tienen configurado correctamente pueden ver restringida parte de su entrega de anuncios. Para un sitio cuyo modelo de negocio depende de los ingresos publicitarios, ads.txt no es solo una recomendación: es, en la práctica, una configuración obligatoria para proteger esos ingresos.
Como especificaciones complementarias, el IAB Tech Lab también creó app-ads.txt para aplicaciones móviles y sellers.json, que publica información sobre los vendedores del lado de los sistemas publicitarios. Juntas, permiten a los anunciantes verificar quién vende qué inventario y bajo qué relación en toda la cadena de suministro.