Imagine uma loja em que todos os painéis parecem estar bem. A página inicial está indexada, o Lighthouse está verde e o validador de dados estruturados não mostra erros. Mas, ao mesmo tempo, o preço no Google Shopping não corresponde ao preço no carrinho, o painel de filtros no mobile prende os usuários de teclado e cada compra é registrada duas vezes.
Nada disso aparece em uma verificação rápida de saúde. Isso porque uma loja online é um sistema conectado, não apenas uma coleção básica de páginas. Os dados de produto fluem para a página, para os dados estruturados e para os feeds de compras. Scripts e tags de terceiros definem a rapidez com que tudo carrega. O checkout transforma interesse em receita, e as análises deveriam registrar toda a jornada com precisão. Quando uma parte falha, ela pode distorcer silenciosamente todo o resto.
É por isso que uma auditoria de e-commerce útil acompanha o comprador, e não o sitemap. A checklist abaixo começa pela descoberta da loja e termina com um pedido concluído. Ela vai lhe dar uma lista classificada de problemas reais, cada um com evidência, um responsável e um teste claro para saber quando foi corrigido.
Quando executar esta auditoria, e por que a ordem importa
Execute a auditoria completa quando assumir um novo cliente de e-commerce, após um redesign ou migração de plataforma, antes de um grande esforço de crescimento, ou quando uma verificação de rotina revelar uma regressão em toda a loja. Reserve de três a seis horas para uma passagem leve, ou de um a dois dias para uma auditoria padrão que teste corretamente cada template importante. Investigações profundas em logs, feeds ou análises geralmente exigem tempo separado.
A ordem é deliberada. Não faz sentido julgar atritos de conversão se o Google não consegue indexar as páginas de categoria, e não faz sentido confiar no relatório de funil se a tag de compra dispara duas vezes.
Um evento de compra duplicado não é evidência de mais vendas, e uma página de produto rápida não está saudável se o preço que o Google vê for diferente do preço no carrinho. Por isso a auditoria avança por etapas. Começa pela primeira descoberta, depois passa para a veracidade dos dados de produto, a velocidade e a própria compra, e só então chega à mensuração.
Antes de começar, reúna o que você precisa. Ou seja, acesso a:
- Search Console,
- Analytics,
- gerenciador de tags,
- catálogo ou fonte do feed,
- Merchant Center,
- uma lista de mudanças recentes no site.
Etapa 1: Os mecanismos de busca conseguem encontrar o catálogo?
1. Monte uma amostra que represente a loja inteira
A maioria dos bugs de e-commerce vive em templates compartilhados e estados incomuns de produto. Uma página inicial impecável não diz nada sobre categorias filtradas, lógica de variantes, esgotamentos de estoque ou checkout. Por isso você deve começar confirmando que está testando o site de produção ao vivo, no mercado, na moeda e no idioma corretos. Depois, escolha pelo menos uma URL para cada um destes casos:
- a página inicial
- uma categoria prioritária
- uma categoria mais profunda ou uma página de filtro aprovada
- um produto típico
- um produto com variantes
- um produto sem estoque ou descontinuado
- uma página de resultados de busca interna, incluindo uma que não retorne resultados
- o carrinho, o checkout e a página de confirmação do pedido
Acrescente um exemplo complicado ou incomum para qualquer template que pareça arriscado. Seu relatório de páginas de destino no analytics e uma exportação do catálogo vão ajudar na escolha.
Você terminou quando cada template importante e cada estado de checkout tiver uma URL de teste nomeada, e tudo o que você não conseguiu testar estiver marcado como “não testado”.
2. Verifique rastreabilidade, indexação, canonicals e sitemaps
Se o caminho de rastreamento está quebrado, publicar mais produtos apenas multiplicará o número de URLs afetadas. Sinais mistos também tornam os problemas mais difíceis de diagnosticar. As regras do robots podem dizer uma coisa, enquanto as tags canonical e o sitemap dizem algo completamente diferente.
Revise o robots.txt, os sitemaps XML, os códigos de resposta, as meta tags e cabeçalhos de robots, as tags canonical, a paginação e os links internos. Use a Inspeção de URL no Search Console para ver qual canonical o Google realmente escolheu para suas páginas de amostra. Depois compare o sitemap com a realidade. Ele deve listar páginas ativas e indexáveis que retornam status 200, e não redirecionamentos, erros, páginas com noindex ou duplicatas.
Você terminou quando suas páginas de destino pretendidas retornam 200, podem ser rastreadas, seguem uma política consistente de canonical e indexação, e aparecem no sitemap. Toda exclusão significativa deve ter uma explicação ou um responsável.
3. Siga os links: redirecionamentos, erros e JavaScript
Uma loja pode parecer completa no navegador enquanto rastreadores e tecnologias assistivas veem uma versão muito mais pobre. Rode um rastreador para encontrar links internos quebrados, cadeias de redirecionamento, loops e soft 404s. Depois compare a página renderizada com o HTML bruto. Cards de produto, paginação, breadcrumbs e links de categoria devem ser reais e rastreáveis, e o conteúdo importante não deve depender apenas de JavaScript.
Você terminou quando os links internos apontam diretamente para seu destino final, as páginas de erro retornam o código de status correto e os produtos prioritários podem ser encontrados sem depender de scroll infinito.
4. Teste categorias, filtros, paginação e busca no site
Sistemas de categoria e filtros podem criar armadilhas de rastreamento para os mecanismos de busca e frustração para os compradores ao mesmo tempo. Uma página pode ser tecnicamente indexável e ainda assim ser uma página de destino fraca se metade dos produtos nela for irrelevante.
Experimente os filtros no desktop e no mobile. Verifique a seleção múltipla, o “limpar tudo”, as contagens de resultados, a ordenação, a paginação ou o “carregar mais”, e combinações de filtros que não retornam nada. Observe as URLs que os filtros geram e compare-as com a política de indexação da loja. Note também se um longo bloco de texto de categoria empurra a grade de produtos para abaixo da dobra.
Você terminou quando os controles se comportam de forma consistente, combinações aleatórias de filtros não se transformam em páginas de destino acidentais, e os compradores podem desfazer um filtro sem perder sua posição.
Pronto para expandir seu negócio?
Comece seu teste gratuito hoje e veja resultados em dias.
Etapa 2: Os dados de produto estão dizendo a verdade?
5. Reconcilie identidade do produto, preço, estoque e variantes
Um único campo errado pode não apenas enganar um comprador, mas ir longe o suficiente para causar uma divergência no checkout. Enquanto isso, os dados podem estar perfeitamente formatados e ainda assim estarem errados.
Para alguns produtos representativos, compare nome, marca, SKU, GTIN ou EAN, variante selecionada, preço, moeda, disponibilidade, imagens e especificações principais em todos os lugares em que aparecem. Verifique o que é exibido na página, nos dados estruturados, no feed do merchant, no carrinho e no checkout. Inclua itens em promoção, variantes, esgotamentos, pré-vendas e produtos descontinuados.
Você terminou quando os fatos amostrados coincidem em todas as superfícies, e qualquer diferença intencional, como marca versus fabricante, está explícita no modelo de dados.
6. Valide os dados estruturados em relação ao que os compradores veem
Os dados estruturados só ajudam quando descrevem a página com precisão. Um validador aceitará “InStock” tranquilamente enquanto a página e o checkout dizem que o produto está indisponível. Por isso você deve rodar cada estado de produto no Teste de Resultados Ricos do Google ou no Validador do Schema.org. Depois compare os valores marcados com o conteúdo visível e com o feed de origem. Para produtos com variantes, verifique se sua abordagem de marcação e sua configuração de canonical correspondem à forma como as páginas são realmente construídas.
Você terminou quando as páginas amostradas e elegíveis não têm propriedades obrigatórias ausentes, a marcação corresponde ao que está visível, e avaliações e notas só são marcadas quando os compradores podem vê-las naquele produto.
Etapa 3: A loja é rápida para compradores reais?
7. Meça o Core Web Vitals a partir dos dados de campo primeiro
Dados de usuários reais e uma única execução do Lighthouse respondem a perguntas diferentes. O Lighthouse ajuda a reproduzir um problema, mas não pode dizer se os compradores reais passam ou falham.
Comece pelo PageSpeed Insights e pelo relatório de Core Web Vitals no Search Console. Anote se existem dados de campo para a URL exata ou apenas para o site inteiro. Os limites “bons” do Google, medidos no 75º percentil, são:
- LCP (carregamento): 2,5 segundos ou menos
- INP (responsividade): 200 milissegundos ou menos
- CLS (estabilidade visual): 0,1 ou menos
Analise mobile e desktop separadamente. Se não houver dados de campo, registre o resultado como desconhecido e trate os resultados de laboratório como provisórios. Desconhecido não é o mesmo que verde.
Você terminou quando cada template prioritário tem um veredito de campo por dispositivo, ou uma ausência de dados claramente declarada, com a fonte e o período registrados.
8. Encontre a causa, não apenas a pontuação
Conselhos genéricos como “comprima suas imagens” ou “reduza o JavaScript” muitas vezes erram o verdadeiro gargalo e geram trabalho que não move a métrica que está falhando. Encontre o elemento, a requisição ou o script específico responsável.
Identifique o elemento de LCP e o que o atrasa. Depois verifique os suspeitos de sempre, como dimensionamento de imagens, lazy-loading em imagens acima da dobra, CSS que bloqueia renderização, carregamento de fontes, scripts de terceiros, tarefas longas, cache, tempo de resposta do servidor, fontes de deslocamento de layout e tags carregadas duas vezes.
Faça testes repetidos nas mesmas condições e compare uma estatística consistente, não sua melhor execução. Lembre-se de que o Total Blocking Time é um sinal útil de laboratório, mas não é o INP.
Você terminou quando cada descoberta de desempenho significativa nomeia a métrica que falha, o template afetado, uma causa reproduzível e um responsável.
Junte-se à nossa newsletter
Receba gratuitamente as últimas dicas, tendências e ofertas.
Etapa 4: As pessoas conseguem realmente comprar algo?
9. Teste usabilidade mobile e acessibilidade nos controles reais de compra
Pontuações automatizadas não cobrem todas as interações. Uma loja pode passar em uma varredura enquanto o painel de filtros prende o foco do teclado, o banner de cookies cobre o botão de adicionar ao carrinho ou o seletor de tamanho não tem rótulo acessível.
Teste em larguras de telefone de 360 a 390 pixels, aplique zoom no texto e tente toda a jornada usando apenas o teclado. Observe a ordem e a visibilidade do foco em menus, painéis e diálogos. Verifique se rótulos, botões, erros de formulário e áreas de toque ainda fazem sentido.
Você terminou quando um comprador consegue percorrer a jornada principal sem controles ocultos ou armadilhas de foco, e nada no mobile esconde o preço, a disponibilidade, a escolha de variante, o botão de adicionar ao carrinho ou o checkout.
10. Execute o carrinho e o checkout como um teste controlado
Um botão de checkout visível não prova que o checkout funciona. Bugs de checkout são incidentes comerciais e também prejudicam suas análises.
Para testar isso, adicione um produto normal e uma variante ao carrinho. Altere a quantidade, remova um item e aplique um cupom (ou um deliberadamente inválido), se houver. Depois teste checkout como convidado e com conta, opções de frete, seleção de pagamento, erros de validação, o botão voltar e o layout mobile. Use um pedido de teste ou um caminho aprovado que não gere cobrança. Nunca faça um pedido real sem permissão.
Você terminou quando a compra é concluída ou chega ao limite de teste combinado, os totais permanecem corretos, as mensagens de erro dizem às pessoas o que fazer, e qualquer caminho bloqueado está documentado com evidência e impacto no negócio.
Etapa 5: Você está medindo a jornada corretamente?
11. Verifique análises, tags duplicadas e consentimento
Tags duplicadas inflam visualizações de página, eventos de adicionar ao carrinho e compras. Valores ausentes ou malformados tornam os relatórios de receita inseguros como base para decisões. O objetivo é simples: uma ação do comprador deve produzir um evento, com o produto, o valor, a moeda, o ID de transação e o estado de consentimento corretos.
Liste cada contêiner de gerenciador de tags, tag do Google, pixel de anúncios, script de afiliados e integração do lado do servidor. Depois, em uma sessão controlada, rastreie view_item, add_to_cart, begin_checkout e purchase. Compare o que o navegador envia com o DebugView do GA4 e o registro do pedido no back-end. Teste antes e depois de o comprador fazer uma escolha de consentimento.
Você terminou quando cada ação dispara seu evento exatamente uma vez, as compras carregam um ID de transação estável, valores e moeda conciliam com o back-end, e as tags não essenciais respeitam a política de consentimento.
12. Reconcilie o Search Console e o Merchant Center com o que você encontrou
Um teste de página local não consegue mostrar todos os canonicals indexados, avisos de sitemap, produtos reprovados ou consultas de busca perdidas. Um alerta de painel, por outro lado, pode descrever um problema que já foi corrigido.
Inspecione suas URLs prioritárias no Search Console, revise os relatórios de produtos e de anúncios do merchant, e verifique os diagnósticos do Merchant Center em relação ao que você viu no site ao vivo. Anote as datas, porque o recrawling e o processamento de feeds ficam atrás das implantações.
Você terminou quando cada problema significativo do painel corresponde a uma evidência ao vivo ou está marcado como aguardando propagação, e cada problema em aberto tem um responsável.
Etapa 6: Um comprador confiaria nesta loja?
13. Verifique sinais de confiança, dados de contato, envio e devoluções
Informações comerciais ocultas ou conflitantes fazem os compradores hesitar e aumentam os tickets de suporte. Compare o cabeçalho e o rodapé, a página de contato, o checkout e as páginas de políticas.
Você terminou quando a identidade da empresa está clara, as afirmações sobre envio, devoluções e pagamento são coerentes ao longo da jornada, e nenhum selo de confiança é inverificável.
14. Verifique HTTPS, conteúdo misto e higiene de front-end
Isto não é um teste de penetração, mas uma questão de higiene básica de dados. Confirme que o HTTP redireciona para HTTPS em um único salto, que o certificado é válido, que não há conteúdo misto e que os formulários são enviados corretamente. Verifique o console em busca de erros graves. Se algo parecer uma vulnerabilidade de segurança real, encaminhe para um especialista em vez de diagnosticá-la a partir de um aviso genérico.
Você terminou quando as páginas prioritárias e o checkout carregam com segurança, os redirecionamentos levam um único salto e os formulários se comportam como esperado.
Das descobertas às correções
15. Transforme as descobertas em uma fila de remediação com responsáveis
Uma auditoria que termina em capturas de tela ou uma pontuação não reduz riscos. Cinquenta sintomas causados por um único template quebrado não devem virar cinquenta tickets sem relação. Agrupe as descobertas pela causa raiz. Anote se é o componente, o template, a regra do feed ou a configuração de rastreamento. Mantenha as URLs afetadas como evidência. Depois priorize:
- P0: uma falha ativa que bloqueia o negócio, ou um problema crítico em todo o site
- P1: um defeito significativo sobre o qual você tem confiança
- P2: um problema importante com escopo limitado
- P3: uma melhoria a monitorar
Você terminou quando cada descoberta significativa tem um responsável, um prazo, um teste para “corrigido” e uma data para verificá-la novamente após o lançamento.
O entregável
Entregue um documento ou planilha versionada com uma linha por descoberta e um resumo curto no topo. Cada linha deve cobrir:
- O comportamento,
- o comportamento esperado,
- as URLs afetadas,
- a evidência e quando você a coletou,
- severidade e confiança,
- a causa provável,
- a correção recomendada,
- o responsável e o teste que comprova que está feito.
Mas lembre-se de que você não deve marcar um problema como corrigido porque alguém fechou o ticket. Marque-o como verificado quando o teste passar em produção.
Ferramentas para o trabalho
Você não precisa de nenhuma assinatura para fazer com sucesso uma primeira passagem sólida. Tudo o que você precisa são estas ferramentas gratuitas:
- Google PageSpeed Insights para dados de campo (quando disponíveis) e diagnósticos do Lighthouse
- Google Search Console para indexação, sitemaps, Inspeção de URL, Core Web Vitals e relatórios de dados estruturados
- Teste de Resultados Ricos do Google e o Validador do Schema.org para dados estruturados
- Chrome DevTools e Lighthouse para rede, desempenho, deslocamentos de layout, acessibilidade e verificações de console
- Google Tag Assistant e DebugView do GA4 para rastreamento de eventos
- SSL Labs Server Test para configuração de TLS
Se você quiser um atalho, o AmICited permite reunir todas essas evidências e guardar a linha de base para depois. A visão de Impacto no Desempenho compara templates por LCP, INP, CLS e tempo de resposta do servidor. Inspeção de URL e Sitemaps e Indexação acompanham a indexação das URLs prioritárias. Produtos e Sortimento mostram quais partes do catálogo carregam mais peso comercial. As Anotações no Reports Hub ligam cada lançamento ao que aconteceu depois. As ferramentas fornecem a evidência. O dono da loja, o desenvolvedor ou o analista ainda decide o que está correto e quais trade-offs são aceitáveis.
Depois da auditoria
Envie cada problema confirmado para o fluxo de trabalho especializado que pode resolvê-lo: problemas de rastreamento e renderização para uma auditoria de SEO técnico , falhas de desempenho de campo para remediação de Core Web Vitals , problemas de facetas e estados de estoque para uma revisão de categoria e produto , e problemas de rastreamento para quem for responsável pelas análises.
Não há necessidade de refazer a auditoria inteira após cada correção. Reteste a área afetada, anote o lançamento para poder ver o que mudou depois, e deixe a verificação de saúde regular capturar a próxima regressão.
De volta à loja onde tudo parecia bem
Lembra da loja do início? Sua página inicial estava indexada, o Lighthouse estava verde e o validador estava limpo. Ainda assim, o Google Shopping mostrava o preço errado, o painel de filtros prendia os usuários de teclado e cada venda era contada duas vezes.
Nenhum painel sinalizou nada disso. Esta checklist teria capturado os três casos: a divergência de preço no passo 5, a armadilha de foco no passo 9 e a compra contada em dobro no passo 11. Cada um deles quebra em algum ponto do caminho do comprador, e é exatamente aí que a auditoria olha.
É isso que acompanhar o comprador em vez do sitemap oferece. Você para de perguntar “o site parece saudável?” e começa a fazer quatro perguntas mais difíceis. As pessoas conseguem encontrar o produto? O que a loja diz sobre ele é verdade? Elas conseguem realmente comprá-lo? E você consegue ver que compraram? Uma loja que pode responder sim a todas as quatro está em melhor forma do que uma com uma pontuação perfeita.
Então escolha suas URLs de amostra, reserve o tempo e comece pela Etapa 1. A primeira passagem é a mais lenta. Depois disso, o trabalho é basicamente garantir que o que você corrigiu continue corrigido.
