Ads.txt para publishers: o guia técnico completo de configuração, gestão e delegação em 2026

Ads.txt é um arquivo público que declara quais empresas estão autorizadas a vender o inventário publicitário do seu site. Foi criado pelo IAB Tech Lab em 2017 pra combater fraude por revenda não autorizada. Se um SSP legítimo não está listado no seu ads.txt, compradores ignoram os lances dele ou aplicam desconto — você perde receita silenciosamente. Gestão manual funciona pra publisher pequeno; pra quem tem múltiplos sites ou trabalha com parceiros que mudam o stack com frequência, delegação via redirecionamento HTTP 301 (suportada oficialmente pela spec do IAB) é o caminho profissional. Este guia cobre o arquivo do zero: o que escrever em cada linha, como o Google verifica, os erros que destroem receita, e quando vale a pena delegar a manutenção.

Ads.txt é o tipo de detalhe técnico que separa publisher amador de profissional. Não muda o que você publica nem o tráfego que recebe, mas afeta diretamente quanto cada visita paga. E a maioria dos publishers brasileiros opera com ads.txt incompleto, desatualizado, ou às vezes inexistente — e perde 10-30% de receita por isso sem entender por quê.

A boa notícia é que o conceito é simples e o trabalho é mais administrativo que técnico. A parte ruim é que ads.txt não é “configurar uma vez e esquecer”: o ecossistema programático muda constantemente, e cada mudança que não reflete no seu arquivo é dinheiro escapando.

Esse guia cobre do conceito básico até as técnicas avançadas de delegação automatizada — incluindo quando delegar faz sentido e quando manter manual ainda é o melhor caminho.

O que é ads.txt e por que ele existe

Ads.txt (Authorized Digital Sellers) é uma especificação criada pelo IAB Tech Lab em 2017 pra resolver um problema concreto: fraude por revenda não autorizada de inventário publicitário.

O problema era assim: alguém pegava o domínio de um site legítimo (digamos, globo.com), criava uma conta em um SSP qualquer dizendo “eu represento o globo.com”, e começava a leiloar inventário falso. Anunciantes pagavam achando que estavam comprando espaço no Globo, mas na verdade os anúncios apareciam em sites de qualidade duvidosa ou em lugar nenhum. Resultado: dinheiro do anunciante desviado, reputação do publisher legítimo prejudicada, ecossistema todo erodido pela desconfiança.

A solução do IAB foi simples e elegante: o publisher publica um arquivo texto no seu próprio domínio, em URL fixa (/ads.txt), listando todas as empresas autorizadas a vender o inventário dele. Compradores programáticos (DSPs) checam esse arquivo antes de licitar. Se a SSP não está na lista, o lance é descartado ou descontado.

Em pouco tempo, ads.txt virou requisito de fato em todo o ecossistema. Google, Amazon, The Trade Desk e basicamente todas as DSPs grandes recusam lances em sites sem ads.txt válido ou com lances vindos de SSPs não declarados. Não é “boa prática opcional” — é infraestrutura básica de monetização programática em 2026.

Anatomia do arquivo: o que vai dentro

O ads.txt é um arquivo texto simples (.txt), publicado na raiz do domínio em https://seusite.com.br/ads.txt. Cada linha autoriza uma combinação de “vendedor + relação + ID”. A sintaxe é estrita:

domain.com, account_id, relationship, certification_id

Os quatro campos:

1. Domain — domínio do sistema de venda (SSP, ad exchange, ad network). Ex: google.com, pubmatic.com, rubiconproject.com.
2. Account ID — seu identificador único dentro daquele sistema. É como o sistema sabe que aquele inventário pertence a você.
3. Relationship — DIRECT (você tem relação direta com aquele SSP) ou RESELLER (autorização pra revender via terceiro).
4. Certification ID — opcional, identificador do IAB pra aquele vendedor (TAG ID).

Exemplo de ads.txt real

# AdSense / Google AdX
google.com, pub-1234567890123456, DIRECT, f08c47fec0942fa0

# Magnite (ex-Rubicon)
rubiconproject.com, 17890, DIRECT, 0bfd66d529a55807
rubiconproject.com, 17890, RESELLER, 0bfd66d529a55807

# Index Exchange
indexexchange.com, 184625, DIRECT
indexexchange.com, 184625, RESELLER

# PubMatic
pubmatic.com, 158334, DIRECT, 5d62403b186f2ace
pubmatic.com, 158334, RESELLER, 5d62403b186f2ace

# Amazon Publisher Services
amazon-adsystem.com, 3458, DIRECT

Algumas observações importantes:

• Linhas iniciadas com # são comentários e ajudam a organizar o arquivo. Não afetam validação.
• Mesmo SSP pode aparecer duas vezes (DIRECT e RESELLER) quando você tem relação direta e também permite revenda via parceiros.
• Espaços extras importam. Vírgulas precisam estar exatamente como na especificação. Erros de formatação fazem linhas inteiras serem ignoradas.
• Ordem não importa, mas convenções de organização (agrupar por SSP, usar comentários) facilitam manutenção.

Onde fica o arquivo e como crawlers verificam

Regra absoluta: o arquivo precisa estar em https://seusite.com.br/ads.txt. Não em /wp-content/ads.txt, não em subdomínio, não em pasta. Raiz do domínio, exatamente nesse nome.

DSPs e validadores rodam crawlers que fazem requisições GET pra esse URL periodicamente — geralmente uma vez por dia ou a cada poucas horas pra publishers grandes. O servidor deve responder:

• HTTP 200 OK com o arquivo texto
• Content-Type: text/plain (ideal, mas a maioria dos crawlers tolera variações)
• Sem autenticação — arquivo público, sempre

Erros comuns que fazem o ads.txt ser ignorado:

• Servidor responde 404 (arquivo não existe ou nome errado)
• Servidor responde 403 (CDN bloqueando o acesso)
• Servidor responde 500 (erro de servidor)
• Arquivo retorna HTML em vez de texto puro (CMS interceptando a rota)
• Arquivo em subdomínio (blog.seusite.com.br/ads.txt) quando o conteúdo está em domínio principal

Como o Google especificamente verifica

O Google tem um validador público: você acessa o Google Ad Manager, vai em Inventário → Diagnóstico do Ads.txt, e vê o status do arquivo, quais linhas foram aceitas, quais estão em conflito. Pra contas grandes, o GAM destaca discrepâncias específicas com sugestões de correção.

O AdSense também faz checagem. Se você é aprovado no AdSense mas não tem google.com, pub-XXX, DIRECT, f08c47fec0942fa0 no ads.txt, o painel exibe alerta amarelo, e parte do inventário pode não ser monetizado.

Subdomínios: o detalhe que pega muita gente

Se o seu blog é blog.seusite.com.br mas o domínio principal é seusite.com.br, cada um precisa do próprio ads.txt se ambos servem anúncios. A spec do IAB trata cada subdomínio como entidade própria.

Exceção: você pode usar redirecionamento HTTP (mesma técnica de delegação) pra apontar o blog.seusite.com.br/ads.txt pro arquivo do domínio principal, evitando duplicação.

Os erros mais comuns que destroem receita silenciosamente

Em ads.txt, “silencioso” é a palavra-chave. Erros não geram alarme — geram queda de receita que aparece no fim do mês como “queda de eCPM” que ninguém consegue explicar.

1. Faltar uma SSP que você efetivamente usa

Você ativou Magnite no header bidding faz três semanas, mas esqueceu de adicionar a linha no ads.txt. DSPs veem lances vindos da Magnite, checam seu ads.txt, não acham rubiconproject.com listado, descartam os lances. Você nunca soube — só vê CPM da Magnite zerado nos relatórios.

2. Listar SSPs que você não usa mais

Trocou de SSP há 6 meses mas deixou as linhas antigas no arquivo. Não tem impacto direto na receita, mas polui o arquivo, dificulta auditoria, e em casos extremos pode levar a checagens de qualidade pelos compradores.

3. Erro de digitação no account ID

Um caractere errado no ID é o suficiente pra todas as impressões daquele SSP serem invalidadas. Erro tipicamente acontece quando publisher copia-cola do email de onboarding e perde um caractere.

4. Relacionamento errado (DIRECT vs RESELLER)

Se você tem relação direta com a SSP mas declarou como RESELLER, ou vice-versa, alguns compradores vão descontar o lance. A regra prática: você é DIRECT quando tem contrato direto com a SSP; RESELLER quando alguém (um parceiro MCM, por exemplo) está revendendo o seu inventário pra essa SSP.

5. Arquivo retornando HTML em vez de texto

WordPress e outros CMSs às vezes interceptam URLs e devolvem página HTML em vez do arquivo texto. Crawlers acham o /ads.txt, mas recebem HTML, e simplesmente não conseguem parsear. Você precisa garantir que o servidor sirva o arquivo como texto puro.

6. CDN cacheando arquivo desatualizado

Você atualiza o ads.txt no servidor, mas o Cloudflare/CDN continua servindo a versão antiga por horas (ou dias). Crawlers veem o desatualizado. Solução: invalidar o cache do CDN sempre que atualizar.

