Plugins de schema são emissores: ferramentas que serializam em JSON-LD os dados que o seu WordPress já tem estruturados. Eles não descobrem nada sobre a sua empresa, apenas publicam o que encontram.
Faz um teste comigo agora, com o site aberto. Ctrl+U, busca por ld+json.
Conta quantos blocos aparecem.
Agora a segunda pergunta, que é a difícil: de onde veio o dado que está dentro deles?
A primeira pergunta todo mundo faz. A segunda quase ninguém faz, e é ela que decide o resultado. Sem dado estruturado por trás, você recebe sintaxe impecável descrevendo vazio.
Hoje vamos falar sobre o nosso GEO Técnico, entidade e schema. Hoje mais especificamente sobre como escolher a ferramenta.
O padrão se repete em empresas de grande porte, e quase sempre começa numa planilha.
Alguém montou um comparativo de plugins de schema. Colunas: preço, nota no repositório, integração com o plugin de SEO e, a estrela do documento, quantidade de tipos suportados.
Quarenta minutos de reunião para decidir qual linha ganha.
O que não está na planilha: uma coluna dizendo onde mora, hoje, o dado que essas ferramentas vão declarar.
Porque quando a gente abre o site, o cenário costuma ser este: a carga horária do curso está escrita no meio do parágrafo, a modalidade aparece só no título, e o nome do docente está na última linha do post, em texto corrido, sem perfil, sem URL, sem nada que ligue aquela pessoa a outra página do mundo.
Não existe plugin que transforme texto corrido em entidade. Ele pode adivinhar.
Adivinhação em escala não é marcação. É ruído com aparência de dado.
A líder de marketing digital precisa lançar a landing do próximo webinar com a marcação certa, sem abrir chamado e esperar a fila de desenvolvimento. Ela olha para o plugin como atalho, e é legítimo.
A liderança de operações olha para o mesmo plugin e vê inventário: mais um item para atualizar, mais uma superfície de conflito em site crítico, mais um fornecedor sem dono definido.
Os dois estão certos. O que está errado é o critério de decisão.
Some a isso o custo escondido: boa parte dessas ferramentas guarda a configuração em postmeta proprietária. Você não está escolhendo um plugin. Está escolhendo o tamanho da sua próxima migração.
Três camadas que viram uma só na cabeça do time, e não são.
Schema.org é o vocabulário: os tipos e as propriedades. JSON-LD é o formato de serialização, um padrão de dados ligados especificado pelo W3C. O plugin é apenas o emissor.
Você não compra vocabulário. Você compra emissor.
E emissor bom não compensa dado ruim.
Daí a regra que orienta tudo o que vem depois: marcação estruturada é uma projeção do seu modelo de conteúdo. Se o valor não existe num campo consultável, ele não vai existir no JSON-LD de forma confiável.
Teste mental rápido: consigo escrever uma consulta que retorna essa informação para qualquer post desse tipo?
Se a resposta é não, o plugin também não consegue. Ele vai inferir, ou vai pedir digitação manual. Os dois caminhos quebram em escala.
A ferramenta precisa mapear propriedade a partir de estrutura que já existe: post-type, taxonomia, campo customizado, perfil de autor, dado de matrícula, dado de produto.
Propriedade sem campo de origem vira campo digitado em cada publicação. E campo digitado em cada publicação é dívida operacional com juros.
Schema em site de empresa raramente vem de um lugar só. Vem do plugin de SEO, do tema e de alguma instalação antiga que ninguém lembra de ter feito.
A ferramenta candidata precisa permitir centralizar, não só somar mais um script.
Centralizar não é estética. É o que torna possível ter @id estável e sameAs apontando para os mesmos perfis em toda a operação.
Sem emissor único, você não tem grafo. Tem blocos independentes que se contradizem entre templates.
Se os dados vivem no seu modelo de conteúdo, trocar de emissor é trocar de emissor.
Se vivem numa tabela proprietária da ferramenta, desinstalar é perder o markup de todas as URLs de uma vez.
Em portal com dezenas de milhares de páginas, essa diferença é a diferença entre um deploy e um projeto de trimestre.
Esse ponto quase nunca entra na planilha e devia entrar primeiro.
O JSON-LD precisa sair no HTML servido, dentro da resposta que a sua camada de cache entrega. Marcação injetada por JavaScript no cliente é aposta: crawler de IA nem sempre renderiza, e nem sempre volta.
Do outro lado, ferramenta que monta o grafo em tempo de requisição, com uma pilha de consultas ao MySQL por página, aparece no TTFB de página não cacheada. O web.dev descreve o TTFB como o tempo até o primeiro byte da resposta, e ele é justamente onde esse tipo de custo se esconde.
Você não vai trocar Core Web Vitals por marcação. Não precisa escolher, mas precisa medir.
Agora a parte que corta ruído.
Contagem de tipos suportados. Se a sua operação declara cinco tipos, suportar oitocentos não muda absolutamente nada no resultado.
A sigla “AI” no nome do plugin. Não é critério técnico, é posicionamento de página de vendas.
Preview bonito no painel. O que vale é o que sai no código servido ao crawler, não o que aparece na tela de configuração.
Promessa de citação em resposta de IA. Ninguém controla isso. O que a gente controla é a clareza e a consistência do que o site declara.
É isso que a gente chama de GEO com base técnica: menos catálogo de recurso, mais coerência de dado.
Os dois primeiros acontecem antes de escolher ferramenta.
Monte o mapa de duas colunas. À esquerda, o que a sua operação precisa declarar. À direita, onde esse dado mora hoje, com o nome exato do campo.
Feche a lacuna no modelo de conteúdo. Crie o campo, migre o valor que está no corpo do texto e transforme docente em perfil com URL pública e ligações externas verificáveis.
Faça a shortlist contra o mapa, não contra a feature list. Pegue três URLs reais de templates diferentes e tente mapeá-las na ferramenta candidata, em ambiente de teste, sem demo guiada.
Rode piloto em um template, medindo os dois lados. Saída validada no HTML servido, custo medido em TTFB antes e depois, taxa de acerto de cache e consultas por requisição.
Consolide o emissor. Desligue o schema do tema e dos plugins duplicados, depois rode o teste de contradição: dois nomes de organização, dois autores para o mesmo artigo, @id que não resolve.
Estabeleça governança e rollout. Staging fiel, snapshot antes, amostra de URLs por template validada depois e acompanhamento do relatório de aprimoramentos no Search Console nas semanas seguintes.
Sobre o passo 1, um exemplo de portal de Educação. Curso de pós-graduação: nome, descrição, modalidade, instituição provedora, corpo docente.
Você vai descobrir que nome e descrição têm campo, modalidade está em taxonomia pela metade, e docente é texto solto.
A coluna da direita vazia é a sua lista de tarefas. Não é lista de compras de plugin.
Todo real investido em estruturar campo rende em qualquer emissor. Todo real investido em emissor sobre dado bagunçado rende em nada.
No passo 3, o número que importa é um só: quantas propriedades do seu mapa a ferramenta puxa de campo existente, sem digitação por post. Esse número é a nota. O resto do comparativo é decoração.
No passo 4, valide o HTML servido com curl na URL, não com o inspetor do navegador. Você quer ver o que sai atrás do cache, não o que o navegador montou.
E guarde esta: contradição custa mais caro que ausência. Máquina que encontra afirmações concorrentes não escolhe a mais bonita.
Critério | Como testar de verdade | Evidência que vale |
|---|---|---|
Cobertura de propriedades | Mapear 3 URLs reais de templates diferentes em ambiente de teste | Número de propriedades puxadas de campo existente, sem digitação por post |
Emissor único | Contar blocos ld+json no Ctrl+U antes e depois de desligar tema e duplicados | Um grafo consolidado, com @id que resolve e sameAs idêntico entre templates |
Custo de execução | TTFB e consultas por requisição no mesmo template, antes e depois do piloto | JSON-LD presente na resposta servida via curl, sem degradar o tempo de resposta |
Custo de saída | Desinstalar em staging e recarregar as URLs do piloto | Markup que sobrevive porque os valores vivem em campos do seu modelo de conteúdo |
Um segundo exemplo, para sair de Educação. Operação de Fintech com central de ajuda.
O time quer marcar FAQ. A ferramenta oferece geração automática a partir de heurística no texto. Resultado: marcação válida, e nenhuma pergunta visível na página para o usuário.
Isso é markup descolado do conteúdo servido.
Marcação descreve o que está na página. Se não está na página, não declara.
O caminho é o contrário: estruturar a seção de perguntas de verdade no template, e deixar a marcação sair derivada dela. Na nossa experiência com operações enterprise, é sempre esse o item que volta como aviso no Search Console meses depois.
Nem sempre. Se o plugin de SEO já cobre os tipos que a sua operação declara e permite conectar propriedades a campos customizados, ele pode ser o emissor único. Adicionar uma segunda ferramenta sem desligar a primeira é o caminho mais rápido para grafos contraditórios na mesma URL.
Preferencialmente um, com as entidades conectadas por @id dentro do mesmo grafo. Vários blocos não são erro de sintaxe, mas dificultam manter consistência de identificadores entre templates e costumam indicar que três fontes diferentes estão emitindo em paralelo sem dono definido.
Não. Nenhuma ferramenta controla o que um modelo cita. O que dado estruturado bem servido faz é reduzir ambiguidade sobre quem você é, o que oferece e quem assina o conteúdo, aumentando a chance de a máquina ler a sua entidade sem margem de interpretação.
Não vale. Tipo declarado sem dado real por trás gera propriedade vazia ou inferida, e inferência em escala vira ruído. Comece pelos tipos que descrevem o núcleo do negócio e só expanda quando existir campo consultável alimentando cada propriedade nova.
Resumo direto, para levar para a próxima reunião de ferramenta.
Vocabulário é Schema.org. Formato é JSON-LD. Plugin é emissor. A qualidade está no dado que alimenta os três.
Quatro perguntas de avaliação: fonte de cada propriedade, quem assina o output, o que sobra na desinstalação e custo de execução no TTFB.
O que não entra na decisão: contagem de tipos, “AI” no nome, preview no painel e promessa de citação.
Se a coluna “onde mora o dado” estiver vazia, nenhum plugin da sua planilha resolve o problema. Ele só automatiza a lacuna.
A gente organizou esse raciocínio no nosso checklist de visibilidade para IA, com o mapa de origem de dado e as perguntas de avaliação na ordem certa. Baixe o material no link da descrição e rode o mapa antes de abrir qualquer comparativo.
E se o assunto é WordPress que aparece na IA, fala com a gente. Esse diagnóstico é parte do que o nosso time roda dentro do WP Care, junto com a operação de manutenção e publicação do dia a dia.
Me conta: quando você rodou o Ctrl+U aí no seu site, quantos blocos apareceram, e quantos deles você conseguiu explicar de onde vieram?
