Formato baseado em JSON para expressar dados estruturados vinculados, geralmente incorporado em um elemento script, para que a página descreva entidades e relações sem alterar o HTML visível.
A decisão e seus limites
JSON-LD é uma forma de serializar dados vinculados em JSON. Em páginas web, ele costuma ser colocado em um elemento script e usado com o vocabulário Schema.org para descrever as mesmas entidades que o visitante vê: um artigo, produto, organização, breadcrumb ou evento. É um formato de representação, não uma promessa de resultado avançado. O grafo precisa ser sintaticamente válido e concordar com os fatos visíveis e atuais da página.
O que inspecionar
Colete o HTML renderizado, em vez de presumir que o template de origem sobreviveu ao deploy. Analise o JSON-LD, identifique cada nó e seus identificadores, e compare as propriedades importantes com a página visível. Confira se as URLs respondem, se as referências apontam para as entidades pretendidas e se valores como datas, preços, disponibilidade, autor e imagem não estão desatualizados. Avalie os avisos do validador no contexto: uma mensagem do validador é um indício a investigar, não automaticamente um defeito.
Um caminho prático de implementação
Escolha o tipo Schema.org menor e adequado, modele primeiro a entidade principal e adicione entidades vinculadas somente quando a página expuser os fatos delas. Gere os valores, quando possível, a partir da mesma fonte estruturada usada pelo template visível. Valide uma página renderizada representativa depois do lançamento e, em seguida, crie verificações de regressão para os templates que geram muitas páginas. Mantenha separadas as verificações de sitemap, canonical e robots da validação do JSON-LD.
Erros e limites de medição
O modo de falha é o que chamo de teatro do schema: adicionar vocabulário que a página não sustenta, na esperança de forçar um recurso de busca. Propriedades ocultas, inventadas ou contraditórias criam risco de manutenção e podem tornar o grafo menos confiável. Valido os dados estruturados contra a página visível primeiro e só depois inspeciono o grafo. Corrijo erros reais de vocabulário ou de referência, e não apenas o que silencia o verificador.
Exemplo prático de implementação. Em um artigo editorial, comece pelo registro visível: título, autor, data de publicação, imagem principal, URL canônica e identidade do publicador. Modele esse artigo em JSON-LD a partir dos mesmos campos de conteúdo que renderizam a página. Dê ao artigo um identificador estável e vincule o publicador e a imagem apenas quando essas entidades forem reais e resolvíveis. Se o autor, a data ou a imagem não aparecem na página visível, não os invente no grafo só para satisfazer um validador.
Critérios de verificação. Busque o HTML renderizado depois do deploy, extraia todos os scripts JSON-LD e analise cada grafo. Compare título, data, imagem, URL e autor com a página visível para as pessoas. Confirme que identificadores e URLs levam aos recursos pretendidos e que um artigo não descreve, por acidente, uma entidade de outro template. Execute o teste de dados estruturados relevante, mas classifique os resultados: um erro de análise, um desvio de vocabulário, uma recomendação opcional ausente e uma observação sobre elegibilidade para recurso de busca são coisas diferentes.
Erros comuns. Não cole um bloco de schema genérico em todas as páginas nem marque serviço, categoria e produto como a mesma entidade principal. Não use JSON-LD para esconder preços, notas, estoque, avaliações ou autores que o usuário não pode ver. Um teste de resultados avançados não consegue verificar canonical, robots, sitemap nem se o conteúdo é verdadeiro, por isso essas verificações também fazem parte da checagem de lançamento. O JSON-LD ajuda a descrever uma página; ele não compensa uma página inacessível ou pouco útil.