É comum ativar os dados estruturados num plugin de SEO, obter um resultado «válido» num teste e esperar que a Google passe a mostrar estrelas, preços ou outros elementos adicionais nos resultados de pesquisa. Mas a validação técnica não garante essa apresentação.
Os dados estruturados permitem descrever explicitamente o significado do conteúdo de uma página. Podem ajudar os motores de pesquisa a interpretá-la e, em determinadas situações, torná-la elegível para resultados enriquecidos. Não substituem o conteúdo, não são um atalho para melhorar o posicionamento e não obrigam a Google a apresentar funcionalidades específicas.
O que são dados estruturados e como funcionam?
Os dados estruturados utilizam um formato padronizado para identificar entidades e propriedades. Numa ficha de produto, por exemplo, podem indicar qual é o nome do artigo, a marca, o preço, a moeda e a disponibilidade. Essa informação deve corresponder ao que o visitante encontra na página.
Há duas distinções importantes:
- Schema.org
- é o vocabulário que define tipos e propriedades, como
Product,Article,Organization,EventouService. - Pesquisa Google
- utiliza parte desse vocabulário para compreender conteúdo e disponibiliza funcionalidades enriquecidas apenas para determinados tipos, sujeitos a requisitos próprios.
Assim, um tipo pode existir em Schema.org sem dar acesso a um resultado enriquecido específico na Google. Acrescentar propriedades para repetir palavras-chave, ou escolher um tipo por parecer «mais SEO», não melhora a descrição da página.
Porque é que o JSON-LD costuma ser a melhor opção?
A Google aceita três formatos: JSON-LD, Microdata e RDFa. Para a maioria dos projetos WordPress, JSON-LD é o mais prático e é o formato recomendado pela Google: permite manter os dados estruturados num bloco próprio, sem distribuir propriedades pelos elementos visíveis do HTML.
O formato facilita a manutenção, mas não corrige informação errada. Um bloco JSON-LD sem erros de sintaxe pode continuar a descrever incorretamente o produto, a empresa ou o evento.
Que tipos fazem sentido num website WordPress?
A escolha deve começar pelo conteúdo real da página, e não pela lista de opções de um plugin.
| Página ou conteúdo | Tipo de Schema.org | O que importa confirmar |
|---|---|---|
| Artigo de blogue | Article ou BlogPosting | Título, autor, datas, imagem e entidade publicadora. |
| Informação institucional | Organization | Nome, website, logótipo, contactos e identidade coerente. |
| Negócio local | LocalBusiness | Atividade, localização e dados locais adequados ao negócio. |
| Caminho de navegação | BreadcrumbList | Percurso útil e coerente, como Blog → WordPress → Artigo. |
| Página de serviço | Service | Serviço efetivamente descrito, sem presumir um resultado enriquecido específico. |
| Ficha de produto | Product e, quando aplicável, Offer | Preço, moeda, disponibilidade, condições de venda e avaliações reais. |
| Página de evento | Event | Data, local, organizador e requisitos da experiência pretendida na Google. |
Por exemplo, um artigo pode utilizar BlogPosting e referenciar a organização que o publica. Isso não exige criar descrições independentes e contraditórias da mesma empresa em várias páginas. De igual modo, LocalBusiness deve corresponder à atividade real; não é uma opção genérica para qualquer empresa que queira melhorar a visibilidade local.
Cuidados especiais no WooCommerce
Numa loja online, os dados estruturados têm uma componente operacional: preços, promoções, disponibilidade e variantes podem mudar frequentemente. O ideal é que a marcação seja gerada a partir dos mesmos dados que alimentam a ficha de produto, em vez de manter valores duplicados manualmente.
A Google distingue duas utilizações principais de Product:
- Product snippets:
- informação adicional em resultados sobre produtos, incluindo páginas editoriais de análise de um produto, sujeita aos requisitos aplicáveis.
- Merchant listings:
- experiências destinadas a páginas onde é possível comprar o produto, com requisitos próprios para ofertas e outros dados comerciais.
Nem todas as páginas que mencionam produtos são elegíveis para estas funcionalidades. Em geral, a marcação deve concentrar-se na página de um produto específico, e não ser aplicada indiscriminadamente às categorias da loja.
Exemplo: se uma ficha WooCommerce mostra o preço de 79,90 €, mas os dados estruturados indicam 69,90 €, existe uma discrepância, mesmo que o JSON-LD seja sintaticamente válido. O mesmo acontece quando a página apresenta «Em stock» e a propriedade de disponibilidade indica OutOfStock. Num catálogo sem preço público, também não deve ser declarado um preço fictício apenas para preencher a marcação.
Nos produtos variáveis, é necessário verificar como estão representadas as opções, os preços e a disponibilidade de cada variante. O vocabulário ProductGroup pode ser pertinente, mas a estrutura depende de as variantes partilharem uma página ou terem URLs próprios. Avaliações, condições de envio e políticas de devolução também só devem ser declaradas quando correspondem à realidade.
Eventos e perguntas frequentes: o suporte da Google muda
O facto de um tipo continuar disponível em Schema.org não significa que a Pesquisa Google mantenha a mesma funcionalidade enriquecida.
Um exemplo claro é FAQPage: desde 7 de maio de 2026, a Google deixou de apresentar resultados enriquecidos de FAQ. As perguntas frequentes continuam a poder ser úteis para esclarecer clientes e organizar o conteúdo, mas a expectativa de obter esse formato nos resultados deixou de justificar a implementação.
Também não faz sentido substituir FAQPage por QAPage para tentar recuperar essa visibilidade. QAPage destina-se a páginas centradas numa pergunta à qual os utilizadores podem acrescentar respostas, como acontece em determinados fóruns e comunidades. Não se aplica a uma secção de perguntas frequentes escrita pela própria empresa nem a um artigo que responde editorialmente a uma questão.
Com Event, a situação é diferente: existem experiências enriquecidas, mas com critérios específicos. A funcionalidade de eventos da Google destina-se a eventos presenciais, acessíveis ao público e que podem ser reservados. Um evento apenas online pode continuar a ser descrito com o vocabulário Schema.org, sem por isso cumprir os critérios dessa funcionalidade da Pesquisa.
Implementar dados estruturados sem criar conflitos
Plugins de SEO, WooCommerce, extensões de eventos ou avaliações e até o próprio tema podem gerar dados estruturados automaticamente. Antes de instalar outra extensão, convém perceber o que já está presente no código final das páginas.
Ter vários blocos JSON-LD não é, por si só, um erro: um artigo, a organização que o publica e o caminho de navegação podem coexistir. O problema surge quando diferentes componentes descrevem a mesma entidade com informações incompatíveis — por exemplo, dois preços, logótipos ou endereços divergentes.
O princípio é simples: definir qual o sistema responsável por cada tipo de informação e evitar cópias manuais de dados que já existem no WordPress ou WooCommerce. Uma nova extensão de Schema só faz sentido quando resolve uma necessidade concreta que a configuração existente não satisfaz.
Como testar e manter os dados estruturados
A validação deve abranger o código, a correspondência com o conteúdo e o funcionamento depois da publicação.
- Identifique o que a página publica. Analise o resultado efetivo de páginas representativas: página inicial, artigo, serviço e, numa loja, produtos simples e variáveis. Não se limite às opções do painel de administração.
- Utilize as ferramentas adequadas. O Teste de Resultados Enriquecidos da Google verifica os tipos de resultados que a Google suporta e os respetivos requisitos. O Validador do Schema.org permite examinar outros tipos e detetar problemas de sintaxe. Um tipo não detetado pela primeira ferramenta não é necessariamente inválido em Schema.org.
- Confirme os dados com o conteúdo visível. Compare nomes, URLs, imagens, autores, datas, preços, stock e avaliações. Uma ferramenta automática não consegue garantir que os valores são verdadeiros ou que uma avaliação é legítima.
- Distinga erros de avisos. A falta de uma propriedade obrigatória pode impedir a elegibilidade para determinada funcionalidade. Uma propriedade recomendada em falta pode gerar um aviso sem invalidar o resultado. A importância de cada indicação depende dos requisitos do tipo em causa.
- Acompanhe o website depois das alterações. Utilize a Inspeção de URL e, quando disponíveis, os relatórios relevantes do Google Search Console. Volte a testar após mudanças de tema, modelos Elementor, plugins SEO ou WooCommerce, sobretudo quando afetam muitas páginas.
Para que a Google possa considerar os dados estruturados, a página também tem de ser acessível aos seus sistemas de rastreamento e cumprir os requisitos aplicáveis. Mesmo uma implementação tecnicamente correta e elegível pode continuar a aparecer como resultado de pesquisa normal.
Dados estruturados e inteligência artificial não são a mesma coisa
Os dados estruturados descrevem páginas e entidades através de vocabulário padronizado. Já os embeddings e os metadados usados em sistemas de pesquisa semântica ajudam, por exemplo, a localizar informação numa base de conhecimento para um assistente de IA.
São mecanismos distintos. Adicionar Schema.org a um artigo não treina automaticamente um chatbot, nem garante que o conteúdo seja utilizado em respostas geradas por IA. Da mesma forma, criar uma base de conhecimento para pesquisa inteligente não substitui os dados estruturados destinados aos motores de pesquisa.
Conclusão
Os dados estruturados fazem sentido quando existe conteúdo que pode ser descrito com precisão, um tipo apropriado e uma forma fiável de manter a informação atualizada. Se o objetivo for obter uma funcionalidade enriquecida na Google, é ainda necessário confirmar que essa experiência existe e que a página cumpre os respetivos requisitos.
Num WordPress ou WooCommerce, a prioridade deve ser corrigir e manter a marcação existente antes de acrescentar novos tipos ou plugins. O melhor resultado não é o que contém mais propriedades, mas o que descreve fielmente a página e permanece coerente quando o website muda.
