Guia completo de arquivos txt e well-known na web: do ads.txt ao security.txt
Voltar para blog

Guia completo de arquivos txt e well-known na web: do ads.txt ao security.txt

25/09/2026 · 17 min · Infraestrutura

Arquivos de texto e a raiz do domínio: o que realmente importa#

Quando montei meu primeiro site, a raiz do domínio tinha meia dúzia de arquivos: a página inicial, uma folha de estilos e, no máximo, um robots.txt para evitar que robôs entrassem em diretórios privados.

Com o tempo, a web foi ficando cheia de regras silenciosas. Hoje, basta rodar uma ferramenta de auditoria de SEO para receber alertas dizendo que falta ads.txt. Abrir um fórum de tecnologia faz parecer que seu site é inseguro sem security.txt. E com a explosão de modelos de linguagem, começaram a surgir manifestos novos como llms.txt.

Fiquei curioso para entender o que é obrigatório, o que é apenas recomendado e o que é puro mito propagado por tutoriais desatualizados. Resolvi testar cada uma dessas regras no meu servidor, vasculhar registros da IANA, auditar requisições de grandes portais com o curl e documentar a realidade prática de cada arquivo.

Aqui está o mapa completo de arquivos de texto plano (.txt, manifestos sem extensão e formatos JSON estáticos) que circulam pela web, com URLs ativas em produção para você testar no seu próprio navegador ou terminal.

1) Indexação e motores de busca: robots, sitemaps e o velho urllist#

Estes são os arquivos que conversam diretamente com rastreadores de busca para definir o que pode ser lido e onde encontrar a lista completa de páginas.

robots.txt: o porteiro clássico#

O arquivo /robots.txt é a convenção mais antiga e universal da web. Ele informa aos rastreadores (Googlebot, Bingbot e dezenas de outros) quais diretórios do seu domínio estão liberados e quais devem ser ignorados.

Se você quiser ver um exemplo gigantesco em produção, pode abrir o Google Brasil robots.txt. A estrutura básica que a maioria dos sites adota segue este modelo:

User-agent: *
Disallow: /search
Disallow: /admin/
Disallow: /temp/

Sitemap: https://www.google.com.br/sitemap.xml

Na prática: é indispensável para qualquer site público. Mesmo que você queira indexar tudo, ter um arquivo com a diretiva do sitemap acelera a descoberta de conteúdo novo.

sitemap.xml e a alternativa sitemap.txt#

A maioria das pessoas só conhece sitemaps em formato XML, como o Google Sitemap. O que pouca gente lembra é que a especificação oficial do protocolo aceita um arquivo de texto simples: o sitemap.txt.

Ele não aceita tags, cabeçalhos nem metadados de data (lastmod). É simplesmente uma lista de URLs completas, uma por linha, codificada em UTF-8:

https://perciocastelo.com.br/
https://perciocastelo.com.br/sobre/
https://perciocastelo.com.br/blog/

Um exemplo aberto clássico pode ser conferido em repositórios públicos como o englishextra urllist.txt.

Na prática: o Google Search Console aceita sitemaps em .txt perfeitamente. Se você mantém um site estático pequeno e não quer gastar tempo gerando árvores XML, uma lista de texto puro resolve o problema em segundos.

urllist.txt: a herança do Yahoo!#

Nos anos 2000, quando os buscadores começaram a aceitar sitemaps, o Yahoo! Search / Yahoo! Site Explorer exigia que listas de texto puro fossem batizadas obrigatoriamente como urllist.txt (ou compactadas como urllist.txt.gz).

Quando o Yahoo! abandonou seu próprio motor e se uniu à infraestrutura do Bing, a obrigatoriedade dessa nomenclatura caiu. Hoje em dia, o Google e o Bing aceitam qualquer arquivo .txt, mas o nome urllist.txt ainda aparece em projetos legados e documentações antigas.

robots-staging.txt: proteção de homologação#

