Schema para comércio

TL;DR — “Schema para comércio” é meu atalho para os tipos do schema.org usados para marcar coisas que as pessoas podem pesquisar e sobre as quais podem agir — produtos para comprar e vagas às quais se candidatar. São três: Product (um item à venda), ProductGroup (grupo de variantes, como uma camisa em vários tamanhos e cores) e JobPosting (uma vaga aberta). Adicione o tipo correto e sua página fica elegível a uma listagem mais sofisticada — resultados de produto no estilo Shopping ou um cartão do Google for Jobs. Isso não melhora o ranqueamento, não garante que o resultado apareça ou receba mais cliques e tampouco faz sua página ser citada por IA. Este hub direciona você ao tipo correto; as tabelas completas de propriedades ficam no artigo de cada tipo.

O que significa “schema para comércio”

“Schema para comércio” é um agrupamento prático, não um único tipo do Schema.org nem um recurso do Google. Evidência desta afirmação Commerce schema is an editorial grouping rather than a single Schema.org type or Google feature. Escopo: This article's taxonomy; Schema.org and Google document individual types and search experiences. Confiança: alta · Verificado: 2026-07-14 Schema.org: Product O Google documenta requisitos e elegibilidades distintos para marcações de produto, listagem de comerciante e organização. Evidência desta afirmação Google documents distinct structured-data requirements for product snippets and merchant listings, and valid markup does not guarantee display. Escopo: Google Product structured data and merchant-listing experiences. Confiança: alta · Verificado: 2026-07-14 Google: Product structured data

Ao olhar uma página que vende uma jaqueta, você distingue o preço, as opções de cor e o rótulo “em estoque” apenas lendo. Um mecanismo vê texto simples e precisa inferir. Marcação schema é o código que você adiciona para explicitar — “este é o preço”, “esta é a disponibilidade”, “este é o cargo” — usando o vocabulário compartilhado do schema.org.

“Schema para comércio” não é termo oficial. É apenas meu guarda-chuva para tipos do schema.org que descrevem listagens comerciais ou transacionais — itens individuais que alguém pode pesquisar, filtrar e usar:

• Product — um item à venda.
• ProductGroup — um pai que conecta variantes do mesmo item (tamanhos, cores), para que os mecanismos saibam que são opções do mesmo produto, não produtos distintos.
• JobPosting — uma vaga aberta em uma página de carreiras.

Agrupo os três porque cumprem a mesma função em SEO: você os adiciona para que o Google possa transformar a listagem em um resultado especializado. Mas atenção: Google e schema.org não os classificam juntos. Retomo essa transparência na aba Avançado, pois ela importa.

Daí a função deste hub: ele é um roteador, não um guia de implementação. Identifique abaixo qual dos três tipos corresponde à sua página e leia a análise desse tipo (e, quando houver avaliações, devoluções ou frete, os registros adjacentes Review/MerchantReturnPolicy/OfferShippingDetails) para consultar as tabelas de propriedades.

Por que vale a pena: resultados avançados

O benefício são os resultados avançados — listagens aprimoradas que se destacam na busca:

• 🛍️ um produto com preço, rótulo “em estoque” e estrelas de avaliações
• 👕 um produto que exibe opções de tamanho e cor
• 💼 uma vaga no quadro de Empregos do Google, com empresa, local e salário

Adicione o schema correspondente com todos os detalhes obrigatórios e sua página fica elegível a esse tratamento. Elegível, nunca garantida — o Google ainda decide se vai exibi-lo.

O que a maioria entende errado

Adicionar schema para comércio não melhora seu ranqueamento. O Google já disse isso de forma clara e repetida. O schema torna você elegível a uma listagem mais rica e ajuda os mecanismos a entender a página. Isso é diferente de ranquear melhor — e elegibilidade também não é garantia: marcação válida não promete que o resultado avançado aparecerá, que haverá mais cliques ou que a página será citada em uma resposta de IA. Trate cada um como resultado separado.

Outra armadilha para iniciantes: esses tipos não são intercambiáveis. Use Product para um item, ProductGroup quando ele tem variantes e JobPosting para uma vaga — nunca para uma página que lista várias vagas. Essa última regra é mais rígida do que muitos esperam.

