Dados estruturados e schema: o que são, quando usar e o que eles não fazem

Adicionar algumas linhas de código ao site não coloca uma empresa na primeira posição do Google. Também não garante estrelas, painéis especiais ou presença em respostas de inteligência artificial.

Ainda assim, dados estruturados são úteis. Eles organizam informações de uma forma padronizada e ajudam sistemas de busca a identificar com mais precisão o que existe em uma página: uma empresa, um produto, um artigo, uma receita, um evento ou uma vaga, por exemplo.

O problema começa quando essa função é transformada em promessa. Schema passa a ser vendido como uma técnica secreta de ranqueamento, e sites recebem marcações extensas, duplicadas ou incompatíveis com o conteúdo visível.

Uma implementação boa costuma ser menos espetacular. Ela descreve corretamente a página, usa apenas propriedades que podem ser confirmadas e continua válida quando preço, horário ou disponibilidade mudam.

O que são dados estruturados

Dados estruturados são informações organizadas de acordo com um vocabulário e uma sintaxe que máquinas conseguem processar.

Em uma página comum, uma pessoa reconhece que “R$ 189,90” é um preço porque observa o contexto. Um sistema precisa relacionar aquele número ao produto certo, à moeda, à disponibilidade e, às vezes, a uma variação específica.

Com a marcação adequada, esses elementos ganham nomes explícitos:

• o item é um Product;
• o valor está em price;
• a moeda aparece em priceCurrency;
• a situação de estoque entra em availability;
• a marca pode ser identificada como Brand.

Essa estrutura não substitui o conteúdo da página. Ela o descreve em outra camada.

Schema.org não é a mesma coisa que resultado rico do Google

Schema.org é um vocabulário compartilhado que reúne tipos e propriedades para descrever entidades e relações na web. Nele existem centenas de possibilidades.

O Google utiliza boa parte desse vocabulário, mas mantém sua própria documentação sobre os tipos e propriedades que podem participar de recursos da Pesquisa. Nem tudo que existe no Schema.org produz um efeito visual no Google.

Essa distinção é importante:

• uma marcação pode ser válida no Schema.org;
• o Google pode compreender essa informação;
• mesmo assim, ela pode não estar ligada a nenhum resultado aprimorado;
• e, ainda que esteja, sua exibição não é garantida.

Para comportamento específico na Pesquisa Google, a referência principal deve ser a documentação do Google. Para validação ampla do vocabulário, o Schema Markup Validator ajuda a verificar a estrutura.

Para que os dados estruturados servem

Há três funções que costumam ser misturadas.

Ajudar a identificar o conteúdo

A marcação oferece pistas explícitas sobre o significado da página. Uma organização pode informar nome, logotipo, endereço e perfis oficiais. Um produto pode relacionar oferta, preço e estoque. Um artigo pode identificar título, autor e data.

Isso reduz ambiguidade, especialmente em sites com muitas entidades, unidades ou variações.

Tornar a página elegível a recursos de pesquisa

Alguns tipos podem permitir uma apresentação mais rica, como informações de produto, eventos, receitas, vagas, breadcrumbs e vídeos.

“Elegível” é a palavra correta. O código abre uma possibilidade. O Google decide se o recurso será exibido de acordo com a consulta, o dispositivo, a localização, a qualidade da página e outros fatores.

Distribuir informação de forma legível por máquina

Dados estruturados também podem ser processados por outros mecanismos, plataformas e aplicações. Em um ambiente de busca que inclui assistentes de IA, oferecer informações claras sobre entidades e relações é útil.

Isso não significa que schema obrigará uma IA a citar a marca. Ele é uma fonte de clareza, não um comando de recomendação.

Dados estruturados melhoram o ranqueamento?

Não há base para prometer uma subida de posição apenas porque o site recebeu schema.

O Google usa dados estruturados para entender o conteúdo e habilitar experiências de pesquisa. Uma apresentação mais informativa pode influenciar a forma como usuários interagem com o resultado em alguns casos. Isso é diferente de afirmar que a marcação funciona como um fator direto e automático de ranqueamento.

Uma página lenta, rasa ou desalinhada à intenção não se torna competitiva porque contém um JSON-LD perfeito. O código também não corrige problemas de indexação, arquitetura, reputação ou conteúdo.

O valor da implementação deve ser medido pelo que ela resolve: clareza, elegibilidade, consistência e eficiência na gestão de informações.

JSON-LD, Microdata e RDFa

O Google aceita três formatos principais.

JSON-LD

É um bloco de dados, geralmente inserido no código com script type="application/ld+json". Como fica separado da marcação visual, costuma ser mais fácil de implementar e manter.

O Google recomenda JSON-LD na maioria dos casos, mas a preferência não dispensa os cuidados com conteúdo e atualização.

Microdata