Em ambientes de teste ou homologação (como subdomínios dev. ou staging.), a regra é o isolamento total. O arquivo /robots.txt nesses subdomínios costuma ter apenas duas linhas:

User-agent: *
Disallow: /

Na prática: é um cuidado básico para evitar que o Google indexe versões inacabadas do seu projeto ou penalize seu site principal por conteúdo duplicado.

2) Modelos de linguagem e bots de IA: llms.txt e a fantasia do ai.txt#

Com o surgimento de chatbots e agentes de busca orientados a IA, surgiram arquivos específicos para alimentar essas ferramentas sem o peso do HTML.

llms.txt: o sumário em Markdown#

Criado pela Answer.AI, o /llms.txt é um índice enxuto em Markdown puro colocado na raiz do site ou na raiz da documentação. Robôs de IA consomem muitos tokens tentando extrair texto de layouts cheios de JavaScript, menus e CSS. Esse arquivo entrega um resumo do projeto e links diretos para os conteúdos essenciais.

Exemplos conhecidos em produção:

A estrutura típica é objetiva:

# Anthropic Documentation
> Anthropic is an AI safety and research company that builds reliable, beneficial AI systems.

## Core Documentation
- [Quickstart Guide](https://docs.anthropic.com/en/docs/quickstart): Get started building with Claude.
- [Prompt Engineering](https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering): Best practices.
- [API Reference](https://docs.anthropic.com/en/api): Complete technical reference.

Na prática: se você escreve tutoriais técnicos, mantém código aberto ou documentação de ferramentas, vale muito a pena colocar no ar. Ele ajuda assistentes de código e mecanismos de busca de IA a citarem seus links com exatidão.

llms-full.txt: a documentação completa em um só arquivo#

Enquanto o llms.txt funciona como um mapa de navegação, o llms-full.txt concatena o conteúdo integral de toda a documentação em um arquivo único de texto. Modelos com grandes janelas de contexto (como Gemini e Claude) podem ler esse arquivo de uma vez só sem precisar fazer dezenas de requisições web.

Você pode conferir esse formato no arquivo da Anthropic llms-full.txt, que reúne páginas e exemplos em um arquivo contínuo de vários megabytes.

ai.txt: a proposta que morreu na praia#

Você talvez já tenha lido tutoriais recomendando criar um /ai.txt para proibir o treinamento de inteligência artificial sobre seus artigos. A verdade precisa ser dita de forma direta: o ai.txt nunca virou padrão na internet.

Nenhum dos grandes laboratórios (OpenAI, Google, Anthropic, Meta) lê esse arquivo. Iniciativas que tentaram promovê-lo (como spawning.ai ou o site ai.txt.org) deixaram os domínios caírem ou abandonaram a especificação. Colocar esse arquivo no servidor não tem efeito prático nenhum.

Quem realmente quer controlar bots de IA hoje usa dois caminhos reais:

  1. User-agents no robots.txt: Portais como The New York Times e grandes portais de notícias barram bots de IA direto no robots.txt tradicional:
User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Google-Extended
Disallow: /
  1. O padrão europeu tdmrep.json: Na União Europeia, veículos que reservam direitos autorais contra mineração de texto adotam o manifesto da W3C em /.well-known/tdmrep.json.

3) Segurança, criptografia e e-mail: security.txt, mta-sts e chaves públicas#

Aqui entram as normas formais da IETF (a maioria registrada sob a RFC 8615 dentro do diretório /.well-known/) para publicação de canais de contato e segurança de rede.

security.txt: contato para relatórios de falhas#

Padronizado pela RFC 9116, o arquivo /.well-known/security.txt resolve um problema recorrente: para onde enviar um alerta quando alguém descobre uma falha de segurança no seu site?

Sem ele, quem encontra uma vulnerabilidade precisa tentar a sorte em formulários gerais de suporte ou redes sociais.

Grandes empresas mantêm esse arquivo sempre ativo:

O modelo que uso no meu domínio inclui os campos essenciais:

Contact: mailto:[email protected]
Expires: 2027-12-31T23:59:59.000Z
Preferred-Languages: pt, en
Canonical: https://perciocastelo.com.br/.well-known/security.txt

Na prática: o campo Expires é obrigatório pela RFC para evitar instruções abandonadas no futuro. É um arquivo leve que recomendo para qualquer pessoa que mantenha um site no ar.

mta-sts.txt: TLS obrigatório no tráfego de e-mail#

O MTA-STS (RFC 8461) serve para proteger o tráfego de mensagens entre servidores de e-mail contra ataques de interceptação (downgrade para texto puro no protocolo SMTP).

A norma exige que ele fique no subdomínio dedicado mta-sts.<dominio> dentro do caminho /.well-known/mta-sts.txt e seja servido exclusivamente via HTTPS com certificado válido.

Dois exemplos em produção:

O conteúdo define os servidores MX e a política de aplicação:

version: STSv1
mode: enforce
mx: smtp.google.com
mx: *.aspmx.l.google.com
max_age: 604800

Na prática: se você gerencia o próprio servidor de correio e quer garantir que mensagens recebidas venham sempre cifradas por TLS, vale a pena configurar em conjunto com o registro DNS _mta-sts.

pgp-key.txt, pgp.asc e publickey.txt#

Disponibilizar a sua chave pública PGP/GPG em texto puro facilita para qualquer pessoa criptografar mensagens antes de enviar para os contatos do seu security.txt, ou auditar assinaturas de commits e pacotes.

Exemplos práticos:

O formato segue o bloco clássico delimitado por -----BEGIN PGP PUBLIC KEY BLOCK-----.

ssh-key.txt e os endpoints .keys#

Embora não seja uma RFC formal, hospedar chaves públicas SSH (id_ed25519.pub) em texto puro é um costume útil entre desenvolvedores.

O GitHub e o GitLab oferecem isso nativamente adicionando .keys no final de qualquer usuário:

Ao subir uma máquina virtual ou VPS nova, um comando direto resolve a autorização:

curl -s https://github.com/torvalds.keys >> ~/.ssh/authorized_keys

jwks.json: chaves públicas de tokens JWT#

Definido pela RFC 7517, o arquivo /.well-known/jwks.json expõe o conjunto de chaves públicas usado por um servidor de autenticação (IdP) para assinar JSON Web Tokens.

Exemplos em produção:

Na prática: permite que microsserviços e APIs validem tokens sem precisar de chaves secretas compartilhadas no backend. Quando as chaves sofrem rotação, os serviços consumidores apenas atualizam o cache do endpoint.

posh: verificação delegada de certificados#

O POSH (RFC 7711) reside em /.well-known/posh/ e atua na verificação delegada de certificados TLS/PKIX quando a aplicação não tem acesso aos registros TLSA do DNS. Seu uso é muito raro fora de redes federadas corporativas.

4) Publicidade e AdTech: a verdade sobre ads.txt, app-ads e sellers.json#

