Dados estruturados para variações de produto: guia prático

Dados estruturados para variações de produto ajudam o Google a relacionar opções de cor, tamanho ou material ao mesmo produto principal. Para isso, a loja combina ProductGroup, que identifica o grupo, com Product, que descreve cada variante. Cada opção precisa ter identificação e informações coerentes, como URL, imagem, preço e disponibilidade.

O Google precisa reconhecer quais atributos diferenciam as opções e quais características são compartilhadas. Em uma camiseta, por exemplo, a marca e o modelo podem ser comuns, enquanto cor, tamanho, SKU, imagem e estoque mudam entre variantes.

Dados estruturados são informações organizadas em um formato padronizado para descrever o conteúdo de uma página. Eles não substituem as informações visíveis para o cliente: precisam refletir o que a página realmente mostra e oferece. Segundo a documentação do Google para variantes de produtos, a marcação de variantes pode ajudar o buscador a entender a relação entre os produtos do mesmo grupo e qualificar páginas para experiências de produto com informações de variantes.

Imagine uma loja de moda que vende uma camisa em azul e areia, nos tamanhos P, M e G. A marcação deve deixar claro que as opções pertencem ao mesmo modelo, mas não são uma única unidade indistinta. Se o tamanho M azul está sem estoque, essa condição não deve ser confundida com a disponibilidade do tamanho G areia.

ProductGroup descreve o conjunto de opções relacionadas. Product descreve cada variante comercializável. A relação entre os dois permite indicar os atributos compartilhados e os que distinguem cada opção.

Segundo o Google Search Central, as propriedades centrais para essa estrutura são variesBy, hasVariant e productGroupID. Uma implementação comum organiza os dados assim:

• ProductGroup: nome do modelo, marca e identificador do grupo, como o SKU principal.
• variesBy: os atributos que definem as opções, referenciados pelas propriedades do Schema.org, como cor e tamanho.
• hasVariant: a lista de itens Product que pertencem ao grupo.
• Product de cada variante: nome específico, cor, tamanho, imagem, identificador próprio e oferta correspondente.
• Offer: URL acessível da opção e dados comerciais, como preço, moeda e disponibilidade, quando aplicáveis.

Por exemplo, o grupo pode ser chamado “Camisa de linho”, enquanto cada Product informa “Camisa de linho azul, tamanho M” ou “Camisa de linho areia, tamanho G”. O grupo precisa de um identificador consistente. Cada variante também deve ter um identificador exclusivo, como SKU ou GTIN, conforme os dados reais do catálogo.

Não repita no nível do grupo um dado que muda por variante. Se uma cor tem uma foto específica, associe a imagem à variante correspondente. Se o preço varia por tamanho ou acabamento, informe a oferta daquela opção, não apenas um preço genérico do modelo. Os exemplos e propriedades aceitos podem ser conferidos na definição de ProductGroup do Schema.org e na documentação do Google.

Cada variante precisa poder ser identificada por uma URL distinta que a abra já selecionada. Isso não significa necessariamente criar uma página totalmente diferente para cada tamanho: a URL pode usar um caminho ou parâmetros, desde que a opção indicada seja carregada corretamente.

A documentação do Google sobre URLs de e-commerce cita estruturas como um caminho dedicado à cor ou um parâmetro de consulta. A escolha depende de como a loja funciona, mas a URL deve ser estável, rastreável e abrir a combinação solicitada.

Modelo de página	Como funciona	O que revisar
Página única	As opções são selecionadas na mesma página; a URL identifica a variante, por exemplo, com parâmetros.	O link deve pré-selecionar a opção, e a página deve exibir a imagem, preço e disponibilidade correspondentes.
Páginas separadas	Variantes, como cores diferentes, podem ser acessadas em páginas próprias.	Cada página precisa apresentar marcação completa e coerente com a variante que exibe.

Na página única, a documentação de variantes do Google orienta que o ProductGroup tenha uma URL canônica comum, geralmente a página-base sem variante pré-selecionada. Já em uma arquitetura com páginas separadas, não existe necessariamente uma única URL que represente o grupo inteiro. Não misture essas configurações: escolha uma arquitetura e alinhe URLs, marcação e canonical a ela.

Se os parâmetros forem opcionais e identificarem variantes, o Google recomenda usar a URL sem esses parâmetros como canonical para agrupar as versões relacionadas. A orientação geral sobre URLs também recomenda consistência entre links internos, sitemap e tags canonical. Veja a orientação oficial para estrutura de URLs de lojas virtuais antes de decidir como tratar páginas de variantes específicas.

O conteúdo visível e os dados estruturados precisam apontar para a mesma opção. Se alguém acessa a URL da camisa azul no tamanho M, a página deve carregar essa combinação e mostrar os dados comerciais correspondentes, sem depender de uma seleção manual posterior.