Quer a versão completa — onde eles ficam na hierarquia do schema.org, como se conectam ao Merchant Center e Google for Jobs e qual artigo ler depois? Mude para a aba Avançado.

TL;DR — “Schema para comércio” é um agrupamento meu, de profissional, não uma categoria do Google ou schema.org, para tipos de listagem que geram resultados transacionais: Product, ProductGroup e JobPosting. O Google os separa — Product/Variantes ficam em “Shopping”, enquanto anúncios de vagas aparecem na lista geral de guias de recursos. O schema.org tampouco os unifica: Product → ProductGroup é uma relação real de pai/filho (Thing > Product > ProductGroup), enquanto JobPosting fica no ramo Intangible (Thing > Intangible > JobPosting), sem relação com Product. O único elo é o uso em SEO — listagens estruturadas que o Google transforma em tratamento especializado na SERP (listagens de comerciantes, Google for Jobs). Nada é fator de ranqueamento; compra elegibilidade — não exibição, aumento de CTR ou citação de IA garantidos, que são três resultados separados e incertos. A elegibilidade de Review/AggregateRating segue perfil próprio, e dados de devolução/frete dividem-se entre política no nível de Organization e exceções no nível de Offer — mais dois contratos aos quais este hub apenas direciona. O risco do ciclo de vida também varia: Product desatualizado costuma perder elegibilidade, mas JobPosting vencido e não removido pode gerar ação manual.

Primeiro, um enquadramento honesto: este agrupamento é meu, não do Google

Este artigo combina vários vocabulários e recursos de busca relacionados por conveniência. Evidência desta afirmação Commerce schema is an editorial grouping rather than a single Schema.org type or Google feature. Escopo: This article's taxonomy; Schema.org and Google document individual types and search experiences. Confiança: alta · Verificado: 2026-07-14 Schema.org: Product Cada experiência do Google tem suas propriedades obrigatórias e recomendadas, e marcação válida não garante exibição. Evidência desta afirmação Google documents distinct structured-data requirements for product snippets and merchant listings, and valid markup does not guarantee display. Escopo: Google Product structured data and merchant-listing experiences. Confiança: alta · Verificado: 2026-07-14 Google: Product structured data

Quero ser transparente desde o início, porque a maioria dos conteúdos sobre schema de “comércio” ou “e-commerce” sugere silenciosamente que esses tipos formam uma família oficial. Não formam.

• A própria documentação do Google os separa. Na galeria de dados estruturados, “Job posting” fica na lista geral e plana de guias de recursos — ao lado de tipos sem relação, como Article, Local business e Organization. Já “Product snippet”, “Merchant listing” e “Variants” ficam sob o subtítulo Shopping. Duas famílias de documentação diferentes.
• O schema.org não os unifica. Sua hierarquia de tipos tem um grupo específico “Product, Offer, and AggregateOffer” — e JobPosting não aparece ao lado dele em nenhum agrupamento de nível superior.

Então por que colocá-los no mesmo artigo? Porque, na prática — na forma de trabalhar de um profissional de SEO —, representam o mesmo tipo de problema: conteúdo estruturado em formato de listagem, marcado para liberar uma experiência especializada na busca. Esse uso compartilhado é real e útil. A taxonomia compartilhada não é. Prefiro dizer isso claramente a fingir que o Google desenhou essa caixa.

Os três tipos em resumo

• Product (schema.org/Product) — um item vendável. O Google transforma marcação Product válida em duas experiências: snippets de produto (estrelas e preço em páginas sem compra) e listagens de comerciantes (resultados mais completos no estilo Shopping em páginas de compra). Mínimo para resultado avançado: name mais pelo menos um entre offers, review ou aggregateRating — mas a rota review/aggregateRating segue as regras separadas de snippet de avaliação do Google (perfil próprio, incluindo restrição a avaliações autocontroladas), não a regra genérica “qualquer página de produto mostra estrelas”. Nem toda página Product ou de comerciante se qualifica automaticamente; consulte a análise de Review.
• ProductGroup (schema.org/ProductGroup) — pai que agrupa as variantes de um item conceitual (camiseta em tamanhos e cores) para o Google entender que são opções do mesmo produto. Conecta variantes com hasVariant, variesBy e productGroupID. Não substitui Product: cada variante continua sendo Product completo; ProductGroup fica acima.
• JobPosting (schema.org/JobPosting) — uma vaga aberta, marcada para elegibilidade à experiência Empregos do Google. As propriedades básicas obrigatórias são title, description, datePosted, hiringOrganization e jobLocation (ou applicantLocationRequirements para vagas totalmente remotas).

