Arquivos de verificação no edge: ads.txt, security.txt, AASA e assetlinks.json
Alguns arquivos precisam ficar na raiz ou em /.well-known/. Se CMS, loja ou site builder dificultam isso, uma resposta edge pode servir tudo com status e Content-Type corretos.
A parte chata de um arquivo de verificação raramente é o conteúdo. É o caminho.
Ad ops precisa de ads.txt na raiz. Segurança precisa de security.txt em /.well-known/. Mobile precisa de apple-app-site-association. Android precisa de assetlinks.json. Um CMS, loja ou site builder pode ser ótimo para páginas e péssimo para essas URLs específicas.
Daí uma campanha, app, verificação de anúncio ou migração fica travada por um arquivo pequeno.
Se você está mexendo em Universal Links ou Android App Links, deixe Como configurar Universal Links e App Links depois do Firebase por perto. Aqui o foco é a entrega dos arquivos.
O problema da raiz e do .well-known
Os arquivos são pequenos, mas as plataformas que verificam costumam ser exigentes.
Erros comuns:
- o CMS não permite arquivo na raiz
/.well-known/cai no roteamento da aplicação- um redirect entra antes do arquivo
- o Content-Type sai errado
- ninguém sabe quem atualiza depois do lançamento
O edge ajuda porque responde exatamente na rota esperada, sem transformar o site todo em projeto de infraestrutura.
Cada arquivo tem um papel
ads.txt e app-ads.txt
Esses arquivos servem para transparência de anúncios e inventário autorizado. Devem ser fáceis de buscar:
- rota direta
- resposta
200 - texto simples
- owner claro
Se ficam atrás de login, redirect ou fallback do CMS, a validação pode falhar.
security.txt
security.txt informa como reportar vulnerabilidades. Em muitas empresas, isso fica dividido entre segurança, jurídico, web e plataforma.
Uma resposta edge deixa explícitos caminho, corpo, Content-Type e responsável.
apple-app-site-association
Universal Links da Apple dependem do arquivo AASA no lugar certo. Quando ele falha, o time pode perder tempo investigando o app, quando o problema está na entrega do arquivo.
assetlinks.json
Android App Links precisa de um assetlinks.json válido. Se o arquivo está ausente, desatualizado ou reescrito pelo site builder, a verificação de domínio fica instável.
O que a resposta edge precisa acertar
Ela não precisa ser sofisticada. Precisa ser exata.
| Arquivo | Caminho típico | Requisito | Erro comum |
|---|---|---|---|
ads.txt | /ads.txt | 200, texto, conteúdo estável | colocar atrás de redirect ou login |
app-ads.txt | /app-ads.txt | 200, texto, inventário app | esquecer o inventário do app |
security.txt | /.well-known/security.txt ou /security.txt | 200, texto, contato atualizado | root sem dono |
apple-app-site-association | /.well-known/apple-app-site-association ou /apple-app-site-association | 200, JSON, corpo exato | Content-Type ou caminho errado |
assetlinks.json | /.well-known/assetlinks.json | 200, JSON, corpo exato | rota reescrita pelo CMS |
Se uma plataforma pedir outro caminho exato, siga a documentação dela. O importante é manter o contrato verificável.
Não esconda esses arquivos atrás de redirects
Para verificação, direto costuma ser melhor.
Um hop a mais cria outro ponto de falha. Também dificulta explicar por que a validação passou ontem e falhou hoje.
Use redirect só se o consumidor aceitar claramente. Caso contrário, sirva o arquivo direto.
Defina dono e revisão
Esses arquivos quebram porque ninguém se sente responsável depois do lançamento.
Modelo simples:
- ad ops cuida de
ads.txteapp-ads.txt - mobile engineering cuida de AASA e
assetlinks.json - segurança ou plataforma cuida de
security.txt - web/platform cuida de rota, status e Content-Type
Em troca de CMS, rebrand ou app novo, isso economiza muito retrabalho.
Operação prática
- escolher o caminho exato de cada arquivo
- definir corpo e Content-Type
- servir direto no edge
- documentar owner e data de revisão
- testar com o consumidor real, não só no navegador
Isso é útil quando você não quer abrir deploy do site para um arquivo root.
Onde a UrlEdge entra
O Custom Response Tool da UrlEdge pode servir respostas de texto ou JSON no edge.
Funciona bem quando:
- o origin não lida bem com raiz ou
.well-known - você precisa de
200direto - Content-Type e corpo precisam ser controlados
- o domínio já usa UrlEdge para redirects ou regras
Não substitui a implementação completa de deep links. Remove a fricção de hospedar os arquivos certos.
FAQ
Esses arquivos precisam ficar no origin?
Não. Precisam estar disponíveis na rota esperada. Se o origin não faz isso bem, o edge é uma alternativa prática.
Posso redirecionar esses arquivos?
Só se a plataforma que verifica aceitar. Resposta direta é mais robusta.
Por que não deixar no CMS?
Muitos CMS lidam bem com páginas e mal com raiz ou /.well-known/. Essa é a lacuna.
Isso é só para apps?
Não. AASA e assetlinks.json são de apps, mas ads.txt, app-ads.txt e security.txt são de publicidade e segurança.
Referências
Sirva arquivos de verificação sem mexer no origin
Publique arquivos root e .well-known no edge com status, Content-Type e responsável definidos.
Ver respostas edgeArtigos relacionados
Ver tudo
www, domínio raiz e wildcard forwarding sem quebrar SEO
Normalizar host parece simples até raiz, www, subdomínios, caminhos e query strings seguirem regras diferentes. Uma política clara mantém a URL canônica estável.
Link firewall para tráfego pago e afiliados: bots, proxies e cliques ruins
Nem todo clique ruim é fraude, mas todo clique ruim pode custar verba, comissão e qualidade de relatório. Um link firewall decide o que acontece antes do tráfego chegar ao destino.