Toda loja Magento 2 nasce com um problema silencioso de SEO técnico: a navegação por camadas (faceted navigation) gera milhares de combinações de URLs com parâmetros, o conteúdo se duplica entre categorias e a configuração padrão raramente está alinhada às diretrizes atuais do Google. O resultado é desperdício de crawl budget, canonicalização errada e perda de posições para concorrentes que dominam o básico.
Neste guia eu trato o SEO técnico do Magento como ele realmente é: uma combinação de configurações nativas do Admin (canonical, URL rewrites, XML sitemap, meta robots) com decisões de arquitetura que seguem a documentação oficial da Adobe Experience League e do Google Search Central. Sem achismo: cada recomendação aqui está ancorada em fonte verificável e no caminho exato dentro do painel. E como performance virou sinal de ranqueamento, vale ler em conjunto com o guia de Performance e Core Web Vitals.
Em mais de 14 anos implementando lojas Magento, aprendi que os ganhos mais rápidos não vêm de conteúdo, mas de corrigir indexação e duplicação. É exatamente por aí que vamos começar.
Tags canonical nativas do Magento: quando e como ativar
O Magento 2 / Adobe Commerce traz suporte nativo a canonical link meta tags, e a maioria das lojas roda com essa configuração desligada por padrão. O caminho exato é Stores > Settings > Configuration > Catalog > Catalog > Search Engine Optimization.
São dois campos independentes, ambos com opção Yes/No:
| Campo | Quando "Yes" | Exemplo de canonical gerado |
|---|---|---|
| Use Canonical Link Meta Tag for Categories | Direciona o indexador ao caminho completo da categoria | mystore.com/gear/bags/ |
| Use Canonical Link Meta Tag for Products | Usa o formato domínio + url-key do produto | mystore.com/driven-backpack.html |
A tag é inserida automaticamente no bloco <head> de cada página. A documentação oficial é direta sobre a recomendação:
As a best practice, it is recommended that you enable canonical meta tags for both categories and products.
Fonte: Magento merchdocs (GitHub)
Por que isso importa tanto no Magento
O motivo é estrutural: por padrão, um mesmo produto pode ser acessado por múltiplos caminhos de categoria (ex.: /gear/bags/driven-backpack.html e /sale/driven-backpack.html), além da URL canônica curta. Sem o canonical de produtos ligado, o Google enxerga várias URLs concorrentes para o mesmo conteúdo. Ao ativar Use Canonical Link Meta Tag for Products, todas essas variações passam a apontar para a forma domínio/url-key.html, consolidando os sinais de ranqueamento.
Minha recomendação prática
Eu ativo ambos como Yes em quase todos os projetos. Apenas em arquiteturas onde a categoria deve ranquear pelo caminho completo com filtro específico vale a pena revisar caso a caso. Lembre-se: o rel=canonical é um sinal forte, mas é uma sugestão (hint), não uma garantia — o Google pode ignorá-lo se houver sinais conflitantes, como veremos na seção sobre conteúdo duplicado.
URL rewrites, sufixo .html e redirecionamentos 301
A arquitetura de URLs do Magento é gerenciada por URL rewrites, que permitem alterar qualquer URL associada a produto, categoria ou página CMS. Existem quatro tipos de rewrite: Product, Category, CMS Page e Custom. O comportamento padrão protege seu SEO de forma elegante quando você muda uma URL key.
Your store can be configured to automatically generate a permanent redirect whenever the URL key of a product or category changes.
Fonte: Adobe Experience League
O campo que governa os redirects automáticos
Em Stores > Settings > Configuration > Catalog > Catalog > Search Engine Optimization existe o campo Create Permanent Redirect for URLs if URL Key Changed. Quando definido como Yes, o Magento gera um 301 sempre que a URL key de um produto ou categoria muda. Adicionalmente, no campo URL Key de cada produto há o checkbox Create Permanent Redirect for old URL, que vem selecionado por padrão.
O 301 é, segundo o Google, um sinal forte de que o destino do redirect deve se tornar canônico — por isso preservar esses redirects é essencial para não perder autoridade acumulada quando você reorganiza o catálogo.
Sufixo de URL: .html ou não?
O sufixo de produtos e categorias é controlado na mesma seção pelos campos Product URL Suffix e Category URL Suffix (tipicamente .html). Decida isso antes de lançar a loja. Mudar o sufixo depois força a recriação de todos os rewrites e gera uma onda de 301 em massa — funcional, mas que polui o índice por semanas.
- Defina cedo: escolha sufixo e padrão de URL key na fase de implementação, não em produção.
- Não delete redirects: manter os 301 antigos é o que preserva o link equity de URLs já indexadas.
- Monitore loops: alterações repetidas de URL key podem criar cadeias de redirect (A→B→C); reescreva-as para apontar direto ao destino final.
- Custom rewrites: use o tipo Custom para migrar URLs de plataformas antigas mapeando endereços legados para os novos.
Esse mapeamento de URLs legadas é justamente um dos pontos mais delicados de um redesign ou troca de plataforma — o tema é tratado em detalhe no guia de Migração de Magento 1 para Magento 2, onde o plano de 301 define se você preserva ou queima o tráfego orgânico acumulado.
Na minha experiência, a tabela url_rewrite de uma loja madura facilmente ultrapassa centenas de milhares de linhas. Auditá-la periodicamente para remover cadeias e duplicidades melhora tanto SEO quanto performance de banco.
Dados estruturados e Rich Results: Product, Offer, AggregateRating e BreadcrumbList
Dados estruturados não influenciam ranqueamento diretamente, mas habilitam resultados ricos (rich results) — preço, avaliação e disponibilidade na SERP — que elevam drasticamente a taxa de clique. O Google suporta três formatos: JSON-LD (recomendado), microdata e RDFa.
Propriedades obrigatórias do tipo Product
| Tipo | Propriedades obrigatórias | Observação |
|---|---|---|
| Product | name, image, offers | image como ImageObject ou URL; offers aninha um Offer |
| Offer | price (ou priceSpecification.price), priceCurrency, availability | priceCurrency em ISO 4217 (3 letras, ex.: BRL); para merchant listing o preço deve ser maior que zero |
| AggregateRating | ratingValue, reviewCount | deve refletir avaliações reais visíveis na página |
| Review | reviewRating (ratingValue, bestRating), author | author como Person com nome válido |
Unlike product snippets, merchant listing experiences require a price greater than zero.
Fonte: Google Search Central
Um ponto que o Google fiscaliza com rigor: notas e avaliações precisam refletir conteúdo genuíno visível ao usuário na página. Injetar AggregateRating sem reviews reais expostas viola as diretrizes e pode gerar ação manual.
Exemplo mínimo de JSON-LD de produto
Para fixar a estrutura, este é o esqueleto que valido no Rich Results Test antes de subir qualquer template de PDP:
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Driven Backpack",
"image": "https://mystore.com/media/driven-backpack.jpg",
"offers": {
"@type": "Offer",
"price": "199.90",
"priceCurrency": "BRL",
"availability": "https://schema.org/InStock"
}
}BreadcrumbList: a trilha que aparece na SERP
O BreadcrumbList melhora a aparência do resultado substituindo a URL crua por uma trilha de navegação. Ele exige itemListElement (array de ListItem), e cada ListItem exige position (inteiro começando em 1), name e item (URL). O item é opcional no último breadcrumb (a própria página atual): se não for incluído, o Google usa a URL da página que contém o markup.
- Mínimo recomendado: ao menos dois ListItem.
- Não inclua: o domínio/host raiz nem a própria página como itens obrigatórios.
- Relação no schema.org: o tipo schema.org/Product relaciona-se a
offers(Offer) eaggregateRating(AggregateRating).
No Magento, o tema Luma já emite alguns dados estruturados, mas em projetos sérios eu recomendo um módulo dedicado ou template customizado emitindo JSON-LD limpo, sempre validado no Rich Results Test do Google antes de subir para produção.
XML sitemap nativo e robots.txt
O Adobe Commerce gera XML sitemaps nativamente em Stores > Settings > Configuration > Catalog > XML Sitemap, organizado em seções como Categories Options, Products Options e CMS Pages Options (além de Store Url Options). Cada uma controla frequência, prioridade e inclusão de imagens de forma independente.
| Parâmetro | Valores aceitos | Padrão / observação |
|---|---|---|
| Frequency | Always, Hourly, Daily, Weekly, Monthly, Yearly, Never | defina por tipo de conteúdo |
| Priority | 0.0 a 1.0 | zero = menor prioridade |
| Add Images into Sitemap | None, Base Only, All | All inclui todas as imagens do produto |
| Maximum No of URLs per File | numérico | padrão 50.000 |
| Maximum File Size | bytes | padrão 10.485.760 bytes (10 MB) |
Quando a loja ultrapassa os limites de URLs ou tamanho, o Magento quebra automaticamente o sitemap em vários arquivos com um índice. Isso é normal e esperado em catálogos grandes. Há ainda a opção Enable Submission to Robots.txt, que inclui o sitemap automaticamente no robots.txt.
For Priority, enter a value between 0.0 and 1.0. Zero has the lowest priority. [...] By default, the limit is 50,000. [...] The default size is 10,485,760 bytes.
Fonte: Adobe Experience League
robots.txt e meta robots no Admin
O robots.txt é editado no Admin, dentro de Content > Design > Configuration, na seção Search Engine Robots. Ali também fica a meta tag Default Robots, com quatro opções:
- INDEX, FOLLOW: padrão, para produção.
- NOINDEX, FOLLOW: útil em ambientes específicos sem perder o fluxo de links.
- INDEX, NOFOLLOW: raramente recomendado.
- NOINDEX, NOFOLLOW: ideal para ambientes de staging/homologação.
Uma regra de segurança oficial que muita gente ignora: não exponha o caminho do Admin no robots.txt. Listar o Admin em Disallow só revela onde ele está. Em ambientes multi-site, use arquivos por domínio (ex.: domainone_robots.txt). Esse cuidado faz parte de uma postura mais ampla de proteção da loja, detalhada no guia de Segurança e Hardening do Magento 2.
Multi-store, store views e hreflang para lojas multi-idioma
A arquitetura de websites → stores → store views do Magento é poderosa para operações multi-idioma e multi-país, mas exige hreflang correto para não gerar canibalização entre versões localizadas. O Google aceita três métodos para indicar versões localizadas:
- Tag HTML:
<link rel="alternate" hreflang="lang_code" href="url" /> - Header HTTP:
Link: <url>; rel="alternate"; hreflang="lang_code" - Sitemap:
<xhtml:link rel="alternate" hreflang="code" href="url"/>
A regra que mais gera erro: bidirecionalidade
Each language version must list itself as well as all other language versions. [...] If two pages don't both point to each other, the tags will be ignored.
Fonte: Google Search Central
Traduzindo para a prática: cada store view deve emitir hreflang para si mesma (auto-referência) e para todas as outras versões. Se a versão em português aponta para a inglesa, mas a inglesa não retribui o link, o Google ignora as tags inteiras. Esse é o erro número um em lojas brasileiras que exportam.
Códigos corretos de idioma e região
- Idioma: ISO 639-1 (ex.:
pt,en,es). - Região (opcional): ISO 3166-1 Alpha 2 (ex.:
de-CHpara alemão da Suíça,pt-BRpara português do Brasil). - Fallback: use o valor reservado
x-defaultpara a versão genérica quando nenhuma localização específica casa com o usuário.
Aplicando no Magento
Cada store view tem sua própria Base URL (subpasta, subdomínio ou domínio dedicado). Eu prefiro emitir o hreflang via tag HTML no <head> por ser o método mais fácil de auditar com ferramentas. Garanta que o mapeamento entre store views e códigos hreflang seja consistente e que cada página inclua a auto-referência — sem isso, todo o esforço de internacionalização é descartado pelo Google.
Core Web Vitals e page experience como sinais de ranqueamento
Performance virou SEO. Os Core Web Vitals fazem parte dos sinais de page experience usados pelo Google, e o Magento — com seu peso de tema, JavaScript e Knockout — exige atenção real para atingir as faixas "good". São três métricas, medidas no 75º percentil de carregamentos, em mobile e desktop:
| Métrica | O que mede | Limiar "good" |
|---|---|---|
| LCP (Largest Contentful Paint) | tempo até o maior elemento visível renderizar | ≤ 2,5 segundos |
| INP (Interaction to Next Paint) | responsividade às interações do usuário | ≤ 200 milissegundos |
| CLS (Cumulative Layout Shift) | estabilidade visual do layout | ≤ 0,1 |
INP will officially become a Core Web Vital and replace FID on March 12 of this year.
Fonte: web.dev (Google/Chrome)
Em 12 de março de 2024, o INP substituiu oficialmente o FID como Core Web Vital. O antigo FID foi removido do Search Console, com período de descontinuação de seis meses em ferramentas como PageSpeed Insights e CrUX. Se sua loja ainda monitora FID, está olhando para a métrica errada.
O que ataco primeiro em uma loja Magento
- LCP: ative Full Page Cache (Varnish em produção), otimize a imagem hero do banner e priorize o carregamento above-the-fold.
- INP: reduza e adie JavaScript não crítico; o tema Luma carrega muito JS via RequireJS que trava a thread principal em interações.
- CLS: reserve dimensões de imagens e banners, e evite injeção tardia de elementos (popups, barras) que empurram o conteúdo.
- Build de produção: rode
php bin/magento setup:static-content:deployephp bin/magento deploy:mode:set productioncom merge/minify de CSS e JS ligados.
Na minha experiência, o maior ganho de LCP em Magento vem de Varnish + CDN + otimização de imagens; o de INP vem de cortar JavaScript de terceiros (chats, pixels, tag managers carregando síncrono). Como este é um tema extenso por si só — com cache, Varnish, imagens em WebP/AVIF e otimização de tema —, aprofundei cada frente no guia dedicado de Performance e Core Web Vitals no Magento 2.
Conteúdo duplicado: paginação, multicategorias, www vs não-www e HTTP vs HTTPS
Conteúdo duplicado em Magento raramente é cópia literal de texto — é duplicação de URL. O mesmo produto ou listagem acessível por vários endereços dilui sinais. O Google oferece um espectro de métodos de canonicalização com forças diferentes, e a estratégia vencedora é combinar mais de um.
| Método de canonicalização | Força do sinal |
|---|---|
| Redirect 301 | sinal forte (destino deve se tornar canônico) |
| rel=canonical | sinal forte (hint, não garantia) |
| Inclusão no sitemap | sinal fraco |
Google prefers HTTPS pages over equivalent HTTP pages as canonical, except when there are issues or conflicting signals.
Fonte: Google Search Central
Cenários típicos no Magento e como resolvo cada um
- Produto em múltiplas categorias: ative Use Canonical Link Meta Tag for Products para consolidar todas as variações de caminho na URL curta
domínio/url-key.html. - Paginação: use canonical e meta robots de forma coerente; eu indexo a página 1 como canônica da série e mantenho as demais rastreáveis com
noindex,followou autocanônicas, dependendo do objetivo. Evite apontar canonical de todas as páginas para a página 1 cegamente. - Parâmetros de URL (filtros, ordenação): resolvidos com a combinação de robots.txt Disallow + canonical, como tratamos na faceted navigation.
- www vs não-www: escolha uma forma na Base URL e force a outra via 301.
- HTTP vs HTTPS: configure a Secure URL, redirecione todo HTTP para HTTPS com 301 e ative HSTS. O Google já prefere HTTPS como canônica, e o HSTS elimina o salto inicial inseguro.
A configuração de HTTPS, HSTS e redirecionamentos seguros se conecta diretamente ao endurecimento da loja — vale conferir o guia de Segurança e Hardening do Magento 2 para o passo a passo completo de TLS e cabeçalhos de segurança.
O rel=canonical é apenas uma sugestão — o Google pode escolher outra URL se houver sinais conflitantes. Por isso a regra de ouro: combinar dois ou mais métodos aumenta a chance de a URL preferida aparecer na busca. Em uma migração, por exemplo, eu uso 301 + canonical + sitemap atualizado simultaneamente, em vez de confiar em um único sinal.
Perguntas frequentes
Devo bloquear os filtros da navegação por camadas no robots.txt ou usar só o canonical?
A recomendação primária do Google é bloquear o rastreamento das URLs de filtros com Disallow no robots.txt, porque elas geram um volume enorme de URLs que consomem crawl budget sem benefício. O rel=canonical é menos eficaz a longo prazo, pois apenas pode, com o tempo, reduzir o rastreamento das versões não-canônicas. Na prática, eu combino robots.txt para o bloqueio, canonical apontando para a categoria limpa e noindex onde a página ainda renderiza.
Ativar as tags canonical nativas do Magento resolve meu problema de conteúdo duplicado?
Ajuda bastante, mas não sozinho. Ativar Use Canonical Link Meta Tag for Products consolida um produto que aparece em múltiplas categorias na URL curta domínio/url-key.html, e a versão para categorias usa o caminho completo. Porém o rel=canonical é um sinal forte do tipo hint, não uma garantia: o Google pode ignorá-lo se houver sinais conflitantes. Para casos como www vs não-www e HTTP vs HTTPS você ainda precisa de 301 e HSTS.
O que acontece com o SEO quando eu mudo a URL key de um produto no Magento?
Se o campo Create Permanent Redirect for URLs if URL Key Changed estiver como Yes (e o checkbox Create Permanent Redirect for old URL marcado, que é o padrão), o Magento cria automaticamente um redirecionamento 301 da URL antiga para a nova. Isso preserva a autoridade acumulada, já que o 301 é o sinal mais forte de canonicalização para o Google. Nunca delete esses redirects antigos.
Quais campos de dados estruturados são obrigatórios para aparecer com preço e avaliação na busca?
Para o tipo Product, são obrigatórios name, image e offers. Dentro de Offer, são obrigatórios price (ou priceSpecification.price), priceCurrency em código ISO 4217 de três letras (BRL no Brasil) e availability. Para experiências de merchant listing o preço deve ser maior que zero. Avaliações via AggregateRating exigem ratingValue e reviewCount e precisam refletir reviews genuínas visíveis na página, sob risco de ação manual.
Quais são as metas de Core Web Vitals que minha loja Magento precisa atingir?
As faixas consideradas boas, medidas no 75º percentil, são LCP até 2,5 segundos, INP até 200 milissegundos e CLS até 0,1. Atenção: o INP substituiu oficialmente o FID como Core Web Vital em 12 de março de 2024, então monitorar FID não faz mais sentido. Em Magento, os maiores ganhos costumam vir de Full Page Cache com Varnish, CDN, otimização de imagens e redução de JavaScript de terceiros.
Preciso preencher a meta keywords nos produtos do Magento?
Não para fins de ranqueamento. O Google confirmou em 2009 que não usa a meta tag keywords no ranqueamento de busca web, e essa política continua válida. O campo ainda existe no Magento, mas preenchê-lo não traz benefício e, no pior caso, expõe seu mapeamento de palavras-chave. Concentre esforço no meta title (abaixo de ~70 caracteres) e na meta description (150–160 caracteres), que afetam o CTR.
Referências oficiais
- Meta data (SEO) - Adobe Commerce Admin — Adobe Experience League
- Use Canonical Link Meta Tag (merchdocs) — Magento merchdocs (GitHub)
- Automatic product redirects (Create Permanent Redirect) — Adobe Experience League
- XML Sitemap - Adobe Commerce Admin — Adobe Experience League
- Managing crawling of faceted navigation URLs — Google Search Central
- Intro to Product structured data on Google — Google Search Central
- Merchant listing (structured data) experiences — Google Search Central
- Breadcrumb (BreadcrumbList) structured data — Google Search Central
- Consolidate duplicate URLs (canonicalization) — Google Search Central
- Tell Google about localized versions (hreflang) — Google Search Central
- INP becomes a Core Web Vital (replaces FID) — web.dev (Google/Chrome)
- Web Vitals (LCP, INP, CLS thresholds) — web.dev (Google/Chrome)