Schema Article: dados estruturados para posts e notícias

O schema Article é a marcação de dados estruturados, no vocabulário do Schema.org, que diz ao Google que uma página é um texto editorial e entrega, em formato de máquina, o título, o autor, as datas de publicação e atualização e a imagem principal. Você usa Article quando tem um post, uma notícia ou uma análise; escolhe o subtipo BlogPosting para posts de blog e NewsArticle para jornalismo; e escreve tudo em JSON-LD dentro do HTML da própria página.

O ponto que quase ninguém explica é o que essa marcação realmente faz. Ela não é um botão de ranqueamento e o Google não garante nenhum resultado visual por causa dela. O que ela faz é reduzir a ambiguidade: o buscador deixa de adivinhar quem assina o texto, quando ele foi publicado e qual imagem o representa. Este guia cobre a escolha do tipo, as propriedades que a documentação do Google cita, um exemplo completo e os erros que aparecem com mais frequência em auditorias.

O que o Google faz com a marcação de artigo

A documentação do Google sobre dados estruturados de Article afirma que a marcação ajuda o buscador a entender melhor a página e a exibir informações mais precisas, como título, imagem e datas, em recursos como a busca e o Google Discover. Note o verbo: ajuda a entender e pode exibir. Não existe uma promessa de estrela, carrossel ou destaque garantido, e quem vende a marcação como atalho para o topo está inventando uma relação que a documentação não faz.

Outro detalhe que surpreende quem chega do mundo das receitas e dos produtos: para Article, o Google não define nenhuma propriedade obrigatória. Todas são recomendadas. Isso não significa que tanto faz. Uma marcação sem autor e sem datas é válida, mas deixa de fornecer justamente os sinais que a página mais precisa confirmar. Pense nas propriedades recomendadas como o conjunto mínimo de bom senso, não como enfeite.

Há também uma regra de coerência que vale para qualquer dado estruturado: a marcação precisa descrever o que o leitor vê na página. Se o JSON-LD diz que o autor é uma pessoa e a página não mostra autor nenhum, ou se a data marcada é de dois anos atrás e a página exibe outra, você criou uma contradição. O Google trata marcação que não corresponde ao conteúdo visível como violação das diretrizes de dados estruturados, e o caminho mais seguro é gerar os dois a partir da mesma fonte de dados.

Article, NewsArticle ou BlogPosting: qual escolher

No Schema.org, NewsArticle e BlogPosting são subtipos de Article. Isso significa que tudo o que vale para Article vale para eles, e que qualquer um dos três é aceito pelo Google nessa funcionalidade. A escolha, portanto, é mais sobre descrever bem a natureza do conteúdo do que sobre desbloquear algo.

A regra prática é simples. Se o texto é um relato de fatos recentes, publicado por um veículo com processo editorial, use NewsArticle. Se é um post de blog, de uma empresa ou de uma pessoa, use BlogPosting. Se é um texto editorial que não se encaixa bem em nenhum dos dois, como um guia perene, um ensaio ou um estudo de caso, use Article. Em caso de dúvida, Article nunca está errado, porque é o tipo mais geral.

• Article: guias, tutoriais longos, ensaios, análises e qualquer texto editorial que não seja notícia nem post de diário de blog.
• BlogPosting: entradas de blog corporativo ou pessoal. É o subtipo natural para a maior parte do conteúdo de um site de empresa.
• NewsArticle: reportagens e notícias de um veículo de imprensa ou de uma editoria de notícias. Usar esse tipo num post de blog promocional não traz benefício e pode confundir quem audita o site.
• Não usar nenhum deles: páginas de produto, de categoria, institucionais e de contato. Marcar uma página comercial como artigo é um erro de tipo, não um truque.

As propriedades que o Google lê e como preenchê-las

A lista recomendada pelo Google para Article é curta: author, dateModified, datePublished, headline e image. Vale entender o que cada uma espera, porque é nos detalhes de formato que a maior parte dos erros nasce.