Mantenho este hub deliberadamente superficial nas tabelas de propriedades de cada tipo — as análises completas estão nos três artigos filhos indicados no final.

Onde ficam na hierarquia do schema.org

Esta é a parte que quase ninguém cita corretamente, e a diferença entre palpite e fato:

• Product — Thing > Product.
• ProductGroup — Thing > Product > ProductGroup. É um subtipo verdadeiro de Product, herda todas as propriedades de Product e adiciona hasVariant, productGroupID e variesBy. Portanto, “Product vs. ProductGroup” não é uma escolha excludente — ProductGroup é um Product especializado, criado para variantes.
• JobPosting — Thing > Intangible > JobPosting. Um ramo totalmente separado. Sua definição não referencia Product, Offer nem qualquer tipo de comércio.

Conclusão: Product e ProductGroup têm relação taxonômica (pai/filho, verificável e citável); JobPosting não. O elo entre os três é o uso em SEO, não a herança de tipos. Diga isso e estará em terreno sólido.

Product vs. ProductGroup: quando usar cada um

Regra simples:

• Uma configuração comprável → Product simples. Um SKU, um preço, uma página na qual se compra.
• Um item conceitual, várias variantes compráveis → ProductGroup envolvendo seus membros Product. É a camisa em cinco cores. ProductGroup não é vendido diretamente — seus membros hasVariant são, cada qual com sku/gtin, preço e disponibilidade próprios.

O Google também documenta ProductGroup de outra forma: ele fica na página Variants, não como guia de recurso independente — reforçando que o Google o trata como extensão de Product, não como tipo de resultado avançado totalmente separado. As tabelas completas, a armadilha da URL completa em variesBy e a conciliação com item_group_id do Merchant Center pertencem à análise de ProductGroup, não aqui.

JobPosting: o elemento diferente

JobPosting não compartilha taxonomia com Product — mas tem o mesmo formato de problema, por isso merece lugar neste hub. Duas coisas o diferenciam operacionalmente:

1. Uma vaga por página, sempre. Regra do Google: “The JobPosting markup must only be used on pages that contain a single job posting.” (Tradução) “A marcação JobPosting só deve ser usada em páginas que contenham uma única vaga.” Nunca em página de listagem ou resultados de busca. Product/ProductGroup não tem restrição equivalente — ProductGroup existe justamente para várias variantes em uma página.
2. Vagas encerradas exigem conformidade, não abandono. Veja o risco abaixo — é onde as consequências mais se distanciam de Product.

Regras básicas compartilhadas pelos três

Embora não compartilhem taxonomia, os tipos seguem as diretrizes gerais de dados estruturados do Google, e vale declarar as regras uma vez:

• Propriedades obrigatórias são o portão da elegibilidade. Se faltar uma, a página não se qualifica ao resultado. Propriedades recomendadas elevam a qualidade — o próprio Google usa salário de vaga como exemplo: usuários preferem anúncios com salário informado. A lógica “quanto mais completo, melhor” também se aplica a Product.
• Elegibilidade ≠ exibição garantida. Marcação válida coloca você no conjunto; os sistemas do Google ainda decidem separadamente se exibem o aprimoramento.
• Marque apenas conteúdo visível e correto. Nada invisível, avaliações falsas ou dados enganosos — políticas de spam e qualidade valem para os três, além das específicas de cada recurso.
• JSON-LD é o formato recomendado para todos — mais fácil de manter em escala que Microdata/RDFa inline.

Onde cada tipo se conecta além da marcação na página

O verdadeiro valor unificador não é a taxonomia — é que o Google trata conteúdo em formato de listagem como uma linha de produto própria:

