Serviços e produtos de suporte e manutenção para WordPress
O WordPress, uma plataforma de gestão de conteúdo, está no mercado há mais de uma década com um modelo open source bem sucedido que o sustenta.
JSON-LD no WordPress é a declaração dos seus dados estruturados em um bloco JSON isolado dentro do HTML, seguindo o vocabulário do Schema.org, sem depender da marcação visual do tema.
Schema não é plugin. Schema é declaração de identidade.
E a maioria dos sites WordPress está declarando três coisas diferentes sobre si mesma na mesma página: uma vinda do plugin de SEO, uma do tema, outra de um plugin antigo que ninguém lembra por que instalou.
Quando a máquina encontra contradição no seu JSON-LD, ela não escolhe a versão mais bonita. Ela desconfia do conjunto.
Aqui a gente coloca a mão no código: Camada 2 do framework de GEO Técnico.
A cena que o nosso time mais encontra em auditoria
Site WordPress grande, empresa de Educação ou Fintech, time de marketing com cinco ou seis editores publicando por semana.
Alguém pergunta: “a gente tem dados estruturados?”. A resposta é sempre a mesma: “tem, o plugin de SEO cuida disso”.
Então você joga a URL no validador e aparecem quatro blocos de JSON-LD. Um Organization do plugin de SEO. Um WebSite do mesmo plugin. Um Article gerado pelo tema, com autor diferente. E um BreadcrumbList órfão de um plugin desativado pela metade.
Nenhum conversa com o outro. Nenhum tem @id. O name da organização muda de página para página.
Primeiro sintoma: schema existe, mas ninguém é dono dele.
O segundo sintoma é político, e dói mais. O marketing quer publicar. Para mexer em schema, precisa de dev. O dev está na fila de outro projeto. O time faz o que dá: instala mais um plugin de schema.
A pilha cresce. Camada sobre camada, cada uma escrita por uma pessoa diferente ao longo de anos, ninguém removendo nada, porque remover dá medo.
Schema quebrado quase nunca é falta de conhecimento técnico. É falta de dono e de fonte única de verdade.
Tem um terceiro sintoma, mais silencioso: o schema está tecnicamente válido, passa no validador, sem erro nenhum, e mesmo assim não diz nada útil. Um Organization com nome e logo, ponto. Sem sameAs, sem @id, sem ligação com autor.
Validação passou. Identidade continua vaga. São coisas diferentes.
Por que JSON-LD e não microdata ou RDFa
Existem três sintaxes possíveis para dados estruturados: microdata, RDFa e JSON-LD. Na prática, trabalhe com JSON-LD.
O motivo é operacional, não ideológico. Microdata e RDFa vivem grudados no HTML: para mudar a marcação você mexe no template, e no WordPress isso significa mexer no tema.
JSON-LD vive em um bloco isolado no <head> ou no rodapé. Você altera a declaração sem tocar na renderização.
Para um time que tem gargalo entre marketing e TI, essa é a diferença entre uma tarefa de meia hora e uma entrada na fila de sprint. A documentação do Google Search Central também aponta JSON-LD como o formato recomendado, o que reduz a discussão interna sobre qual caminho seguir.
Sintaxe | Onde a marcação mora | Custo de alterar |
|---|---|---|
Microdata | Atributos no HTML do template do tema | Ticket para dev front-end, deploy de tema |
RDFa | Atributos no HTML do template do tema | Ticket para dev front-end, deploy de tema |
JSON-LD | Bloco script isolado, gerado em PHP por plugin ou mu-plugin | Alteração em um único arquivo, sem tocar no layout |
Os três conceitos que separam schema decorativo de schema que funciona
@id: nome próprio para cada nó
@id é uma URI única que identifica um nó do seu grafo. Sem ele, cada bloco de Schema.org que você publica é um objeto anônimo, descartável, que morre no fim da página.
Pensa assim: sem @id, você está dizendo “nesta página existe uma organização chamada Apiki”. Com @id, você está dizendo “esta página pertence àquela organização, aquela mesma, a de sempre”.
Sem @id você não tem um grafo de entidades. Você tem um monte de cartão de visita solto, um por página.
@graph: uma fonte de verdade por página
Em vez de cuspir quatro blocos de JSON-LD independentes, você emite um único bloco com um array de nós conectados entre si por referência de @id.
Organização, site, página, artigo, autor, breadcrumb. Tudo em um objeto, tudo se apontando.
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "Organization",
"@id": "https://seudominio.com.br/#organization",
"name": "Sua Empresa",
"url": "https://seudominio.com.br/",
"logo": "https://seudominio.com.br/logo.png",
"sameAs": ["https://www.linkedin.com/company/sua-empresa"]
},
{
"@type": "WebSite",
"@id": "https://seudominio.com.br/#website",
"url": "https://seudominio.com.br/",
"publisher": { "@id": "https://seudominio.com.br/#organization" }
},
{
"@type": "WebPage",
"@id": "https://seudominio.com.br/artigo/#webpage",
"isPartOf": { "@id": "https://seudominio.com.br/#website" }
},
{
"@type": "Article",
"@id": "https://seudominio.com.br/artigo/#article",
"isPartOf": { "@id": "https://seudominio.com.br/artigo/#webpage" },
"author": { "@id": "https://seudominio.com.br/autor/nome/#person" },
"publisher": { "@id": "https://seudominio.com.br/#organization" }
},
{
"@type": "Person",
"@id": "https://seudominio.com.br/autor/nome/#person",
"name": "Nome Real",
"jobTitle": "Coordenador de Conteúdo",
"worksFor": { "@id": "https://seudominio.com.br/#organization" },
"sameAs": ["https://www.linkedin.com/in/nome"]
}
]
}sameAs: o documento de identidade da entidade
sameAs é o campo onde você lista os perfis oficiais da entidade em outros lugares: LinkedIn, GitHub, página institucional, base de conhecimento pública.
É o que permite reconciliar “esta organização aqui” com “aquela organização que eu já vi lá fora”. O vocabulário completo está no próprio Schema.org.
Schema sem sameAs é identidade sem documento.
As quatro perguntas que toda página bem declarada responde
Esse é o modelo mental que eu quero que você leve para dentro do seu WordPress, nessa ordem:
Que site é este? Nó WebSite com @id fixo, ligado ao publisher.
Quem publica? Nó Organization com @id fixo, name padronizado, url, logo e sameAs com os perfis oficiais.
Que página é esta? Nó WebPage ligado ao WebSite por isPartOf e ao BreadcrumbList real da URL.
Quem escreveu e sobre o quê? Nó Article ligado a um nó Person com @id próprio, e o Person ligado à organização por worksFor.
Quatro perguntas, quatro nós, um @graph. Isso é noventa por cento do trabalho de Camada 2 em conteúdo editorial.
Não é volume de marcação. É coerência de marcação. Um grafo pequeno e consistente vale mais que dez tipos declarados que se contradizem.
Cinco movimentos para implementar JSON-LD no WordPress
Movimento 1: inventário do que já sai do site
Antes de escrever uma linha, você precisa saber o que o seu site já declara.
Abra uma página de artigo, uma de serviço e a home. Rode no Schema Markup Validator e no teste de resultados enriquecidos do Google. Conte quantos blocos de JSON-LD aparecem e anote quem gera cada um.
No WordPress os suspeitos são sempre os mesmos: plugin de SEO, tema comprado em marketplace, plugin de FAQ, plugin de review, plugin de eventos e algum snippet colado no functions.php por um freelancer em 2019.
Movimento 2: escolher a fonte de verdade
Uma só. Ou o plugin de SEO gera o grafo inteiro e você desliga o resto, ou você assume o controle e desliga o do plugin.
Plugin de SEO maduro expõe filtro em PHP para alterar ou remover nós do grafo. Isso é preferível a duplicar, porque duplicar é o que gera contradição.
Se o schema vem do tema, isso é dívida técnica: trocar de tema apaga a sua identidade. Tire de lá e coloque em plugin próprio ou em mu-plugin.
Movimento 3: travar a organização
Um nó Organization com @id fixo, no padrão https://seudominio.com.br/#organization.
O name precisa ser idêntico em todo lugar: rodapé, LinkedIn, schema, título institucional. Sem razão social em um canto e nome fantasia em outro.
Esse nó é declarado uma vez e referenciado por todas as páginas. Não replique o objeto inteiro em cada template.
Movimento 4: pessoas de verdade, não rótulos
Aqui está o problema mais comum em site com muitos editores. O WordPress te dá o WP_User de graça, mas o autor virou “admin” ou “Equipe de Conteúdo”.
Isso não é entidade. É rótulo.
O trabalho é criar nó Person com @id próprio por autor real, ligar ao Organization via worksFor, popular jobTitle e sameAs com o LinkedIn do autor, e garantir que a página de autor exista, seja indexável e traga credencial real.
Campo customizado resolve isso sem virar projeto de seis semanas.
Movimento 5: conectar tudo
Cada Article aponta para o Person via author e para o Organization via publisher. Cada WebPage aponta para o WebSite via isPartOf.
E o BreadcrumbList tem que ser coerente com a hierarquia real de URLs, não com o menu que o time de design desenhou.
Três armadilhas que a gente vê toda semana
Schema que mente. Declarar FAQPage em uma página sem FAQ visível para o usuário, ou AggregateRating sem avaliação real, é risco e não atalho: a marcação precisa refletir o que está renderizado.
Schema injetado por JavaScript. Se o seu JSON-LD só existe depois que o JavaScript roda, você criou uma dependência a mais para ser lido. Emita no HTML servido, direto do PHP, porque é mais barato e mais previsível.
Camada de cache desalinhada. Site grande roda page cache e edge agressivos. Já vimos grafo correto em staging e grafo velho servido pelo edge em produção por semanas, então valide a versão em cache, não só a versão local.
É como uma casa com três placas de número diferentes na fachada. O carteiro não escolhe a mais bonita: ele desconfia do endereço inteiro.
Perguntas frequentes sobre JSON-LD no WordPress
Preciso de plugin para gerar JSON-LD no WordPress?
Não necessariamente. Um plugin de SEO maduro já emite um grafo razoável e expõe filtros em PHP para você ajustar nós, o que costuma ser o caminho mais rápido. Se o seu grafo exige nós que o plugin não cobre, gere o JSON-LD em um plugin próprio ou mu-plugin, nunca no tema.
Ter mais tipos de schema declarados melhora o resultado?
Não. Antes de declarar tipo novo, prove que o grafo básico está consistente: um Organization com @id fixo, uma Person por autor real e nenhum bloco duplicado. Grafo pequeno e coerente vale mais que dez tipos que se contradizem.
JSON-LD garante citação em respostas de IA?
Não, e nenhum fornecedor sério vai prometer isso. Schema bem estruturado aumenta a chance de a máquina reconhecer, nomear e atribuir crédito ao seu conteúdo, o que é diferente de garantia de aparecer em toda resposta gerada.
Conclusão
JSON-LD no WordPress não é um campo a preencher. É a resposta que o seu site dá quando a máquina pergunta quem ele é, quem publica e quem escreveu.
E a resposta só funciona se for uma. Fonte única de verdade, @id fixo, @graph conectado, sameAs populado, nenhum bloco duplicado.
Medimos. Testamos. Validamos. Escalamos. Nessa ordem, e sempre depois do inventário.
Se você quer ver como isso se encaixa nas outras camadas, vale passar pelo nosso guia de GEO Técnico e pelo checklist de visibilidade para IA no WordPress. Se preferir olhar o seu grafo com o nosso time, é só chamar: WordPress que aparece na IA? Fale conosco.
Me conta: quantos blocos de JSON-LD apareceram quando você jogou a sua home no validador?
