O que uma auditoria de Magento precisa cobrir
Auditoria é o diagnóstico técnico que sustenta uma decisão: trocar de suporte, planejar um upgrade, aprovar um projeto de performance. Por isso ela vale pelo que dá para conferir. A regra que eu aplico e recomendo cobrar: achado sem evidência não entra, e toda evidência tem data.
O escopo mínimo tem seis blocos e 24 verificações. Em cada linha está a evidência que deve aparecer no relatório e quando o item deixa de ser ok. Os critérios abaixo são os que eu uso; ajuste a régua ao risco do seu negócio.
Versão, infraestrutura e código: verificações e evidência
Versão e patches
| Verificação | Evidência no relatório | Vira atenção ou crítico quando |
|---|---|---|
| Versão instalada | saída de bin/magento --version | crítico se a versão está fora do suporte na política da Adobe |
| Patches de segurança | versão comparada com a página de versões lançadas da Adobe | crítico se falta patch de segurança já publicado |
| Prazo de suporte | data de fim de suporte da versão, com a fonte | atenção se faltam menos de 12 meses |
Infraestrutura
| Verificação | Evidência no relatório | Vira atenção ou crítico quando |
|---|---|---|
| PHP, banco, busca, cache e fila | versão de cada serviço lado a lado com a matriz de requisitos da versão | crítico se a combinação não está na matriz |
| Modo de execução | saída de bin/magento deploy:mode:show | crítico em modo developer, que mostra exceções no navegador; atenção em default |
| Raiz do site | configuração do servidor web apontando para pub/ | crítico se a raiz é a pasta da instalação, que expõe o resto dos arquivos |
| Cache de página | valor de system/full_page_cache/caching_application (1 interno, 2 Varnish) | atenção se produção não usa Varnish, que a Adobe recomenda |
| Disco | saída de df -h e tamanho das maiores tabelas | crítico se não cabe um backup completo |
Código e extensões
| Verificação | Evidência no relatório | Vira atenção ou crítico quando |
|---|---|---|
| Pacotes diretos | saída de composer show --direct e composer outdated --direct | atenção para extensão sem versão compatível com a versão alvo |
| Módulos ativos e desativados | saída de bin/magento module:status | atenção para módulo desativado que continua no código |
| Código próprio | lista de app/code e app/design e onde está o repositório | crítico se o código só existe no servidor |
| Alteração direta em produção | saída de git status no servidor, quando o deploy é por git | crítico com arquivo alterado que ninguém explica |
Segurança, operação e SEO técnico: verificações e evidência
Segurança
| Verificação | Evidência no relatório | Vira atenção ou crítico quando |
|---|---|---|
| Varredura externa | relatório do Security Scan da Adobe, gratuito na conta Magento, com data | conforme os testes reprovados e a recomendação do próprio relatório |
| Usuários do admin | consulta à tabela admin_user por último login (abaixo) | atenção para usuário ativo sem login recente ou que nunca entrou |
| Dois fatores no admin | Magento_TwoFactorAuth fora da lista de bin/magento module:status --disabled | crítico se o módulo foi desativado sem login pelo Adobe IMS no lugar |
| Integrações | lista de Sistema > Extensões > Integrações com o dono de cada uma | atenção para integração ativa sem dono conhecido |
| Executável em mídia | busca por arquivos .php dentro de pub/media | crítico se encontrar |
Operação e dados
| Verificação | Evidência no relatório | Vira atenção ou crítico quando |
|---|---|---|
| Cron | contagem da cron_schedule por status | crítico sem execução recente |
| Indexadores e filas | bin/magento indexer:status e processos de consumidores | atenção para índice pendente recorrente; crítico com fila parada |
| Relatórios de exceção | quantidade de arquivos novos em var/report no último mês | atenção para erro que se repete |
| Backup | data do último backup e do último teste de restauração | crítico se a restauração nunca foi testada |
SEO técnico e performance
| Verificação | Evidência no relatório | Vira atenção ou crítico quando |
|---|---|---|
| Robots | valor de Default Robots em Conteúdo > Design > Configuração e o robots.txt servido | crítico com NOINDEX em produção |
| Canonical | valores de catalog/seo/product_canonical_tag e category_canonical_tag, desligados de fábrica | atenção se desligados com filtros e parâmetros indexáveis |
| Dado de campo | CrUX no PageSpeed: percentil 75 de LCP, INP e CLS em home, categoria e produto | atenção fora do limite de bom |
SELECT username, email, is_active, logdate FROM admin_user ORDER BY logdate;
find pub/media -name '*.php'Como saber se a auditoria da loja foi bem feita
Sinais de relatório feito só com ferramenta automática:
- a nota do PageSpeed aparece como conclusão, sem o dado de campo e sem dizer qual página foi medida;
- print de scanner sem data, sem URL e sem explicar o que cada item significa para a sua loja;
- achado sem evidência: "extensões desatualizadas" sem a lista, "servidor fraco" sem números;
- lista longa sem prioridade, em que uma meta description faltando pesa o mesmo que o 2FA desligado;
- nenhuma palavra sobre cron, filas e backup, que só aparecem com acesso ao servidor;
- recomendação genérica que serviria para qualquer plataforma.
Um teste rápido: escolha três achados e peça a evidência de cada um. Quem auditou de verdade tem o material guardado e responde sem refazer o trabalho. Se o relatório não diz o que ficou de fora por falta de acesso, pergunte.
Modelo de sumário executivo de uma página
O relatório técnico pode ter dezenas de páginas, mas a decisão sai do sumário. O modelo que eu recomendo:
- Contexto: versão, edição, data da coleta e o que motivou a auditoria.
- Placar: quantos itens ok, atenção e crítico em cada bloco.
- Críticos: até cinco, cada um com o risco em uma frase e a referência da evidência.
- Prazo externo: a data de fim de suporte da versão e o que ela obriga.
- Próximos passos: o que fazer em 30 dias, o que entra no plano de upgrade e o que pode esperar, com estimativa por faixa.
- Limites: o que não foi avaliado e por quê.
Se a auditoria abre uma consultoria, o sumário vira o insumo do roadmap, como mostro em o que uma consultoria Magento entrega. Se a decisão é trocar de suporte, as verificações de operação viram a base da rotina de manutenção preventiva. Para auditar a sua loja, fale comigo pela página de suporte Magento 2.
Perguntas frequentes
O que uma auditoria de Magento precisa cobrir?
No mínimo seis blocos: versão e patches, infraestrutura, código e extensões, segurança, operação e dados, SEO técnico e performance. Cada verificação precisa trazer a evidência coletada, com data, e uma classificação de risco, para que outra pessoa consiga conferir o achado.
Diagnóstico técnico de loja Magento precisa de acesso ao servidor?
Para ser completo, precisa. Sem acesso dá para avaliar só o que aparece de fora: velocidade, SEO, cabeçalhos e a varredura externa. Cron, filas, backup, extensões instaladas, usuários do admin e alterações de código só aparecem com acesso ao servidor e ao banco, e o relatório deve dizer o que ficou de fora.
Como saber se a auditoria da loja foi bem feita?
Peça a evidência de três achados que você escolher e veja se cada um tem data, origem e critério. Desconfie de relatório que usa só nota do PageSpeed, print de scanner sem explicação ou lista longa sem prioridade.
Dá para fazer só a auditoria de segurança e performance do Magento?
Dá, quando a decisão é só sobre esses temas. O risco é tratar sintoma isolado: loja lenta por cron parado ou por tabela de histórico gigante aparece como performance, mas a causa está na operação. Antes de um projeto grande, eu prefiro o escopo completo.
Fontes oficiais
- Security scan (Adobe Experience League)
- Modify docroot to improve security (Adobe Experience League)
- Application modes (Adobe Experience League)
- Configure Varnish (Adobe Experience League)
- Two-factor authentication (2FA) (Adobe Experience League)
- Adobe Commerce lifecycle policy (Adobe Experience League)