• Product / ProductGroup ↔ Google Merchant Center. Você pode fornecer dados como marcação na página, feed do Merchant Center ou ambos. O Google recomenda ambos para maximizar elegibilidade e os concilia — sistemas separados, validados separadamente. Passar no teste de resultados avançados não valida o feed, e vice-versa. Preço e disponibilidade precisam coincidir na marcação, feed e checkout.
• JobPosting ↔ Empregos do Google. Marcação válida torna uma página de vaga única elegível à experiência de Empregos — vertical distinta de Shopping.
• Devoluções e frete se dividem do mesmo modo, em granularidade menor. MerchantReturnPolicy costuma ficar no nível de Organization — janela e condições padrão. OfferShippingDetails atua no nível de Offer para substituir o padrão em um item. São dois registros que podem ficar desatualizados separadamente; ambos precisam de manutenção.
• Dados estruturados na página, feed do Merchant Center e o que recursos da Busca ou respostas de IA exibem são três contratos separados, não um pipeline — marcação válida gera elegibilidade no primeiro, não preenche automaticamente o segundo nem garante o terceiro.

Vale explicitar a assimetria do Bing: ele valida genericamente os três tipos conforme o schema.org, mas não publica tabelas próprias de propriedades ou políticas para nenhum deles, nem oferece equivalente a listagens de comerciantes ou Google for Jobs. Sobre ProductGroup, Fabrice Canel, do Bing, disse em setembro de 2024 que ele ainda não era consumido em legendas de Shopping, embora estivesse “no radar”. Mesmo vocabulário-base, mas apenas o Google construiu experiências documentadas específicas sobre ele.

Diferenças de risco e ciclo de vida

Este é o contraste que mais quero que as pessoas internalizem, porque quase ninguém o enquadra assim: listagens desatualizadas exigem higiene de ciclo de vida nos três tipos — mas os riscos são muito diferentes.

• Um Product desatualizado ou sem estoque geralmente só perde elegibilidade ou mostra “esgotado”/“sem estoque”. Incômodo, não catastrófico.
• Um JobPosting desatualizado e não removido é outra categoria de risco. Google: “We don’t allow expired job postings,” (Tradução) “Não permitimos vagas vencidas”, e deixar de expirar/remover vagas encerradas “may result in a manual action.” (Tradução) “pode resultar em ação manual”. As três formas aceitas: definir validThrough no passado, retornar 404/410 ou remover a marcação.

A lição é a mesma — listagens estruturadas precisam de processo de ciclo de vida —, mas, se você só puder criar um pipeline de limpeza, faça-o para vagas.

Schema para comércio ajuda no SEO?

Não no ranqueamento. John Mueller foi direto: “Structured data won’t make your site rank better.” (Tradução) “Dados estruturados não farão seu site ranquear melhor.” Eles geram elegibilidade a resultados avançados e experiências especializadas e, separadamente, ajudam o Google a entender as páginas. Confundir “adicionei schema” com “vou ranquear melhor” é o mito mais comum nos três tipos.

E não se trata apenas de ranqueamento. Elegibilidade, resultado avançado efetivamente exibido, aumento de CTR e receita são quatro alegações separadas — não as reduza a uma. Marcação válida não garante exibição em Shopping ou Empregos, mais cliques nem — como nenhum tipo deste hub é sinal documentado de visibilidade por IA — aparição/citação em AI Overviews ou AI Mode. Meça cada resultado isoladamente; implemente schema pelo recurso de busca que pode conquistar, não como substituto dos demais.

Minha visão acompanha a de Mueller: saiba para que o schema realmente serve antes de gastar tempo de desenvolvimento. Ele veio para ficar — Mueller também disse que o Google não está eliminando schema —, mas você o implementa para conquistar um recurso de busca, não para subir nos resultados, garantir cliques ou mover uma resposta de IA.

Para onde seguir

Este hub é o mapa; cada item abaixo é uma análise própria aninhada nele:

• Schema Product — as duas experiências do Google, propriedades obrigatórias/recomendadas, enum de availability e confusão entre feed e marcação. Comece aqui se a página vende um item.
• Schema ProductGroup — agrupamento com hasVariant/variesBy/productGroupID, padrões de uma ou várias páginas, armadilha da URL completa do schema.org e conciliação com item_group_id. Comece se há tamanhos/cores/materiais.
• Schema JobPosting — propriedades, trabalho remoto/híbrido, regra de uma vaga por página, expiração e mudanças de acesso à Indexing API em 2024–2025. Comece para carreiras ou portal de vagas.
• Schema MerchantReturnPolicy — tipo aninhado para política de devolução, precedência entre marcação e Merchant Center e confusão applicableCountry vs. returnPolicyCountry.
• Schema OfferShippingDetails — propriedade complementar para tarifa/destino/prazo de frete e quando o Google a exige para listagens gratuitas.
• Schema Review — perfil separado de elegibilidade por trás de review/aggregateRating: avaliação única vs. agregada, restrição a avaliações autocontroladas e por que nem todo produto mostra estrelas.

