Schema.org Product em 2026: o que é obrigatório, o que é recomendado, e onde declarar devoluções e entrega

A documentação da Google sobre as páginas de produto distingue duas coisas que muitos artigos misturam: as propriedades exigidas para que uma página seja elegível a um resultado enriquecido, e as propriedades que enriquecem esse resultado quando estão presentes. As informações de devolução e de entrega pertencem à segunda categoria. A Search Central arruma-as explicitamente entre os enriquecimentos de resultado, com as classificações, a disponibilidade e as descidas de preço.

Este artigo retoma a marcação Product tal como está documentada, secção a secção: o que é obrigatório, o que não é, e onde colocar cada bloco no PrestaShop 8/9 e no WooCommerce.

A base obrigatória cabe em cinco propriedades

Em Product:

• name
• image, um ou vários URL rastreáveis e indexáveis
• offers

Em Offer:

• price, ou priceSpecification.price
• priceCurrency, ou priceSpecification.priceCurrency

Acrescentam-se três restrições. As experiências Merchant listing exigem um Offer e não um AggregateOffer, já que é você quem vende. O preço tem de ser estritamente superior a zero. E a página tem de tratar de um produto único ou das suas variantes, não de uma lista ou de uma categoria.

A Google distingue, além disso, duas famílias de marcação. O product snippet visa as páginas em que não se pode comprar diretamente, tipicamente um teste editorial, com opções suplementares do lado das avaliações. O merchant listing visa as páginas em que o visitante compra na sua loja, com os tamanhos, a entrega e as devoluções. Preencher as propriedades exigidas do merchant listing torna em geral a página elegível também ao product snippet.

Tudo o resto é recomendado

A tabela das propriedades recomendadas de Offer contém availability, itemCondition, url, priceValidUntil, validFrom, validThrough, hasMerchantReturnPolicy e shippingDetails. Do lado de Product: brand.name, sku, mpn, os gtin, description, category, color, size, material, pattern, audience, hasCertification, review, aggregateRating, inProductGroupWithID, isVariantOf e subjectOf.

Estas propriedades servem para desbloquear exibições: nota média, custo de entrega e entrega gratuita, disponibilidade, informações de devolução, descida de preço. A Google precisa que estes enriquecimentos são mostrados à discrição de cada experiência e podem evoluir, e aconselha portanto a fornecer o máximo de informação de produto possível sem procurar visar uma exibição precisa.

O ponto decisivo: o procedimento de passagem a produção pede para corrigir os erros críticos devolvidos pelo Rich Results Test, e acrescenta que os problemas não críticos podem melhorar a qualidade da marcação, mas que corrigi-los não é necessário para ser elegível aos resultados enriquecidos. Ora, «Missing field hasMerchantReturnPolicy» e «Missing field shippingDetails» surgem precisamente como não críticos na Search Console.

Devoluções e entrega: o nível certo é Organization

Para uma política de devolução que cobre todo ou quase todo o catálogo, a Google pede que seja declarada uma única vez, na página que descreve essa política, num MerchantReturnPolicy aninhado em Organization (ou OnlineStore) através de hasMerchantReturnPolicy. É inútil repeti-la em cada página do site.

A esse nível, duas opções de marcação mínima:

• Opção A: applicableCountry e returnPolicyCategory. Se a categoria for MerchantReturnFiniteReturnWindow, então merchantReturnDays passa a ser obrigatório.
• Opção B: merchantReturnLink, o URL da página que descreve a política aos clientes.

O resto é recomendado e permite ser preciso: returnFees, returnMethod, returnShippingFeesAmount, returnPolicyCountry, refundType, restockingFee, returnLabelSource, itemCondition, as variantes customerRemorse* e itemDefect*, e returnPolicySeasonalOverride para restringir a janela durante as festas. Lembre-se de que a janela declarada nunca pode ficar abaixo dos 14 dias de livre resolução do Decreto-Lei n.º 24/2014.

{
  "@context": "https://schema.org",
  "@type": "OnlineStore",
  "name": "A minha loja",
  "url": "https://example.com",
  "hasMerchantReturnPolicy": {
    "@type": "MerchantReturnPolicy",
    "@id": "https://example.com/devolucoes#policy",
    "applicableCountry": ["PT", "ES"],
    "returnPolicyCountry": "PT",
    "returnPolicyCategory": "https://schema.org/MerchantReturnFiniteReturnWindow",
    "merchantReturnDays": 30,
    "returnMethod": "https://schema.org/ReturnByMail",
    "returnFees": "https://schema.org/FreeReturn",
    "refundType": "https://schema.org/FullRefund"
  }
}

O nível Offer só serve em dois casos: derrogar a política normal para um produto preciso, ou não ter qualquer política normal. As propriedades suportadas aí são um subconjunto das disponíveis ao nível da loja. Para referenciar sem ambiguidade a política global a partir de uma página, basta um @id:

"hasMerchantReturnPolicy": { "@id": "https://example.com/devolucoes#policy" }

A entrega segue a mesma lógica. A política normal declara-se em Organization, com um conjunto de propriedades mais largo do que o disponível ao nível do produto, e uma página pode remeter para ela através de hasShippingService:

