Dados estruturados: para que servem realmente aos motores de busca

Compra elegibilidade, e elegibilidade não é uma promessa

O modelo mental que causa mais desilusão é aquele em que a marcação é uma alavanca: acrescente schema, obtenha um ganho. Não é isso. Os dados estruturados são uma camada de tradução. A sua página diz, em prosa destinada a uma pessoa, que este artigo foi escrito por Camille Laurent a 18 de agosto e atualizado em setembro. A marcação diz o mesmo numa forma que um analisador consegue ler sem adivinhar. Nada de novo entra na página; a máquina apenas deixa de ter de inferir.

O que essa tradução compra é algo concreto e limitado: a elegibilidade para um resultado enriquecido. As próprias diretrizes da Google colocam-no num aviso destacado — não garante que os seus dados estruturados apareçam nos resultados, mesmo com a página corretamente marcada. Se a funcionalidade é desenhada depende da consulta, do dispositivo, do desenho daquela página de resultados em concreto e de a Google confiar o suficiente no seu site para a renderizar. Marcação correta leva-o de inelegível a elegível. Nada nela o sobe uma posição.

A confirmação mais nítida de que marcação e posicionamento são sistemas separados vem do lado da penalização. A Google descreve uma ação manual por dados estruturados como algo que faz uma página perder a elegibilidade para aparecer como resultado enriquecido, e precisa que não afeta a forma como essa página posiciona na pesquisa web. Dois botões independentes. Se a marcação pudesse empurrar posições para cima, abusar dela empurrá-las-ia para baixo — e a penalização documentada não faz nada disso.

JSON-LD ganhou, e a razão é a manutenção

Há três sintaxes para pôr schema.org numa página. Microdata e RDFa assentam em atributos: polvilha-se itemscope, itemprop e typeof sobre os elementos HTML que já contêm os valores, pelo que a marcação vive dentro da marcação. JSON-LD é um bloco autónomo, uma etiqueta script do tipo application/ld+json com um objeto JSON comum, normalmente colocada no head ou no fim do body. As três são analisadas. A Google recomenda JSON-LD para dados estruturados se a configuração do site o permitir, e chama-lhe a solução mais fácil de implementar e manter em escala.

A razão não é a elegância, é o acoplamento. A marcação por atributos está soldada ao DOM: mude o template, mova o preço para outro componente, deixe um designer trocar um span por uma div, e o itemprop vai com ele ou desaparece em silêncio. JSON-LD está totalmente desacoplado da apresentação, o que significa que sobrevive a redesenhos, pode ser montado no servidor a partir dos mesmos dados que renderizam a página, e lê-se num pull request como um único objeto legível em vez de quinze atributos espalhados. Esse desacoplamento é também o seu perigo, e é exatamente disso que trata a secção seguinte à próxima.

Que tipos ainda produzem algo que se veja

É aqui que a maioria dos conselhos publicados se estragou, por isso verifique a data de tudo o que ler, isto incluído. A Google mantém uma galeria dos tipos de dados estruturados que suporta, e essa galeria é a única autoridade de confiança sobre o assunto. Hoje lista Article, Breadcrumb, Product, Event, Recipe, Video, Job posting, Local business, Organization, Review snippet, Q&A, Dataset, Software app, Vacation rental, Discussion forum, Profile page e mais alguns. Dois nomes que estavam em todas as listas de SEO não constam.

HowTo desapareceu. A Google retirou os resultados enriquecidos HowTo durante 2023, primeiro do telemóvel e depois do computador, e removeu a documentação. FAQPage durou mais tempo mas também desapareceu: a partir de agosto de 2023 foi restringido a sites governamentais e de saúde reconhecidos e com autoridade, e a 7 de maio de 2026 deixou de aparecer de todo. A documentação de FAQPage foi removida a 15 de junho de 2026, e os relatórios associados — o filtro de aparência nos resultados, o relatório de resultados enriquecidos, o suporte no teste de resultados enriquecidos — foram atrás. Se uma lista lhe disser para acrescentar schema de FAQ para ganhar espaço no resultado, essa lista tem pelo menos um ano de atraso, provavelmente três.

Isso não torna a marcação inútil, nem significa que deva arrancá-la. A posição da Google sobre funcionalidades retiradas é que não é preciso removê-las, porque outros motores e serviços podem ainda estar a usá-las. Schema.org é um vocabulário partilhado, não um produto Google: assistentes, agregadores, outros motores e um número crescente de cadeias de recuperação de modelos de linguagem analisam o mesmo JSON. A formulação honesta é que FAQPage e HowTo passaram de um benefício visível e mensurável para um especulativo — o que muda de facto quanto tempo de engenharia merecem.