Aqui está o ponto onde donos de blogs mais perdem tempo por causa de avisos genéricos em painéis de auditoria.

ads.txt: útil para leilão, inútil para afiliados#

O ads.txt (Authorized Digital Sellers) foi criado pelo IAB Tech Lab para barrar fraudes em leilões programáticos de banners. Ele lista publicamente quais empresas têm permissão para vender espaços no seu domínio.

Exemplos reais:

O arquivo usa linhas separadas por vírgula:

google.com, pub-1234567890123456, DIRECT, f08c47fec0942fa0
appnexus.com, 1234, RESELLER, f5ab79cb980f11d1

A realidade prática:

app-ads.txt: a versão para aplicativos de celular#

É a mesma especificação do ads.txt, mas voltada para jogos e aplicativos em smartphones e smart TVs. Como o aplicativo instalado no celular não roda um servidor web, os compradores de mídia consultam a URL do desenvolvedor cadastrada na loja e buscam o arquivo /app-ads.txt na raiz daquele domínio.

Exemplos reais:

Se você não mantém um aplicativo móvel com blocos de anúncio nas lojas, não precisa dele.

sellers.json e buyers.json: o outro lado do leilão#

Enquanto o ads.txt fica no site do publicador, o sellers.json e o buyers.json ficam nos servidores das próprias redes de publicidade:

Eles servem para cruzar dados e comprovar quem recebeu dinheiro por cada impressão ou quem comprou determinado banner (ajudando a rastrear malvertising). Nenhum dono de site comum cria esses arquivos.

5) Identidade e o fediverso: atproto-did, did.json, webfinger e o abandono do humans.txt#

Arquivos em texto puro também servem para validar identidades em redes sociais e no ecossistema descentralizado.

atproto-did e did.json: domínio como arroba no Bluesky#

O AT Protocol (que move a rede Bluesky) permite que você use seu domínio pessoal como identificador oficial na rede (por exemplo, @perciocastelo.com.br).

A especificação prevê um arquivo simples em /.well-known/atproto-did contendo apenas uma linha com o seu DID (did:plc:abcdef...). No entanto, na prática, quase todo mundo (de usuários individuais ao New York Times) opta por criar um registro DNS TXT em _atproto.<dominio> em vez de subir o arquivo.

O motivo é simples: o resolvedor da rede testa o DNS primeiro. Se o DNS responder, a requisição HTTP nem chega a acontecer. Já a especificação geral da W3C para did:web utiliza o arquivo /.well-known/did.json, retornando um documento completo com chaves criptográficas:

keybase.txt: prova matemática de titularidade#

O Keybase foi pioneiro em usar um arquivo estático para provar posse de domínio. Em /.well-known/keybase.txt ou na raiz, o proprietário publica uma mensagem assinada via PGP vinculando seu nome de usuário ao domínio.

Você pode conferir a prova ativa no site do criador do Keybase: Chris Coyne keybase.txt.

webfinger: a lista telefônica do ActivityPub#

Padronizado pela RFC 7033, o WebFinger permite descobrir perfis e endereços de caixas de entrada no Fediverso (Mastodon, Lemmy, Threads) a partir de um identificador estilo e-mail (acct:usuario@dominio).

Um exemplo clássico pode ser consultado com o curl:

O servidor responde com um JSON contendo o link do perfil, a rota da API e as chaves públicas da conta.

host-meta e nodeinfo: metadados de servidores federados#

O /.well-known/host-meta (RFC 6415) ensina clientes externos como montar URLs para consultar serviços do servidor. Já o /.well-known/nodeinfo expõe estatísticas da instância (versão do software, usuários ativos e protocolos habilitados):

humans.txt e a lição do abandono digital#

O /humans.txt foi criado pelo movimento humanstxt.org em 2011 como uma ideia amigável: enquanto o robots.txt fala com robôs, o humans.txt apresentava os nomes das pessoas, designers e ferramentas que construíram o site.

Com o passar dos anos, o arquivo praticamente desapareceu. Grandes referências que mantinham o arquivo no ar (como MDN Web Docs e A List Apart) o removeram durante migrações para plataformas estáticas e CDNs. Até o site oficial da iniciativa (humanstxt.org) chegou a ficar com o arquivo quebrado.

Essa trajetória expõe uma regra clara da web: arquivos que sustentam máquinas e dinheiro (ads.txt, security.txt, jwks.json) são mantidos a qualquer custo, porque sua ausência gera perdas imediatas. Arquivos que dependem puramente de nostalgia ou capricho acabam descartados na primeira reformulação de repositório.

Quando você clica em um link no navegador do smartphone e ele abre direto no aplicativo instalado (em vez de carregar a página web), esses dois arquivos são os responsáveis pela mágica.

O arquivo /.well-known/assetlinks.json cria a ligação criptográfica entre o domínio web e o aplicativo Android. Ele impede que aplicativos falsificados roubem cliques ou interceptem tráfego do seu domínio:

Exemplos massivos em produção:

O conteúdo declara o pacote do app e a impressão digital SHA-256 do certificado de assinatura da Google Play:

[{
  "relation": [
    "delegate_permission/common.handle_all_urls",
    "delegate_permission/common.get_login_creds"
  ],
  "target": {
    "namespace": "android_app",
    "package_name": "com.instagram.android",
    "sha256_cert_fingerprints": [
      "0B:20:9B:6C:5F:8B:D8:0F:7B:6A:9C:12:4D:2E:3F:4A:5B:6C:7D:8E:9F:0A:1B:2C:3D:4E:5F:60:71:82:93"
    ]
  }
}]

No ecossistema iOS e macOS, o arquivo cumpre o mesmo papel sob o caminho /.well-known/apple-app-site-association:

Exemplos reais:

A Apple impõe requisitos muito estritos: o arquivo não pode ter extensão, deve retornar o cabeçalho Content-Type: application/json e o servidor precisa responder com HTTP 200 direto (qualquer redirecionamento 301 ou 302 invalida a checagem).

Ambos só são necessários se você publica e mantém aplicativos nativos para celular.

7) Validação de domínio e pagamentos: acme, buscadores e Apple Pay#

Provedores e autoridades de certificação frequentemente exigem pequenos arquivos temporários para provar que você é dono do servidor.

Desafio ACME HTTP-01#

Ao emitir certificados SSL/TLS gratuitos com o Let's Encrypt ou Certbot, o cliente cria um arquivo temporário em /.well-known/acme-challenge/<token>. O validador da autoridade faz uma requisição HTTP nesse caminho para confirmar o controle do domínio antes de liberar o certificado. Esse processo é totalmente automatizado.

Arquivos de verificação de buscadores#

Para comprovar que um site pertence a você sem mexer na zona DNS, ferramentas de webmasters oferecem o envio de arquivos estáticos:

Na prática: depois que a propriedade é confirmada no painel, a maioria dos times migra para verificação via registro DNS e remove o arquivo para não deixar arquivos soltos na raiz.

apple-developer-merchantid-domain-association#

Quem habilita pagamentos com Apple Pay no navegador precisa subir um arquivo binário PKCS #7 assinado pela Apple em /.well-known/apple-developer-merchantid-domain-association. Sem essa assinatura, o Safari se recusa a exibir o botão oficial de pagamento:

8) Políticas de rede e descoberta: caldav, traffic-advice e telemetria#

Manifestos em /.well-known/ também ajudam clientes de rede a descobrir serviços internos ou definir como navegadores pré-carregam dados.

caldav e carddav: atalho para agendas e contatos#

Definido pela RFC 6764, o caminho /.well-known/caldav não entrega um arquivo estático. Ele funciona como um redirecionamento HTTP 301 ou 307 que aponta para a URL real do servidor WebDAV da sua organização.

Aplicativos de calendário do iPhone, Mac ou Thunderbird consultam esse endereço para descobrir sozinhos onde a API de sincronização está rodando:

traffic-advice: controle de prefetch do Chrome#

O Google Chrome tenta pré-carregar páginas em segundo plano para que o clique em resultados de busca pareça instantâneo. O arquivo /.well-known/traffic-advice permite que o dono do site declare se aceita esse pré-carregamento especulativo ou se deseja limitar a taxa de requisições.

Curiosidade prática: se você testar google.com/.well-known/traffic-advice, receberá um erro 404. Isso acontece porque o Google Search é quem emite o prefetch, não o destino. Além disso, a regra da especificação diz que, se o site de destino der 404, o Chrome assume autorização padrão para pré-carregar.

network-error-logging e trust-tokens#

9) Privacidade e atalhos de navegador: gpc.json, senhas e revalidação de cache#

Padrões modernos criados para respeitar preferências de privacidade e melhorar a experiência do usuário.

gpc.json: Global Privacy Control#