"shippingDetails": {
  "@type": "OfferShippingDetails",
  "hasShippingService": { "@id": "https://example.com/entregas#policy" }
}

Ao nível de Offer, se descrever a entrega diretamente, quatro propriedades são exigidas para o enriquecimento: deliveryTime (com handlingTime e transitTime), shippingDestination (com addressCountry em ISO 3166-1 alpha-2), shippingRate.currency e shippingRate.value ou shippingRate.maxValue. Uma tarifa por bloco OfferShippingDetails: para várias tarifas, vários blocos, e é assim que se declara com limpeza uma tarifa diferente para os Açores e a Madeira.

A marcação chega em último na ordem de prioridade

A Google documenta uma ordem de precedência para as informações de devolução, da fonte mais forte à mais fraca:

1. Content API for Shopping, definições de devolução
2. Definições no Merchant Center ou na Search Console
3. Marcação ao nível da página de produto
4. Marcação ao nível de Organization

Duas consequências práticas. Se as devoluções já estão configuradas na Search Console ou no Merchant Center, é essa configuração que será usada e a marcação torna-se redundante. E a ausência de marcação numa página não se traduz em «sem política de devolução»: a Google desce simplesmente na cadeia para encontrar a informação. Num catálogo em que os portes mudam com frequência, a documentação sugere aliás passar pelo Merchant Center em vez da marcação.

priceValidUntil não é uma data a renovar todos os anos

Definição oficial: a data e a hora depois das quais o preço deixará de estar disponível, em formato ISO 8601. A documentação acrescenta uma única advertência, e não é a que se lê em todo o lado: a página pode não aparecer se priceValidUntil indicar uma data passada. O risco vem de uma data caducada, não de uma propriedade ausente.

Desde a refundição da secção dedicada à duração das promoções, o papel desta propriedade é preciso: delimitar um desconto. O início declara-se com validFrom, o fim com validThrough ou priceValidUntil. A Google recomenda fornecer as duas balizas, verificar que o início precede o fim, e incluir a hora e o fuso horário.

"offers": {
  "@type": "Offer",
  "price": 10.00,
  "priceCurrency": "EUR",
  "validFrom": "2026-11-20T08:00:00+00:00",
  "priceValidUntil": "2026-11-30T23:59:59+00:00",
  "priceSpecification": {
    "@type": "UnitPriceSpecification",
    "priceType": "https://schema.org/StrikethroughPrice",
    "price": 15.00,
    "priceCurrency": "EUR"
  }
}

Atenção à colocação. No nó Offer, priceValidUntil e validThrough são intercambiáveis. Num nó PriceSpecification, só validThrough funciona: priceValidUntil não é aplicável aí.

Se o preço não tem data de fim real, não ponha priceValidUntil. Uma data deslizante a um ano, gerada automaticamente, não descreve nada e equivale a anunciar um fim de promoção que não existe.

Preço riscado, preço de membro, preço ao litro

São reconhecidos três tipos de preço, codificados em priceSpecification sob Offer:

• Preço ativo: nem priceType nem validForMemberTier. Pode também ficar ao nível da oferta, em price.
• Preço riscado: priceType a https://schema.org/StrikethroughPrice. É ele que desencadeia a exibição promocional, passando o preço ativo a preço de saldo. Em Portugal, tem de ser o preço mais baixo dos 30 dias anteriores, como impõe o Decreto-Lei n.º 70/2007.
• Preço de membro: validForMemberTier a apontar para um MemberProgramTier definido no Merchant Center ou num MemberProgram sob Organization.

Os dois marcadores não se combinam: uma especificação de preço com priceType e validForMemberTier ao mesmo tempo é ignorada. Se preencher ao mesmo tempo offers.price e offers.priceSpecification para o preço ativo, a Google retém offers.price.

Nos produtos vendidos ao volume, ao peso ou ao comprimento, o preço unitário passa por referenceQuantity num UnitPriceSpecification. A documentação sinaliza que este formato conta particularmente na União Europeia, na Nova Zelândia e na Austrália.

Variantes: ProductGroup, duas estruturas possíveis

Só uma propriedade é exigida em ProductGroup: name. O identificador do grupo declara-se ou por productGroupID no ProductGroup (o SKU pai), ou por inProductGroupWithID em cada variante. Se preencher os dois, têm de coincidir. variesBy lista os eixos de variação, com seis valores suportados: color, size, material, pattern, suggestedAge e suggestedGender.

Estão documentadas duas estruturas. Ou as variantes estão aninhadas no ProductGroup através de hasVariant, ou são declaradas ao lado e remetem para o pai através de isVariantOf e de um @id. A Google recomenda a primeira, descrita como a representação mais compacta e mais natural. A segunda é muitas vezes mais simples de gerar a partir de um CMS.

As restrições técnicas contam tanto como a marcação. Cada variante precisa de um identificador único (sku ou gtin) e de um URL distinto que permita pré-selecioná-la, com a imagem certa, o preço certo, a disponibilidade certa e a possibilidade de a adicionar ao carrinho. Num site em que tudo se joga numa página, um único URL canónico representa o grupo. Num site com várias páginas, cada página tem de conter uma marcação completa e autónoma, com a definição do ProductGroup repetida.