Obrigatório contra recomendado, para os três que ainda compensam

Article é o caso surpreendente: não tem nenhuma propriedade obrigatória. A Google recomenda acrescentar as propriedades que se aplicam ao seu conteúdo, e cita author, datePublished, dateModified, headline e image como recomendadas. Isso não é autorização para as saltar. Uma propriedade recomendada é aquela cuja ausência não invalida o objeto mas reduz o que um consumidor pode fazer com ele — um Article sem author é um Article que não alimenta assinatura nenhuma a jusante. Forneça as que conseguir fornecer com exatidão, e o conselho da Google é preferir menos propriedades recomendadas, completas e exatas, a todas as possíveis mal preenchidas.

BreadcrumbList é o mais estrito dos três e o mais barato de acertar. Exige itemListElement, um array ordenado de objetos ListItem, e cada ListItem exige position e name. A propriedade item — o URL para onde essa migalha aponta — é obrigatória em todas as entradas exceto a última, onde a Google recorre ao URL da página atual. A lista tem de conter pelo menos dois ListItem para ser mostrada; uma migalha de um só elemento não é um caminho. É o tipo com melhor relação entre efeito visível e esforço de implementação, porque troca um URL feio por um caminho legível, e porque num site com estrutura de URL disciplinada o caminho gera-se a partir do próprio path.

Product fica a meio. Para um fragmento de produto as propriedades obrigatórias são name mais pelo menos um de review, aggregateRating ou offers — basta um dos três. Na prática é offers que ganha o seu lugar, porque um preço e um estado de disponibilidade dentro do resultado respondem às duas perguntas que um comprador tem antes de clicar. Repare no aviso que o teste de resultados enriquecidos pode levantar se fornecer offers sem qualquer classificação: é um aviso, não um erro, e inventar uma classificação para o calar é exatamente o comportamento de que trata a secção seguinte.

A regra que decide tudo: marcar o que é visível

As diretrizes de dados estruturados da Google contêm uma instrução que causa mais ações manuais do que todos os erros técnicos juntos: não marque conteúdo que não seja visível para os leitores da página. Parece óbvio até reparar em como o JSON-LD facilita quebrá-la. O bloco vive à parte do HTML, é gerado por um template, nunca é renderizado — por isso ninguém na equipa alguma vez o olha lado a lado com a página. É precisamente por isso que ele deriva.

Os modos de falha são banais, não maliciosos. Um template de produto emite aggregateRating a partir de um campo de catálogo enquanto a página não mostra avaliações porque ainda nenhuma foi escrita. Uma página de preços renderiza um preço no servidor depois de uma conversão de moeda, mas o JSON-LD foi construído a partir do preço base e agora contradiz o que o visitante lê. Um bloco de artigo carrega um dateModified que o CMS incrementa a cada republicação enquanto a página mostra a data original. Cada um desses casos é marcação a descrever algo que o leitor não consegue verificar, e cada um é a mesma infração que falsificar cinco estrelas de propósito.

A correção de engenharia cabe num princípio: nunca construa o JSON-LD a partir de uma segunda fonte de verdade. Monte-o exatamente a partir dos mesmos objetos que renderizam a página visível, no mesmo pedido, para que um valor não possa aparecer num e não no outro. Se o preço mostrado vem de uma cadeia formatada, derive o preço da marcação do número por trás dessa cadeia, não de uma consulta separada. Depois acrescente um teste por template que verifique que cada valor marcado aparece algures no HTML renderizado. Esse teste apanha a deriva de template no dia em que acontece, em vez de numa mensagem da Search Console três meses depois.

Testar: três ferramentas, três perguntas diferentes

O validador do schema.org responde à pergunta do vocabulário: isto é schema.org válido, os tipos existem, as propriedades estão bem escritas, os objetos aninhados cabem nos intervalos esperados. Não sabe nada da Google. O teste de resultados enriquecidos responde à pergunta de elegibilidade para a Google em concreto: com esta marcação, a página é elegível para uma funcionalidade que a Google suporta atualmente, e se não, que propriedade obrigatória falta. Os relatórios de resultados enriquecidos da Search Console respondem à terceira e mais importante: o que está a acontecer no site em produção, em escala, em todos os URL, depois de o template ir para o ar.

