Saiba quais tipos de schema servem para posts de blog, termos de glossário e notícias, e veja passos simples para testar marcação schema em blogs para obter rich results.
A marcação schema é um pequeno bloco de dados estruturados que você adiciona a uma página para que os motores de busca possam ler fatos-chave em um formato claro e consistente. Pense nisso como uma etiqueta numa caixa: o conteúdo continua sendo o conteúdo, mas a etiqueta facilita ordenar e exibir.
Quando os motores de busca entendem melhor sua página, eles podem apresentá‑la como um resultado enriquecido em vez de um link azul padrão. Um resultado enriquecido pode incluir detalhes extras como manchete, data de publicação, autor, breadcrumbs ou uma prévia curta. Isso não acontece em toda página, e sempre cabe ao motor de busca decidir.
É útil ser claro sobre o que o schema pode e não pode fazer. Dados estruturados melhoram a clareza e a elegibilidade para certos recursos de busca, mas não aumentam o ranqueamento por si só. Se uma página for rasa, desatualizada ou difícil de rastrear, o schema não vai consertar isso. E ele não pode forçar a aparição de um resultado enriquecido.
Em muitos sites, alguns padrões importam mais do que todo o resto:
Um exemplo simples: você publica uma definição de glossário e um post de blog que a referencia. Com a marcação correta, um motor de busca pode tratar com mais confiança uma página como a definição e a outra como um guia, em vez de duas “artigos” concorrentes.
Se você publica muitas páginas (especialmente a partir de templates ou uma API), o schema fica ainda mais valioso porque mantém sua saída consistente conforme você adiciona posts de blog, notícias e entradas de glossário ao longo do tempo.
Para a maioria dos blogs, o ponto de partida é BlogPosting, que é uma versão mais específica de Article.
Os maiores ganhos geralmente vêm de acertar o básico em cada post. Os motores de busca valorizam sinais precisos e estáveis mais do que uma longa lista de propriedades opcionais.
Faça estes campos precisos em todo post:
Se você atualizar um guia antigo, mantenha datePublished como a data original e defina dateModified para a data da atualização. Não altere datePublished só para parecer mais novo, e não atualize dateModified a não ser que algo realmente mude.
Campos opcionais podem ajudar, mas só se forem precisos e fáceis de manter. keywords funciona se você já exibe tags ou categorias. wordCount é ok para páginas longas e estáticas, mas evite se o conteúdo mudar muito após a publicação. speakable só faz sentido quando você mantém um resumo curto e limpo pensado para leitura em voz alta.
Se seu pipeline gera JSON-LD automaticamente (por exemplo, através de um template do CMS ou um renderer orientado por API), priorize consistência e correção antes de adicionar campos extras.
Páginas de notícias são avaliadas fortemente por frescor e clareza. Os motores de busca querem saber o que aconteceu, quando foi publicado e quem publicou. Por isso a marcação de notícias tende a ser menos tolerante.
Use NewsArticle quando a página reportar um evento ou desenvolvimento pontual que ficará desatualizado (mesmo que fique no seu arquivo). Use Article para reportagens evergreen, peças de opinião e long reads que não estão vinculadas a um momento específico.
Uma regra prática:
As datas importam mais para notícias do que para quase qualquer outro tipo de conteúdo. Inclua tanto datePublished quanto dateModified e garanta que coincidam com o que o leitor vê na página. Se você atualizar uma matéria, atualize dateModified. Se você “republicar” um conteúdo antigo como novo, certifique‑se de que as datas visíveis e os dados estruturados contem a mesma história.
Para muitas páginas de notícia, um pequeno conjunto de campos traz a maior parte do valor: headline, description, image (uma imagem real e rastreável), author, publisher (como Organization), mainEntityOfPage, datePublished e dateModified.
Se você tem paywall ou assinatura, marque claramente com isAccessibleForFree e detalhes do conteúdo paywalled. Não diga que algo é gratuito se não for.
Para matérias republicadas ou sindicadas, evite parecer uma fonte duplicada. Mantenha uma URL canônica por matéria, mantenha os dados estruturados consistentes nessa versão canônica e evite mudar manchetes entre cópias. Se a mesma matéria existir em vários lugares, deixe óbvio qual página é a principal.
Páginas de glossário podem conseguir snippets mais claros quando os motores de busca entendem que você está definindo termos, e não publicando artigos regulares. Mesmo que seu foco principal seja schema para blogs, a marcação de definições ajuda os motores a classificar conteúdo do glossário mais rapidamente.
Use DefinedTerm quando uma página explica um termo. Use DefinedTermSet quando a página for uma coleção de termos, como um glossário A–Z ou uma página de categoria com várias entradas. Use FAQPage apenas quando a página for realmente uma lista de perguntas e respostas, não uma definição única.
Uma regra simples: se o objetivo da página for “definir isto”, escolha DefinedTerm. Se o objetivo for “navegar por muitas definições”, escolha DefinedTermSet.
Para uma página de termo único, mantenha a marcação focada em um termo e sua definição, além de onde ele pertence.
{
"@context": "https://schema.org",
"@type": "DefinedTerm",
"name": "Canonical tag",
"alternateName": ["rel=canonical", "canonical URL"],
"description": "A canonical tag tells search engines which URL is the preferred version of a page.",
"inDefinedTermSet": {
"@type": "DefinedTermSet",
"name": "SEO Glossary"
}
}
Para uma página de categoria, use DefinedTermSet. Adicione um ItemList dos termos somente se essa lista for visível para os usuários na página.
Quando tiver sinônimos, use alternateName para variações reais, siglas e diferenças de grafia. Mantenha curto e honesto; não faça stuffing de palavras‑chave.
Alinhe o texto da definição com o que os usuários podem ler. Se a descrição no JSON-LD disser uma coisa e a definição visível disser outra, a probabilidade de rich results diminui.
Alguns tipos de schema ajudam quase toda página, seja um post de blog, uma entrada de glossário ou uma atualização de notícia.
BreadcrumbList é uma das vitórias mais simples. Mostra onde a página está no seu site usando a mesma trilha que os usuários veem (Home › Blog › Tópico › Post). Isso pode limpar a aparência do seu resultado e reduzir confusão quando páginas semelhantes existem em seções diferentes.
Organization e WebSite fornecem sinais claros de marca. Organization cobre seu nome, logo e contatos básicos. WebSite pode descrever o site e, opcionalmente, uma ação de busca interna. Inclua marcação de busca somente se os usuários realmente puderem pesquisar no seu site.
As imagens merecem atenção. Se as páginas dependem de imagens de destaque, adicionar ImageObject (ou descrever completamente a imagem no seu schema principal) ajuda os motores a entender o que a imagem é, onde está e suas propriedades principais.
A marcação de autor frequentemente causa inconsistências evitáveis. Escolha uma abordagem e mantenha‑a: use Person quando um indivíduo real escreve e é creditado na página, e use Organization quando o conteúdo é produzido sob uma byline de marca. Evite alternar entre Person e Organization para o mesmo nome de autor.
Use sameAs apenas para perfis oficiais que você controla. Se tiver dúvida, pule. Perfis desatualizados ou incorretos podem enfraquecer a confiança.
JSON-LD é frequentemente a maneira mais segura de adicionar dados estruturados porque vive em um único bloco \u003cscript type=\"application/ld+json\"\u003e e não altera o que os usuários veem. Coloque‑o no HTML da página (comum no \u003chead\u003e ou perto do fim do \u003cbody\u003e) e garanta que ele seja renderizado na página final, não apenas numa pré‑visualização.
Comece pelo conteúdo visível e mapeie para os campos do schema. Se a página mostra uma manchete, nome do autor, data de publicação, imagem em destaque e uma descrição curta, seu JSON-LD deve corresponder exatamente a esses valores. Incompatibilidades são uma causa comum de falha na hora de conseguir rich results.
Crie um template repetível por tipo de conteúdo (post de blog, item de notícia, termo de glossário). O setup mais seguro é quando o template puxa da mesma fonte que o conteúdo da página, assim as atualizações permanecem sincronizadas.
Um fluxo de rollout que mantém o risco baixo:
@id.Aqui vai um pequeno padrão para IDs estáveis (observe o @id baseado em URL):
{
"@context": "https://schema.org",
"@type": "BlogPosting",
"@id": "https://example.com/blog/my-post#blogposting",
"headline": "My Post Title",
"datePublished": "2026-01-16",
"mainEntityOfPage": "https://example.com/blog/my-post"
}
Se seu site for construído com um framework como Next.js, gere esse bloco em tempo de render a partir do seu CMS ou API de conteúdo.
A validação tem duas partes. Primeiro, verifique se o JSON-LD é válido e corresponde às regras de schema. Depois, cheque se o Google o considera elegível para rich results. Passar em checagens de sintaxe não garante que você obterá um resultado enriquecido.
Comece copiando o JSON-LD renderizado exatamente da página ao vivo (não de um arquivo de template) e valide para problemas gerais de schema. O Schema Markup Validator é útil para identificar nomes de propriedades errados, campos obrigatórios ausentes e incompatibilidades de tipo.
Em seguida, teste a elegibilidade para rich results com o Rich Results Test do Google. Isso foca nos recursos que o Google realmente exibe e destaca campos faltantes que bloqueiam a elegibilidade mesmo quando a marcação é tecnicamente válida. Para conteúdo de blog, lacunas pequenas como imagem ausente ou autor ausente são motivos comuns para não aparecer como enriquecido.
Trate os achados de formas diferentes:
Se você atualizar um template compartilhado e o Rich Results Test começar a sinalizar datePublished ausente em algumas páginas, muitas vezes isso aponta para um problema de dados (um campo vazio no CMS), não um problema do schema.
Re‑teste após cada alteração de template, mesmo que pareça pequena. Se você gera conteúdo via API, valide uma página recém‑publicada de cada tipo de conteúdo antes de propagar as mudanças em todo lugar.
Resultados enriquecidos falham frequentemente por motivos simples: os motores de busca conseguem ler seus dados estruturados, mas não confiam neles.
A regra mais importante é corresponder ao que os usuários veem. Se seu JSON-LD declara um nome de autor, uma manchete ou uma data de publicação, esses detalhes devem ser visíveis na página. Não esconda informações-chave apenas no markup e não use redações diferentes.
Campos obrigatórios ausentes são outro bloqueador frequente. Para páginas tipo Article, headline, image e datas de publicação ou atualização são requisitos comuns. Se sua imagem for muito pequena, ausente ou inacessível, a página pode ficar fora dos rich results mesmo que o resto esteja correto.
Usar o tipo de schema errado também pode prejudicar. Adicionar FAQPage a uma página que na verdade não é uma seção de perguntas e respostas pode fazer com que a marcação seja ignorada ou sinalizada. Escolha tipos que reflitam a página real: BlogPosting para post de blog, NewsArticle para notícia, DefinedTerm para definição.
Alguns problemas que aparecem repetidamente:
Exemplo: uma equipe publica uma notícia e a página mostra “Atualizado em 16 de jan.”, mas o markup ainda contém a data da semana passada de um template reaproveitado. Mesmo com schema NewsArticle correto, os motores podem tratar como não confiável até que o conteúdo visível e os dados estruturados coincidam.
Antes de publicar, faça uma checagem rápida de consistência. A maioria dos problemas com rich results não são dificuldades grandes; são pequenas discrepâncias entre o que a página mostra e o que o markup declara.
Se você está adicionando marcação schema para blogs, comece decidindo o que a página é (BlogPosting, NewsArticle ou uma página de definição). Todo o resto deve apoiar essa escolha.
Se você publica uma atualização de notícia e depois reutiliza o mesmo template para uma entrada de glossário, não deixe campos de NewsArticle para trás. Uma página de definição que ainda afirma ser NewsArticle costuma falhar nas checagens de elegibilidade.
Imagine um site pequeno que publica três coisas: posts semanais de blog, um glossário de termos-chave e um hub simples de notícias para atualizações da empresa. O objetivo é snippets de busca mais claros e elegibilidade para rich results sem mudar o desenho da página.
As escolhas de schema diferem por intenção. Posts de blog costumam caber em BlogPosting (ou Article). Atualizações de notícias cabem em NewsArticle apenas quando são realmente pontuais. Entradas de glossário devem focar em DefinedTerm e DefinedTermSet (frequentemente pareadas com WebPage) para que os motores entendam “esta página define um termo”, não “isto é uma matéria”.
Aqui vai um rollout prático de 2 semanas que mantém o risco baixo:
BreadcrumbList e um perfil de Organization (publisher).Após a implantação, confirme duas coisas: o markup continua presente na página ao vivo (não foi removido pelo renderer ou por ferramentas de consentimento) e os motores estão rastreando as páginas atualizadas e reportando dados estruturados nos relatórios de enhancement e rich results.
Sucesso geralmente significa mais impressões para páginas que já ranqueiam, novos itens de enhancement aparecendo para tipos elegíveis e um aumento moderado de CTR a partir de títulos, datas e breadcrumbs mais limpos.
Schema não é tarefa única. Ele quebra mais frequentemente quando um template muda, um campo é renomeado ou um novo bloco de conteúdo é adicionado e o JSON-LD não é atualizado para corresponder.
Faça dos dados estruturados parte do processo de publicação. Se você gerencia um blog, hub de notícias e glossário, decida quais campos são obrigatórios para cada tipo de conteúdo e trate esses campos como trata o título e a URL: eles devem ser entregues sempre.
A maneira mais simples de manter a marcação para blogs consistente é vinculá‑la à mesma fonte de verdade que você usa para gerar a página: título, autor, data de publicação, imagens, categoria e o corpo principal. Quando o conteúdo é criado em ferramentas diferentes por pessoas diferentes, campos ausentes aparecem (sem autor, formato de data errado, array de imagens vazio) e rich results ficam menos prováveis.
Uma rotina leve que funciona para a maioria das equipes:
Se você publica em escala, automação ajuda. Por exemplo, GENERATED (generated.app) pode gerar conteúdo de blog, notícias e glossário via API e manter campos de dados estruturados consistentes entre templates, inclusive quando você traduz ou atualiza conteúdo.
Exemplo: se você introduzir um novo selo de “última atualização”, atualize também seu JSON-LD para incluir dateModified e então valide um post de blog de amostra, uma página NewsArticle e uma página de termo de glossário antes da mudança ir ao vivo.
A marcação schema é dados estruturados que ajudam os motores de busca a ler fatos importantes da sua página de forma consistente. Pode tornar sua página elegível para resultados enriquecidos (como exibir datas, breadcrumbs ou detalhes extras), mas por si só não aumenta o posicionamento.
Use BlogPosting quando a página for claramente uma entrada de blog, como um guia, resumo, opinião ou atualização. Use Article quando o conteúdo for editorial mais amplo ou quando você quiser um tipo consistente em várias seções e seu sistema já exporta Article.
Comece com os campos que precisam ser precisos e estáveis: headline, author, datePublished, image e mainEntityOfPage. Se esses corresponderem ao que os usuários veem na página, você já fez a maior parte do trabalho necessário para elegibilidade e confiança.
Mantenha datePublished como a data original de publicação e atualize dateModified somente quando houver uma mudança real no conteúdo. Alterar datePublished para parecer mais recente pode sair pela culatra se não corresponder ao que a página mostra e ao que os usuários esperam.
Use NewsArticle apenas para matérias pontuais com momento de publicação claro, como anúncios ou atualizações de última hora que podem ficar desatualizadas. Use Article para guias evergreen, editoriais e reportagens longas que não estão vinculadas a um evento específico.
Use DefinedTerm quando uma página define um termo único, e DefinedTermSet quando a página é uma coleção de termos (como um glossário A–Z). Mantenha a definição estruturada alinhada com a definição visível para não parecer inconsistente.
BreadcrumbList ajuda os motores de busca a mostrar uma trilha de navegação limpa em vez de uma URL longa, o que reduz confusão quando páginas semelhantes existem em seções diferentes. É também um dos tipos de schema mais fáceis de manter precisos porque espelha a navegação visível.
Adicione um único bloco JSON-LD dentro de uma tag de script (type=\"application/ld+json\") no HTML renderizado final, normalmente no head ou perto do fim do body. A abordagem mais segura é gerar o JSON-LD a partir da mesma fonte de dados que renderiza o título, datas, autor e imagem visíveis, para que fiquem sincronizados.
Valide em dois passos: primeiro, verifique se o JSON-LD é válido em termos de schema e usa propriedades/tipos corretos; depois, verifique a elegibilidade para rich results separadamente. Uma página pode ter schema válido e ainda não ser elegível para um resultado enriquecido, então trate os testes de elegibilidade como uma verificação distinta.
Os bloqueadores mais comuns são incompatibilidades entre o markup e o que os usuários veem, ausência de campos-chave como imagem acessível ou data de publicação, e blocos de schema conflitantes que discordam sobre URLs, manchetes ou autores. Mantenha um tipo principal claro por página, IDs e URLs canônicos consistentes, e evite adicionar tipos que não refletem o conteúdo real da página.