• headline: o título do artigo. Deve ser conciso e coincidir com o título que aparece na página. Não é o lugar para empilhar palavras-chave nem para copiar o title inteiro quando ele carrega o nome do site.
• author: a pessoa ou a organização que escreveu o texto, como objeto do tipo Person ou Organization, com name e, de preferência, url apontando para uma página que fale do autor. Com mais de um autor, cada um vira um objeto separado dentro de uma lista, nunca vários nomes colados num só campo.
• datePublished: a data e a hora da primeira publicação, em formato ISO 8601, idealmente com fuso horário, por exemplo 2026-03-18T09:30:00-03:00. Sem o fuso, o Google assume um padrão que pode não ser o seu.
• dateModified: a data da última alteração relevante, no mesmo formato. Só deve mudar quando o conteúdo muda de verdade.
• image: uma ou mais URLs de imagens rastreáveis e indexáveis que representem o artigo. O Google recomenda oferecer várias proporções (como 16:9, 4:3 e 1:1) para que ele escolha a mais adequada a cada superfície.
• mainEntityOfPage: não consta na lista recomendada do Google, mas é uma propriedade padrão do Schema.org que liga o artigo à URL canônica da página. Incluí-la é inofensivo e ajuda a deixar claro de que página o objeto fala.
• publisher: também fora da lista do Google, mas útil para declarar o veículo ou a empresa responsável, com nome e logotipo. Trate como informação complementar, não como requisito.

Um exemplo completo em JSON-LD

O Google recomenda JSON-LD, colocado num bloco de script do tipo application/ld+json no head ou no body da página. É o formato mais fácil de manter, porque fica separado do HTML visível. Veja um BlogPosting completo para um post fictício, com um autor e uma organização como publicadora.

O bloco abaixo deve ser lido assim: o contexto aponta para o vocabulário do Schema.org; o tipo é BlogPosting; mainEntityOfPage repete a URL canônica; headline repete o título visível; image traz três arquivos em proporções diferentes; author é uma Person com página própria; e as duas datas têm fuso horário explícito.

{ "@context": "https://schema.org", "@type": "BlogPosting", "mainEntityOfPage": { "@type": "WebPage", "@id": "https://exemplo.com.br/blog/guia-de-canonical" }, "headline": "Canonical: como escolher a URL certa", "image": [ "https://exemplo.com.br/img/canonical-16x9.jpg", "https://exemplo.com.br/img/canonical-4x3.jpg", "https://exemplo.com.br/img/canonical-1x1.jpg" ], "datePublished": "2026-03-18T09:30:00-03:00", "dateModified": "2026-08-02T14:10:00-03:00", "author": { "@type": "Person", "name": "Marina Duarte", "url": "https://exemplo.com.br/autores/marina-duarte" }, "publisher": { "@type": "Organization", "name": "Exemplo Ltda", "logo": { "@type": "ImageObject", "url": "https://exemplo.com.br/img/logo.png" } } }

Se o seu site já usa outros objetos de dados estruturados, como Organization no site inteiro ou BreadcrumbList nas páginas internas, você pode reuni-los num único bloco com @graph e ligá-los por @id. Assim o autor do artigo e a organização publicadora apontam para as mesmas entidades declaradas no resto do site, em vez de serem redescritos de forma ligeiramente diferente em cada página.

Autor e datas: onde a marcação mais erra

Autor é a propriedade mais maltratada. O erro clássico é preencher name com algo que não é um nome: o slogan do blog, a palavra admin, um cargo como Equipe editorial de marketing digital ou vários autores separados por vírgula. O Google pede que o campo contenha apenas o nome do autor, e que cada autor seja declarado separadamente. Se o texto é institucional e não tem uma pessoa por trás, declare uma Organization como autora em vez de inventar uma pessoa.

O segundo cuidado é a página do autor. Incluir url apontando para um perfil real, com quem é a pessoa e o que já publicou, dá ao Google um ponto de ancoragem para reconhecer que textos diferentes vêm da mesma pessoa. Se você ligar também os perfis externos da pessoa por meio de sameAs, limite-se a perfis que realmente sejam dela. Marcar um autor que não existe ou copiar o nome de um especialista conhecido é exatamente o tipo de declaração enganosa que as diretrizes proíbem.

Com as datas, o problema é de honestidade e de formato. No formato, o mais comum é escrever 18/03/2026 em vez de 2026-03-18, ou omitir a hora e o fuso, o que pode deslocar a data em um dia conforme o servidor. Na honestidade, a tentação é atualizar dateModified sempre que o modelo do site muda, o rodapé é trocado ou um comentário chega. Isso não é atualização de conteúdo. Se o texto não mudou, a data também não deve mudar, e dateModified nunca deve ser anterior a datePublished.

A relação entre a data marcada e a data exibida é tratada em outro guia do blog, sobre como o Google decide qual data mostrar. Aqui, o que importa é a consequência para o schema: a data do JSON-LD e a data visível precisam contar a mesma história, e o ideal é que ambas saiam do mesmo campo do banco de dados.

