# Schema.org Product em 2026: o que é obrigatório, o que é recomendado, e onde declarar devoluções e entrega
> Só cinco propriedades são exigidas para ser elegível aos resultados de produto. hasMerchantReturnPolicy e shippingDetails são enriquecimentos, a declarar de preferência ao nível Organization. O que diz a documentação da Google, e como o aplicar no PrestaShop 8/9 e no WooCommerce.
- Página:
- Idioma: pt
- Publicado em: 2026-07-20
- Atualizado em: 2026-09-03
- Outros idiomas: [fr](https://www.datafirefly.com/2026/07/20/schema-org-product-2026-hasmerchantreturnpolicy-shippingdetails-prestashop-woocommerce/index.md), [en](https://www.datafirefly.com/en/2026/07/20/schema-org-product-2026-hasmerchantreturnpolicy-shippingdetails-prestashop-woocommerce-en/index.md), [es](https://www.datafirefly.com/es/2026/07/20/schema-org-product-2026-hasmerchantreturnpolicy-shippingdetails-prestashop-woocommerce-es/index.md), [de](https://www.datafirefly.com/de/2026/07/20/schema-org-product-2026-hasmerchantreturnpolicy-shippingdetails-prestashop-woocommerce-de/index.md), [it](https://www.datafirefly.com/it/2026/07/20/schema-org-product-2026-hasmerchantreturnpolicy-shippingdetails-prestashop-woocommerce-2/index.md), [pl](https://www.datafirefly.com/pl/2026/07/20/schema-org-product-2026-zwroty-dostawa-prestashop-woocommerce/index.md), [nl](https://www.datafirefly.com/nl/2026/07/20/schema-org-product-2026-hasmerchantreturnpolicy-shippingdetails-prestashop-woocommerce/index.md)
- Índice:
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](https://www.datafirefly.com/pt/produto/all-in-one-seo-prestashop/) 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](https://www.datafirefly.com/pt/produto/llms-txt-aeo-woocommerce-schema-ia-pt/) 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](https://www.datafirefly.com/pt/2026/05/01/seo-ecommerce-guia-completo-2026/) e [o FAQ schema e os rich snippets](https://www.datafirefly.com/pt/2026/05/09/faq-schema-prestashop-rich-snippets-google-2026/).
Para passar à ação: [a nossa seleção de módulos para otimizar as suas páginas de produto](https://www.datafirefly.com/pt/solutions/prestashop/ficha-de-produto/).