O /.well-known/gpc.json é o manifesto oficial em que um site declara que respeita o sinal Global Privacy Control (GPC) enviado por navegadores focados em privacidade (como Brave e Firefox).

Grandes veículos de comunicação mantêm esse arquivo para cumprir exigências legais de proteção de dados (como a lei da Califórnia e a LGPD):

O arquivo é bem direto:

{
  "gpc": true,
  "version": 1,
  "last-update": "2024-01-15",
  "privacy-policy": "https://www.exemplo.com/privacy-policy"
}

O antigo dnt-policy.txt (Do Not Track da década passada) foi formalmente descontinuado pela W3C em 2019 e substituído pelo GPC.

change-password: o atalho dos gerenciadores de senhas#

Padronizado pela RFC 8615, o caminho /.well-known/change-password não tem conteúdo: é um redirecionamento temporário HTTP 302 apontando direto para a página de troca de senha da conta.

Quando o Chrome, o Safari, o 1Password ou o Bitwarden alertam que uma senha vazou na internet, eles exibem um botão que faz uma requisição direta nesse caminho:

Se o seu site tem área de membros ou login de usuários, configurar essa regra no Nginx ou Apache leva trinta segundos e melhora muito a usabilidade.

reload, revalidate e pay#

10) Monitoramento e esteira de deploy: health.txt, version.txt e licenças#

Nos bastidores de servidores próprios e esteiras de automação, arquivos estáticos simples facilitam o diagnóstico sem onerar recursos da máquina.

health.txt e status.txt: sondas de vida ultra-leves#

Para saber se o servidor web está online, consultar uma rota pesada que bate no banco de dados a cada dez segundos desperdiça memória.

Um simples arquivo /health.txt contendo a palavra OK permite que monitores externos (como UptimeRobot) verifiquem a saúde do servidor com consumo quase zero:

location = /health.txt {
    access_log off;
    default_type text/plain;
    return 200 "OK\n";
}

O /status.txt segue a mesma linha, mas pode incluir métricas do servidor ou conexões ativas.

version.txt e build.txt: a assinatura do deploy#

Em esteiras de CI/CD, é uma excelente prática gerar um arquivo /version.txt estático contendo o hash do Git e a data do deploy:

version=2.18.4
commit_sha=a3f92b71c82d90ef01b88e458e0a7df8921a9c4b
build_time=2026-09-25T23:58:12Z
branch=main

Com um simples curl, qualquer pessoa da equipe sabe exatamente qual commit está em produção sem precisar abrir painéis de hospedagem. O build.txt cumpre papel similar, registrando detalhes da esteira que gerou o binário para fins de auditoria de software.

LICENSE.txt, CHANGELOG.txt e AUTHORS.txt#

A trindade clássica do código aberto. Em projetos web, ferramentas de build frequentemente empacotam um LICENSE.txt ou 3rdpartylicenses.txt na raiz pública para cumprir as cláusulas legais de redistribuição de bibliotecas JavaScript usadas no frontend.

O filtro prático: o que deixei no meu site e o que você pode ignorar#

Depois de testar cada uma dessas regras na prática, a constatação é direta: a maioria esmagadora dos avisos automáticos de auditoria não passa de ruído.

No meu próprio domínio, reduzi os arquivos a um conjunto que realmente entrega valor:

  1. robots.txt: Essencial para guiar buscadores e indicar o sitemap.
  2. security.txt: Fundamental dentro de /.well-known/ para dar um canal sério de contato a pesquisadores.
  3. llms.txt: Uma adição limpa na raiz para orientar assistentes e robôs de IA modernos.
  4. health.txt e version.txt: Bastidores operacionais leves para monitorar o servidor e conferir versões pelo terminal.
  5. atproto-did: Apenas se você quiser seu domínio no Bluesky (embora validar pelo DNS seja ainda mais rápido).

Todo o resto só faz sentido se o seu projeto ativamente utiliza aquela funcionalidade:

Manter a raiz do servidor limpa, protegida por uma camada de borda como o Cloudflare e com apenas os manifestos que o seu projeto realmente consome, poupa dor de cabeça e evita que você perca tempo perseguindo avisos que não têm relação com a sua realidade.

Prompt pronto para auditar seu projeto com IA e exportar relatório em PDF#

Para que você não precise conferir manualmente arquivo por arquivo em cada site ou repositório que administra, estruturei um prompt técnico pronto para uso.

A ideia é simples: copie o bloco de instruções abaixo e cole diretamente na sua ferramenta de inteligência artificial favorita (como Claude, ChatGPT, Gemini ou DeepSeek). A IA assumirá a postura de um especialista em arquitetura web e segurança, lerá o contexto das especificações deste guia, fará perguntas direcionadas sobre o seu projeto (ou analisará a URL e os arquivos que você enviar), filtrará o que realmente é aplicável para a sua stack, entregará os arquivos prontos com os dados do seu domínio e, ao final, gerará um relatório técnico estruturado com script para salvar em PDF.

Atue como um Arquiteto Web Sênior, Especialista em AppSec e Engenheiro de Padrões Web (RFCs e IANA).

Seu objetivo é auditar o meu projeto/domínio web e determinar com precisão cirúrgica quais arquivos de texto plano (.txt), manifestos na pasta /.well-known/ e padrões de metadados da web devem ser implementados, quais são opcionais recomendados e quais devem ser ESTRITAMENTE IGNORADOS para evitar poluição desnecessária na raiz do servidor.

Ao final da auditoria, você me entregará o conteúdo pronto de cada arquivo aplicável e um script executável autossuficiente (em Python com ReportLab / WeasyPrint) ou documento HTML/CSS responsivo com folha de estilo de impressão (@media print) para gerar um relatório executivo profissional em PDF com todos os resultados.

---

### ETAPA 1: COLETA DE DADOS DO PROJETO

Se eu ainda não informei na minha mensagem inicial, faça uma pausa e me pergunte:
1. Qual é o domínio principal do projeto (ex: meusite.com.br)?
2. Qual é a natureza do projeto? (Blog/portal de conteúdo, SaaS/aplicativo web, API REST/GraphQL, e-commerce, landing page estática, repositório open-source)?
3. Qual é a stack tecnológica? (WordPress, Next.js, Laravel, Django, Node.js puro, HTML estático, etc.)?
4. O site monetiza com redes programáticas de anúncios (Google AdSense, AdX, OpenX)?
5. O projeto possui aplicativo mobile nativo (Android/iOS) que exige Deep Linking?
6. O domínio hospeda servidor próprio de e-mail (Postfix, Exim) ou usa provedor terceirizado (Google Workspace, Proton, Fastmail)?
7. O domínio atua como provedor de identidade (OAuth 2.0 / OIDC) ou consome provedores externos?
8. Você tem repositório de código ou arquivos que gostaria de colar/enviar agora para análise direta?

(Caso eu já tenha fornecido essas informações ou a URL do site no início, pule as perguntas e execute a auditoria imediatamente).

---

### ETAPA 2: MATRIZ DE AUDITORIA TÉCNICA

Analise cada um dos seguintes arquivos e padrões com base na realidade técnica do meu projeto:

1. Indexação e Descoberta:
   - robots.txt (Regras de User-agent, Disallow, Allow e diretiva Sitemap)
   - sitemap.xml e sitemap.txt (Lista de URLs)
   - urllist.txt (Classificar como legado/dispensável ou explicar equivalência)

2. Inteligência Artificial e Modelos de Linguagem:
   - llms.txt (Sumário enxuto em Markdown na raiz ou /docs/)
   - llms-full.txt (Versão expandida para indexação por LLMs)
   - ai.txt (Classificar como mito/proposta não padronizada)

3. Publicidade Programática e AdTech:
   - ads.txt e app-ads.txt (Autorização IAB Tech Lab)
   - sellers.json e buyers.json (Apenas para intermediários/exchanges)