Adiciona atributos diretamente aos elementos HTML. Pode funcionar bem, porém tende a ficar mais difícil de revisar em páginas complexas porque estrutura visual e marcação semântica se misturam.

RDFa

Também usa atributos no HTML para expressar relações. É válido, mas menos comum em implementações comerciais atuais.

Os três podem funcionar quando o código é válido e representa a página. O melhor formato é aquele que a equipe consegue manter sem criar divergências.

Um exemplo simples de Organization

Para um site institucional, a página inicial pode identificar a organização. Um exemplo básico em JSON-LD seria:

html <script type="application/ld+json"> { "@context": "https://schema.org", "@type": "Organization", "@id": "https://www.exemplo.com.br/#organization", "name": "Empresa Exemplo", "url": "https://www.exemplo.com.br/", "logo": "https://www.exemplo.com.br/imagens/logo.png", "sameAs": [ "https://www.linkedin.com/company/empresa-exemplo", "https://www.instagram.com/empresaexemplo" ] } </script>

O @id funciona como um identificador interno daquela entidade no conjunto de dados. Ele permite que outras marcações da página façam referência à mesma organização sem recriar informações conflitantes.

sameAs deve apontar para perfis ou páginas oficiais que representam a mesma entidade. Não é uma lista de backlinks, parceiros ou lugares onde a marca gostaria de aparecer.

Organization ou LocalBusiness?

Organization descreve uma organização de forma ampla. LocalBusiness é um subtipo voltado a negócios com presença local, como lojas, restaurantes, clínicas e outros estabelecimentos.

Quando existe atendimento em local físico, o Google recomenda usar o subtipo de LocalBusiness mais específico que represente a operação, sempre que houver um adequado.

Um exemplo resumido:

html <script type="application/ld+json"> { "@context": "https://schema.org", "@type": "Dentist", "@id": "https://www.exemplo.com.br/unidades/goiania/#local", "name": "Clínica Exemplo — Unidade Goiânia", "url": "https://www.exemplo.com.br/unidades/goiania/", "telephone": "+55 62 3000-0000", "address": { "@type": "PostalAddress", "streetAddress": "Rua Exemplo, 100", "addressLocality": "Goiânia", "addressRegion": "GO", "postalCode": "74000-000", "addressCountry": "BR" }, "geo": { "@type": "GeoCoordinates", "latitude": -16.686900, "longitude": -49.264800 }, "openingHoursSpecification": [{ "@type": "OpeningHoursSpecification", "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"], "opens": "08:00", "closes": "18:00" }] } </script>

Os dados são fictícios e não devem ser copiados para produção. Endereço, coordenadas, telefone, URL e horários precisam corresponder à unidade descrita e ao que o usuário vê na página.

Para negócios locais, a marcação complementa o Perfil da Empresa no Google. Ela não cria uma ficha no Maps nem substitui a verificação.

Como tratar empresas com várias unidades

Cada endereço deve ser representado como uma entidade local própria, de preferência na página específica da unidade.

Todas as unidades podem se relacionar à mesma organização, mas não devem compartilhar telefone, coordenadas e horário se a operação for diferente. Uma marcação genérica repetida em centenas de páginas dificulta justamente a distinção que o schema deveria oferecer.

Uma estrutura comum é:

• Organization na página institucional;
• uma página para cada unidade;
• um LocalBusiness específico em cada página local;
• identificadores @id estáveis;
• relação entre unidade e organização quando aplicável;
• dados visíveis e consistentes com o site e com os perfis locais.

Se a empresa atende uma região, mas não possui unidade física ali, não deve inventar um LocalBusiness para aquela cidade. Página de área atendida e estabelecimento físico são coisas diferentes.

Quais marcações fazem sentido para cada tipo de site

Não existe um pacote universal. A escolha depende do conteúdo e dos recursos suportados.

Sites institucionais e de serviços

Podem usar Organization, LocalBusiness quando elegível, BreadcrumbList, Article para conteúdos editoriais e outros tipos que representem elementos reais.

E-commerce

Product, Offer, informações de disponibilidade, frete, devolução e variantes podem ajudar o Google a compreender o catálogo e tornar produtos elegíveis a experiências comerciais.

O desafio maior não é gerar o código uma vez. É manter preço, estoque, moeda e variações sincronizados com o que está visível e com os feeds comerciais.

Blogs e portais

Article, BlogPosting, BreadcrumbList, VideoObject e ProfilePage podem ser relevantes conforme o conteúdo. Autor, data e imagem precisam corresponder à página.

Eventos

Event deve representar eventos reais, com data, local ou formato on-line e informações de oferta quando aplicáveis. Uma página institucional que apenas menciona vários eventos não deve marcar todos sem seguir os requisitos de cada item.

Vagas

JobPosting é adequado para uma vaga individual, válida e disponível. Marcar uma página genérica de carreiras como se fosse uma vaga específica cria informação enganosa.

