SEO no Magento (Adobe Commerce): o que configurar

Configurar SEO no Magento não é o mesmo exercício que em uma loja Shopify ou WooCommerce. A plataforma tem uma arquitetura própria — catálogo multi-store, navegação em camadas construída sobre atributos de produto, um sistema de URL rewrites separado do conteúdo em si — e cada uma dessas peças, deixada na configuração padrão, cria duplicidade, desperdício de crawl budget ou páginas indexadas por engano.

Este artigo assume que você já sabe o que é uma tag canonical ou um redirecionamento 301 e quer saber, especificamente, onde o Magento (Adobe Commerce, na versão comercial) exige uma decisão diferente da que você tomaria em outra plataforma: navegação em camadas, canonical de produtos que vivem em várias categorias, o comportamento do URL rewrite ao renomear algo, store views com hreflang, e os pontos de performance que a própria plataforma expõe como configuração administrável.

Navegação em camadas: por que ela cria um problema de rastreamento

A navegação em camadas (layered navigation) gera uma URL para cada combinação de filtro — preço, cor, tamanho, disponibilidade — normalmente como parâmetros de query sobre a URL da categoria. Em um catálogo com uma dúzia de atributos filtráveis, o número de combinações possíveis cresce rápido, e cada combinação é, para um rastreador, uma página nova para visitar, mesmo que o conteúdo seja quase idêntico ao da categoria-base.

O ponto de configuração fica em cada atributo de produto: em Catálogo, a propriedade 'Usar em navegação em camadas' aceita 'Sim (com resultados)', 'Sim (sem resultados)' ou 'Não'. Cada atributo marcado como filtrável entra na combinatória. Isso não é uma decisão binária de tudo-ou-nada — a decisão prática é por atributo: um filtro de 'tamanho' em uma loja de roupas pode ter demanda de busca própria e valer a pena deixar indexável com uma landing page dedicada; um filtro de 'em estoque' ou um slider de preço não tem intenção de busca nenhuma e só produz ruído.

Para os filtros que você decide não indexar, as duas ferramentas disponíveis são o robots.txt (bloqueando os parâmetros de query específicos usados pelos atributos, não um bloqueio genérico de toda a navegação em camadas) e a tag canonical, apontando a página filtrada de volta para a URL limpa da categoria. O erro mais comum aqui é bloquear a navegação em camadas inteira no robots.txt: isso impede o rastreador de sequer chegar às combinações que você queria indexar, e ainda esconde o próprio sinal de canonical, porque o Google não processa canonical em uma URL que nunca rastreou.

Canonical para produtos que aparecem em várias categorias

É comum um produto pertencer a mais de uma categoria — uma camisa listada em 'Roupas femininas' e em 'Promoções', por exemplo. O Magento tem uma configuração em Catálogo > Search Engine Optimization chamada 'Usar caminho de categorias para URLs de produto'. Quando ativada, a URL do produto incorpora o caminho da categoria pela qual ele foi acessado, o que significa que o mesmo produto pode responder em mais de um caminho de URL válido, dependendo de por onde o visitante (ou o rastreador) chegou até ele.

Isso é, na prática, uma armadilha de conteúdo duplicado autoinfligida. A correção estrutural é desativar essa opção e manter uma única URL de produto, independente da categoria de origem — a navegação por categoria continua existindo normalmente, só não vira parte do caminho da URL. Mas se a loja já está no ar com essa opção ativada há tempo, simplesmente desligá-la troca a URL de cada produto multi-categoria de uma vez, e cada mudança de URL sem redirecionamento correspondente é um 404 na hora e uma perda de qualquer autoridade acumulada naquela URL específica. É uma migração, não um toggle: exige mapear as URLs antigas para as novas e criar os redirecionamentos 301 correspondentes antes de considerar o trabalho concluído.

Independentemente dessa configuração, verifique se a tag canonical está de fato sendo emitida: o campo 'Canonical Link Meta Tag' existe separadamente para categorias e para produtos, também em Catálogo > Search Engine Optimization, e um tema customizado pode sobrescrever ou remover essa tag no template do produto sem que isso apareça em nenhum lugar do admin. Confirme olhando o HTML renderizado, não apenas a configuração.