Na visão mais ampla, este hub fica no subcluster de dados estruturados — veja também o artigo irmão sobre marcação schema para vocabulário, formatos e ciclo de descontinuação. Tudo fica no cluster on-page, onde dados estruturados convivem com o restante do SEO técnico on-page.

Resumo por IA

Uma versão condensada da seção Avançado:

• O que é: “Schema para comércio” é o agrupamento prático de Patrick — não uma categoria do Google ou schema.org — para tipos de listagem que geram resultados transacionais: Product, ProductGroup, JobPosting.
• Não é família oficial: a galeria do Google põe Product/Merchant listing/Variants em Shopping e Job posting nos guias de recursos gerais. O schema.org agrupa Product, Offer e AggregateOffer, mas não JobPosting.
• Hierarquia: Product = Thing > Product; ProductGroup = Thing > Product > ProductGroup (subtipo real para variantes); JobPosting = Thing > Intangible > JobPosting (ramo sem relação).
• Quando usar: uma configuração comprável → Product; item com variantes → ProductGroup envolvendo Products; uma vaga → JobPosting (uma por página).
• Resultados avançados: Product → snippets e listagens de comerciantes; ProductGroup → listagens cientes das variantes; JobPosting → Google for Jobs.
• Regras compartilhadas: propriedades obrigatórias = elegibilidade; elegibilidade ≠ exibição; marque conteúdo visível/correto; JSON-LD recomendado.
• Além da marcação: Product/ProductGroup ↔ Google Merchant Center (sistemas separados conciliados; preço/disponibilidade devem coincidir). JobPosting ↔ Google for Jobs. MerchantReturnPolicy costuma ser de Organization; OfferShippingDetails substitui por Offer.
• Estrelas têm perfil separado: review/aggregateRating segue regras próprias de snippet de avaliação, não “qualquer produto se qualifica”.
• Bing: valida genericamente, sem especificações próprias ou equivalentes; segundo Fabrice Canel (set. 2024), ainda não usava ProductGroup em legendas de Shopping.
• Risco: Product desatualizado costuma perder elegibilidade; JobPosting pode causar ação manual — expire com validThrough passado, 404/410 ou remoção.
• Impacto em SEO: não é fator de ranqueamento (Mueller: “Structured data won’t make your site rank better” (Tradução) “Dados estruturados não farão seu site ranquear melhor”) — gera elegibilidade e compreensão, não garante exibição, CTR ou citação por IA.
• Este hub direciona, não implementa: tabelas completas ficam nas análises de Product, ProductGroup, JobPosting, Review, MerchantReturnPolicy e OfferShippingDetails.

Documentação oficial

Documentação de fontes primárias para os três tipos de schema para comércio e as regras que compartilham.

Google — regras compartilhadas

• Diretrizes gerais de dados estruturados — princípio da elegibilidade e políticas de qualidade/spam aplicáveis aos três tipos.
• Galeria de dados estruturados — fonte da verdade sobre o que gera resultados avançados e onde se vê a divisão “Shopping” vs. “Guias de recursos”.

Google — Product e ProductGroup (“Shopping”)

• Introdução aos dados estruturados de Product — divisão entre snippet e listagem de comerciante e relação marcação vs. feed.
• Dados estruturados de snippet de produto — propriedades da experiência mais leve.
• Dados estruturados de listagem de comerciante — requisitos mais rígidos para “compre aqui”.
• Dados estruturados de variante de produto (ProductGroup) — ProductGroup documentado como extensão de Product.
• Merchant Center — especificação de dados de produto — especificação do feed conciliado com a marcação.

Google — JobPosting (“Guias de recursos”)

• Dados estruturados de anúncio de vaga — propriedades, regra de uma vaga por página, políticas e expiração.

Schema.org (taxonomia)

• schema.org/Product · schema.org/ProductGroup · schema.org/JobPosting · visão geral da hierarquia de tipos