7. Esquecer subdomínio

Domínio principal tem ads.txt impecável; subdomínio m.seusite.com.br (versão mobile) não tem. Crawlers consideram o subdomínio sem autorização, descontam lances. Resolva com ads.txt próprio ou redirecionamento HTTP.

A complicação: ads.txt manual não escala

Pra publisher com um site e poucas SSPs estáveis, gestão manual funciona. Você edita uma vez, valida, esquece por meses até ter mudança real no stack.

O problema aparece em dois cenários:

Cenário A: stack programático ativo

Se você trabalha com parceiro de monetização (MCM, GCPP, agência) que conecta seu inventário a dezenas de SSPs e DSPs, o “lado deles” do ads.txt pode mudar várias vezes por mês. Um SSP nova entra, uma rota de revenda muda, um parceiro descontinua serviço. Cada mudança deve refletir no seu arquivo em horas — não em semanas.

Cenário B: múltiplos sites

Se você gerencia 5, 10, 50 sites, cada um tem seu ads.txt. As mesmas mudanças precisam ser aplicadas em todos eles. Manter sincronizado manualmente é trabalho repetitivo propenso a erro — uma vez que você esquece de aplicar a mudança em um site, esse site perde receita silenciosamente até alguém perceber.

Foi pra resolver isso que o IAB adicionou delegação à especificação.

Delegação de ads.txt: o que é e como funciona

Delegação é, na essência, terceirizar a hospedagem do arquivo. Em vez de você manter o conteúdo no seu servidor, um parceiro hospeda o arquivo no servidor dele e mantém atualizado automaticamente. Seu domínio apenas redireciona pra lá.

Não é truque nem workaround — está explicitamente previsto na spec do IAB Tech Lab. Quando um crawler faz GET em seusite.com.br/ads.txt, seu servidor pode responder com HTTP 301 (Moved Permanently) ou 302 (Found) apontando pra outro URL. O crawler segue o redirecionamento, lê o arquivo no destino, e considera aquele conteúdo como o ads.txt válido do seu domínio.

Do ponto de vista do comprador, é transparente. Pra todos os efeitos, o arquivo do destino é o seu ads.txt.

A variável MANAGERDOMAIN (spec v1.1)

A versão 1.1 da especificação introduziu uma linha especial pra sinalizar delegação explícita:

MANAGERDOMAIN=adstxt.parceiro.com

Quando essa linha aparece no arquivo hospedado pelo parceiro, ela declara formalmente que aquele domínio é o gestor autorizado do ads.txt. Crawlers e validadores reconhecem isso como sinal padronizado de delegação ativa — em vez de inferir do redirecionamento, leem a declaração explícita.

Nem todos os crawlers checam MANAGERDOMAIN ainda em 2026, mas o suporte está crescendo. Vale ter no arquivo se seu parceiro de delegação implementa.

Como configurar delegação na prática

O processo, em três passos:

1. Importar o ads.txt atual pro painel do parceiro

O parceiro (Clickio, MonetizeMore, Setupad, ou qualquer outro que ofereça o serviço) lê o seu ads.txt atual. Separa o que é deles (as SSPs conectadas via deles) do que é seu (AdSense direto, deals diretos, outras parcerias). Mantém ambas as listas combinadas.

2. Revisar e publicar o arquivo combinado

Você pode editar suas linhas (AdSense, outros parceiros) pelo painel do parceiro. Quando estiver tudo certo, o arquivo é publicado em um URL controlado pelo parceiro — algo como https://adstxt.parceiro.com/seusite.com.br/ads.txt.

3. Configurar redirecionamento 301 no seu servidor

Você configura no servidor (Apache, Nginx, Cloudflare, etc.) um redirecionamento permanente:

Origem: https://seusite.com.br/ads.txt
Destino: https://adstxt.parceiro.com/seusite.com.br/ads.txt
Status: 301

A partir desse momento, quando um crawler pede /ads.txt do seu domínio, ele é redirecionado pro arquivo hospedado pelo parceiro. Toda mudança feita pelo parceiro reflete instantaneamente — sem você tocar em nada.

Quando delegação faz sentido (e quando não)

Delega:

• Você tem 3+ sites ou planeja escalar pra múltiplos domínios
• Trabalha com parceiro MCM/GCPP que muda fontes de demanda com frequência
• Não tem equipe técnica disponível pra manutenção rápida de arquivos
• Já teve queda de receita por ads.txt desatualizado

Mantém manual:

• Tem um único site
• Stack programático estável (mesmas 3-5 SSPs há meses)
• Tem capacidade interna pra atualizar arquivo em horas quando necessário
• Não quer dependência adicional em terceiros
• Quer auditoria visual direta do arquivo sem precisar logar em plataforma externa

A escolha não é binária. Muitos publishers fazem delegação parcial: as linhas do parceiro principal são delegadas, mas o ads.txt no servidor próprio adiciona linhas estáticas (AdSense, deals diretos) acima do redirecionamento. Tecnicamente isso requer servir o arquivo combinado em vez de redirecionar — algumas plataformas suportam, outras não.

Sellers.json: o complemento que ninguém menciona

Ads.txt sozinho conta metade da história. Ele autoriza venda; sellers.json identifica quem está vendendo.

Sellers.json é um arquivo público que cada SSP/ad exchange publica no domínio dela (ex: https://sellers.indexexchange.com/sellers.json) listando todos os publishers que ela representa. Compradores cruzam as duas informações:

• Ads.txt do publisher: “fulano de SSP X está autorizado a me representar”
• Sellers.json do SSP X: “esse account ID corresponde ao publisher fulano”

Se as informações cruzam, lance válido. Se não cruzam (ou se um deles está inconsistente), lance descartado.

O ponto pra publishers: você não controla o sellers.json — o SSP controla. Mas precisa verificar. Após cadastrar com um SSP novo, confira que seu domínio e account ID aparecem corretamente no sellers.json deles em até alguns dias. Inconsistências entre o que está no seu ads.txt e o sellers.json da SSP geram a mesma queda silenciosa de receita.

Validadores como o adstxt-crawler do IAB checam ambos automaticamente. Vale rodar uma vez por trimestre.

Como auditar seu ads.txt

Auditoria periódica é higiene básica. Sugestão de cadência: rápida toda vez que mudar o stack, completa uma vez por trimestre.

Auditoria rápida (5 minutos)

1. Acesse https://seusite.com.br/ads.txt no navegador. Verifique que o arquivo aparece como texto puro, sem HTML, sem erro.
2. Compare a lista de linhas com a lista de SSPs ativos no seu Prebid/header bidding. Toda SSP ativa precisa estar declarada.
3. No GAM, vá em Inventário → Diagnóstico do Ads.txt e veja se há alertas.

Auditoria completa (30-60 minutos)

1. Liste todas as SSPs/redes que efetivamente geram receita no último mês (relatório do GAM por rede)
2. Cruze com as linhas do ads.txt — toda rede ativa precisa ter linha correspondente
3. Identifique linhas órfãs — SSPs declaradas que não geram receita há 90+ dias podem ser removidas
4. Use um validador externo (adstxt.guru, adstxt-validator.com, ou similar) pra checar sintaxe e cruzar com sellers.json
5. Verifique subdomínios — m.seusite.com.br, blog.seusite.com.br, etc., todos têm ads.txt válido?
6. Confira que o servidor responde corretamente:
   • HTTP 200 OK
   • Content-Type: text/plain (ou tolerado)
   • Tempo de resposta razoável (< 2 segundos)
7. Se usa CDN, valide que o cache foi invalidado após a última atualização

Para fechar

Ads.txt é o tipo de detalhe técnico que separa publisher que trata monetização como prioridade de publisher que trata como afterthought. Não é glamoroso, não muda quanto tráfego você atrai, não aparece em case de sucesso. Mas afeta 10-30% da sua receita programática dependendo de quão desalinhado está com seu stack real.

A pergunta certa não é “preciso ter ads.txt?” — é “meu ads.txt está sincronizado com o que efetivamente roda no meu inventário hoje?”. Se você não consegue responder com certeza, vale a auditoria de 30 minutos. Se a resposta for “tem coisas desatualizadas há meses”, você está sangrando receita.

Pra publisher com um site e stack estável, gestão manual com auditoria trimestral resolve. Pra quem opera múltiplos sites ou trabalha com parceiro que muda fontes de demanda com frequência, delegação via HTTP 301 — uma técnica oficial do IAB, não atalho — vira ferramenta de produtividade real. A escolha entre uma e outra não é técnica; é organizacional. Quantos sites você tem, quanto a stack muda, quanto tempo tem pra dedicar à manutenção.

O que não muda é o resultado de ignorar ads.txt: receita escapando sem você saber. Em 2026, com toda DSP séria verificando o arquivo antes de licitar, não ter ads.txt impecável é o equivalente a deixar dinheiro na mesa por preguiça de atualizar um arquivo texto. Vale o pequeno trabalho de fazer direito.