Use-as por essa ordem e pare na terceira. O conselho da Google é testar durante o desenvolvimento e depois vigiar a validade após a implantação, porque os problemas aparecem depois de publicar, por questões de templates e de serviço que nenhuma verificação prévia consegue ver. Uma página que passou no teste de resultados enriquecidos no portátil de um programador pode falhar em produção porque uma camada de cache retira a etiqueta script, porque um banner de consentimento atrasa a renderização para lá do ponto em que o rastreador desistiu, ou porque uma categoria em quarenta tem um null no campo que alimenta name.

Perguntas frequentes

Os dados estruturados são um fator de posicionamento?

Não. A marcação torna uma página elegível para resultados enriquecidos; não a sobe nem a desce nos resultados web comuns. A prova mais nítida é a penalização: a Google descreve uma ação manual por dados estruturados como algo que custa à página a elegibilidade para aparecer enriquecida, precisando que não afeta a sua posição na pesquisa web. Dois sistemas separados. Qualquer benefício indireto vem de um resultado mais informativo que atrai mais cliques, não de a marcação ser pontuada.

Devo remover o schema de FAQ e HowTo agora que não produzem nada?

Não, e a Google di-lo explicitamente para as funcionalidades retiradas: não é preciso removê-las, porque outros motores e serviços podem ainda estar a usá-las. Schema.org é um vocabulário partilhado que a Google não possui. O que deve mudar é o seu orçamento, não o seu HTML — pare de construir marcação FAQ nova à espera de um retorno visível no Google, e pare de reportar sobre uma funcionalidade cujo relatório da Search Console já não existe. Se a marcação já é gerada por um template cuja manutenção não custa nada, deixá-la é a decisão mais barata.

A minha marcação é válida e o teste de resultados enriquecidos passa, mas não aparece nenhum resultado enriquecido. Porquê?

Porque passar no teste prova elegibilidade, e elegibilidade não é exibição. A Google afirma que não garante o aparecimento dos dados estruturados mesmo com a página corretamente marcada. A decisão depende da consulta, do dispositivo, do desenho daquela página de resultados em concreto e da confiança da Google no site. Não há alavanca para puxar. A resposta produtiva é confirmar que a página está indexada, que o relatório da Search Console mostra o item como válido em produção e não apenas na ferramenta de teste, e depois esperar — a exibição começa muitas vezes semanas após a primeira rastreagem da marcação.

Posso pôr o JSON-LD no head, ou tem de ser no body?

Ambas funcionam. A Google analisa a etiqueta script onde quer que apareça no documento, e não há diferença de posicionamento nem de elegibilidade entre as duas posições. O que importa muito mais é que a etiqueta chegue ao rastreador. Se o bloco for injetado por JavaScript do lado do cliente, depende de a renderização se concluir, o que introduz um modo de falha que a marcação renderizada no servidor não tem. Emita-o no servidor se a sua stack o permitir, e se tiver de ser no cliente, verifique com a ferramenta de inspeção de URL que o HTML renderizado que a Google vê o contém mesmo.

O que exatamente vale a um site uma ação manual por dados estruturados?

Marcação que descreve algo que o leitor não consegue ver. As diretrizes da Google dizem claramente para não marcar conteúdo que não seja visível para os leitores da página, e o conteúdo marcado escondido é citado como razão para os dados não aparecerem. Na prática as faltas são: classificações de produtos sem avaliações na página, preços que não batem certo com o preço mostrado, tipos que não correspondem ao propósito real da página, e datas inventadas pelo CMS. A consequência é a perda de elegibilidade para resultados enriquecidos, não uma queda de posição — mas a elegibilidade era toda a razão para acrescentar a marcação.

Um gerador de marcação schema produz algo que eu possa publicar tal como está?

Produz um esqueleto correto, que é de facto a metade tediosa do trabalho — o tipo certo, as propriedades obrigatórias presentes, o aninhamento válido, o JSON bem formado. O que não consegue fazer é conhecer a sua página. Duas coisas continuam a ser suas: verificar que cada valor que cola é um valor visível na página renderizada, e ligar o bloco aos seus dados para que continue verdadeiro após a próxima mudança de conteúdo. Um gerador é a ferramenta certa para uma página pontual ou um primeiro template; é a ferramenta errada para um catálogo de quarenta mil produtos, que precisa de geração a partir dos mesmos objetos que renderizam a página.