O Google especifica que a pré-seleção direta da variante deve apresentar a imagem, o preço e a disponibilidade corretos e permitir que o cliente adicione aquela opção ao carrinho. Por isso, testar apenas o seletor visual não basta: abra cada URL como se fosse uma visita nova.

Faça uma conferência por variante

• Imagem: corresponde à cor ou ao material escolhido, e não a outra opção do catálogo.
• Preço: coincide com o valor apresentado ao cliente para aquela opção.
• Disponibilidade: representa o estoque real daquela combinação, não o estoque total do produto.
• Identificador: SKU ou GTIN corresponde à variante selecionada e não é reutilizado indevidamente.
• Compra: o botão de adicionar ao carrinho leva a variante correta, não apenas o modelo genérico.

Um erro frequente aparece quando o seletor altera a foto na tela, mas a URL continua igual e a marcação mantém a imagem ou o estoque da opção padrão. Outro problema é o ERP atualizar o saldo de uma SKU sem que a página e os dados estruturados acompanhem a mudança. Para reduzir esse risco, defina qual sistema é a fonte dos dados e confira o fluxo entre catálogo, ERP e loja.

Se a marcação Product é montada por JavaScript, verifique também o HTML renderizado e o que o robô do Google consegue acessar. O Google recomenda incluir os dados de Product no HTML inicial para melhorar a confiabilidade do rastreamento de compras, especialmente para informações que mudam com frequência, como preço e disponibilidade.

Antes de publicar, confirme que o agrupamento descreve o catálogo real, que os identificadores não se contradizem e que as URLs não apresentam uma variante diferente da indicada nos dados.

• Grupo sem variantes bem identificadas: use ProductGroup para o modelo e Product para cada combinação relevante.
• variesBy incompleto: liste os atributos que realmente distinguem o grupo, como cor e tamanho.
• SKU repetido entre variantes: confira se cada opção tem identificador próprio e se o grupo tem um ID consistente.
• Preço ou estoque genérico: evite declarar que todas as opções têm o mesmo valor ou disponibilidade quando isso não é verdade.
• Imagem da variante errada: alinhe a imagem estruturada à opção que a página mostra ao carregar.
• Canonical incompatível: em página única com parâmetros, não deixe cada seleção declarar uma canonical conflitante com a URL-base do grupo.
• Informação invisível ou desatualizada: não marque dados que a página não mostra ou que já não correspondem à oferta ativa.
• URL que não restaura a opção: abra o link em uma nova sessão e confira se cor e tamanho continuam selecionados.

O canonical não deve ser decidido isoladamente por uma regra genérica de “uma página por SKU” ou “uma página para tudo”. Considere se as variantes compartilham uma página com seleção dinâmica ou se são páginas distintas. Para páginas com URLs próprias, revise também a orientação do Google sobre canonical de produtos com variantes e mantenha a estratégia coerente em links internos e sitemap.

Teste primeiro a validade da marcação e depois confira como o Google interpreta a página publicada. Uma ferramenta sem erros de sintaxe não garante que o conteúdo, a canonical ou a variante carregada estejam corretos.

1. Escolha páginas representativas: inclua um produto com opções de cor e tamanho e uma variante com preço ou estoque diferente, se houver.
2. Valide a marcação: use o Teste de pesquisa aprimorada do Google e corrija erros críticos. Avalie também os avisos que indiquem propriedades incompletas.
3. Teste as URLs de variante: acesse cada endereço diretamente e confirme seleção, imagem, preço, disponibilidade e adição ao carrinho.
4. Inspecione a URL no Search Console: use a ferramenta de inspeção para verificar acesso, renderização e dados que o Google encontrou.
5. Revise bloqueios e indexabilidade: confirme que a página não está bloqueada por robots.txt, noindex ou uma exigência de login, quando ela deve ser rastreável.
6. Monitore após publicar: acompanhe os relatórios de resultados aprimorados e atualize o sitemap quando a estrutura ou as páginas mudarem.

Esse processo segue a sequência indicada pelo Google Search Central para dados de variantes: validar a marcação, testar páginas publicadas com a inspeção de URL e permitir tempo para novo rastreamento. O Google não garante que a marcação será exibida como resultado aprimorado; ela ajuda a tornar as informações compreensíveis e elegíveis, mas a apresentação final depende do buscador.

Como próximo passo, escolha um produto com várias opções e compare, variante por variante, a URL, o seletor da loja, a SKU, o preço, o estoque e a marcação. Se o problema envolver geração automática de dados, integração com ERP ou canonical de muitas páginas, um diagnóstico técnico da loja com a WEHSOFT pelo WhatsApp pode ajudar a localizar o ponto de divergência.