Bing / Microsoft

• Bing Webmaster Tools — marcando seu site com dados estruturados — suporte genérico ao schema.org; sem especificação de elegibilidade por tipo.

Citações das fontes

Declarações registradas. Quando a página expõe o texto, o link leva diretamente ao trecho citado.

Documentação do Google — princípio compartilhado de elegibilidade

• “Specify all required properties listed in the documentation for your specific rich result type. Items that are missing required properties are not eligible for rich results. The more recommended properties that you provide, the higher quality the result is to users. For example: users prefer job postings with explicitly stated salaries than those without…” (Tradução) “Informe todas as propriedades obrigatórias do seu tipo de resultado avançado. Itens sem elas não são elegíveis. Quanto mais propriedades recomendadas, maior a qualidade; por exemplo, usuários preferem vagas com salários explícitos.” Ir para a citação
• “Content in structured data must also follow the additional content guidelines or policies, as documented in the specific feature guide. For example, content in JobPosting structured data must follow the job posting content policies.” (Tradução) “O conteúdo em dados estruturados também deve seguir as diretrizes ou políticas adicionais do guia específico; por exemplo, JobPosting deve seguir as políticas de anúncios de vagas.” Ir para a citação

Documentação do Google — Product e a relação com Merchant Center

• “Two markup types exist: Product snippets for non-purchase pages, emphasizing reviews, and Merchant listings for purchase pages, highlighting product details like sizing and shipping.” (Tradução) “Existem dois tipos de marcação: snippets de Product para páginas sem compra, com destaque para avaliações, e listagens de comerciantes para páginas de compra, com detalhes como tamanho e frete.” Ir para a citação
• “To provide rich product data to Google Search you can add Product structured data to your web pages, upload data feeds with Google Merchant Center and opt into free listings within the Merchant Center console, or both.” (Tradução) “Para fornecer dados ricos de produto à Pesquisa Google, adicione dados Product às páginas, envie feeds ao Merchant Center e participe das listagens gratuitas, ou faça ambos.” Ir para a citação

Documentação do Google — regras específicas de JobPosting

• “The JobPosting markup must only be used on pages that contain a single job posting. We don’t allow the use of JobPosting markup in any other page, including pages that do not list any job.” (Tradução) “A marcação JobPosting só deve ser usada em páginas com uma única vaga. Não permitimos seu uso em nenhuma outra página, incluindo páginas sem vagas.” Ir para a citação
• “We don’t allow expired job postings. Ideally you should remove expired job postings from your website. If you prefer to not remove them, then you need to ensure the validThrough property is populated and in the past.” (Tradução) “Não permitimos vagas vencidas. O ideal é removê-las; se preferir não remover, a propriedade validThrough deve estar preenchida e no passado.” Ir para a citação
• “Jobs that are no longer open for applications must be expired in one of the following ways. Failure to take timely action on expired jobs may result in a manual action.” (Tradução) “Vagas que não aceitam mais candidaturas devem ser expiradas de uma das formas indicadas. Não agir a tempo pode resultar em ação manual.” Ir para a citação

John Mueller, Google — schema não é fator de ranqueamento

• “Structured data won’t make your site rank better.” (Tradução) “Dados estruturados não farão seu site ranquear melhor.” E: “It’s fine to use it for other things in schema.org, that won’t cause problems, but you’re unlikely to see any visible change from it in Google Search.” (Tradução) “Tudo bem usá-los para outras coisas do schema.org; não causará problemas, mas é improvável que produza mudança visível na Pesquisa Google.” Cobertura Transmitido pela cobertura do Search Engine Roundtable das publicações de Mueller no Bluesky em abril de 2025; trate a redação como transcrição secundária.
• “In order to be eligible to be shown as a rich result, you need to make sure that the page uses the right structured data and that it complies with the appropriate policies on our side.” (Tradução) “Para ser elegível à exibição como resultado avançado, a página precisa usar os dados estruturados corretos e cumprir nossas políticas.” Cobertura Transmitido pela cobertura do Search Engine Land de uma resposta #AskGoogleWebmasters de 2019.
• “Exactly. Understand that markup types come and go, but a precious few you should hold on to (like title, and meta robots).” (Tradução) “Exatamente. Entenda que tipos de marcação vêm e vão, mas há alguns preciosos que você deve manter (como title e meta robots).” Cobertura Transmitido pela cobertura do Search Engine Roundtable de uma resposta no Reddit em novembro de 2025.