URL rewrites: como o Magento gerencia URLs e onde isso falha

O Magento mantém uma tabela de URL rewrites que traduz o caminho amigável (a URL que o visitante vê) para a rota interna real. Isso é separado do conteúdo — mudar a 'URL key' de uma categoria ou produto não move nada no banco de dados de catálogo, apenas gera uma nova entrada de rewrite e, dependendo da opção escolhida, mantém ou descarta a antiga.

Ao editar a URL key de um produto ou categoria pelo admin, o Magento oferece uma caixa de seleção para 'criar redirecionamento permanente para a URL antiga'. Se ela ficar desmarcada, a mudança quebra a URL anterior sem nenhum redirecionamento — um 404 puro, com qualquer sinal de ranking associado àquela URL perdido. Se a caixa é marcada, mas alguém depois entra em Marketing > SEO & Search > URL Rewrites e apaga manualmente a entrada antiga 'para limpar', o efeito é exatamente o mesmo: a proteção que a opção criou é destruída pela mesma pessoa que a ativou.

Antes de qualquer reestruturação em lote de categorias (renomear uma família inteira de URLs, por exemplo), o fluxo de trabalho seguro é: exportar a tabela de rewrites atual, planejar o mapeamento explícito de origem para destino, executar a mudança pelo admin (não por edição direta no banco — o Magento não recria rewrites automaticamente a partir de uma alteração de linha no banco, precisa passar pelos objetos de rewrite), e testar uma amostra de URLs antigas depois da mudança para confirmar que redirecionam e não retornam 404.

Uma armadilha específica de instalações multi-store: os rewrites são gerados por store view. Um script de importação em lote que só grava rewrites para o store view padrão deixa os outros store views com 404 em URLs que funcionavam antes — um erro que só aparece quando alguém testa a partir da loja secundária, não da principal.

Store views, hreflang e como evitar duplicidade entre lojas

A hierarquia website / store / store view do Magento permite expor o mesmo catálogo em múltiplas store views para idiomas, moedas ou regiões diferentes, frequentemente compartilhando a mesma categoria raiz e um conteúdo quase idêntico, variando só as strings traduzidas e o preço exibido.

Sem hreflang, o rastreador vê a URL de cada store view como uma página independente, competindo pelas mesmas palavras-chave — e, se a tradução de uma store view ainda estiver incompleta, como conteúdo literalmente duplicado do idioma de origem. O Magento não gera hreflang automaticamente a partir da estrutura de store views; isso precisa ser implementado como um bloco de tags rel='alternate' hreflang, mantido em sincronia manualmente (ou por um módulo dedicado) toda vez que uma store view nova é criada ou uma antiga é descontinuada, com referência própria (self-referencing) em cada URL e um x-default apontando para um fallback razoável.

Uma decisão que aparece na prática: usar o código de idioma isolado ('es') ou o código completo de idioma e região ('es-MX', 'es-AR') quando o mesmo idioma atende países diferentes com store views separadas por moeda e preço. Usar 'es' genérico em todas elas cria uma ambiguidade de destino que o buscador resolve por conta própria, e não necessariamente da forma que você esperaria — o resultado observável é a store view errada aparecendo para o país errado.

Dois erros recorrentes na implementação: apontar as tags hreflang para a URL de uma store view antes dela estar de fato publicada e indexável, e esquecer a exigência de reciprocidade — toda URL do conjunto hreflang precisa linkar de volta para todas as outras, não só apontar para a store view 'principal'. Um conjunto hreflang incompleto ou assimétrico é tratado como sinal inválido e ignorado.

Performance: cache, Varnish e o que de fato move os Core Web Vitals na plataforma

O Magento é, por padrão, mais pesado em processamento de servidor do que a maioria das plataformas de e-commerce hospedadas. O full page cache embutido (presente tanto na versão open source quanto na Adobe Commerce) precisa estar ativo, e em produção com tráfego real deve ficar atrás de um Varnish configurado, não do cache de arquivo ou banco de dados que vem como padrão de desenvolvimento.

