SEO para e-commerce organiza um catálogo para que categorias atendam buscas amplas, produtos atendam buscas específicas e filtros não multipliquem páginas sem valor. O trabalho combina arquitetura, conteúdo, dados estruturados e performance com regras operacionais para estoque, variações e mudanças de plataforma.
O ponto de partida não é adicionar texto em todas as URLs. É decidir quais páginas merecem ser encontradas, qual intenção cada uma resolve e como robôs e pessoas chegam até elas sem atravessar duplicatas, parâmetros ou experiências dependentes de JavaScript.
Diagnóstico
Onde lojas virtuais perdem tráfego orgânico
A perda costuma aparecer de forma diferente em cada template. Avaliar somente o domínio esconde se o problema está em categorias, produtos, filtros ou na descoberta do catálogo.
- Home — tenta ranquear para todos os termos, enquanto categorias recebem links e contexto insuficientes. A home apresenta a loja; não deve substituir a arquitetura do catálogo.
- Categorias — usam nomes internos, misturam intenções ou mostram apenas uma grade sem explicar seleção, atributos e subcategorias. Paginação e ordenação criam variações sem regra.
- Produtos — repetem a descrição do fabricante, ocultam informações importantes em abas ou desaparecem ao ficar sem estoque. Variações competem entre si sem uma página principal definida.
- Filtros e busca interna — geram combinações rastreáveis quase ilimitadas. Algumas têm demanda real; a maioria apenas reorganiza o mesmo conjunto e dilui crawl e sinais.
- Conteúdo editorial — responde à dúvida, mas não conduz para categoria ou produto relacionado. O tráfego informacional fica isolado da jornada de compra.
Uma auditoria SEO, AEO e GEO cruza crawl, Search Console e templates para separar sintomas. Impressão em queda pode vir de `noindex`, mudança de canônico, produto removido, concorrência entre páginas ou perda de demanda; cada causa pede uma correção diferente.
Arquitetura de intenção
Categoria, produto e filtro: qual página deve ranquear
A página certa depende da intenção. Uma busca por tipo de produto normalmente pede comparação e variedade, então a categoria é a candidata. Uma consulta com marca, modelo, medida ou código pede a página do item. Um atributo combinado pode justificar uma landing filtrada somente quando existe demanda, sortimento suficiente e conteúdo que a diferencie.
| Tipo de página | Intenção principal | Conteúdo necessário | Erro comum |
|---|---|---|---|
| Categoria | Explorar uma classe de produtos e comparar opções. | Título claro, descrição útil, subcategorias, filtros relevantes, produtos e orientação de escolha. | Usar taxonomia interna que ninguém busca ou apontar o canônico para a home. |
| Produto | Avaliar ou comprar um item ou variante específica. | Nome, imagens, preço, disponibilidade, atributos, política aplicável e informação original. | Descrição copiada, dados divergentes e remoção definitiva quando o estoque zera. |
| Filtro indexável | Encontrar um subconjunto com atributo que altera a decisão. | URL estável, título próprio, lista suficiente, links internos e regra de canônico coerente. | Indexar toda combinação só porque a plataforma gera uma URL. |
O erro estrutural mais comum é deixar produto, categoria e filtro disputarem a mesma consulta. A arquitetura define uma página principal e usa links, âncoras, canônicos e conteúdo para reforçar essa escolha.
Relevância
Canibalização e conteúdo duplicado no catálogo
Canibalização ocorre quando páginas do mesmo site competem pela mesma intenção sem uma função clara. Não é simplesmente duas URLs conterem a mesma palavra. O sinal aparece quando a busca alterna entre páginas, nenhuma consolida posição ou uma URL menos adequada recebe impressões da consulta principal.
- Detectar — cruze consulta e página na Search Console, agrupe títulos e headings no crawl e compare produtos, categorias e facetas que aparecem para o mesmo conjunto de termos.
- Escolher a página principal — use intenção, sortimento, estabilidade, links e capacidade de conversão. A URL preferida precisa resolver melhor a consulta, não apenas ser a mais antiga.
- Diferenciar ou consolidar — se as intenções são distintas, ajuste escopo, heading e links. Se são equivalentes, una conteúdo e sinais, redirecione a URL descartada ou aplique canônico quando a duplicata precisa continuar acessível.
- Reforçar a arquitetura — atualize menus, breadcrumbs, artigos, sitemap e links de produtos para apontar diretamente à página escolhida. Depois acompanhe consulta por URL, não apenas cliques do domínio.
Duplicidade também nasce de parâmetros, versões imprimíveis, HTTP/HTTPS, maiúsculas, barra final e IDs de sessão. A correção começa na geração de URLs e links; depender apenas de canônico deixa o problema sendo produzido.
Conteúdo comercial
Descrição de produto: original onde a decisão exige
Copiar o fabricante torna a página intercambiável com outras lojas e frequentemente omite dúvidas de compra. Conteúdo original não é trocar sinônimos: é organizar informação confirmada sobre uso, compatibilidade, medida, material, cuidado, limitações e escolha da variante.
Em catálogo grande, reescrever tudo de uma vez é inviável. Priorize produtos com demanda, margem, estoque estável, diferenciação ou muitas dúvidas. Crie módulos por atributo e categoria, mas reserve texto específico para o que muda naquele item. Dados do fabricante continuam úteis como fonte técnica; devem ser normalizados e complementados, não apenas replicados.
Avaliações e perguntas de clientes podem revelar lacunas, desde que sejam reais, moderadas e vinculadas ao produto correto. Nunca se cria avaliação para preencher schema.
Dados estruturados
Schema para lojas: Product, Offer e dados que precisam bater
Dados estruturados descrevem o produto, mas precisam corresponder ao que a pessoa vê. Para product snippets, `Product` exige `name` e pelo menos `review`, `aggregateRating` ou `offers` para elegibilidade. Em página de venda, merchant listing adiciona propriedades comerciais mais detalhadas. A documentação do Google, não apenas o vocabulário amplo do schema.org, define o que um recurso de busca suporta.
- `Product` — representa um item específico ou variantes do mesmo produto. Nome, imagem, descrição, marca, SKU e identificadores ajudam a entidade; páginas genéricas de categoria não devem fingir ser um único produto.
- `Offer` — liga preço, moeda, disponibilidade, condição e URL à oferta. O valor no JSON-LD deve acompanhar o preço visível e a moeda da página, inclusive depois de promoções ou atualização de estoque.
- `AggregateRating` e `Review` — só entram quando avaliações reais estão visíveis e seguem as regras do tipo. Nota inventada, importada sem origem ou escondida viola a correspondência entre markup e página.
- Disponibilidade — usa valores reconhecidos, como `InStock`, `OutOfStock`, `PreOrder` ou o estado aplicável. Texto, botão de compra, feed e schema não devem se contradizer.
- Frete e devolução — informações de envio podem ser associadas à oferta; políticas de devolução da empresa podem ser declaradas na organização. Só marque condições que a loja realmente pratica e mantenha regiões, custos e prazos coerentes com o checkout.
- Variantes — cor e tamanho podem compartilhar um grupo, mas URLs, identificadores, oferta e disponibilidade precisam representar a variante selecionada. A estratégia depende de cada combinação ter ou não URL própria.
Experiência e escala
Performance em catálogo grande
Catálogos acumulam imagens, scripts de recomendação, analytics, avaliações, personalização e tags de campanha. No LCP, ataque primeiro o recurso principal acima da dobra: dimensão correta, formato, prioridade e caminho sem bloqueio. Carrosséis não devem baixar todas as imagens com a mesma prioridade.
INP piora quando filtros, variações e carrinho executam tarefas longas no thread principal. Dividir trabalho, reduzir hidratação e adiar terceiros preserva resposta. CLS pede dimensões para mídia, preço, selo e módulos tardios. Em categorias, consulta, cache e paginação do backend também precisam responder antes que otimização de frontend faça efeito.
Meça por template e dispositivo. Uma home rápida não representa categoria com muitos produtos nem página que carrega widgets adicionais.
Descoberta do catálogo
Paginação e scroll infinito rastreável
Google descobre URLs principalmente em `href` de links e não depende de clicar em botões para revelar todo o catálogo. Paginação deve oferecer URL própria para cada parte, links sequenciais e canônico para si mesma. Apontar todas as páginas para a primeira pode esconder produtos que só aparecem depois.
Scroll infinito pode continuar como experiência visual, desde que exista uma sequência paginada acessível sem interação. Estado apenas em fragmento `#` não serve para páginas distintas. Sitemaps e feeds complementam a descoberta, mas não substituem uma arquitetura navegável.
Mudança de plataforma
Migração de e-commerce sem perder receita orgânica
Antes da troca, exporte URLs, consultas, páginas de entrada, backlinks, canônicos, schema, produtos, categorias, filtros e redirects existentes. Monte o mapa antigo → novo por equivalência real, preserve páginas com demanda e teste checkout, estoque, analytics e feeds no ambiente de homologação. O processo completo está no guia de migração de plataformas.
Se hospedagem, banco ou rede mudam junto, use também o runbook de migração de servidores. Separar cutover de infraestrutura, catálogo e URLs deixa rollback e validação executáveis. Depois do go-live, rastreie redirects, erros, indexação, pedidos e integrações antes de encerrar o ambiente anterior.