Fabrice Canel, Microsoft Bing — sobre ProductGroup

• “ProductGroup markup isn’t used in our captions yet, but it’s on our radar. Our team is closely monitoring its adoption. Stay tuned!” (Tradução) “A marcação ProductGroup ainda não é usada em nossas legendas, mas está no radar. Nossa equipe acompanha de perto sua adoção. Fique atento!” Cobertura Transmitido pela cobertura do Search Engine Roundtable de uma declaração no X em setembro de 2024; informação datada — confira o suporte atual antes de depender dela.

Schema para comércio em resumo

Comparação dos três tipos

Fatos rápidos

• “Schema para comércio” é um agrupamento prático, não categoria do Google ou schema.org — os tipos compartilham uso em SEO, não taxonomia.
• Product e ProductGroup são pai/filho; JobPosting é um ramo sem relação.
• Elegibilidade ≠ exibição — marcação válida inclui você no conjunto; o Google ainda decide.
• Não é fator de ranqueamento nem garantia de CTR, exibição ou citação por IA. Schema gera elegibilidade e ajuda na compreensão; os demais resultados são separados.
• Elegibilidade de Review/AggregateRating tem perfil próprio. Nem toda página de produto se qualifica a estrelas.
• Devoluções e frete também se dividem. MerchantReturnPolicy costuma ser no nível de Organization; OfferShippingDetails substitui por Offer. Dois registros, duas manutenções.
• JSON-LD é o formato recomendado pelo Google para os três.
• Feed do Merchant Center e marcação Product na página são sistemas separados que o Google concilia — forneça ambos e mantenha preço/disponibilidade consistentes.
• Higiene de vagas tem o maior risco: expire vagas encerradas (validThrough passado, 404/410 ou remoção da marcação) ou arrisque ação manual.

De qual tipo de schema para comércio eu preciso?

Responda pensando na página que você está marcando e chegará ao tipo correto (e à análise certa para ler em seguida).

Erros que realmente vejo em schema para comércio

Estes são erros concretos cometidos com marcações Product, ProductGroup e JobPosting — não hipóteses. Cada um tem solução.

Colocar marcação JobPosting em uma página que lista várias vagas

A regra do Google é explícita: JobPosting “must only be used on pages that contain a single job posting,” (Tradução) “só deve ser usada em páginas que contenham uma única vaga”, e é proibida em qualquer outra página, inclusive sem vaga. Adicioná-la a um índice de carreiras ou resultados não rende várias listagens — torna a marcação não conforme e inelegível.

Faça isto: dê a cada vaga aberta sua própria URL e marque apenas essa página. Use a página de índice/listagem para navegação, não schema JobPosting.

Deixar uma vaga encerrada publicada sem expirá-la

Product desatualizado geralmente só perde elegibilidade ou mostra “sem estoque” — incômodo leve. JobPosting desatualizado pertence a outra classe: o Google não permite vagas vencidas, e não expirar/remover uma vaga encerrada “may result in a manual action.” (Tradução) “pode resultar em ação manual”. É penalidade no site, não apenas perda de snippet.

Faça isto: assim que a vaga encerrar, adote uma das três opções aceitas — defina validThrough no passado, retorne 404/410 ou remova a marcação JobPosting. Incorpore isso à desativação no sistema de recrutamento, não deixe como tarefa manual posterior.

Tratar ProductGroup como substituto da marcação de cada variante

ProductGroup é o pai que conecta variantes com hasVariant, variesBy e productGroupID — mas não substitui Product. Cada variante (combinação de tamanho, cor ou material) ainda precisa de marcação Product completa, com sku/gtin, preço e disponibilidade próprios. Publicar só ProductGroup deixa variantes sem os dados de que o Google precisa.

Faça isto: marque cada variante comprável como Product próprio e envolva o conjunto em um ProductGroup que as referencie.

Esperar que schema para comércio melhore o ranqueamento

É o mito mais comum nos três tipos, e o Google já foi claro repetidas vezes — John Mueller: “Structured data won’t make your site rank better.” (Tradução) “Dados estruturados não farão seu site ranquear melhor.” Tratar a implantação como iniciativa de ranqueamento cria expectativa errada e pode desviar esforço para marcação que nunca moveria posições.

