A página de produto é onde o SEO de uma loja virtual vira receita. É a página que responde à busca de quem já sabe o que quer comprar, e também a que mais sofre com texto copiado do fabricante, variações mal resolvidas e dados estruturados que não batem com o que o cliente vê.
Este guia reúne o que a documentação oficial do Google diz sobre título, descrição, imagens, avaliações, variações e dados estruturados de produto, e traduz isso em um passo a passo para lojas brasileiras. Onde a documentação não dá um número, dizemos isso, para que convenções de mercado não sejam confundidas com regra.
A lógica é simples: o Google precisa entender qual é o produto, quanto custa, se está disponível e por que a sua página é a melhor para o usuário. Cada seção abaixo cuida de uma dessas respostas.
O que o Google precisa ver numa página de produto
Uma página de produto bem resolvida combina quatro camadas: a estrutura (URL, canonical e links), o conteúdo visível (título, descrição, imagens e avaliações), os dados estruturados (Product, Offer e políticas) e o feed do Merchant Center. As camadas precisam dizer a mesma coisa. Quando preço ou disponibilidade diferem entre elas, o Google deixa de mostrar o resultado enriquecido ou trata o caso como violação das diretrizes.
A ordem de trabalho abaixo é a que recomendamos em auditorias. O passo destacado, dados estruturados, é o que mais depende dos anteriores: não adianta marcar o que a página não mostra.
- 1URL e canonicalUma URL estável por produto, com canonical autorreferente nas páginas indexáveis.
- 2Título e H1Nome do produto claro, com marca e atributo principal, sem repetição.
- 3Descrição própriaTexto original com uso, medidas, materiais e dúvidas reais do cliente.
- 4ImagensFotos nítidas, arquivos com nome descritivo, texto alternativo e peso controlado.
- 5Avaliações visíveisNotas e textos de clientes reais exibidos na própria página.
- 6Dados estruturadosProduct, Offer e políticas de frete e devolução, iguais ao que a página mostra.
- 7Feed do Merchant CenterPreço e estoque do feed iguais aos da página, com atualização frequente.
Para tirar a teoria do papel, o esquema a seguir mostra a ordem sugerida dos elementos de uma página de produto. O wireframe é uma recomendação da Analytikos para organizar o que a documentação do Google pede e o que ajuda o cliente a decidir. Ele não é um modelo oficial e deve ser adaptado à sua plataforma.
Leitura do wireframe: os itens 1 a 6 ocupam a parte de cima da página e respondem à pergunta “é isto que eu procuro, quanto custa e quando chega?”. Os itens 7 a 10 sustentam a decisão com informação, prova social e respostas às dúvidas finais. O item 11 não é visível, mas precisa refletir exatamente o que está nos itens 3, 4 e 5, porque os dados estruturados devem corresponder ao conteúdo da página.
FAQ na página de produto
A seção de perguntas frequentes (item 9 do wireframe) tira dúvidas na hora da decisão: quem não encontra a resposta sobre prazo, troca ou medida costuma sair da página e buscar em outro lugar. Para o SEO, ela também acrescenta texto útil e específico ao produto, com a linguagem que o cliente realmente usa.
Como montar um FAQ de produto que funciona
- Use perguntas reais, vindas do atendimento, do chat, das avaliações e das perguntas feitas no marketplace.
- Cubra o que trava a compra: frete e prazo, troca e devolução, medidas e tamanho, compatibilidade, cuidados e garantia.
- Escreva respostas curtas e diretas, com a informação completa já na primeira frase.
- Mantenha as respostas visíveis no HTML da página, sem depender de clique para carregar o texto.
- Fale do produto em questão. Perguntas genéricas da loja inteira ficam em uma página de ajuda, com link a partir daqui.
E a marcação FAQPage?
O Google deixou de exibir resultados enriquecidos de FAQPage na Pesquisa e removeu essa documentação. Por isso, o valor do FAQ está no conteúdo visível, que ajuda o cliente e dá contexto à página. Se sua plataforma já gera a marcação, ela não prejudica, desde que reflita exatamente as perguntas e respostas mostradas na página. Não vale a pena investir tempo só para obtê-la.
Título e descrição: o que a documentação diz e o que é convenção
Segundo a documentação do Google sobre links de título, não há limite de tamanho para o elemento title, e o Google trunca o que exceder a largura do dispositivo. A mesma página explica que o Google gera o título exibido a partir de várias fontes, como o title, o H1 e o texto âncora, e pode reescrevê-lo quando ele está vazio, desatualizado, repetitivo ou não bate com a página. As boas práticas são títulos distintos por página, descritivos e concisos, sem repetição de palavras-chave.
Para a descrição, a documentação de snippets também não define limite de caracteres. O snippet vem principalmente do conteúdo da página e muda conforme a busca; a meta description é usada quando resume a página melhor do que o texto. O Google recomenda descrições únicas por página, que funcionem como um resumo preciso e incluam detalhes úteis, como o preço. Gerar descrições de forma programática é aceito, se o resultado for legível e variado.
Os números de 60 caracteres para título e 155 para descrição que circulam no mercado são convenções para evitar truncamento, não regras do Google. Usamos 60 e 140 a 160 como referência de trabalho, e você deve conferir o resultado na busca.
| Elemento | Fórmula recomendada | Exemplo |
|---|---|---|
| Título (title) | Produto + atributo principal + marca | Tênis de corrida Aero 2, masculino | Loja Exemplo |
| H1 | Nome do produto, igual ou próximo ao título | Tênis de corrida Aero 2 masculino |
| Meta description | Benefício + atributo + preço ou condição | Tênis leve para corrida de rua, amortecimento em espuma. Frete grátis acima de R$ 199. |
Conteúdo da página: descrição única e atributos que respondem dúvidas
As diretrizes de conteúdo útil do Google pedem conteúdo original, que ofereça valor substancial em relação aos outros resultados, e tratam texto produzido em massa sem revisão como pouco esforço. A documentação não cita descrição de fabricante em páginas de produto. Que a cópia do fabricante, repetida em dezenas de lojas, não ajuda a página a se diferenciar é uma inferência nossa a partir dessas diretrizes.
Na prática, a descrição própria cobre o que o cliente precisa saber para decidir: para quem é, o que acompanha, medidas, materiais, compatibilidade, cuidados, prazo de uso e perguntas frequentes. Os dados do atendimento e da busca interna indicam quais dúvidas incluir. Esse trabalho também conversa com a pesquisa de termos, que detalhamos em pesquisa de palavras-chave: o guia passo a passo.
Imagens: o que a documentação exige e o que ajuda
Para elegibilidade em listagens de comerciantes, a documentação de merchant listing pede imagens rastreáveis e indexáveis, com ao menos 50 mil pixels (largura vezes altura), com o produto claramente visível. Recomenda ainda várias imagens, nas proporções 16:9, 4:3 e 1:1.
No SEO de imagens, a documentação do Google Imagens orienta usar o elemento img ou picture (imagens de fundo em CSS não são indexadas), formatos suportados como JPEG, PNG, WebP, SVG e AVIF, texto alternativo descritivo e nomes de arquivo claros, além de sitemap de imagens quando houver CDN. Sempre mantenha um img com src como alternativa ao usar srcset. Sobre formatos mais novos, veja JPEG XL no Google Imagens e no Discover.
Imagens pesadas prejudicam o carregamento. Os limites de Core Web Vitals considerados bons, medidos no percentil 75 segundo o web.dev, são LCP de até 2,5 segundos, INP de até 200 milissegundos e CLS de até 0,1. Em páginas de produto, a imagem principal costuma ser o elemento do LCP.
Avaliações na página e as estrelas nos resultados
Para ganhar estrelas, a documentação de review snippets exige, em um Review, o autor (com menos de 100 caracteres), o nome do item avaliado e a nota; em um AggregateRating, o nome do item, a nota média e a contagem de avaliações. Product é um tipo suportado.
As regras mais importantes: não agregue avaliações de outros sites, não use avaliações falsas ou incentivadas sem divulgação, e marque apenas o que está visível na página. Se você marca várias avaliações de um tipo, inclua todas as visíveis. Segundo as políticas de dados estruturados, avaliações que não foram escritas por usuários reais podem gerar ação manual, que remove a elegibilidade a resultados enriquecidos sem afetar o ranking da busca web.
Dados estruturados de produto: o que é obrigatório e o que é recomendado
A documentação do Google separa dois usos. Os product snippets valem para páginas em que não se compra direto, como análises. Os merchant listings valem para páginas onde se compra, e trazem detalhes como frete e devolução. Uma loja virtual deve mirar nos requisitos de merchant listing, que também habilitam os product snippets, como explica a visão geral de dados estruturados de produto.
| Item | Obrigatório | Recomendado |
|---|---|---|
| Product (merchant listing) | name, image e offers (do tipo Offer) | aggregateRating, brand, category, color, description, gtin |
| Offer | price maior que zero e priceCurrency | availability, itemCondition, url, priceValidUntil, hasMerchantReturnPolicy, shippingDetails |
| Product snippet | name e ao menos um entre review, aggregateRating ou offers | availability, priceCurrency, priceValidUntil |
| Review | Autor, nome do item e nota | Texto da avaliação visível na página |
| AggregateRating | Nome do item, nota média e contagem de avaliações | Somente avaliações reais e visíveis |
Dois detalhes evitam perdas silenciosas. Primeiro, um priceValidUntil com data passada pode suprimir o snippet. Segundo, AggregateOffer serve para vários vendedores do mesmo produto, não para variantes. O exemplo abaixo mostra a estrutura mínima, com valores fictícios, em JSON-LD, que o Google recomenda por ser o formato mais simples de manter.
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Tênis de corrida Aero 2 masculino",
"image": ["https://www.exemplo.com.br/img/aero2-1x1.jpg", "https://www.exemplo.com.br/img/aero2-4x3.jpg"],
"description": "Tênis leve para corrida de rua, com amortecimento em espuma.",
"sku": "AERO2-M-42",
"gtin13": "7890000000000",
"brand": { "@type": "Brand", "name": "Marca Exemplo" },
"aggregateRating": { "@type": "AggregateRating", "ratingValue": "4.6", "reviewCount": "128" },
"offers": {
"@type": "Offer",
"url": "https://www.exemplo.com.br/tenis-aero-2",
"price": "349.90",
"priceCurrency": "BRL",
"availability": "https://schema.org/InStock",
"itemCondition": "https://schema.org/NewCondition"
}
}Os valores acima são inventados para ilustrar a estrutura. Em produção, gere o JSON a partir dos mesmos dados que alimentam a página, para que preço e estoque nunca divirjam.
Frete e devolução
Para frete e devolução, o Google prefere uma política única declarada no nível da organização. Na política de devolução, é obrigatório informar o país de aplicação e a categoria da política (por exemplo, janela finita com número de dias) ou um link para a política. Na política de frete, o serviço de envio é declarado na organização e referenciado por produto; detalhes por oferta ficam para casos fora do padrão. Em caso de conflito, as configurações do Merchant Center e do Search Console têm precedência sobre o markup do produto. Não confirmamos aqui a lista completa de propriedades obrigatórias de frete em nível de oferta; consulte a documentação antes de implementar.
Variações de produto: uma URL ou várias?
A documentação de variantes recomenda ProductGroup com hasVariant, productGroupID e variesBy (cor, tamanho, material e outros). Cada variante precisa de um sku ou gtin próprio. Quando cada variante tem URL própria, ela deve abrir pré-selecionada, com imagem, preço, disponibilidade e carrinho corretos.
Há uma tensão entre duas recomendações oficiais. O guia de estrutura de URLs para e-commerce diz que, com parâmetros opcionais de variante, a URL sem parâmetro é a canônica e, com URL própria por variante, o canonical pode apontar para o produto principal. A decisão é de projeto, e a tabela resume as duas opções.
| Opção | Quando usar | Cuidado |
|---|---|---|
| Uma URL por produto, variante por seletor | Variações com pouca diferença de busca (cor, tamanho) | O estado da variante não é indexado; preço e imagem do seletor precisam estar claros. |
| Uma URL por variante, canonical no produto principal | Quando o catálogo ou o feed exigem URL por variante | Defina qual página deve ranquear; mantenha links, sitemap e canonical coerentes. |
| Uma URL por variante, canonical autorreferente | Quando a variante tem demanda de busca própria (modelo, não só cor) | Evite conteúdo quase idêntico entre variantes. |
Produto esgotado ou fora de linha
A documentação define como sinalizar indisponibilidade: use o valor OutOfStock (ou SoldOut) em availability, um valor por oferta, e mantenha o dado atualizado, porque o Google não mostra resultado enriquecido para conteúdo sensível ao tempo que perdeu a relevância. Não encontramos orientação oficial sobre manter, redirecionar ou remover a página de produto esgotado, e por isso não afirmamos nada além disso. O tratamento completo desse caso é tema de outro guia.
Como testar e monitorar
Teste o markup com o Teste de Resultados Enriquecidos do Google e com o Schema Markup Validator, e acompanhe os relatórios de dados estruturados e de listagens de comerciantes no Search Console. A própria documentação alerta que os testes pegam a maioria dos erros técnicos, mas não todos, porque as diretrizes de qualidade não são totalmente testáveis. O processo de auditoria completo está em auditoria de SEO: como fazer e o que analisar.
Um exemplo numérico, hipotético, mostra como priorizar. Uma loja com 2.000 produtos indexados roda a validação e encontra 340 páginas com priceValidUntil vencido e 90 sem a propriedade price. Corrigir a data resolve 17% do catálogo (340 ÷ 2.000) com uma única regra no template; a ausência de preço afeta 4,5% (90 ÷ 2.000) e exige correção no cadastro. A primeira correção entrega mais cobertura por hora de trabalho.
Erros comuns na página de produto
Os erros abaixo são os que mais vemos em auditorias de lojas virtuais. Cada um traz o motivo, o efeito no resultado e a correção.
Erros de dados estruturados e de feed
| Erro | Por que acontece e qual o efeito | Como corrigir |
|---|---|---|
| JSON-LD diferente do que a página mostra | O markup é gerado por um plugin ou template antigo, que não acompanha promoções. O Google trata a divergência de preço ou estoque como violação das diretrizes e o resultado enriquecido some. | Gerar o JSON-LD a partir da mesma fonte de dados da página e do feed. |
| priceValidUntil vencido | A data foi fixada no template. O snippet pode deixar de ser exibido, mesmo com o resto correto. | Remover a propriedade ou calculá-la dinamicamente. |
| Marcar conteúdo invisível | Para parecer completo, o markup traz avaliações ou campos que o usuário não vê. É contra as políticas e pode gerar ação manual. | Marcar só o que está visível na página. |
| Agregar avaliações de outros sites | O selo de outro marketplace é copiado para a página. A documentação proíbe agregar avaliações de outros sites. | Usar apenas avaliações coletadas na própria loja. |
| Product só montado por JavaScript | O markup nasce depois da renderização. O Google pode rastrear com menos frequência e preço e estoque ficam desatualizados na busca. | Entregar o Product no HTML inicial. |
| Preço que muda por IP ou navegador | A landing page personaliza o preço. O Merchant Center exige que o dado estruturado bata com o que o cliente vê. | Exibir o mesmo preço para todos os acessos. |
Erros de conteúdo e de estrutura
| Erro | Por que acontece e qual o efeito | Como corrigir |
|---|---|---|
| Descrição copiada do fabricante | O cadastro importa o texto do fornecedor. A página fica igual a dezenas de outras e perde a chance de ser a mais útil. | Escrever descrição própria com uso, medidas e dúvidas reais. |
| Mesmo título em muitas páginas | O template repete o nome da loja ou usa só o modelo. O Google reescreve o título e a página fica indistinta nos resultados. | Título único por produto, com atributo principal. |
| Imagens só em CSS ou sem alt | Galerias de tema usam background-image. A imagem não é indexada e a página perde busca por imagem. | Usar img com src, nome de arquivo claro e alt descritivo. |
| Variantes sem sku ou gtin próprios | O catálogo usa o mesmo código para todas as cores. O Google não distingue as variantes e o feed apresenta erros. | Um sku ou gtin por variante. |
Erros de operação
| Erro | Por que acontece e qual o efeito | Como corrigir |
|---|---|---|
| Nunca validar depois de uma mudança de tema | A atualização do tema altera o template e o markup quebra sem aviso. A perda aparece semanas depois, nos relatórios do Search Console. | Validar uma amostra de páginas a cada mudança de template. |
| Tratar o feed e a página como projetos separados | Times diferentes cuidam de cada um. Preço e estoque divergem e as listagens são reprovadas. | Um responsável pelos dados de produto e uma rotina de comparação. |
Checklist de SEO para página de produto
- Uma URL estável por produto, com canonical autorreferente.
- Título único, com produto, atributo principal e marca.
- H1 claro e alinhado ao título.
- Meta description única, com benefício e condição.
- Descrição própria, com uso, medidas, materiais e dúvidas frequentes.
- Imagens com ao menos 50 mil pixels, nomes de arquivo claros e texto alternativo.
- Imagem principal otimizada para LCP de até 2,5 segundos.
- Avaliações de clientes reais, visíveis na página, sem agregar outros sites.
- Product e Offer no HTML inicial, com name, image, price e priceCurrency.
- availability atualizado e priceValidUntil válido ou ausente.
- Política de frete e devolução declarada no nível da organização.
- Variantes com sku ou gtin próprios e regra de canonical definida.
- Preço e estoque do feed iguais aos da página.
- Validação em uma amostra de páginas a cada mudança de template.
Perguntas frequentes
Qual o tamanho ideal de título e de meta description?
A documentação do Google não define limite de caracteres. Os números usados no mercado, como 60 para o título e 155 para a descrição, são convenções para reduzir truncamento. Confira o resultado na busca e priorize clareza.
Preciso de dados estruturados para ranquear?
Dados estruturados não são requisito de ranqueamento, mas habilitam recursos como estrelas, preço e disponibilidade nos resultados. Eles não garantem a exibição.
Posso marcar avaliações que vêm de outros sites?
Não. A documentação proíbe agregar avaliações ou notas de outros sites. Marque apenas avaliações coletadas na sua loja e visíveis na página.
Cada cor e tamanho deve ter uma URL própria?
Depende do catálogo. A documentação aceita variantes com URL própria, desde que abram pré-selecionadas e tenham sku ou gtin único, e descreve também o uso de uma URL única com seletores. Defina o canonical conforme a demanda de busca de cada variante.
Descrição do fabricante é um problema?
A documentação não cita o caso, mas as diretrizes de conteúdo útil pedem conteúdo original, com valor próprio. Um texto igual ao de outras lojas dificulta a diferenciação. Complemente com uso, medidas e dúvidas dos seus clientes.
Como saber se meu markup está correto?
Use o Teste de Resultados Enriquecidos do Google e o Schema Markup Validator, e acompanhe os relatórios do Search Console. Os testes cobrem a maioria dos erros técnicos, mas não todas as diretrizes de qualidade.
