Recurso aberto · versão 2026.11
Checklist From Code to Production
Um software está pronto para produção quando passa nos itens essenciais deste checklist. São 55 itens em 7 pilares, os mesmos que a WIP confere num diagnóstico técnico. 24 deles podem ser verificados de fora, sem acesso ao sistema.
Atualizado em
Como usar este checklist?
Comece pelos itens marcados como essenciais: sem eles, o sistema funciona até o primeiro incidente sério. Depois avance para os recomendados e, se o negócio depende do sistema o tempo todo, para os avançados. Cada item diz por que importa, como conferir e qual norma ou documentação oficial o sustenta.
Se preferir que alguém confira por você, o WIP Check passa por todos os pilares e entrega um plano de ação priorizado.
Deploy e ambientes
Publicar uma nova versão é um processo repetível, documentado e com caminho de volta.
-
O deploy para produção é automatizado e repetível
Por que importa: Deploy feito à mão depende da memória de quem faz e falha nos detalhes. Um processo automatizado executa sempre os mesmos passos, na mesma ordem.
Como conferir: Pergunte: se a pessoa que costuma publicar ficar indisponível, outra consegue publicar seguindo só o que está no repositório? Procure o pipeline (por exemplo, em .github/workflows) ou o script de deploy versionado.
-
Existe um caminho testado para voltar à versão anterior
Por que importa: Toda mudança pode dar errado. Saber reverter rápido transforma um incidente longo em um susto curto.
Como conferir: Peça para alguém executar a reversão em um ambiente de teste e cronometre. Confira se as migrações de banco de dados também têm caminho de volta ou são compatíveis com a versão anterior do código.
-
Produção é separada de desenvolvimento e testes, com dados e credenciais próprios
Por que importa: Testar em produção arrisca os dados reais dos clientes, e credenciais compartilhadas fazem um erro de teste atingir o sistema verdadeiro.
Como conferir: Compare as variáveis de ambiente de cada ambiente: banco de dados, chaves de API e serviço de e-mail de produção não podem aparecer em desenvolvimento nem em testes.
-
Código, configuração e dependências estão versionados, e a versão em produção é identificável
Por que importa: Sem histórico, não dá para saber o que mudou antes de um problema nem recuperar uma versão que funcionava. Sem lockfile, o mesmo código pode instalar dependências diferentes a cada deploy.
Como conferir: Confira se o repositório Git contém o código, a configuração (sem segredos), os scripts de deploy e o lockfile de dependências (package-lock.json, bun.lock, poetry.lock ou equivalente), e se a versão no ar corresponde a um commit ou tag conhecido.
-
Testes automatizados rodam antes de cada deploy e bloqueiam a publicação se falharem
Por que importa: Testes pegam regressões antes do usuário. Se uma falha não impede o deploy, o teste vira decoração.
Como conferir: Abra a configuração do pipeline e confirme que a etapa de testes vem antes da publicação e que uma falha interrompe o processo. Faça um teste falhar de propósito em um branch para ver o bloqueio acontecer.
-
Há documentação de operação: como publicar, reverter, ver os logs e quem acionar
Por que importa: No meio de um incidente ninguém tem tempo de ler o código para descobrir onde estão os logs. Um documento curto evita depender de uma única pessoa.
Como conferir: Procure um README ou runbook com os passos de deploy, reversão, acesso aos logs, restauração de backup e contatos. Peça para alguém que não montou o ambiente seguir o documento.
-
O ambiente pode ser recriado a partir de arquivos versionados (infraestrutura como código)
Por que importa: Servidores configurados à mão acumulam ajustes que ninguém lembra. Com infraestrutura como código, recriar o ambiente depois de uma perda é um procedimento, não uma investigação.
Como conferir: Pergunte: se o servidor ou a conta sumisse hoje, quanto do ambiente seria recriado a partir do repositório, com Terraform, OpenTofu, Ansible, Docker Compose ou ferramenta equivalente?
Referência: OWASP: Infrastructure as Code Security Cheat Sheet
Segurança e acessos
Só quem precisa tem acesso, os segredos ficam fora do código e o tráfego é sempre protegido.
-
Todo o site usa HTTPS: o acesso por HTTP redireciona e o cabeçalho HSTS está ativo
Por que importa: Sem HTTPS, senhas, cookies e dados de formulário trafegam legíveis para quem estiver no caminho. O HSTS faz o navegador usar HTTPS mesmo quando alguém digita http:// ou segue um link antigo.
Como conferir: Rode curl -I http://exemplo.com.br e confira um redirecionamento permanente (301 ou 308) para https://. Depois, rode curl -sI https://exemplo.com.br e procure strict-transport-security com max-age longo, como 31536000 (um ano).
Referência: RFC 6797: HTTP Strict Transport Security (HSTS)
-
As respostas HTTP incluem os cabeçalhos de segurança básicos
Por que importa: Esses cabeçalhos impedem que o navegador interprete arquivos do jeito errado, limitam o que vaza para outros sites e evitam que a página seja embutida em sites de terceiros para enganar quem usa.
Como conferir: Rode curl -sI https://exemplo.com.br e confira x-content-type-options: nosniff, uma referrer-policy (como strict-origin-when-cross-origin) e proteção contra enquadramento, com frame-ancestors na CSP ou x-frame-options.
Referência: OWASP: HTTP Security Response Headers Cheat Sheet
-
A página define uma Content-Security-Policy que restringe a origem dos scripts
Por que importa: Uma CSP restritiva reduz o estrago de uma injeção de script (XSS), porque o navegador recusa código que não veio de origens autorizadas.
Como conferir: Rode curl -sI https://exemplo.com.br e confira o cabeçalho content-security-policy. O script-src não deve depender de 'unsafe-inline'; prefira nonces ou hashes.
Referência: MDN: Content Security Policy (CSP)
-
Nenhum segredo está no código nem no histórico do repositório
Por que importa: Segredo que entra no Git continua no histórico mesmo depois de apagado, e qualquer pessoa com acesso ao repositório, ou a uma cópia vazada dele, passa a ter a chave.
Como conferir: Rode uma ferramenta de varredura de segredos, como gitleaks ou trufflehog, no repositório inteiro, incluindo o histórico. Segredo encontrado deve ser trocado e revogado, não só apagado.
Referência: OWASP: Secrets Management Cheat Sheet
-
Contas administrativas usam autenticação em dois fatores
Por que importa: Uma senha vazada não pode bastar para tomar o domínio, apagar o servidor ou publicar código em seu nome.
Como conferir: Liste as contas com poder administrativo (nuvem, registrador de domínio, repositório, e-mail, meio de pagamento) e confira em cada uma se o segundo fator está ativo, de preferência com aplicativo autenticador ou chave de segurança.
Referência: OWASP: Multifactor Authentication Cheat Sheet
-
Cada pessoa e cada sistema têm só os acessos de que precisam
Por que importa: Acesso sobrando é risco sem benefício: amplia o estrago de uma conta invadida ou de um erro, e acessos de quem já saiu continuam abertos.
Como conferir: Exporte a lista de usuários e chaves com acesso à nuvem, ao banco de dados, ao repositório e ao painel administrativo e compare com quem realmente trabalha no sistema hoje. Remova o que não tiver dono.
-
As regras de acesso aos dados são verificadas no servidor ou no banco, não só na interface
Por que importa: Esconder um botão não protege nada, porque qualquer pessoa pode chamar a API diretamente. Se o navegador acessa o banco de dados direto, as regras de segurança por linha precisam estar ativas.
Como conferir: Com uma conta comum, tente abrir pela API ou pelo endereço direto um registro de outro usuário. Em bancos acessados pelo navegador, confirme que todas as tabelas têm políticas de acesso por linha (row level security) ativas.
Referência: OWASP: Authorization Cheat Sheet
-
Dependências com vulnerabilidades conhecidas são identificadas e atualizadas
Por que importa: Bibliotecas de terceiros também têm falhas. Quando uma vulnerabilidade é publicada, quem não atualiza fica exposto a um ataque já documentado.
Como conferir: Rode npm audit, pip-audit, composer audit ou a ferramenta do seu ecossistema e ative alertas automáticos de dependências no repositório.
Referência: OWASP: Vulnerable Dependency Management Cheat Sheet
-
O site publica /.well-known/security.txt com um contato para relatar falhas
Por que importa: Quem encontra uma vulnerabilidade precisa saber a quem avisar. Sem um canal, o aviso se perde ou vira exposição pública.
Como conferir: Acesse https://exemplo.com.br/.well-known/security.txt e confira se há um campo Contact válido e um campo Expires com data futura.
Referência: RFC 9116: A File Format to Aid in Security Vulnerability Disclosure
Dados, backup e recuperação
Os dados têm cópia fora do ambiente principal, e a restauração já foi testada, não apenas imaginada.
-
O banco de dados tem backup automático, com frequência compatível com a perda aceitável
Por que importa: Backup manual é esquecido justamente quando faz falta. A frequência define quanto trabalho se perde no pior caso.
Como conferir: Confira o agendamento (no provedor ou no cron), a data do último backup concluído e se a frequência atende à perda de dados aceitável (RPO) combinada.
-
Há cópia dos backups fora da conta e do servidor principais
Por que importa: Se o backup fica no mesmo servidor ou na mesma conta, uma falha, um erro humano ou uma conta invadida apaga os dados e as cópias de uma vez.
Como conferir: Localize onde os backups ficam guardados e confirme que ao menos uma cópia está em outra conta, outro provedor ou outra região, com credenciais diferentes e, de preferência, protegida contra exclusão durante o período de retenção.
-
A restauração do backup foi testada recentemente, com o tempo medido
Por que importa: Backup que nunca foi restaurado é uma hipótese. O teste revela cópias incompletas, senhas perdidas e passos esquecidos antes da emergência.
Como conferir: Restaure o backup mais recente em um ambiente separado, confira se a aplicação funciona com os dados restaurados e registre a data do teste e o tempo total.
-
Estão definidos o RPO (perda de dados aceitável) e o RTO (tempo para voltar ao ar)
Por que importa: Sem essas duas metas, não dá para escolher a frequência de backup nem a arquitetura de recuperação, e cada incidente vira negociação na hora.
Como conferir: Pergunte a quem responde pelo negócio: quanto de dados podemos perder? Quanto tempo podemos ficar fora do ar? Compare as respostas com o que o backup e o último teste de restauração entregam hoje.
-
Arquivos enviados pelos usuários também têm backup ou versionamento
Por que importa: Imagens, documentos e anexos geralmente ficam fora do banco de dados. Banco restaurado sem esses arquivos ainda é um sistema quebrado.
Como conferir: Descubra onde ficam os uploads (disco do servidor ou armazenamento de objetos) e confirme que esse local entra na rotina de backup ou tem versionamento ativo.
-
O banco de dados não aceita conexões diretas da internet
Por que importa: Banco aberto para a internet pode ser encontrado por varreduras automáticas, e então basta uma senha fraca ou uma falha não corrigida.
Como conferir: Confira as regras de firewall ou do grupo de segurança: a porta do banco (por exemplo, 5432 no PostgreSQL ou 3306 no MySQL) deve aceitar conexões só da aplicação ou de uma rede privada.
Referência: OWASP: Database Security Cheat Sheet
-
Os dados pessoais estão mapeados: quais são, onde ficam, por quanto tempo e quem acessa
Por que importa: A LGPD exige saber o que se faz com dados pessoais. Sem esse mapa, não há como atender ao pedido de um titular nem medir o tamanho de um vazamento.
Como conferir: Liste as tabelas, planilhas e serviços que guardam nome, e-mail, telefone, documento ou localização e anote, para cada um, a finalidade, o prazo de retenção e quem tem acesso.
Referência: Lei nº 13.709/2018 (LGPD)
Monitoramento e incidentes
Você descobre o problema antes do cliente e sabe o que fazer quando ele acontece.
-
Um monitor externo verifica o site e a API e avisa quando param de responder
Por que importa: Sem monitor, quem avisa da queda é o cliente, e às vezes ele simplesmente desiste e não avisa.
Como conferir: Confira se existe uma verificação periódica, feita de fora da sua infraestrutura, para as páginas e os endpoints principais. Derrube um ambiente de teste monitorado e veja se o alerta chega.
-
Os alertas chegam a uma pessoa responsável, por um canal que ela acompanha
Por que importa: Alerta que cai numa caixa de e-mail sem dono é igual a não ter alerta.
Como conferir: Dispare um alerta de teste e veja quem recebe, por qual canal (e-mail, chat, telefone) e em quanto tempo alguém reage. Confira também quem cobre férias e fins de semana, se o negócio exigir.
-
O certificado TLS renova sozinho, e a data de expiração é monitorada
Por que importa: Certificado vencido faz o navegador bloquear o site com um aviso de segurança, e é uma falha totalmente evitável.
Como conferir: Rode echo | openssl s_client -connect exemplo.com.br:443 -servername exemplo.com.br 2>/dev/null | openssl x509 -noout -enddate e confira a data. A renovação deve ser automática, com alerta se faltar pouco para vencer.
Referência: OWASP: Transport Layer Security Cheat Sheet
-
Os logs ficam guardados fora do servidor, pesquisáveis e com prazo de retenção definido
Por que importa: Investigar o erro de ontem é impossível se os logs ficaram no servidor que foi recriado ou se só existem na tela de quem rodou o comando.
Como conferir: Tente encontrar os erros de um dia específico da semana passada e veja quanto tempo leva. Confira também se os logs não guardam senhas, tokens ou dados pessoais desnecessários.
Referência: OWASP: Logging Cheat Sheet
-
Os erros da aplicação são capturados com contexto: rota, versão e mensagem
Por que importa: Erro sem contexto vira adivinhação. Com a rota, a versão e a pilha de chamadas, a correção começa no lugar certo.
Como conferir: Provoque um erro de propósito em um ambiente de teste e confira se ele aparece na ferramenta de rastreamento de erros com rota, versão e horário.
-
Tempo de resposta, taxa de erros e uso de recursos são medidos e têm histórico
Por que importa: Sem histórico, não dá para saber se o sistema piorou, desde quando, nem se a última mudança ajudou ou atrapalhou.
Como conferir: Abra o painel de métricas e tente responder: qual era o tempo de resposta na semana passada? Quantas requisições deram erro ontem? Quanto de disco e de memória sobra hoje?
-
Existe um roteiro de incidente: quem é acionado, como se comunica e como se registra
Por que importa: No meio de uma queda, decidir quem faz o quê custa tempo. Um roteiro curto organiza a resposta, a comunicação com os clientes e o registro que evita repetir o problema.
Como conferir: Procure o documento de resposta a incidentes e confira se ele tem contatos atualizados, canal de comunicação e modelo de registro. Veja se os últimos incidentes geraram ações de prevenção e se elas foram concluídas.
Performance e custos
O sistema responde rápido para quem usa e custa o que deveria custar, com números para provar.
-
As páginas principais atendem às Core Web Vitals (LCP, INP e CLS)
Por que importa: Essas métricas medem o que a pessoa sente: quanto demora para o conteúdo principal aparecer, se a página responde rápido às interações e se o layout pula durante o carregamento.
Como conferir: Teste as páginas principais no PageSpeed Insights (pagespeed.web.dev) e veja os dados de campo, quando houver, além do teste de laboratório.
Referência: web.dev: Web Vitals
-
Respostas de texto (HTML, CSS, JavaScript e JSON) são enviadas comprimidas
Por que importa: A compressão reduz o volume transferido sem mudar o conteúdo, o que acelera o carregamento e diminui o custo de tráfego.
Como conferir: Rode curl -s -o /dev/null -D - -H "Accept-Encoding: br, gzip" https://exemplo.com.br e confira se a resposta traz content-encoding: br ou content-encoding: gzip.
Referência: MDN: Content-Encoding
-
Arquivos estáticos têm cache longo e nome versionado, e o HTML tem política de cache explícita
Por que importa: Cache bem configurado evita que o navegador e a CDN baixem de novo o que não mudou, e alivia o servidor nos picos.
Como conferir: Rode curl -sI no endereço de um arquivo CSS ou JavaScript e confira cache-control com max-age longo (e immutable, quando o nome do arquivo tem hash). Depois, confira se a página HTML tem um cache-control definido de propósito.
Referência: web.dev: Prevent unnecessary network requests with the HTTP Cache
-
As consultas lentas ao banco de dados são registradas e revisadas
Por que importa: Uma única consulta sem índice pode deixar o sistema inteiro lento à medida que os dados crescem.
Como conferir: Ative o registro de consultas lentas (no PostgreSQL, log_min_duration_statement ou a extensão pg_stat_statements; no MySQL, o slow query log) e revise as consultas mais frequentes e as mais demoradas.
-
O custo mensal é conhecido por serviço, e há alerta de orçamento configurado
Por que importa: Conta de nuvem sem acompanhamento cresce em silêncio: recursos esquecidos, logs sem limite e tráfego inesperado só aparecem na fatura.
Como conferir: Abra o painel de faturamento, veja o gasto por serviço nos últimos meses e confirme que existe alerta de orçamento. Liste também recursos sem dono, como servidores, discos, IPs e ambientes de teste esquecidos.
-
APIs pagas, como as de IA, têm limite de gasto, e o sistema limita requisições por usuário
Por que importa: Sem limite, um robô, um usuário abusivo ou um erro em laço consome a API paga em seu nome e gera uma fatura inesperada.
Como conferir: Confira no painel de cada API paga se há teto de gasto ou de uso. Em um ambiente de teste, envie várias requisições seguidas e veja se, a partir de certo ponto, a resposta passa a ser 429 (Too Many Requests).
Referência: MDN: 429 Too Many Requests
-
O sistema foi testado com carga acima da esperada antes de lançamentos e campanhas
Por que importa: Descobrir o limite do sistema durante a campanha é a forma mais cara de descobrir.
Como conferir: Pergunte quando foi o último teste de carga, com qual volume de acesso simultâneo e qual parte cedeu primeiro. Ferramentas como k6 ou Locust simulam o tráfego em um ambiente controlado.
Domínio, DNS e e-mail
O domínio está protegido contra perda e falsificação, e os e-mails da empresa chegam a quem deveriam.
-
O domínio tem renovação automática, e a data de expiração é monitorada
Por que importa: Domínio vencido derruba site e e-mail ao mesmo tempo e, depois de liberado, pode ser registrado por outra pessoa.
Como conferir: Consulte a data de expiração com whois exemplo.com.br (para domínios .br, também no site do Registro.br), confirme a renovação automática no painel do registrador e verifique se o e-mail de contato do domínio é de alguém que ainda responde por ele.
-
A conta do registrador tem dois fatores, e o domínio tem bloqueio de transferência
Por que importa: Quem controla o registrador controla o domínio, e com ele o site e o e-mail.
Como conferir: No painel do registrador, confira o segundo fator, quem tem acesso e o bloqueio de transferência. Em domínios genéricos, o whois mostra o status clientTransferProhibited quando o bloqueio está ativo.
-
O domínio publica um único registro SPF com os serviços que enviam e-mail em seu nome
Por que importa: O SPF diz aos servidores de destino quais servidores podem enviar e-mail pelo seu domínio. Sem ele, a entrega piora e fica mais fácil falsificar o remetente.
Como conferir: Rode dig +short TXT exemplo.com.br e procure um único registro iniciado por v=spf1, com os serviços que você usa, terminando em ~all ou -all.
Referência: RFC 7208: Sender Policy Framework (SPF)
-
Os e-mails enviados pelo domínio são assinados com DKIM
Por que importa: A assinatura DKIM prova que a mensagem saiu de um servidor autorizado e não foi alterada no caminho.
Como conferir: Envie uma mensagem de cada serviço que usa o domínio (caixa de e-mail, sistema, newsletter) para uma conta externa, abra o original da mensagem e confira dkim=pass com o seu domínio no cabeçalho Authentication-Results.
Referência: RFC 6376: DomainKeys Identified Mail (DKIM) Signatures
-
O domínio publica uma política DMARC e recebe os relatórios
Por que importa: O DMARC diz o que fazer com mensagens que falham no SPF e no DKIM e envia relatórios de quem está usando o seu domínio. Sem ele, fica mais fácil alguém se passar pela sua marca.
Como conferir: Rode dig +short TXT _dmarc.exemplo.com.br e confira v=DMARC1, uma política p=quarantine ou p=reject (p=none serve só para começar a observar) e um endereço rua= para receber os relatórios.
Referência: RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)
-
Os registros MX apontam para o serviço de e-mail em uso, ou declaram que o domínio não recebe e-mail
Por que importa: MX antigo ou errado faz mensagens sumirem. Um domínio que não recebe e-mail pode publicar um MX nulo e evitar que remetentes fiquem tentando entregar.
Como conferir: Rode dig +short MX exemplo.com.br e confira se os servidores listados são do serviço de e-mail contratado hoje. Em domínios que não recebem e-mail, o MX nulo é um registro com prioridade 0 e destino “.” (um ponto).
Referência: RFC 7505: A "Null MX" No Service Resource Record
-
O domínio tem registro CAA com as autoridades certificadoras autorizadas
Por que importa: O CAA impede que uma autoridade certificadora não autorizada emita um certificado válido para o seu domínio.
Como conferir: Rode dig +short CAA exemplo.com.br e confira se aparecem só as autoridades que você realmente usa, incluindo as do seu provedor de CDN, se houver.
Referência: RFC 8659: DNS Certification Authority Authorization (CAA)
-
O domínio tem DNSSEC ativo e com cadeia de validação correta
Por que importa: O DNSSEC assina as respostas de DNS e dificulta que alguém desvie o tráfego do domínio com respostas falsificadas.
Como conferir: Rode dig +short DS exemplo.com.br: se houver registro DS, o DNSSEC está publicado na zona pai. Para conferir a cadeia inteira, use um analisador como o DNSViz (dnsviz.net).
Referência: RFC 9364: DNS Security Extensions (DNSSEC)
Prontidão para buscadores e agentes de IA
Buscadores e assistentes de IA conseguem encontrar, ler e citar o seu conteúdo, nos termos que você definir.
-
O site publica um robots.txt válido que não bloqueia por engano o conteúdo público
Por que importa: O robots.txt é o primeiro arquivo que buscadores e robôs de IA consultam. Uma linha esquecida, como um Disallow: / herdado do ambiente de testes, tira o site inteiro das buscas.
Como conferir: Acesse https://exemplo.com.br/robots.txt e confira se responde 200 com texto puro, se as regras liberam as páginas públicas e se há uma linha Sitemap: com o endereço completo do sitemap.
Referência: RFC 9309: Robots Exclusion Protocol
-
O robots.txt tem regras explícitas para robôs de IA, separando busca de treinamento
Por que importa: Robôs que buscam páginas para as respostas de assistentes e robôs que coletam dados para treinar modelos são diferentes. Bloquear um não precisa bloquear o outro, e a escolha deve ser uma decisão sua, não um acidente.
Como conferir: Procure no robots.txt entradas User-agent para robôs de busca de IA (como OAI-SearchBot e Claude-SearchBot) e para robôs de treinamento (como GPTBot, ClaudeBot e Google-Extended), com regras que reflitam a sua decisão.
Referência: Is Your Site Agent-Ready?
-
O robots.txt declara as preferências de uso do conteúdo com Content-Signal
Por que importa: A diretiva Content-Signal diz se o conteúdo pode ser usado para busca, como entrada de respostas de IA e para treinar modelos. Nem todo robô respeita, mas a sua preferência fica registrada de forma explícita.
Como conferir: Procure no robots.txt uma linha como Content-Signal: search=yes, ai-input=yes, ai-train=no, com os três valores definidos conforme a sua decisão.
Referência: Content Signals
-
O site publica um sitemap XML atualizado, só com URLs canônicas
Por que importa: O sitemap lista as páginas que você quer ver encontradas e quando mudaram, o que ajuda buscadores e agentes a descobrir conteúdo novo ou atualizado.
Como conferir: Acesse https://exemplo.com.br/sitemap.xml (ou o endereço indicado no robots.txt) e confira se as URLs respondem 200, são as versões canônicas e têm lastmod coerente com a última alteração real de cada página.
Referência: Google Search Central: visão geral dos sitemaps
-
O conteúdo principal está no HTML entregue pelo servidor, sem depender de JavaScript
Por que importa: Nem todo robô executa JavaScript. Se o texto só aparece depois que o script roda, parte dos buscadores e dos agentes de IA vê uma página vazia.
Como conferir: Rode curl -s https://exemplo.com.br/pagina e procure, no HTML retornado, o título e os primeiros parágrafos da página. Se não estiverem lá, o conteúdo depende de JavaScript para aparecer.
Referência: Google Search Central: noções básicas de SEO para JavaScript
-
As páginas públicas permitem trechos: sem noindex, nosnippet ou max-snippet:0
Por que importa: Buscadores e recursos de IA precisam de um trecho do texto para mostrar e citar a página. No Google, nosnippet também impede o uso do conteúdo como entrada direta dos AI Overviews e do AI Mode.
Como conferir: Confira a meta robots no HTML e o cabeçalho x-robots-tag (com curl -sI): as páginas públicas não devem ter noindex, nosnippet nem max-snippet:0. A regra max-snippet:-1 libera trechos sem limite de tamanho.
Referência: Google Search Central: meta tag robots e X-Robots-Tag
-
As páginas principais têm dados estruturados (JSON-LD) coerentes com o conteúdo visível
Por que importa: Dados estruturados dizem de forma explícita quem é a organização, o que cada página oferece e quais perguntas ela responde, sem depender de interpretação.
Como conferir: Teste as páginas no Teste de pesquisa aprimorada do Google ou no validador do schema.org (validator.schema.org) e confira se não há erros e se os dados batem com o que está escrito na página.
Referência: Google Search Central: introdução aos dados estruturados
-
Cada página tem uma versão em Markdown, por negociação de conteúdo ou por link alternativo
Por que importa: O Markdown entrega ao agente o texto da página sem menus, scripts e marcação visual, o que facilita a leitura e a citação correta.
Como conferir: Rode curl -s -H "Accept: text/markdown" https://exemplo.com.br/pagina e confira se a resposta vem com content-type: text/markdown, ou procure no HTML um <link rel="alternate" type="text/markdown"> apontando para a versão em Markdown.
Referência: MDN: Content negotiation
-
O site publica um /llms.txt com um resumo e os links das páginas mais importantes
Por que importa: O llms.txt é uma proposta de arquivo em Markdown que apresenta o site a modelos de linguagem e aponta o conteúdo mais útil. Ainda não tem adoção universal, mas custa pouco publicar.
Como conferir: Acesse https://exemplo.com.br/llms.txt e confira se o arquivo começa com um título (#) e um resumo curto, seguidos de listas de links para as páginas principais.
Referência: llms.txt
Comece pelo diagnóstico
Antes de investir em mudanças, entenda os riscos, gargalos e desperdícios do seu sistema. O WIP Check entrega um relatório executivo e um plano de ação priorizado.