Etiquetagem energética: hasCertification

Nos eletrodomésticos, lâmpadas ou ecrãs vendidos na União Europeia, a propriedade a usar é hasCertification, com um objeto Certification:

• issuedBy.name: EC ou European_Commission para as etiquetas energéticas da UE, ADEME e BMWK para as classes de CO2 dos veículos.
• name: EPREL, Vehicle_CO2_Class ou Vehicle_CO2_Class_Discharged_Battery.
• certificationIdentification: o código EPREL, exigido nas etiquetas energéticas europeias.
• certificationRating: a usar quando o código EPREL não existe (Noruega, Suíça, Reino Unido) ou para as classes de CO2. ratingValue é exigido, e para a eficiência energética bestRating e worstRating também.

Até dez certificações por produto. A antiga propriedade hasEnergyConsumptionDetails continua a ser lida, mas a documentação recomenda passar a hasCertification.

E as AI Overviews?

Nenhuma documentação pública da Google condiciona a aparição nas AI Overviews a hasMerchantReturnPolicy, shippingDetails ou outra propriedade de Product. Estas propriedades estão documentadas para as experiências Merchant listing: painel de conhecimento Shopping, Popular products, Google Imagens, Google Lens, product snippets.

Uma marcação limpa ajuda os sistemas da Google a compreender a página, o que continua a ser uma boa razão para a cuidar. Mas enquanto nenhuma documentação nem estudo reproduzível o estabelecer, mais vale não construir escolhas orçamentais sobre uma relação de causa e efeito entre estas propriedades e as respostas generativas.

Implementação no PrestaShop 8 e 9

O tema Classic produz um JSON-LD Product com offers, mas nem as políticas de devolução e de entrega, nem a estrutura ProductGroup para as variantes. Dois estaleiros distintos, a não confundir.

Do lado do catálogo. Ou sobrepõe o template que emite o JSON-LD no seu tema-filho, com a manutenção que isso implica a cada subida de versão, ou passa por um módulo. Nos dois casos, verifique que só é emitido um bloco Product por página: dois módulos SEO ativos ao mesmo tempo produzem duas marcações concorrentes.

Do lado da loja. A política de devolução e a política de entrega declaram-se uma vez, nas páginas CMS correspondentes, num bloco Organization. O mais simples continua a ser um campo de código personalizado injetado no head dessas duas páginas.

O módulo DataFirefly All in One SEO cobre o primeiro estaleiro: grafo JSON-LD com Organization, WebSite, BreadcrumbList, Product incluindo offers, priceValidUntil e o AggregateRating vindo do productcomments, mais FAQPage e LocalBusiness. Fornece também os campos de código personalizado no head e no fim do body, onde declarar as políticas ao nível da loja.

Implementação no WooCommerce

O WooCommerce emite de origem um Product com offers, alterável pelo filtro woocommerce_structured_data_product. O Yoast SEO e o Rank Math geram cada um o seu próprio grafo e expõem o seu próprio ponto de extensão. Escolha uma só destas três fontes: acumular equivale a publicar vários blocos Product no mesmo URL.

Para as políticas, a lógica é idêntica à do PrestaShop: um bloco Organization na página de devoluções e na página de entregas, referenciado a partir das páginas de produto por @id se quiser afastar qualquer ambiguidade. O plugin llms.txt e AEO Schema WooCommerce trata dessa parte de grafo e de FAQ para os agentes.

Verificar o resultado

1. Rich Results Test. Corrija os erros críticos. Os avisos não críticos ficam ao seu critério: decida segundo os enriquecimentos que quer obter.
2. Validador schema.org. Sintaxe JSON-LD e coerência dos @type, independentemente das regras da Google.
3. Search Console, relatório Merchant listings. O estado real em produção, uma vez as páginas rastreadas de novo. Conte vários dias depois da publicação.
4. Merchant Center ou Search Console, definições de devolução. Verifique que uma configuração existente não prevalece já sobre a sua marcação.

Por onde começar

1. Verificar que name, image, offers, price e priceCurrency estão presentes e exatos em 100 % das páginas. É o único ponto realmente bloqueante.
2. Acrescentar availability, itemCondition, sku, brand.name e o GTIN quando existe.
3. Declarar a política de devolução e a política de entrega uma vez, ao nível de Organization, nas páginas dedicadas.
4. Só pôr priceValidUntil nos preços que têm data de fim real, com validFrom em frente.
5. Tratar as variantes com ProductGroup, depois de garantir que cada variante tem mesmo um URL próprio.

Uma regra encima tudo: a marcação tem de descrever o que a página mostra. Uma devolução gratuita marcada tem de estar anunciada no site, um prazo de 30 dias marcado tem de ser um prazo de 30 dias efetivo. É este princípio, e não o número de propriedades, que explica a maioria das ações manuais sobre dados estruturados.

Leia também: o guia completo do SEO para e-commerce e o FAQ schema e os rich snippets.

Para passar à ação: a nossa seleção de módulos para otimizar as suas páginas de produto.