Schema e rich results: guia de dados estruturados sem atalhos ou promessas

Resposta direta

Schema é um vocabulário para descrever entidades e relações em formato legível por máquinas. No site, a implementação costuma usar JSON-LD. Rich results são aparências especiais que o Google pode exibir quando uma página atende aos requisitos técnicos, de conteúdo e de política de um recurso compatível. Marcação válida não garante destaque e não transforma uma página fraca em conteúdo relevante. O caminho correto é escolher um tipo apropriado, representar apenas informação visível e verdadeira, validar, publicar e monitorar.

Precisa organizar Schema no seu site sem gerar marcação enganosa? Fale com a LTA pelo WhatsApp.

Sumário

1. Schema e rich results não são a mesma coisa
2. Quais tipos fazem sentido para um site empresarial
3. Como escolher propriedades e identificadores
4. Implementação em JSON-LD
5. Validação e monitoramento
6. Avaliações, FAQ e cuidados de política
7. Arquitetura de entidades e links internos
8. Checklist e erros comuns
9. Perguntas frequentes

Schema e rich results não são a mesma coisa

Schema.org mantém um vocabulário compartilhado por diferentes ecossistemas. Ele inclui tipos como Organization, LocalBusiness, Article, Product, Service, BreadcrumbList, Person e VideoObject. Um site pode usar esse vocabulário para comunicar que uma página é um artigo escrito por determinada organização ou que uma unidade tem um endereço.

O Google oferece suporte a um conjunto específico de recursos de dados estruturados para resultados enriquecidos. Nem todo tipo do Schema.org gera um recurso visual na busca. Mesmo entre tipos aceitos, requisitos e disponibilidade podem mudar. Por isso, comece pela galeria e pela documentação oficial do Google correspondente ao recurso, não por um gerador que promete “estrelas em qualquer página”.

O objetivo principal é coerência semântica. Uma implementação bem feita ajuda sistemas a compreender relações, mas conteúdo, rastreamento, indexação e relevância continuam necessários. Na criação de sites com SEO e geolocalização, dados estruturados são tratados como uma camada da página, junto a arquitetura, velocidade, conteúdo e conversão.

Quais tipos fazem sentido para um site empresarial

Organization

Organization descreve a empresa: nome, URL, logo, contatos e perfis oficiais. Use uma entidade consistente e um identificador estável, geralmente um @id baseado no domínio. A home ou página institucional costuma ser o local adequado. Links sameAs podem apontar para redes oficiais, não para qualquer citação da marca.

LocalBusiness

LocalBusiness é um subtipo de Organization voltado a presença local. Use um subtipo mais específico quando apropriado e informe apenas endereço, telefone, horário e área que aparecem e são verdadeiros. Empresas com várias unidades podem ter uma entidade por localização, conectada à organização principal. Uma empresa de área de atendimento não deve inventar endereço público.

Article ou BlogPosting

Artigos podem informar título, imagem, datas, autor e publicador. A marcação deve acompanhar conteúdo editorial real. dateModified só deve mudar quando houve atualização relevante, não automaticamente a cada carregamento. Uma página de blog precisa mostrar autoria e facilitar a identificação de quem responde pelo conteúdo.

BreadcrumbList

Breadcrumbs mostram a posição da página na arquitetura. Cada item deve corresponder ao caminho lógico e, em geral, ao breadcrumb visível. Eles são especialmente úteis em sites com serviços de marketing, softwares, cases e artigos organizados por tema.

Product e SoftwareApplication

Product descreve uma oferta que atende aos requisitos; SoftwareApplication acrescenta propriedades de software. Preço, disponibilidade, versão e avaliações precisam ser atuais e corresponder à página. Para soluções B2B com preço sob consulta, não invente uma oferta numérica apenas para completar o código. Os softwares da LTA são produtos distintos que devem ser modelados conforme informações realmente disponíveis.

VideoObject

Quando uma página incorpora um vídeo relevante, VideoObject pode informar título, descrição, thumbnail, data e URL. O vídeo deve estar acessível e as propriedades exigidas precisam existir. Não marque um vídeo meramente decorativo ou inacessível aos usuários.

Como escolher propriedades e identificadores

Comece pela entidade central. Se o site representa a LTA Agência, defina um @id para a organização, como https://dominio.example/#organization. Em cada artigo, publisher pode referenciar esse identificador. A página institucional pode usar mainEntity ou relações pertinentes, desde que façam sentido.

Um @id não precisa ser uma URL navegável, mas deve ser globalmente único e estável dentro do site. Evite criar uma nova organização com dados ligeiramente diferentes em cada página. Padronize nome, logo, telefone e perfis. O mesmo cuidado vale para autores.

