Validador de ads.txt
Cole o conteúdo do seu ads.txt para verificar a sintaxe instantaneamente. Valida linha por linha os campos DOMAIN, PUBLISHER_ID e RELATIONSHIP (DIRECT/RESELLER), ajudando você a configurar corretamente o arquivo que protege contra a revenda não autorizada de inventário publicitário (domain spoofing).
Dicas
- O formato básico tem 3 campos — DOMAIN, PUBLISHER_ID e RELATIONSHIP — com um quarto campo opcional para o ID da autoridade certificadora. Conte as vírgulas para verificar se não falta nem sobra nenhuma.
- RELATIONSHIP só aceita
DIRECT(o proprietário do site tem contrato direto) ouRESELLER(vendido por meio de um revendedor). Não diferencia maiúsculas de minúsculas, mas o estilo convencional usa maiúsculas. - Linhas que começam com
#são ignoradas como comentários. Adicionar diretivas de variáveis comoCONTACT=ouOWNERDOMAIN=ajuda os sistemas de anúncios a conferir sua conta. - O ads.txt deve ser hospedado na raiz do domínio (
https://example.com/ads.txt). Colocá-lo em um subdiretório faz com que sistemas de anúncios e rastreadores não o reconheçam. - Existe uma especificação complementar para aplicativos móveis chamada
app-ads.txt. Se você vende inventário de anúncios tanto em um site quanto em um aplicativo móvel, precisa hospedar os dois arquivos.
Perguntas frequentes
DIRECT significa que o proprietário do site tem contrato direto com o sistema de anúncios e detém a autoridade para vender esse inventário. RESELLER é usado quando um revendedor (como uma rede de anúncios) vende o inventário em nome do proprietário, com autoridade delegada. Se um mesmo espaço publicitário for vendido por vários sistemas de anúncios, cada relação precisa ser listada corretamente.SUBDOMAIN= que permite apontar subdomínios específicos para um arquivo separado.
Curiosidade — Por que o ads.txt existe: um padrão do setor contra a "falsificação" de inventário publicitário
O ads.txt (Authorized Digital Sellers) é uma especificação criada em 2017 pelo IAB Tech Lab. Na época, a publicidade programática era assolada pelo chamado "domain spoofing": golpistas copiavam e revendiam sem autorização o inventário de editores legítimos. Anunciantes acreditavam estar comprando espaço em um site premium, mas seus anúncios acabavam em páginas de baixa qualidade sem relação alguma, corroendo a confiança tanto de anunciantes quanto de editores.
O mecanismo é simples: o editor publica, na raiz do seu domínio, um arquivo de texto simples listando os sistemas de anúncios que autorizou a vender seu inventário. Os sistemas de compra de anúncios consultam esse arquivo para verificar se o inventário em que estão dando lances é realmente vendido por um canal oficialmente aprovado por aquele domínio. Por ser um design tão simples, o custo de adoção é baixo, e em poucos anos a maioria dos grandes sistemas de anúncios e editores o adotou como padrão do setor.
O Google AdSense também vem promovendo a adoção do ads.txt desde 2019, e sites sem a configuração correta podem ter parte da veiculação de anúncios restringida. Para um site cujo modelo de negócio depende de receita publicitária, o ads.txt não é apenas uma recomendação — é, na prática, uma configuração obrigatória para proteger essa receita.
Como especificações complementares, o IAB Tech Lab também criou o app-ads.txt para aplicativos móveis e o sellers.json, que publica informações sobre os vendedores do lado dos sistemas de anúncios. Juntas, elas permitem que os anunciantes verifiquem quem vende qual inventário e sob qual relação em toda a cadeia de suprimentos.