Receitas, vídeos, cursos e outros conteúdos

Cada tipo tem propriedades obrigatórias e recomendadas próprias. Antes de implementar, verifique se o Google ainda documenta aquele recurso e quais limitações estão em vigor.

FAQPage ainda faz aparecer perguntas no Google?

Para a maioria dos sites, não de forma regular.

O Google restringiu os resultados ricos de FAQ principalmente a sites governamentais e de saúde reconhecidos como autoridades. Outros sites podem manter a marcação sem sofrer problema apenas por isso, mas não devem vender ou planejar o recurso como se as perguntas fossem aparecer visualmente.

Isso não torna a seção de perguntas frequentes inútil. FAQ pode ajudar o leitor, organizar objeções e ampliar o conteúdo. O benefício editorial continua existindo mesmo sem o destaque visual.

A decisão de implementar FAQPage deve considerar o esforço de manutenção e o uso por outros sistemas, não uma promessa ultrapassada de ocupar mais espaço na busca.

Posso marcar avaliações do Google para exibir estrelas no meu site?

Exibir avaliações e marcar avaliações são questões diferentes.

O Google considera autoavaliativas as notas de LocalBusiness ou Organization quando a própria entidade controla a página que publica a avaliação sobre si mesma. Nesses casos, a página não se qualifica para o recurso de estrelas, mesmo que os comentários tenham sido incorporados por um widget de terceiros.

Também não se deve copiar avaliações de outras plataformas para criar um AggregateRating próprio.

Para produtos, receitas, softwares e outros tipos elegíveis, as regras variam. O conteúdo de avaliação precisa estar visível na página, referir-se a um item específico e seguir as propriedades exigidas.

Adicionar cinco estrelas ao JSON-LD sem que essa nota exista de forma legítima e visível é marcação enganosa.

Erros comuns em implementações de schema

Marcar informação que não aparece na página

Se o código informa um preço, uma nota ou um autor, a pessoa deve encontrar essa informação no conteúdo. Dados ocultos apenas para o buscador violam as diretrizes.

Usar o tipo mais chamativo, não o mais correto

Uma consultoria não vira Product apenas porque deseja exibir preço. Um texto que menciona um evento não é necessariamente uma página de Event. O tipo deve representar a entidade principal.

Copiar um exemplo e esquecer de trocar os dados

Modelos publicados em tutoriais contêm nomes, URLs e endereços fictícios. Quando são levados para produção sem revisão, o site passa a declarar informações de outra empresa.

Gerar marcações duplicadas

Tema, plugin, aplicativo e código personalizado podem inserir blocos diferentes para a mesma entidade. O problema não é a existência de vários blocos, mas contradições de nome, URL, autor, preço ou identificador.

Criar um schema gigantesco sem necessidade

Mais propriedades não significam mais relevância. O próprio Google recomenda priorizar informações completas e corretas em vez de preencher tudo de forma incompleta.

Não atualizar dados dinâmicos

Preço, estoque, data, horário e status de evento envelhecem. Um código válido hoje pode se tornar incorreto amanhã se não estiver ligado à fonte que atualiza a página.

Tratar aviso como erro — ou ignorar erro crítico

No teste de resultados ricos, erros costumam indicar ausência de propriedades obrigatórias ou problemas que impedem a elegibilidade. Avisos geralmente apontam campos recomendados. Eles merecem avaliação, mas não têm o mesmo peso.

Como implementar sem criar uma dívida técnica

O processo deve começar no conteúdo, não no gerador de código.

1. Liste os tipos de página. Produto, categoria, artigo, unidade, evento, vaga e página institucional têm necessidades diferentes.
2. Defina a entidade principal. O que aquela URL representa?
3. Consulte a documentação atual. Confirme tipos, propriedades e políticas.
4. Escolha a fonte dos dados. Evite cadastrar manualmente informações que já existem no CMS, ERP ou catálogo.
5. Gere a marcação a partir da mesma fonte. Isso reduz divergências.
6. Valide o código. Use ferramentas do Google e do Schema.org.
7. Teste páginas reais. Verifique o HTML renderizado e a leitura do Google.
8. Publique por amostra. Antes de aplicar em milhares de URLs, valide algumas de cada modelo.
9. Monitore. Mudanças de template e plugin podem quebrar marcações sem aviso visual.

Em projetos grandes, documente @id, tipos usados, campos de origem e responsáveis pela manutenção. O conhecimento não pode ficar apenas com quem escreveu o primeiro script.

Como testar dados estruturados

Duas ferramentas respondem a perguntas diferentes.

Teste de pesquisa aprimorada

O Rich Results Test verifica marcações ligadas a recursos compatíveis do Google e pode mostrar uma prévia em alguns casos. Uma mensagem de elegibilidade confirma que o código atende aos requisitos detectáveis; não garante exibição.

