JSON-LD vai dentro de uma tag <script type="application/ld+json"> no <head> da página. Você escreve um objeto JSON descrevendo quem é você ou o que a página contém, e os motores de busca e crawlers de IA leem esse dado diretamente, sem precisar interpretar o layout visual ou o texto corrido. Cada tipo de página tem seu bloco correspondente: Organization na home, Article nos posts, FAQPage onde há perguntas e respostas.
A vantagem prática é a separação entre dado e apresentação. O JSON-LD fica num script isolado, fora do HTML que define a aparência. Quando o design muda, os dados estruturados não precisam mudar. Quando os dados mudam, como o nome da empresa, um novo telefone ou uma FAQ atualizada, você edita um bloco de texto, não o template inteiro da página.
Por que JSON-LD é o formato preferido para dados estruturados?
Existem três formas de adicionar dados estruturados a uma página: JSON-LD, Microdata e RDFa. Os três são tecnicamente válidos e reconhecidos pelo Google. A diferença está na manutenção, na legibilidade e no que acontece quando o site evolui.
| Formato | Como funciona | Manutenção | Recomendação do Google |
|---|---|---|---|
| JSON-LD | Script separado no <head> | Arquivo isolado, fácil de editar | Preferido |
| Microdata | Atributos itemscope/itemprop no HTML | Acoplado ao markup visual | Suportado |
| RDFa | Atributos no HTML com vocabulário RDF | Verboso, difícil de debugar | Suportado |
Com Microdata e RDFa, o dado semântico fica entrelaçado com o HTML de apresentação. Mudar o layout pode quebrar os dados; mudar os dados exige mexer no template. Uma refatoração de front-end pode derrubar a marcação sem nenhum alerta. Com JSON-LD, você tem um bloco separado que o rastreador lê de forma direta, sem depender de como a página foi construída visualmente.
Para crawlers de IA, essa separação importa ainda mais. Um modelo que faz grounding no conteúdo da sua página consegue extrair os dados do JSON-LD de forma inequívoca. O dado está ali, explícito, legível por máquina, sem inferências sobre divs ou classes CSS.
Se você ainda não decidiu quais tipos de schema fazem sentido para o seu site, o guia quais tipos de schema usar cobre essa decisão antes de você escrever uma linha de código. Para o contexto geral de por que a camada técnica importa para GEO, o hub de GEO técnico reúne os recursos em ordem.
Onde o script JSON-LD deve ficar no HTML?
A resposta oficial do Google é: dentro do <head>. O motor de busca também processa scripts no <body>, mas o <head> é a posição mais segura e mais adotada na prática.
O motivo é simples: o <head> é processado antes da renderização visual. O dado está disponível para crawlers sem depender de JavaScript de terceiros, lazy loading ou qualquer lógica de carregamento do corpo da página. Se algum script externo falhar e bloquear a renderização do body, o JSON-LD no head já foi lido.
Em CMS como WordPress, você pode usar o Yoast SEO ou o Rank Math para gerar os blocos automaticamente por tipo de página, sem tocar em código. Em frameworks como Next.js ou Nuxt, você injeta o script programaticamente por tipo de rota (home, artigo, produto, FAQ) usando o componente de <Head> ou similar. Em sites estáticos, vai direto no template HTML de cada tipo de página.
Um ponto que muita implementação erra: cada página pode (e muitas vezes deve) ter mais de um bloco JSON-LD. A home pode carregar Organization + WebSite. Um artigo pode ter Article + BreadcrumbList. Uma página de produto pode combinar Product + FAQPage. Não existe limite de blocos por página; cada um vai numa tag <script> separada.
Passo 1: Schema Organization na home
O schema Organization declara quem é a empresa por trás do site: nome oficial, URL, logo e os perfis verificados em outras plataformas. É o bloco de identidade da marca, e o lugar dele é a página inicial (e, opcionalmente, as páginas institucionais como "Sobre" e "Contato"). Não coloque Organization em cada post do blog: o tipo para páginas de conteúdo é Article.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "Nome Oficial da Empresa",
"url": "https://www.seusite.com.br",
"logo": {
"@type": "ImageObject",
"url": "https://www.seusite.com.br/images/logo.png",
"width": 300,
"height": 80
},
"description": "Descrição curta e factual do que a empresa faz e para quem atende.",
"sameAs": [
"https://www.linkedin.com/company/sua-empresa",
"https://www.instagram.com/sua_empresa",
"https://www.facebook.com/sua.empresa",
"https://pt.wikipedia.org/wiki/Nome_da_Empresa"
],
"contactPoint": {
"@type": "ContactPoint",
"contactType": "customer service",
"availableLanguage": "Portuguese",
"areaServed": "BR"
}
}
</script>
O campo sameAs é onde você lista os perfis oficiais da marca em outras plataformas. Ele ajuda os modelos de linguagem a conectar menções da sua marca em contextos diferentes, formando uma entidade coesa. Se a empresa tiver uma página na Wikipedia ou no Wikidata, inclua-a no sameAs: esse link tem peso desproporcional para o reconhecimento da marca por IAs generativas, porque são fontes que os modelos tratam como autoritativas.
O campo logo pede URLs absolutas (com https://). Evite URLs relativas. As dimensões são opcionais, mas ajudam na exibição correta em rich results do Google.
A description deve ser factual e concisa: setor, o que a empresa faz, para quem. Sem adjetivos de marketing. Essa frase é o que separa, por exemplo, uma "Aurora Consultoria" que atua em finanças de outra que atua em tecnologia, quando o modelo tenta desambiguar a entidade.
Para empresas locais, o tipo LocalBusiness (subtipo de Organization) permite campos adicionais como endereço físico, horário de funcionamento e telefone. O artigo Schema Organization passo a passo detalha essa variação campo a campo e explica o que cada propriedade sinaliza para as IAs.
Passo 2: Schema Article nos artigos do blog
Cada artigo publicado deve ter um schema Article (ou BlogPosting, subtipo mais específico para posts de blog). Os campos mais relevantes são o título exato, as datas de publicação e modificação, e o autor com URL de perfil.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "Título do artigo, idêntico ao que aparece na página",
"datePublished": "2026-07-02T08:00:00-03:00",
"dateModified": "2026-07-02T09:30:00-03:00",
"author": {
"@type": "Person",
"name": "Nome do Autor",
"url": "https://www.seusite.com.br/autores/nome-do-autor"
},
"publisher": {
"@type": "Organization",
"name": "Nome da Empresa",
"logo": {
"@type": "ImageObject",
"url": "https://www.seusite.com.br/images/logo.png"
}
},
"description": "Resumo do artigo em uma ou duas frases diretas.",
"mainEntityOfPage": {
"@type": "WebPage",
"@id": "https://www.seusite.com.br/blog/titulo-do-artigo"
}
}
</script>
O campo dateModified é frequentemente esquecido, mas tem relevância prática: sinaliza para crawlers de IA que o conteúdo foi atualizado. Para conteúdo que as IAs citam, uma data de modificação recente indica atualidade sem exigir a reescrita do artigo inteiro. Artigos desatualizados tecnicamente tendem a perder relevância progressivamente nas fontes consultadas pelos modelos.
O campo author com @type: Person e uma URL de perfil é preferível a usar a organização diretamente. Isso ajuda os modelos a atribuir expertise a um indivíduo específico, o que fortalece o sinal de autoridade do conteúdo. Uma URL de página de autor válida e consistente também reforça a credibilidade da fonte para fins de E-E-A-T.
O mainEntityOfPage com @id apontando para a URL canônica fecha a referência: o schema descreve essa página, não uma cópia redistribuída em outro domínio.
Passo 3: Schema FAQPage para perguntas e respostas
O FAQPage é um dos schemas com maior impacto direto para GEO. Quando você estrutura pares de pergunta e resposta em JSON-LD, entrega o dado no formato que os modelos de linguagem consomem para gerar respostas diretas em chatbots. A pergunta delimita o escopo; a resposta é a unidade que o modelo extrai.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "Qual o prazo de entrega para todo o Brasil?",
"acceptedAnswer": {
"@type": "Answer",
"text": "O prazo de entrega é de 3 a 7 dias úteis para todo o Brasil, contados a partir da confirmação do pagamento. Pedidos para a capital saem em até 3 dias úteis."
}
},
{
"@type": "Question",
"name": "Como funciona a política de trocas?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Trocas podem ser solicitadas em até 7 dias corridos após o recebimento, com o produto sem uso e na embalagem original. O frete da primeira troca é por nossa conta."
}
}
]
}
</script>
As respostas dentro de acceptedAnswer.text precisam ser autocontidas: quem lê apenas a resposta, sem o contexto da página, tem que entender completamente. Uma resposta que depende de "como vimos acima" ou de um elemento visual da página não serve para extração por IA. Escreva as perguntas e respostas na página primeiro; o FAQPage espelha o que já está visível, não cria um paralelo oculto.
O artigo FAQPage no código detalha as boas práticas de escrita para as respostas e as armadilhas mais comuns de validação, incluindo o erro de marcar conteúdo que não aparece para o usuário.
Por que os crawlers de IA leem esses dados?
Os modelos de linguagem processam o conteúdo da web durante o treinamento e, em alguns casos, em tempo real via busca. Em ambos os cenários, dados estruturados funcionam como metadados legíveis por máquina que complementam o texto da página.
Quando um modelo encontra um Organization com sameAs apontando para perfis verificados, ele tem um sinal para associar menções da marca em contextos diferentes. Quando encontra um Article com dateModified recente, tende a tratar esse conteúdo como fonte atual. Quando encontra um FAQPage bem preenchido, tem os pares de pergunta e resposta prontos para uso numa resposta de chatbot.
Isso não garante citação. O que muda é a probabilidade de o seu conteúdo ser legível, atribuível e aproveitável quando o modelo está construindo uma resposta. Um site sem nenhum schema força o modelo a inferir identidade, setor e relevância a partir do texto corrido, e inferência produz erros. O artigo sobre dados estruturados explora por que essa camada técnica faz parte da estratégia de GEO, não apenas de SEO clássico.
Como validar o JSON-LD antes de publicar?
Duas ferramentas gratuitas cobrem os casos de uso principais, e as duas são necessárias porque verificam coisas diferentes.
O Rich Results Test (search.google.com/test/rich-results) verifica se o schema qualifica para rich results no Google. Mostra erros que bloqueiam a ativação e avisos para campos recomendados ausentes. Útil para confirmar Organization, Article e FAQPage antes de publicar. Cole a URL da página ou o código diretamente.
O Validador do schema.org (validator.schema.org) valida a sintaxe JSON e as propriedades segundo a especificação oficial. Mais técnico, mas necessário para pegar erros de estrutura que o teste do Google pode não reportar, como um @type mal escrito ou uma propriedade colocada no nível errado do JSON.
| Erro comum | O que significa | Como corrigir |
|---|---|---|
| Campo obrigatório ausente | Schema incompleto para rich results | Adicione a propriedade indicada pelo validador |
| URL inválida | Formato relativo ou sem https:// | Use URLs absolutas com protocolo |
@type desconhecido | Nome digitado errado ou com espaço | Confira o nome exato em schema.org |
| JSON inválido | Vírgula extra ou aspas não fechadas | Cole o JSON em jsonlint.com para localizar o erro |
| Data em formato errado | ISO 8601 não seguido | Use YYYY-MM-DDTHH:MM:SS±HH:MM |
O fluxo recomendado: valide no schema.org Validator primeiro (pega erros de sintaxe e de estrutura) e depois no Rich Results Test (confirma elegibilidade para ativação de rich results). Erros bloqueiam; avisos indicam campos recomendados ausentes. Corrija os erros antes de considerar o trabalho pronto.
Depois de publicar, o Google pode levar alguns dias para recrawlear a página. O Search Console tem um relatório de "Dados estruturados" que mostra quais schemas foram detectados em produção e se há erros ativos. Acompanhe esse relatório nas primeiras semanas após implementar cada tipo novo de schema.
Para uma visão completa do que auditar antes de se preocupar com JSON-LD especificamente, o guia de auditar seu site para GEO coloca o diagnóstico em ordem de prioridade, incluindo o que olhar no robots.txt, no sitemap e na estrutura de headings.
JSON-LD implementado corretamente é o começo, não o destino. O próximo passo é verificar se os dados estão chegando legíveis para as IAs que rastreiam o seu site. A auditoria de site da Promptis analisa automaticamente se os dados estruturados estão bem formados, se os tipos certos estão nas páginas certas e onde há lacunas que reduzem a legibilidade para modelos de linguagem. Você também consegue comparar como o seu site aparece para as IAs em relação aos concorrentes diretos. A primeira análise é gratuita, sem precisar de cartão de crédito.
