Como usar Codex ou Claude Code para auditar o site da empresa sem mexer na produção
Um roteiro de terminal para mapear o projeto, testar links, formulários, SEO e acessibilidade numa cópia controlada antes de aceitar qualquer alteração.
Por Cesar A. Machado · · 3 min
Comece numa cópia limpa e registre o commit inicial.
Separe diagnóstico, correção e publicação.
Exija diff, testes e evidências visuais.
Mantenha credenciais e produção fora do primeiro ciclo.
A primeira decisão é onde o agente pode agir
Codex e Claude Code conseguem ler repositórios, executar comandos e propor mudanças. Isso é poderoso. O erro é começar apontando para o servidor porque parece mais rápido. Eu prefiro uma cópia local ou worktree, sem segredos, com o commit inicial anotado e uma definição explícita do que é somente leitura.
No exemplo ruim, o pedido é “melhore meu site” dentro da pasta de produção. No bom, o pedido lista objetivo, páginas, verificações, comandos permitidos e entrega esperada: relatório primeiro, diff depois, deploy fora do escopo.
O preflight que eu executaria
git status --short
git rev-parse HEAD
git remote -v
# depois de identificar os scripts do projeto
npm test
git diff --check
Esses comandos são exemplos; o projeto pode usar outra stack. Eu pediria ao agente para ler documentação e scripts antes de escolher testes. Se a árvore já estiver suja, ele deve separar o trabalho existente em vez de tratá-lo como parte da auditoria.
Área
Verificação
Evidência
Rotas
Links e 404
Lista de URLs e status
SEO
title, canonical, sitemap
HTML observado
Formulário
sucesso e falha
Resposta e log sanitizado
Acessibilidade
teclado e contraste
Relatório e captura
Diagnóstico antes do patch
Eu dividiria em três fases. Primeiro, inventário de rotas, componentes e deploy. Segundo, auditoria reproduzível com problemas classificados. Terceiro, correções pequenas em branch própria. Cada problema precisa de causa, impacto e modo de verificar. “O Lighthouse ficou melhor” não explica qual comportamento foi protegido.
Para interface, peço capturas em desktop e celular, erros do navegador e teste dos fluxos importantes. Para backend, peço entradas inválidas, permissões e falhas externas. O agente deve dizer o que não conseguiu testar.
O diff deve ser pequeno e explicar comportamento antes e depois. Testes precisam cobrir o risco real, não repetir a implementação. Eu reviso arquivos alterados, comandos executados e efeitos externos. Credenciais nunca entram em prompt, log ou commit.
Planos de US$ 100 ajudam em repositórios maiores, sessões longas e várias rodadas de testes. Não substituem isolamento. Mais uso permite ao agente fazer mais; por isso limites, branch e aprovação ficam ainda mais importantes.
Produção continua sendo outra decisão
Depois do patch, eu quero build, testes, preview e um rollback definido. Só então existe uma decisão de publicação. O agente pode preparar tudo, mas a ativação deve ser explícita e deixar manifesto, versão e resultado verificável.
Se você quer auditar um site ou sistema sem abrir produção para experimentos, descreva em https://blog.cesarmachado.com/contato o repositório, o problema percebido e o fluxo mais importante. Eu posso conduzir o diagnóstico, preparar as correções e deixar a publicação como etapa controlada.
Exija um relatório que separe evidência de sugestão
Eu pediria uma tabela com achado, evidência reproduzível, impacto, risco da correção e próximo passo. Erro de console observado, link quebrado confirmado e dependência desatualizada são fatos diferentes de “esta arquitetura poderia melhorar”. A prioridade vem do efeito sobre venda, atendimento, segurança ou operação, e não da facilidade com que o agente consegue gerar um patch.
Um bom achado inclui rota, comando ou captura, comportamento esperado e comportamento observado. Um ruim diz “o site precisa de otimização” e oferece mudar vinte arquivos. Se você está lendo isso antes de dar acesso ao repositório, crie uma cópia ou branch isolada e peça primeiro somente o diagnóstico. O limite mais importante é o que impede uma hipótese de virar produção por acidente.
Os projetos são apresentados pelo problema e pela engenharia envolvida, preservando informações internas. O objetivo é mostrar como decisões de produto, arquitetura e operação se conectam.
Um projeto começa com uma pergunta de negócio, avança por uma primeira versão controlada e só cresce quando os dados mostram que a solução cabe na operação.
{{ item.num }}
{{ item.title }}
{{ item.text }}
LIMITES CLAROS
A confiança também está no que o sistema não promete.
Empresas de 20 a 100 pessoas, com um processo real para melhorar.
O ponto de partida é um processo específico, com responsável, volume e impacto identificáveis. A solução precisa caber na capacidade da equipe, produzir evidência e preservar controle sobre decisões importantes.
→{{ item }}
Tecnologias e camadas
A FERRAMENTA SEGUE O PROCESSO
{{ item }}
SE FIZER SENTIDO
Descreva um processo que você gostaria de entender melhor.
Envie o fluxo atual, o volume aproximado e o principal gargalo. A primeira conversa serve para entender o problema e avaliar o próximo passo mais proporcional.
Ferramentas
Clique em uma ferramenta para abrir. Conteúdo de cada uma a definir.
Kit atual
{{ t.num }}
{{ t.title }}
{{ t.desc }}
{{ t.state }}
Portfólio
Projetos de software e ecossistemas construídos com engenharia de IA. Conteúdo de cada caso a definir.
{{ caseCount }}
Projetos
capa do projeto{{ p.num }}
{{ p.kind }} · {{ p.year }}
{{ p.title }}
{{ p.desc }}
{{ tg.label }}
ABRIR CASO
{{ detail.num }}{{ detail.kind }}
{{ detail.title }}
{{ detail.desc }}
{{ m.k }}
{{ m.v }}
imagem principal do caso
{{ bl.title }}
{{ bl.hint }}
Briefing
3 PASSOS · CERCA DE 1 MINUTO
Toque nas opções que descrevem seu projeto. Só o último passo pede digitação.
Briefing recebido
Obrigado. Retorno pelo e-mail informado com as próximas perguntas.
