45 minutos para corrigir dados estruturados e aumentar suas chances de ser citado por IAs

O tipo de Schema.org deve representar a página, não o desejo de conquistar um resultado visual específico. Uma clínica pode usar LocalBusiness ou Dentist na página institucional, uma loja pode usar Product na página de um SKU e um artigo pode usar Article. Misturar tudo em todas as URLs cria um catálogo confuso, não uma presença mais forte.

Para uma página sobre a empresa, use Organization ou um subtipo apropriado, como LocalBusiness. Inclua nome, URL, logo, telefone, endereço e áreas atendidas somente quando esses dados forem verdadeiros e estiverem visíveis na página. Um salão, por exemplo, não deve informar atendimento 24 horas no JSON-LD se o horário publicado diz que fecha às 19h.

Para uma página de produto, Product é o ponto de partida. Nome, descrição, imagem, marca, identificador, disponibilidade e preço precisam corresponder ao produto apresentado. Se o preço varia por tamanho ou configuração, explique a variação no texto e escolha uma estrutura que não finja existir um único valor universal.

Review e AggregateRating exigem cuidado extra. Uma avaliação deve ser real, atribuída a uma fonte legítima e exibida na página. Não transforme uma frase promocional como “clientes adoram nosso serviço” em uma nota de cinco estrelas. Além de ser uma prática ruim, essa inconsistência pode invalidar recursos de pesquisa e prejudicar a confiança.

FAQPage pode organizar perguntas e respostas que estejam realmente visíveis. O uso de FAQ não garante um resultado destacado no Google e não deve servir para esconder dezenas de palavras-chave. Para criar respostas mais claras, consulte o guia de estrutura de FAQ e perguntas e respostas para citações em IA.

BreadcrumbList, WebSite e Article também podem ser úteis, especialmente em blogs. Eles ajudam a descrever hierarquia, publicação e contexto. Ainda assim, são complementos: um artigo sem resposta objetiva não fica bom só porque recebeu uma marcação Article.

Uma regra prática resolve boa parte das dúvidas: marque o que a pessoa consegue confirmar na tela. Se o visitante não encontra o telefone, a política de entrega ou a resposta da FAQ no conteúdo visível, não inclua esse dado apenas no código.

Os exemplos abaixo são pontos de partida, não formulários para copiar sem editar. Substitua todos os dados entre colchetes, mantenha somente propriedades verdadeiras e confira se o texto correspondente está publicado na página. Um JSON-LD tecnicamente válido ainda pode estar semanticamente errado.

Para um dentista, a página institucional pode usar um subtipo de LocalBusiness. O endereço deve ser o local real de atendimento, e as áreas de serviço precisam refletir o que a clínica oferece:

<script type="application/ld+json">{"@context":"https://schema.org","@type":"Dentist","@id":"https://exemplo.com/#dentista","name":"[Nome da clínica]","url":"https://exemplo.com/","telephone":"[Telefone]","address":{"@type":"PostalAddress","streetAddress":"[Rua e número]","addressLocality":"[Cidade]","addressRegion":"[UF]","postalCode":"[CEP]","addressCountry":"BR"},"areaServed":"[Cidade e região]"}</script>

Para um restaurante, inclua horário e faixa de preço somente quando a página mostrar essas informações. Se o cardápio muda diariamente, mantenha o JSON-LD básico e atualize os dados com um processo confiável, em vez de publicar preços antigos:

<script type="application/ld+json">{"@context":"https://schema.org","@type":"Restaurant","name":"[Nome do restaurante]","url":"https://exemplo.com/restaurante","telephone":"[Telefone]","servesCuisine":"[Tipo de culinária]","priceRange":"[Faixa de preço]","openingHoursSpecification":[{"@type":"OpeningHoursSpecification","dayOfWeek":["Monday","Tuesday","Wednesday","Thursday","Friday"],"opens":"11:30","closes":"22:00"}],"address":{"@type":"PostalAddress","streetAddress":"[Endereço]","addressLocality":"[Cidade]","addressRegion":"[UF]","postalCode":"[CEP]","addressCountry":"BR"}}</script>

Para uma loja local, LocalBusiness ajuda a organizar dados básicos de entidade e localização. Não use um endereço residencial ou um horário genérico só para preencher campos. A precisão é mais importante que a quantidade de propriedades:

<script type="application/ld+json">{"@context":"https://schema.org","@type":"Store","name":"[Nome da loja]","url":"https://exemplo.com/loja","image":"https://exemplo.com/imagem-loja.jpg","telephone":"[Telefone]","address":{"@type":"PostalAddress","streetAddress":"[Rua e número]","addressLocality":"[Cidade]","addressRegion":"[UF]","postalCode":"[CEP]","addressCountry":"BR"},"sameAs":["[URL real do perfil social ou Google Business Profile]"]}</script>

