Por que diagnosticar proativamente
A maioria dos problemas técnicos em e-commerce não aparece de uma hora para outra. Eles se acumulam silenciosamente: um plugin desatualizado aqui, uma query lenta ali, um cron job que parou de rodar há 3 semanas. O checkout começa a apresentar erros intermitentes, o Google reduz o tráfego orgânico por Core Web Vitals ruins, a taxa de conversão cai 0,4% ao mês — e você só descobre quando já perdeu R$50 mil em receita.
Diagnóstico proativo é o processo de identificar esses sinais antes que se tornem incidentes. Não é difícil, mas requer sistematização. Este artigo apresenta a metodologia que usamos para auditar lojas de clientes — adaptada para que você possa aplicar de forma autônoma.
Dado relevante: 79% dos problemas de performance em e-commerce identificados em auditorias técnicas existiam há mais de 60 dias antes do diagnóstico — e nenhum havia sido detectado pelo time interno da loja.
As três dimensões do diagnóstico técnico
Um diagnóstico completo de e-commerce cobre três dimensões interdependentes. Problemas em qualquer uma delas afetam as outras.
Performance
Core Web Vitals, TTFB, tempo de checkout, carregamento mobile — tudo que afeta conversão e SEO.
Estabilidade
Erros 5xx, logs de exceção, cron jobs, integrações com ERPs — o que pode quebrar o fluxo de venda.
Segurança
Versões desatualizadas, permissões de arquivo, uploads sem validação, credenciais expostas.
1. Diagnóstico de Performance
Comece pelos dados de campo — o que usuários reais estão experimentando. Ferramentas de laboratório são úteis para debug, mas as métricas de campo refletem a realidade da sua base de usuários (dispositivos, conexões, localização).
Ferramentas e onde olhar primeiro
| Ferramenta | O que mede | Tipo | Frequência |
|---|---|---|---|
| Google Search Console (CWV) | LCP, INP, CLS por URL — dados reais de usuários | Campo | Semanal |
| PageSpeed Insights | LCP, INP, CLS + diagnóstico de causas | Lab + Campo | Quinzenal |
| Chrome DevTools → Network | Waterfall de recursos, bloqueio de render | Lab | Por alteração |
| WebPageTest | TTFB, First Byte, comparativo mobile/desktop | Lab | Mensal |
| GTmetrix | Waterfall visual, Largest Contentful Paint element | Lab | Mensal |
O que verificar no Search Console
Navegue para Experiência → Core Web Vitals. O relatório agrupa URLs por status (Bom / Precisa melhorar / Ruim) baseado em dados reais dos últimos 28 dias. Priorize:
- URLs na categoria "Ruim" com maior volume de impressões
- Tendências de degradação — URLs que passaram de "Bom" para "Precisa melhorar"
- Diferença significativa entre mobile e desktop (mobile ruim + desktop bom = problema de imagem ou layout shift)
Verificando o LCP element
Abra o Chrome DevTools, vá na aba Performance, grave um reload da página. No timeline, clique no marcador "LCP" para ver qual elemento HTML foi medido. Na maioria dos e-commerces, é a imagem hero ou o banner principal. Se o LCP é uma imagem, as causas mais comuns são:
- Falta de
fetchpriority="high"no elemento - Imagem não pré-carregada com
<link rel="preload"> - Imagem servida em formato JPEG/PNG ao invés de WebP/AVIF
- Imagem oversized (4000px de largura numa tela de 400px)
2. Diagnóstico de Estabilidade
Estabilidade é a dimensão mais difícil de monitorar sem acesso a logs — e onde problemas graves se escondem por mais tempo. O objetivo aqui é identificar erros silenciosos que não quebram o site visivelmente, mas prejudicam fluxos críticos como checkout, email transacional e sincronização de estoque.
Verificação de erros HTTP (todos os dias)
Configure alertas no Google Analytics 4 ou na ferramenta de analytics da sua plataforma para picos de erros 4xx e 5xx. Erros 5xx numa loja em operação normal devem ser zero ou muito próximo disso. Um aumento de 500 para 800 erros 404 por dia pode indicar que um app removeu URLs de produto sem redirecionar.
Logs de aplicação (Magento / WooCommerce)
# Magento — erros das últimas 24 horas
grep -c "CRITICAL\|ERROR" var/log/system.log
tail -100 var/log/exception.log | grep "$(date +%Y-%m-%d)"
# WooCommerce — log do WooCommerce
# Admin → WooCommerce → Status → Logs
# Filtrar por: Fatal, Critical, Error
# PHP error log (servidor)
tail -200 /var/log/php/error.log | grep -v "Deprecated"
Atenção aos "Deprecated": erros PHP de deprecação geralmente não quebram o site hoje, mas indicam código que quebrará na próxima versão do PHP. Monitore a quantidade — se está crescendo, é dívida técnica acumulando.
Cron jobs — o ponto cego mais comum
Cron jobs parados são uma das causas mais subestimadas de problemas em e-commerce. Eles não geram erro visível, mas param de executar tarefas críticas: limpeza de sessões, envio de emails de recuperação de carrinho, sincronização de estoque, geração de sitemap, reindexação de busca.
# Magento — verificar status dos cron jobs
php bin/magento cron:status
# ou direto no banco:
SELECT job_code, status, executed_at, finished_at
FROM cron_schedule
WHERE executed_at > DATE_SUB(NOW(), INTERVAL 24 HOUR)
ORDER BY executed_at DESC;
# WordPress — verificar WP-Cron
# Plugin WP Crontrol para visualização no admin
# ou via WP-CLI:
wp cron event list --fields=hook,next_run,recurrence
3. Diagnóstico de Segurança
Não é preciso contratar um pentest completo para identificar as vulnerabilidades mais comuns. Uma auditoria de segurança básica cobre 80% dos vetores de ataque mais frequentes contra e-commerces.
Verificar versões desatualizadas
CMS, plugins, tema, PHP, MySQL, servidor web — todos devem estar na última versão estável. Use WPScan para WordPress/WooCommerce, ou verifique manualmente no admin.
Auditar usuários administrativos
Liste todos os usuários com papel de admin. Remova qualquer conta que não reconheça. Verifique se 2FA está ativo para todos os admins.
Verificar permissões de arquivo
Arquivos de configuração (wp-config.php, app/etc/env.php) devem ter permissão 600 ou 640, nunca 644 ou 777. Diretórios de upload não devem executar PHP.
Testar SSL e headers de segurança
Use ssllabs.com para verificar a nota do SSL. Verifique os headers HTTP com securityheaders.com — Content-Security-Policy e X-Frame-Options são os mais importantes para e-commerce.
Checar scripts de terceiros
Abra o DevTools → Network e filtre por scripts carregados de domínios externos. Cada script third-party é um vetor de ataque (Magecart). Avalie se todos são necessários.
Frequência e priorização
| Verificação | Frequência | Prioridade |
|---|---|---|
| Erros 5xx no servidor / logs de exceção | Diária | 🔴 Crítica |
| Status de cron jobs e integrações | Diária | 🔴 Crítica |
| Core Web Vitals (Search Console) | Semanal | 🟡 Alta |
| Updates de segurança disponíveis | Semanal | 🟡 Alta |
| Auditoria completa de performance (PSI) | Mensal | 🟢 Média |
| Revisão de usuários administradores | Mensal | 🟢 Média |
| Auditoria de plugins/módulos ativos | Trimestral | 🟢 Média |
| Teste completo de segurança (WPScan/etc.) | Semestral | 🟢 Média |
Quando acionar um especialista
Nem todo problema técnico precisa de suporte externo. Mas há situações onde tentar resolver internamente pode piorar o problema ou atrasar a resolução de algo crítico.
Acione um especialista imediatamente se:
- Checkout apresenta erros para mais de 5% dos usuários
- Você encontrou arquivos suspeitos no servidor (possível invasão/malware)
- LCP está acima de 6s em mobile no Search Console (risco de penalização de ranking)
- Logs mostram exceções críticas que você não consegue identificar a causa
- Cron jobs parados há mais de 72 horas sem razão aparente
Situações que permitem diagnóstico gradual:
- LCP entre 2.5s e 4s (atenção, mas não emergência)
- Alguns plugins desatualizados sem CVE conhecido
- Performance degradada progressivamente (sem queda abrupta)
- Erros 404 aumentando (geralmente resolvível com redirects)
Não tem certeza do que encontrou no diagnóstico?
Envie os logs ou resultados das ferramentas e fazemos uma análise gratuita para identificar a gravidade e o próximo passo correto.