Regras de preço por catálogo, exibição de preço diferente por grupo de cliente, e blocos injetados dinamicamente (mini-carrinho, produtos vistos recentemente, recomendações) forçam cache miss ou exigem hole-punching na página cacheada, o que aumenta o tempo de resposta do servidor especificamente para sessões logadas ou personalizadas — e esse tempo de resposta entra direto nos dados de campo que o Google coleta para Core Web Vitals.

No lado de imagens, o Magento gera múltiplos tamanhos derivados por produto e por tema. Uma troca de tema ou uma reconfiguração de galeria sem limpeza deixa tamanhos antigos não utilizados acumulados no diretório de cache de mídia; separadamente, imagens originais enviadas sem compressão e servidas sem um pipeline de otimização ou CDN são a causa mais comum de LCP alto em catálogos de produto.

No lado de JS e CSS, o processo de deploy de conteúdo estático do Magento (via linha de comando, com o modo de produção configurado) é responsável por minificar e agrupar os arquivos. Deixar a loja em modo de desenvolvedor em produção — o que acontece com mais frequência do que se imagina, geralmente depois de um deploy apressado — serve os assets sem minificação e sem merge, e é uma regressão de performance fácil de diagnosticar e fácil de corrigir, mas fácil de não notar até alguém medir.

Sitemap XML e robots.txt: o que revisar de fato

O sitemap XML do Magento é gerado por um job agendado (configurável em Marketing > SEO & Search > XML Sitemap, executado via cron). Se o cron não estiver rodando de verdade — algo fácil de assumir e nunca verificar —, o arquivo fica com data de geração antiga e passa a listar URLs que já não refletem a estrutura atual do catálogo. Vale checar o timestamp de geração do arquivo, não só assumir que ele está atualizado porque existe.

O robots.txt recomendado para o Magento costuma trazer linhas de disallow para checkout, conta de cliente, resultados de busca interna, comparador de produtos e lista de desejos. Se em algum momento um robots.txt customizado foi colado por cima do padrão sem incorporar essas linhas, essas áreas voltam a ficar abertas ao rastreamento sem que ninguém tenha decidido isso ativamente. Vale a pena revisar se essas linhas continuam presentes, e complementar com bloqueio dos parâmetros de filtro específicos usados pelos atributos filtráveis da sua navegação em camadas — os nomes de parâmetro variam de catálogo para catálogo, então uma lista genérica copiada de outro projeto não necessariamente cobre os seus.

Por fim, o sitemap deve listar apenas as URLs canônicas — produto e categoria em sua forma limpa, não as variações de navegação em camadas nem rewrites duplicados. O gerador nativo do Magento normalmente já faz isso corretamente, puxando direto das tabelas de produto e categoria; o risco aparece quando um módulo customizado injeta URLs adicionais no sitemap — inclusive, por engano, as próprias combinações de filtro que a seção sobre canonical de produto e a seção sobre navegação em camadas orientam a manter fora do índice.

Erros que aparecem com frequência em lojas Magento

A maioria dos problemas de SEO em lojas Magento não vem de decisões erradas conscientes — vem de configurações padrão que ninguém revisitou depois do lançamento, ou de uma mudança feita em uma área sem considerar o efeito em outra.

• Navegação em camadas totalmente aberta ao rastreamento, sem canonical nem bloqueio de parâmetro, gerando milhares de combinações de filtro indexadas.
• 'Usar caminho de categorias para URLs de produto' ativado sem plano de redirecionamento quando um produto muda de categoria ou é removido de uma delas.
• Edição da URL key de uma categoria ou produto sem marcar a opção de redirecionamento permanente, ou com a entrada antiga apagada manualmente depois.
• Bloco de hreflang copiado de outro projeto ou de um template genérico, sem apontar de fato para as store views reais da loja.
• Loja em modo desenvolvedor em produção, com assets sem minificação e sem full page cache ativo.
• Sitemap XML gerado uma única vez no lançamento e nunca mais regenerado depois de uma reestruturação de categorias.