4. Segurança, Contato e RFCs:
   - /.well-known/security.txt (RFC 9116: Contact, Expires obrigatório, Canonical, Preferred-Languages, Policy, Encryption)
   - /.well-known/security.txt.sig (Assinatura digital PGP desanexada)
   - /.well-known/mta-sts.txt (RFC 8461 para servidores de e-mail próprios)
   - humans.txt (Créditos da equipe)

5. Chaves Criptográficas Públicas:
   - pgp-key.txt, pgp.asc ou /.well-known/openpgpkey/
   - publickey.txt ou chaves SSH autorizadas

6. Identidade, Federação e Redes Sociais:
   - /.well-known/jwks.json e openid-configuration (JSON Web Key Set e OIDC)
   - /.well-known/webfinger (RFC 7033 para Mastodon/Fediverse)
   - /.well-known/atproto-did (Verificação de domínio no Bluesky / AT Protocol)

7. Integração Mobile e Aplicações Nativas:
   - /.well-known/assetlinks.json (Android App Links)
   - /.well-known/apple-app-site-association (iOS Universal Links)

8. Operação, CI/CD e Observabilidade:
   - health.txt ou status.txt (Endpoints ultraleves para probes de uptime)
   - version.txt ou build.txt (Hash de Git e carimbo de esteira de deploy)
   - LICENSE.txt e 3rdpartylicenses.txt

---

### ETAPA 3: RELATÓRIO DE DIAGNÓSTICO E ARQUIVOS GERADOS

Organize os resultados nas seguintes categorias claras:
- CRÍTICO / OBRIGATÓRIO: Arquivos indispensáveis para o tipo de projeto informado.
- RECOMENDADO: Boas práticas que agregam segurança, visibilidade de IA ou observabilidade sem ônus de manutenção.
- DISPENSÁVEL / NÃO APLICÁVEL: Arquivos que NÃO devem ser criados, com justificativa técnica direta para evitar perda de tempo e alarmes falsos de SEO/segurança.

Para cada arquivo classificado como Crítico ou Recomendado:
1. Forneça o caminho exato onde o arquivo deve ser salvo (ex: /public_html/.well-known/security.txt).
2. Entregue o código completo, validado e com sintaxe perfeita, já preenchido com as informações reais do meu domínio.
3. Se necessário, forneça o bloco de configuração do servidor web (Nginx, Apache ou regras de cabeçalho do Cloudflare) para servir Content-Type: text/plain; charset=utf-8.

---

### ETAPA 4: GERADOR DE RELATÓRIO EXECUTIVO EM PDF

Para documentar a auditoria perante a equipe, cliente ou liderança técnica, gere ao final:
1. O relatório completo formatado.
2. Um script autônomo em Python (utilizando a biblioteca reportlab ou weasyprint) OU uma estrutura HTML5/CSS3 autônoma com estilos @media print prontos para abrir no navegador e salvar via Ctrl + P -> "Salvar como PDF".
O documento deve conter:
- Cabeçalho executivo com nome do domínio, data da auditoria e versão do relatório.
- Tabela resumo com o status de cada arquivo (Obrigatório, Recomendado, Dispensável).
- Blocos de código dos arquivos recomendados.
- Recomendações de segurança e cabeçalhos HTTP.

Este artigo foi útil?

Deixe uma reação rápida para apoiar o conteúdo:

Veja também

Infraestrutura Por que separar sitemaps: arquitetura de índice para SEO técnico
Infraestrutura Anatomia de um SIGKILL no login failure daemon: depurando a falha de inicialização do LFD no Linux
Infraestrutura A ilusão do `sshd_config`: como realmente garantir a segurança da autenticação SSH no cPanel/CloudLinux
CC BY-NC

Este post está licenciado sob CC BY-NC.

Comentários

Participe da discussão abaixo.

Ao comentar, você concorda com nossos Termos de Uso e Política de Privacidade.

0 comentários