Faça isto: implemente schema para conquistar elegibilidade a um recurso específico (listagem de comerciante, cartão de Empregos) — meta legítima, com valor próprio em cliques e apresentação — e meça por isso, não pela posição.

Deixar marcação na página, feed do Merchant Center e checkout perderem sincronia

Dados de produto podem vir da página, feed ou ambos, e o Google os concilia como sistemas separados, não cópias. Passar no teste de resultados avançados não valida o feed, e vice-versa — se preço ou disponibilidade divergir entre marcação, feed e checkout, a inconsistência prejudica elegibilidade e confiança.

Faça isto: mantenha preço e disponibilidade idênticos nas três superfícies e valide marcação e feed separadamente, sem presumir que um cobre o outro.

Ferramentas para criar e verificar schema para comércio

Meu Validador de marcação schema é a primeira parada após escrever JSON-LD para qualquer um dos três tipos. Cole um bloco Product, ProductGroup ou JobPosting (ou página completa) e ele executará verificações por gravidade contra o vocabulário schema.org e requisitos de resultados avançados do Google — útil para encontrar uma propriedade obrigatória ausente antes de publicar.

Meu Verificador de elegibilidade a resultados avançados responde à pergunta específica deste hub: não “este JSON-LD é válido?”, mas “esta página realmente se qualifica?”. Cole JSON-LD, HTML ou busque uma URL; ele mostra campos presentes e ausentes para Product (offers/review/aggregateRating) ou JobPosting (title, description, datePosted, hiringOrganization, jobLocation) — o portão exato de elegibilidade descrito aqui.

Meu Verificador de SEO para PDP foi criado especificamente para páginas de detalhes de produtos — analisa uma página ao vivo além do schema, cobrindo sinais on-page que acompanham Product/ProductGroup ao avaliar páginas de SKU único ou variantes.

Quando a marcação passar nessas verificações, execute a página no Teste de resultados avançados do Google — é a ferramenta usada pelo próprio Google para determinar elegibilidade, portanto é a palavra final antes da publicação para qualquer tipo deste hub.

Teste seus conhecimentos: schema para comércio

Cinco perguntas rápidas sobre os três tipos, como se relacionam e o que fazem (e não fazem). Escolha uma resposta para cada uma e confira.

Recursos que valem seu tempo

Meus textos sobre marcação schema

• Marcação schema — minha visão ampla do vocabulário, formatos, compreensão de entidades e ciclo de descontinuação. Schema para comércio é uma parte disso.
• Guia para iniciantes em SEO técnico — onde enquadro schema como código que ajuda mecanismos a entender conteúdo e alimenta recursos que destacam listagens.
• SEO empresarial — minha regra prática, também aplicável aqui: “I’m a fan of schema markup as long as it gets you a search feature.” (Tradução) “Sou fã de marcação schema desde que ela gere um recurso de busca.”

Minhas palestras

• Como a busca funciona (SlideShare) — minha explicação de rastreamento, renderização, indexação e ranqueamento; contexto útil para dados estruturados. (Aplica-se meu aviso habitual: “This is my understanding of systems… not going to be 100% complete or accurate.” (Tradução) “Este é meu entendimento dos sistemas… não será 100% completo nem preciso.”)

De outros profissionais

• Google reafirma que dados estruturados não fazem seu site ranquear melhor (Search Engine Roundtable) — declaração de Mueller de abril de 2025, que desfaz o principal mito deste hub.
• Google não está eliminando schema — marcações podem vir e ir (Search Engine Roundtable) — enquadramento de que “tipos de marcação vêm e vão, mas alguns preciosos devem ser mantidos”.
• Bing pode usar marcação ProductGroup no futuro (Search Engine Roundtable) — declaração de Fabrice Canel em setembro de 2024 sobre a falta de suporte.
• Siga as diretrizes de dados estruturados se quiser o resultado avançado (Search Engine Land) — Mueller sobre elegibilidade exigir marcação correta e conformidade com políticas.
• Hierarquia de tipos do schema.org — o próprio vocabulário, direto da fonte; veja o grupo “Product, Offer, and AggregateOffer” e onde JobPosting está (e não está).

Registro de alterações