É melhor testar a URL publicada, porque o processamento de JavaScript e outros elementos do ambiente real podem mudar o resultado.

Schema Markup Validator

O validador do Schema.org verifica o vocabulário de forma mais ampla, inclusive tipos que não geram recursos específicos no Google.

A inspeção de URL e os relatórios do Google Search Console ajudam a verificar como o Google acessou a página e quais problemas foram encontrados.

Válido não significa verdadeiro

Um código pode passar no teste e continuar ruim.

O validador consegue conferir sintaxe, tipos e propriedades. Ele não sabe, em todos os casos, se o preço está atualizado, se a empresa atende naquele endereço, se o autor existe ou se a avaliação foi inventada.

Essa é a diferença entre validação técnica e qualidade. A responsabilidade sobre a veracidade continua sendo de quem publica.

As diretrizes também exigem que o conteúdo marcado seja relevante para o foco da página, esteja acessível ao usuário e não seja usado para enganar. Violações podem retirar a elegibilidade a resultados ricos e, em casos de abuso, levar a ação manual relacionada aos dados estruturados.

Como medir o resultado da implementação

Não avalie schema apenas pelo número de itens válidos no Search Console. Validade é condição de funcionamento, não resultado comercial.

Antes de implementar, registre:

• aparência atual das páginas na busca;
• impressões;
• cliques;
• CTR;
• posição média;
• conversões das URLs envolvidas;
• erros e avisos existentes.

Implemente primeiro em um grupo controlado de páginas, quando possível. Depois, compare períodos suficientemente longos e considere sazonalidade, alterações de conteúdo, posição e mercado.

Se um recurso visual passa a aparecer, observe se mudou a taxa de cliques e a qualidade do tráfego. Em e-commerce, confira também se preço e estoque exibidos correspondem ao site. Um resultado chamativo com informação errada pode aumentar o clique e piorar a experiência.

Dados estruturados e inteligência artificial

Sistemas de IA precisam identificar entidades, atributos e relações. Uma estrutura coerente pode facilitar essa leitura, principalmente em catálogos, organizações, autores, produtos e unidades.

Mas seria exagero afirmar que schema, sozinho, garante citação. Assistentes podem considerar conteúdo, autoridade, referências externas, atualidade e outras fontes. Alguns nem dependem do mesmo conjunto de recursos do Google.

O papel dos dados estruturados é reduzir ambiguidade. A marca ainda precisa ser compreensível no texto, reconhecida fora do próprio site e consistente em diferentes plataformas.

O artigo sobre SEO para inteligência artificial aprofunda essa relação sem transformar marcação técnica em atalho de visibilidade.

Perguntas frequentes sobre dados estruturados

Todo site precisa de schema?

Nem todo site terá acesso a um resultado rico, mas muitas páginas podem se beneficiar de uma descrição mais clara de organizações, artigos, produtos ou navegação. A prioridade depende do tipo de negócio, da escala e da capacidade de manter os dados corretos.

Plugin de SEO resolve a implementação?

Plugins podem gerar uma boa base, principalmente em sites simples. Ainda é preciso revisar tipos, campos, duplicidades e dados dinâmicos. Instalar dois plugins que marcam a mesma entidade pode criar conflitos.

JSON-LD precisa ficar no head?

O Google consegue processar JSON-LD no head ou no body, desde que a marcação esteja acessível e corresponda ao conteúdo da página. A escolha deve facilitar a manutenção e evitar duplicidade.

Schema faz aparecer estrelas nas avaliações da empresa?

Não para avaliações autoavaliativas de Organization ou LocalBusiness em páginas controladas pela própria entidade. Outros tipos, como produtos, têm regras específicas e também não oferecem garantia de exibição.

Preciso marcar todas as propriedades do Schema.org?

Não. Inclua as propriedades obrigatórias para o recurso desejado e as recomendadas que realmente se aplicam. Poucos dados corretos são melhores do que um bloco extenso, incompleto ou inventado.

O melhor schema é o que continua verdadeiro

Dados estruturados bem implementados não chamam atenção para si mesmos. Eles acompanham o site, refletem o conteúdo e permanecem corretos quando a operação muda.

O trabalho técnico não está em gerar um bloco de JSON-LD. Está em decidir o que cada página representa, conectar a marcação à fonte certa e impedir que site, catálogo e código contem histórias diferentes.

Na Cadence SEO, schema entra como parte de uma estrutura maior de Search & AI Visibility. Ele ajuda mecanismos a compreender informações, mas não substitui conteúdo, autoridade, experiência e consistência. É nessa combinação que a implementação deixa de ser enfeite técnico e passa a sustentar a presença digital.

--- No Search & AI Visibility, dados estruturados entram como parte de uma base de informação clara, consistente e conectada à presença da marca.