Dados estruturados: quais precisa mesmo um site de empresa
Os dados estruturados não são um fator de posicionamento. São uma tradução: dizem às máquinas o que significa um trecho de texto, em vez de as deixarem adivinhar. E é isso que decide cada vez mais se uma página aparece sequer nas respostas.
O essencial
- Quatro tipos chegam a quase qualquer site de empresa: Organization, WebPage ou Article, BreadcrumbList e FAQPage.
- Entregam-se como JSON-LD no
<head>– não como marcação no texto corrido. - O erro mais frequente é silencioso e caro: indicações nos dados estruturados que não constam da própria página.
- Três tipos muito discutidos podem ser dispensados por uma empresa de serviços – só atuam com uma oferta adequada ou com avaliações verdadeiras.
Uma máquina que lê uma página vê, à partida, apenas texto. Que «Emma Woelk» é uma pessoa, «TEISENDA GmbH» uma empresa e «22 de agosto de 2026» uma data de publicação, tem de o adivinhar – ou está lá dito expressamente.
Os dados estruturados são essa presença expressa. Não melhoram nenhuma posição. Decidem se uma página é sequer considerada para apresentações enriquecidas e para respostas geradas.
Os quatro que chegam
1. Organization – uma vez, na página inicial
Quem são: nome, morada, logótipo, ano de fundação, perfis noutras redes. É o registo que permite que um logótipo apareça ao lado do resultado de pesquisa – e a razão mais frequente para ele faltar é simplesmente a ausência deste registo.
Importante: o logótipo tem de existir como imagem rasterizada. Um SVG não é avaliado neste ponto.
2. WebPage ou Article – em todas as páginas
O que esta página é: título, descrição, língua, data de publicação e da última revisão. Nos artigos, adicionalmente Article ou BlogPosting com o autor como registo Person próprio – com função, não apenas com nome.
Importante: a data de alteração tem de ser verdadeira. Uma data que é reposta a cada geração da página é um sinal que se desvaloriza a si próprio.
3. BreadcrumbList – em todas as subpáginas
Onde esta página se situa na estrutura. Visível como caminho no topo da página, legível por máquinas no cabeçalho. As duas coisas andam juntas – um caminho nos dados que não existe na página é uma indicação falsa.
4. FAQPage – onde houver perguntas verdadeiras
A secção de perguntas no fim de um artigo. Para os motores de resposta é o tipo mais valioso de todos, porque já entrega pergunta e resposta em par – exatamente a forma em que se cita.
Importante: apenas para perguntas efetivamente visíveis na página. Perguntas inventadas, que só existem nos dados, constituem uma violação das diretrizes.
Três que podem ser dispensados
Product e Offer. Para serviços com proposta a pedido não trazem nada – sem preço e sem disponibilidade não são de qualquer forma apresentados. Só fazem sentido com uma loja a sério.
AggregateRating. As estrelas no resultado de pesquisa são tentadoras e estão ligadas a condições estritas: as avaliações têm de ser verdadeiras, verificáveis e visíveis na página. As avaliações atribuídas a si próprio são uma violação das diretrizes com risco real.
HowTo. Foi claramente reduzido na apresentação e já não compensa o esforço de manutenção para a maioria dos sites de empresa.
Sabia que…?
Os dados estruturados não são um fator de posicionamento – a Google esclareceu isso várias vezes. Decidem sobre a apresentação, não sobre a posição.
Nos motores de resposta o caso é um pouco diferente. Um modelo que tem de construir uma resposta a partir de uma página usa de preferência o que está marcado de forma inequívoca: pares de pergunta e resposta, autor com função, data da última verificação. Não tem então de adivinhar o que pertence a quê. O benefício está portanto menos no posicionamento e mais na citabilidade.
Como se integram
Três regras que evitam a maioria dos problemas.
- JSON-LD, no
<head>. Não como atributos no texto corrido. O JSON-LD mantém-se separado do layout e não se perde nas alterações de design. - Um bloco por página, não cinco. Vários registos pertencem a um
@graphe ligam-se entre si por@id. Assim o artigo remete para a mesma organização que está na página inicial, em vez de a repetir. - Gerar a partir da mesma fonte que o conteúdo visível. Se título, data e autor vêm dos mesmos campos que a página, não podem sequer divergir. É a prevenção mais eficaz que existe.
O erro mais caro é o mais silencioso: os dados estruturados dizem algo que não está na página. Uma data de alteração de ontem num texto de 2023. Um autor que não aparece na zona visível. Perguntas nos dados que não existem na página.
Nenhuma ferramenta de verificação dá por isso – os dados são formalmente válidos. Dá-se por isso numa verificação manual, e então a consequência não afeta apenas a marcação em causa. Por isso a regra «gerar a partir da mesma fonte» é mais importante do que qualquer completude.
Verificar – por esta ordem
| Passo | Com o quê | O que se vê |
|---|---|---|
| 1. Sintaxe | Schema Markup Validator | se o JSON é válido e o tipo está correto |
| 2. Apresentabilidade | Teste de resultados enriquecidos | se uma apresentação enriquecida seria possível |
| 3. Realidade | Search Console, área de melhorias | o que foi de facto reconhecido, em todas as páginas |
| 4. Correspondência | Ler pessoalmente | se cada indicação também consta visivelmente da página |
O passo quatro é o único que nenhuma ferramenta assume – e o único em que os erros graves saltam à vista.
Verifica os dados estruturados desta página quanto à completude e à correspondência com o conteúdo visível. Conteúdo visível da página: [colar texto da página] JSON-LD da página: [colar bloco] Tarefas: 1. Indica todas as informações do JSON-LD que não aparecem no conteúdo visível. É o ponto mais importante – sê minucioso. 2. Indica todas as informações visíveis que deveriam estar marcadas mas faltam (autor com função, data de alteração, perguntas, caminho). 3. Verifica se os quatro tipos básicos estão sensatamente preenchidos: Organization, WebPage/Article, BreadcrumbList, FAQPage. 4. Indica os tipos do bloco que, para uma empresa de serviços sem loja e sem avaliações verificáveis, não têm utilidade. 5. Assinala todas as violações das diretrizes, em especial avaliações atribuídas a si próprio e perguntas que não existem na página. Devolve no fim o JSON-LD corrigido por completo. Não inventes valores – marca o que falta como [a completar].
Conclusão
Os dados estruturados são rapidamente sobrestimados e igualmente depressa mal feitos. Quatro tipos cobrem a necessidade de um site de empresa, e a sua utilidade está menos na posição e mais em ser citável.
A regra que sustenta tudo: não marcar nada que não esteja na página. Quem gera os dados a partir da mesma fonte que o conteúdo visível resolveu este problema de forma estrutural – e pode dispensar em larga medida as verificações posteriores.
Perguntas frequentes
De que dados estruturados precisa um site de empresa?
Quatro tipos chegam: Organization uma vez na página inicial, WebPage ou Article em todas as páginas, BreadcrumbList em todas as subpáginas e FAQPage sempre que existam perguntas verdadeiras e visíveis. Product, AggregateRating e HowTo não compensam, em regra, a uma empresa de serviços.
Os dados estruturados melhoram o posicionamento?
Não. Não são um fator de posicionamento, decidem sobre a apresentação – por exemplo se um logótipo, um caminho ou perguntas expansíveis podem aparecer no resultado de pesquisa. Nos motores de resposta aumentam a citabilidade, porque os pares de pergunta e resposta, o autor e a data estão marcados de forma inequívoca em vez de terem de ser adivinhados.
Porque é que a Google não mostra o nosso logótipo?
A razão mais frequente é um registo Organization em falta ou incompleto na página inicial. Segunda razão mais frequente: o logótipo guardado existe apenas como SVG – neste ponto é necessária uma imagem rasterizada. Mesmo com a marcação correta não há direito à apresentação.
Qual é o erro mais frequente nos dados estruturados?
Informações que constam dos dados mas não do conteúdo visível: uma data de alteração errada, um autor não referido, perguntas inventadas. As ferramentas de verificação não assinalam isso, porque os dados são formalmente válidos. Evita-se gerando a marcação a partir da mesma fonte que o texto visível.
JSON-LD ou microdados?
JSON-LD no <head>. É a forma recomendada pela Google, mantém-se separada do layout e não se perde nas alterações de design. Os microdados espalham a marcação pelo texto corrido e partem-se a cada remodelação da página.
Marketing que se configura sozinho
A beta do Studio Engine está aberta. Reserve o seu lugar e participe desde o início.
Participar na beta →