Plugins de schema: o que importa de verdade na escolha

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.

A planilha que decide errado

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.

E tem o atrito de sempre entre marketing e TI

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.

Vocabulário, formato e emissor não são a mesma coisa

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.

As quatro perguntas que importam na avaliação

1. Qual é a fonte de cada propriedade?

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.

2. Quem assina o output da página?

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.

3. O que sobra quando eu desinstalar?

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.

4. Quanto isso custa em execução?

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.

O que não importa na escolha de plugins de schema

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.

Seis passos para sair da planilha e virar trabalho de segunda-feira

Os dois primeiros acontecem antes de escolher ferramenta.

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.

6. 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 de planilha contra critério que decide

Quando a ferramenta inventa conteúdo que não está na página

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.

Perguntas frequentes sobre plugins de schema

Preciso de um plugin de schema se meu plugin de SEO já emite JSON-LD?

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.

Quantos blocos de JSON-LD uma página deveria ter?

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.

Marcação estruturada garante citação em respostas de IA?

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.

Vale marcar tipos que a minha operação não usa?

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.

Conclusão

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?