Use o tipo mais específico sem extrapolar

Se uma entidade é uma agência, escolha o tipo disponível que melhor representa a operação; quando não há subtipo perfeito, Organization é seguro. Não selecione Physician, Store ou outra categoria apenas porque ela oferece mais propriedades. A precisão vale mais do que preencher campos.

Propriedades recomendadas não são licença para inventar

Ferramentas distinguem campos obrigatórios e recomendados. Um aviso de propriedade recomendada ausente pode significar que o resultado terá menos recursos, não que a página está inválida. Adicione somente quando houver dado real e exibido. Uma avaliação inexistente não deve ser fabricada para eliminar um aviso.

Implementação em JSON-LD

O Google recomenda JSON-LD para muitos casos porque a marcação fica separada do HTML visual e é fácil de manter. O script deve estar no HTML renderizado e corresponder à página. Um exemplo simplificado de artigo seria:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "@id": "https://exemplo.com/blog/guia/#article",
  "headline": "Título do guia",
  "description": "Resumo fiel do conteúdo",
  "image": ["https://exemplo.com/imagens/guia.jpg"],
  "datePublished": "2026-07-20",
  "dateModified": "2026-07-20",
  "author": {
    "@type": "Organization",
    "@id": "https://exemplo.com/#organization",
    "name": "Empresa Exemplo"
  },
  "publisher": { "@id": "https://exemplo.com/#organization" },
  "mainEntityOfPage": "https://exemplo.com/blog/guia/"
}
</script>

O exemplo não é um bloco universal. URLs, entidade autora, imagens e datas devem ser adaptadas. Verifique a documentação do recurso antes de publicar. Em frameworks modernos, gere o objeto no servidor e serialize com segurança. Em WordPress, evite que tema e vários plugins emitam o mesmo tipo com entidades conflitantes.

Uma página pode ter mais de um tipo

Sim. Um artigo pode conviver com Organization, WebSite e BreadcrumbList. Use um @graph para organizar entidades relacionadas quando isso facilita manutenção. O problema não é quantidade, mas conflito ou irrelevância. Não marque cada menção a um serviço como Product.

Conteúdo dinâmico precisa manter a marcação sincronizada

Se preço, estoque, autor ou data mudam, o JSON-LD deve acompanhar a tela. O mesmo sistema de dados deve alimentar ambos quando possível. Isso reduz divergências. Em sites multilíngues ou com páginas locais, cada URL deve refletir seu conteúdo específico.

Validação e monitoramento

Use o Teste de pesquisa aprimorada para verificar recursos compatíveis com o Google. Use o Schema Markup Validator para validar vocabulário mais amplo. Uma ferramenta pode aceitar um tipo que não gera rich result; por isso, entenda o papel de cada teste.

Depois, inspecione a URL no Search Console e acompanhe relatórios de aprimoramentos disponíveis. Erros impedem elegibilidade; avisos indicam oportunidades ou campos recomendados. Corrija a causa no template para todas as páginas afetadas. Não valide apenas o código colado: teste a URL publicada, pois cache e renderização podem mudar a saída.

Resultados enriquecidos podem aparecer, mudar ou desaparecer. Isso não significa necessariamente penalidade. O Google decide com base em vários fatores, e recursos variam por dispositivo, consulta e disponibilidade. Registre alterações e avalie impressões, cliques e comportamento, sem prometer exibição.

Avaliações, FAQ e cuidados de política

Estrelas e avaliações

Review e AggregateRating têm regras. A avaliação deve se referir a um item elegível, estar visível e ser coletada de forma legítima. O Google limita avaliações “autorreferenciais” para Organization e LocalBusiness quando a própria entidade controla as avaliações exibidas. Copiar nota do Perfil da Empresa e marcar no site sem entender as políticas pode gerar ação manual de dados estruturados.

Apresente depoimentos verdadeiros para ajudar a decisão mesmo sem estrelas no resultado. O conteúdo deve ter valor sem o rich result. Cases podem organizar evidências de maneira mais completa; veja Cases de Sucesso.

FAQ

FAQPage descreve perguntas e respostas mantidas pelo site, mas a exibição de FAQ rich results foi restringida pelo Google principalmente a sites governamentais e de saúde reconhecidos. Uma FAQ continua útil para usuários e atendimento, mesmo quando não gera aparência especial. Nunca crie perguntas repetitivas apenas por causa da marcação.

Conteúdo oculto ou enganoso