Imagem: formatos, tamanhos e o vínculo com o Discover

A imagem em Article pode ser uma única URL ou uma lista. O Google recomenda fornecer várias proporções da mesma imagem, cada uma em sua própria URL, porque diferentes superfícies recortam de maneiras diferentes. As três proporções do exemplo, 16:9, 4:3 e 1:1, cobrem os recortes mais comuns. Os arquivos precisam estar acessíveis a um rastreador, ou seja, não bloqueados por robots.txt, não escondidos atrás de login e em formatos que o Google indexa, como JPEG, PNG, WebP ou GIF.

Se o seu objetivo inclui o Discover, o requisito relevante vem da documentação específica dessa superfície, não do schema: imagens grandes, com pelo menos 1200 pixels de largura, e a permissão de visualização ampla por meio da diretiva max-image-preview:large na meta tag robots ou do uso do AMP. Sem isso, a imagem pode aparecer pequena ou nem aparecer. O schema sozinho não resolve essa parte.

Um erro de bastidor frequente é apontar image para uma miniatura de 150 pixels, gerada automaticamente pelo tema. Ela é válida para a ferramenta de teste, mas é a pior escolha possível. Use o arquivo original redimensionado em boa qualidade, o mesmo que você usaria como imagem de destaque.

Erros comuns e como validar a marcação

Depois de implementar, valide em duas ferramentas com objetivos diferentes. O Teste de Resultados Ricos do Google mostra se a página é elegível a recursos no Google e lista avisos sobre propriedades recomendadas ausentes. O Validador de Markup de Schema.org, que não é do Google, verifica se o JSON-LD é sintaticamente correto e coerente com o vocabulário, inclusive em propriedades que o Google ignora. Um aviso de propriedade recomendada ausente não invalida a marcação, mas um erro de sintaxe pode deixá-la totalmente ignorada.

No Search Console, os relatórios de dados estruturados e de melhorias só aparecem quando o Google detecta tipos com suporte, e pode levar um tempo para refletir as correções, pois dependem de o Google voltar a rastrear as páginas. Não espere mudança instantânea depois de publicar.

• Marcação que não bate com a página: título, autor ou data no JSON-LD diferentes do que o leitor vê. É o erro mais sério, porque entra no território de marcação enganosa.
• Tipo errado: usar NewsArticle em posts promocionais, ou Article em página de produto.
• Autor inválido: name com cargo, slogan, lista de nomes ou a palavra admin, e url apontando para a home em vez de um perfil.
• Datas em formato livre ou sem fuso, e dateModified atualizado sem mudança real de conteúdo.
• Imagem inacessível: URL bloqueada, redirecionada para uma página de login, ou miniatura minúscula.
• JSON quebrado: aspas tipográficas coladas de um editor de texto, vírgula sobrando no último item ou quebra de linha dentro de uma string. O bloco inteiro deixa de ser lido.
• Duplicidade entre plugin e tema: é comum que um plugin de SEO e o tema gerem, cada um, o seu Article. Dois objetos com valores diferentes para a mesma página geram conflito. Fique com um só gerador.
• Marcação aplicada em páginas de listagem: a página de categoria ou de arquivo do blog lista vários posts, mas não é, ela mesma, um artigo.

Como decidir o que implementar no seu site

Para um blog, o caminho mais enxuto é gerar um único BlogPosting por post, a partir dos campos que o seu sistema já tem: título, autor, data de publicação, data de modificação e imagem de destaque. Se esses campos não existem, o problema não é de schema, é de modelo de conteúdo, e vale resolvê-lo antes de escrever o JSON-LD. Um site que não sabe dizer quem escreveu cada texto dificilmente vai conseguir marcá-lo de forma honesta.

Para um veículo de notícias, mantenha NewsArticle e cuide ainda mais das datas, porque a cronologia é parte do produto. Para sites que misturam guias perenes e posts, é aceitável usar Article nos guias e BlogPosting nos posts, desde que o critério seja documentado e aplicado de forma consistente. A consistência vale mais do que a escolha em si.

Por fim, meça com expectativas realistas. A marcação de artigo é manutenção de higiene: ela corrige ambiguidades e deixa a página elegível a melhores apresentações, mas o que sustenta a posição nos resultados continua sendo a qualidade do conteúdo, o rastreamento e a indexação. Implemente com cuidado, valide, revise quando o modelo do site mudar e siga em frente.