Para um SKU de e-commerce, Product deve representar uma oferta específica. Se há várias cores, tamanhos e preços, modele a variação correta ou remova o preço do exemplo até que a estrutura de ofertas esteja pronta. Não coloque o preço da categoria inteira em cada produto:

<script type="application/ld+json">{"@context":"https://schema.org","@type":"Product","name":"[Nome exato do produto]","image":["https://exemplo.com/produto.jpg"],"description":"[Descrição visível e factual]","sku":"[SKU]","brand":{"@type":"Brand","name":"[Marca]"},"offers":{"@type":"Offer","url":"https://exemplo.com/produto","priceCurrency":"BRL","price":"[Preço]","availability":"https://schema.org/InStock"}}</script>

O guia oficial do Google para dados estruturados de produto explica propriedades e requisitos específicos para resultados de produtos. Use a documentação como conferência final, principalmente quando preço, disponibilidade e avaliações mudarem com frequência.

A validação precisa acontecer em três camadas. Primeiro, verifique a sintaxe no Validador de Schema.org. Depois, confirme os requisitos de recursos de pesquisa no teste do Google. Por fim, leia a página como uma pessoa e compare cada campo importante com o conteúdo publicado.

O teste oficial de resultados avançados do Google é útil, mas não deve ser tratado como um selo de ranqueamento. Uma página pode passar no teste e ainda não aparecer em um resultado aprimorado, porque o Google avalia qualidade, relevância, indexação e elegibilidade separadamente.

No Search Console, observe a inspeção de URL, o status de indexação e os relatórios de melhorias quando disponíveis. Procure sinais como página excluída, canônica escolhida pelo Google diferente da declarada ou conteúdo bloqueado para rastreamento.

Para a camada de IA, faça testes manuais com perguntas específicas, sem esperar uma resposta idêntica em todos os motores. Pergunte, por exemplo, “qual dentista atende implante dentário em [bairro]?” ou “qual é o preço e a disponibilidade do [produto]?”. Registre se a informação aparece, se está correta e se a fonte é atribuída à sua página.

Uma citação não é uma métrica binária perfeita. A IA pode usar o conteúdo sem mostrar um link, pode citar a marca sem escolher a URL certa ou pode responder com fontes diferentes conforme a consulta, localização e data. Por isso, combine testes de resposta com impressões do Search Console e eventos do Analytics.

Se você já recebe tráfego orgânico, use o Google Search Console para encontrar consultas que podem gerar mais citações pelo Gemini. A melhor página para corrigir primeiro costuma ser aquela que já demonstra demanda, mas responde de forma incompleta ou ambígua.

Repita o roteiro semanalmente em uma página diferente. Em quatro semanas, você terá revisado quatro URLs prioritárias sem transformar a tarefa em um projeto técnico interminável.

Antes de encerrar a sessão, abra a URL em uma janela anônima e confirme que a página carrega sem login. Veja se o título, a resposta principal, o contato e a chamada para ação estão claros nos primeiros blocos de conteúdo.

Depois, procure o JSON-LD no código-fonte ou use uma extensão de inspeção. Confirme se existe apenas uma marcação principal para a entidade central e se o campo @id, a URL e a imagem apontam para a página correta. Se você não entende um campo, não precisa preenchê-lo só porque ele aparece em um modelo.

Confira quatro correspondências: nome no texto e no código, preço no texto e no código, disponibilidade no texto e no código, endereço no texto e no código. Em artigos, troque preço e estoque por autor, data de publicação, data de atualização e organização responsável.

Valide a página em uma ferramenta de Schema.org e no teste de resultados avançados. Um erro vermelho deve ser corrigido antes da publicação; um aviso amarelo precisa ser avaliado, mas nem sempre exige adicionar informação que não faz sentido para seu negócio.

Por último, registre uma hipótese simples: “corrigi o horário da loja para reduzir informações desatualizadas” ou “adicionei Product à página do SKU porque o preço já estava visível”. Depois acompanhe indexação, impressões, cliques e consultas por pelo menos duas a quatro semanas.

Se os dados estiverem corretos e a página ainda não for citada, não conclua que o Schema falhou. Talvez falte uma resposta direta, uma fonte de confiança, links internos, conteúdo suficiente ou uma página mais alinhada à pergunta que os clientes fazem. Dados estruturados são a legenda da página, não o filme inteiro.