Dados estruturados devem representar o conteúdo principal visível. Não marque prêmio, preço, avaliação ou evento ausente. Não use tipos desconectados da página para tentar ocupar mais espaço na busca. Violações podem remover elegibilidade de uma página ou do site.

Arquitetura de entidades e links internos

Schema não substitui links HTML. Mecanismos descobrem e entendem páginas por navegação, âncoras e conteúdo. Uma entidade bem conectada no JSON-LD, mas isolada no site, continua difícil para pessoas. Crie hubs: marketing aponta para serviços; software aponta para produtos; blog liga guias a soluções; cases mostram aplicações.

Um artigo sobre anúncios pode apontar contextualmente para gestão de tráfego pago. Um guia de redes sociais liga a redes sociais e conteúdo. A marcação de BreadcrumbList reflete essa arquitetura, mas o breadcrumb visível também ajuda o leitor a voltar.

Pense em uma identidade consistente da organização em todo o site: logo, nome, contatos e redes. A página institucional deve ser a referência da organização, enquanto páginas de produto descrevem ofertas. Isso reduz entidades duplicadas e facilita manutenção.

Processo recomendado

1. Inventarie templates, entidades e marcações existentes.
2. Remova duplicações e conflitos entre tema, plugin e código.
3. Consulte a documentação atual do recurso desejado.
4. Mapeie propriedades para campos reais da página.
5. Defina @id estável para organização, autores e itens.
6. Gere JSON-LD a partir da mesma fonte usada na interface.
7. Valide código e URL publicada.
8. Monitore Search Console e logs de template.
9. Atualize quando políticas, conteúdo ou modelo de negócio mudarem.

Checklist de dados estruturados

• O tipo representa a entidade principal da página.
• O recurso é documentado como compatível quando o objetivo é rich result.
• Todas as propriedades obrigatórias estão presentes e verdadeiras.
• Campos recomendados só foram adicionados quando existem.
• Informações marcadas também aparecem para o usuário.
• URLs são absolutas, canônicas e acessíveis.
• Imagens atendem a tamanho, formato e acesso exigidos.
• Datas refletem publicação e atualização reais.
• Organização e autores têm @id consistente.
• Não há marcação duplicada ou conflitante.
• Avaliações seguem as políticas específicas.
• O teste foi feito na URL publicada.
• O time entende que elegibilidade não garante exibição.

Erros comuns

Copiar um JSON-LD genérico

Modelos aceleram o início, mas valores de exemplo e tipos errados podem ficar em produção. Mapeie cada campo para o conteúdo real.

Marcar tudo como Product

Uma página institucional ou artigo não vira produto por mencionar serviço. Use o tipo que representa o foco da URL.

Atualizar dateModified automaticamente

Alterar a data sem revisão substancial pode confundir o usuário. Mostre e marque a data verdadeira da atualização editorial.

Depender de estrelas para converter

Rich results podem não aparecer. Proposta, prova, conteúdo e CTA precisam funcionar no resultado comum e na página.

Ignorar scripts duplicados

Tema, plugin e app podem gerar organizações diferentes. Audite o HTML final e escolha uma fonte de verdade.

Perguntas frequentes

Schema melhora o ranking diretamente?

Não há promessa de ganho direto. Dados estruturados ajudam mecanismos a compreender conteúdo e podem habilitar recursos, enquanto relevância e qualidade continuam essenciais.

JSON-LD é melhor que Microdata?

O Google aceita formatos suportados e frequentemente recomenda JSON-LD por facilidade de implementação. A precisão do conteúdo é mais importante do que o formato.

Posso usar FAQPage em qualquer blog?

Você pode descrever uma FAQ que cumpra as diretrizes, mas a exibição enriquecida é limitada. Considere se a marcação acrescenta valor operacional; mantenha a FAQ visível de qualquer forma.

Como colocar estrelas no Google?

Não existe botão garantido. O conteúdo precisa representar um tipo elegível, avaliações legítimas e políticas. O Google decide a exibição. Evite marcação autorreferencial ou inventada.

Um plugin resolve Schema sozinho?

Plugins ajudam, mas dependem de configuração e dos dados fornecidos. Audite o resultado, principalmente em templates customizados, produtos e múltiplas unidades.

Como solicitar uma auditoria?

Envie URLs prioritárias e informe quais recursos deseja representar. Chame a LTA no WhatsApp para alinhar conteúdo, código e monitoramento.

Fontes oficiais

• Google Search Central — entenda como os dados estruturados funcionam
• Google Search Central — políticas gerais de dados estruturados
• Google Search Central — galeria de elementos visuais
• Google Search Central — mudança na exibição de FAQ
• Google Search Central — dados estruturados de avaliações
• Schema.org — documentação