Dados estruturados para mecanismos de resposta: o que marcar de verdade

Marcação é apresentação, não enfeite

Existe uma imagem bastante difundida de que dados estruturados são um recurso de aparência: algo que se adiciona à página para que ela ganhe estrelinhas, perguntas expandidas ou um trecho mais rico no resultado da busca. Essa imagem não é falsa, mas é secundária. O que a marcação faz em primeiro lugar é mais elementar e mais importante: ela entrega à máquina uma frase de apresentação sobre você, escrita em uma linguagem que não depende de interpretação de layout.

Publicamos pesquisa editorial: não é consultoria e não garante resultado comercial. O texto descreve um enquadramento de mecanismo a partir da documentação pública do vocabulário schema e de observação de produto, não um método testado por nós. Onde citamos comportamento de sistemas de resposta, tratamos de direção, não de valor apurado. Nenhuma empresa é indicada aqui como fornecedora recomendada.

A consequência prática dessa mudança de enquadramento é que a pergunta certa deixa de ser "quantos tipos de marcação eu coloco" e passa a ser "o que eu consigo afirmar com segurança sobre esta página". Um site com cinco marcações honestas é mais legível do que um site com dezoito marcações otimistas. A máquina não premia quantidade de declarações; ela premia declarações que sobrevivem ao confronto com o texto visível.

Por que o JSON-LD resiste a reformas de template

Há mais de uma maneira de expressar marcação, e a escolha entre elas não é neutra. A forma que adotamos e que a literatura de mercado costuma apontar como mais robusta é o JSON-LD, um bloco de dados isolado que descreve a página sem estar fisicamente entrelaçado com as tags de conteúdo.

A vantagem é estrutural e não estética. Quando a marcação mora dentro da marcação de conteúdo, qualquer alteração de template ameaça a integridade semântica: alguém move um elemento, um atributo se perde, e a declaração passa a dizer algo que não era a intenção. Quando a marcação mora em um bloco próprio, a reforma do layout não toca nela, e o inverso também vale: ajustar o bloco não exige mexer na renderização. Para quem publica com frequência, essa separação é a diferença entre uma declaração que sobrevive dois anos e uma que quebra silenciosamente na próxima mudança de tema.

O segundo motivo é de leitura. Um bloco de dados é trivial de extrair, comparar e validar de forma automática, e é trivial de comparar com o texto visível por um processo que não precisa entender HTML. Para um fluxo que precisa decidir em fração de segundo qual é a entidade da página e qual é a entidade do autor, um objeto autocontido é um atalho. Isso não significa que as outras formas não funcionem; significa que o JSON-LD é a que menos depende da boa vontade de quem mexe no template depois.

A pilha mínima

Uma pilha mínima de marcação não precisa ser grande. Ela precisa ser coerente e cobrir quatro camadas: quem é a organização, o que é o site, onde a página está na hierarquia e que tipo de coisa esta página é.

A primeira camada é um nó Organization, único e canônico, com nome, nome legal, endereço do site, logotipo, canais de verificação externa, ponto de contato, endereço físico quando existir e os temas sobre os quais a organização declara conhecimento. A segunda é WebSite, que amarra o site à organização e declara a URL canônica. A terceira é BreadcrumbList, que diz onde a página está. A quarta é a camada de tipo de conteúdo: Article ou BlogPosting para texto editorial, FAQPage apenas onde houver perguntas e respostas visíveis, HowTo apenas onde houver um procedimento real executável pelo leitor.

O erro mais comum na montagem dessa pilha é tratar a quarta camada como decorativa. Marcar tudo como Article porque é mais fácil costuma gerar conflito com o que a página efetivamente é, e conflito é o que produz desconfiança. Também é comum marcar a primeira camada em cada página com valores ligeiramente diferentes, o que transforma uma entidade em várias e anula justamente o efeito que se queria obter.

Organization: um nó apenas, referido por identificador

A forma mais limpa de organizar a marcação é usar um grafo, o campo @graph, com um nó Organization declarado uma única vez e referido nas demais partes por meio de um identificador, o campo @id. Em vez de repetir o objeto completo em cada página, as outras declarações apontam para o mesmo identificador.

Isso resolve um problema que se acumula devagar. Quando cada template embute sua própria cópia da organização, uma divergência de um caractere no nome, ou um endereço desatualizado em uma seção, cria versões diferentes da mesma entidade. Para um sistema que tenta consolidar quem você é, duas descrições conflitantes valem menos do que uma, porque a consolidação passa a exigir uma decisão sobre qual delas acreditar. Com um único nó e referências por identificador, a consolidação é trivial.

O identificador também permite que a organização seja referida em contextos que não são a página inicial, sem duplicação. O nó de autor de um artigo pode apontar para uma pessoa; o nó de publicador aponta para a organização pelo mesmo identificador de sempre. O resultado é uma teia pequena e verificável, que é exatamente o que um processo de leitura automática precisa.

WebSite e BreadcrumbList: o mapa do lugar

WebSite é uma declaração curta e costuma ser tratada como burocracia, mas ela faz um trabalho específico: liga o domínio à organização e à URL canônica. É onde se resolve, de forma explícita, qual é a versão preferencial de uma página quando existem variações de endereço, parâmetros ou duplicatas históricas. Sem essa declaração, a decisão sobre qual endereço é o principal fica inteiramente a cargo de quem lê, e decisões deixadas a cargo do leitor são decididas de forma inconsistente.

BreadcrumbList é a declaração de posição. Ela diz que a página está dentro de uma seção, que a seção está dentro do site, e qual é o rótulo de cada nível. Para uma máquina, isso é informação de estrutura: permite saber que um texto é um item de uma série, e não uma página órfã. Para o leitor humano, a trilha visível também precisa existir, porque a regra de honestidade vale aqui também: declarar hierarquia que não aparece na navegação é uma afirmação que o texto não sustenta.

Vale uma ressalva de bom senso: hierarquia inventada para parecer organizada é pior do que hierarquia ausente. Se a seção na qual o artigo foi publicado não corresponde à trilha declarada, o conflito é detectável por qualquer comparação trivial entre a marcação e o que está na tela.

Article e BlogPosting: o mínimo obrigatório

Para texto editorial, o tipo mais usado é Article ou a sua especialização BlogPosting. A escolha entre os dois é menos importante do que o conjunto de campos presentes, e há um núcleo que consideramos obrigatório: título, data de publicação, data de modificação, autor, publicador e a página canônica da qual o texto é o assunto principal.

O título precisa ser o mesmo que aparece na página. Isso parece óbvio e é violado com frequência, porque é tentador escrever na marcação uma versão mais otimizada do título, com palavras que não estão no texto visível. Esse é o tipo mais comum de divergência, e é também o mais fácil de detectar: basta comparar duas strings.

As datas, datePublished e dateModified, fazem um trabalho de atualidade. A data de publicação diz desde quando a afirmação existe; a data de modificação diz quando ela foi revista. O uso desonesto desse par é conhecido: alterar a data de modificação sem alterar nada, para parecer recente. Quando o corpo do texto não mudou e a data mudou, temos uma declaração falsa de frescor, e o custo dela é a confiança em todas as outras declarações da mesma página.

O campo que aponta para a página canônica como assunto principal é o que amarra o objeto ao endereço. Sem ele, o objeto flutua: existe um artigo descrito, mas não se sabe qual página o contém. É um detalhe pequeno de sintaxe com efeito grande de interpretação.

O autor como Person

Entre todos os campos de um artigo, o autor é o que mais frequentemente é subaproveitado. A prática comum é declarar o autor como uma string, ou seja, um nome escrito como texto simples. Funciona como rótulo, mas não funciona como entidade: não há como saber de qual pessoa se trata, nem conectá-la a qualquer outra informação.

A alternativa é declarar o autor como Person, com um identificador próprio e com os mesmos recursos que usamos na organização: canais de verificação externa e temas de conhecimento. Isso transforma um nome em uma entidade endereçável. A pessoa que escreveu o texto passa a ser a mesma pessoa nos dez artigos seguintes, porque o identificador e os canais externos são estáveis, enquanto o nome pode variar de grafia.

A razão pela qual insistimos nisso é econômica. Declarar o autor como entidade é a forma mais barata de colocar uma pessoa dentro do grafo aberto de conhecimento, sem depender de que alguém a cadastre. Não é uma garantia de reconhecimento, é uma redução do custo de ser corretamente identificado. E identificação correta é pré-requisito para qualquer atribuição futura.

Há um cuidado de governança: autor declarado precisa ser autor real. Em ambiente corporativo, é comum marcar a empresa como autora de tudo por comodidade, e há casos em que isso é honesto, como em comunicado institucional. Mas quando existe uma pessoa que escreveu e revisou, apagar essa pessoa da declaração é perder a informação mais valiosa da página, que é a responsabilidade sobre o que foi dito.

knowsAbout: precisão antes de volume

knowsAbout é o campo em que uma entidade declara sobre o que sabe. É também o campo mais fácil de usar mal, porque a tentação é tratá-lo como lista de palavras-chave. Quando isso acontece, o resultado é uma nuvem de vinte ou trinta termos vagos que diluem o sinal em vez de aumentá-lo.

A orientação que adotamos é de três a oito termos precisos. Poucos termos bem escolhidos dizem mais do que muitos termos genéricos, porque o que se quer não é cobertura, é categoria. Trata-se, em essência, de dizer ao sistema em qual prateleira você deve ser colocado. Uma prateleira é definida por um termo específico; uma nuvem de sinônimos não define prateleira nenhuma.

O teste que usamos para escolher um termo é se ele sobrevive ao confronto com o acervo. Se alguém lesse apenas aquele termo e depois lesse cinco textos seus, continuaria fazendo sentido? Se a resposta for sim, o termo é honesto. Se o termo descreve uma ambição e não uma produção, ele não deve entrar, porque a divergência entre declaração e acervo é detectável por amostragem.

Os temas declarados na organização e os declarados na pessoa não precisam ser idênticos, e em geral não devem ser. A organização declara o escopo editorial; a pessoa declara a própria especialidade. Quando ambos batem exatamente em tudo, é razoável suspeitar que um dos dois foi copiado do outro em vez de descrito.

sameAs serve para desambiguação

sameAs é o campo que aponta para outros lugares onde a mesma entidade aparece. A sua função principal não é acumular referências, é resolver ambiguidade: dizer que a organização mencionada aqui é a mesma organização mencionada ali, e não uma homônima.

A implicação prática é que a lista deve ser curta e verificável. Incluir apenas os perfis e cadastros que realmente existem, que são mantidos pela entidade e que podem ser conferidos por qualquer pessoa. Incluir endereços que não existem, ou que não podem ser confirmados, transforma um instrumento de desambiguação em uma fonte de ruído, e ruído em campo de identidade é particularmente caro.

Também é importante entender o que o campo não faz. Ele não é um mecanismo de promoção, não transfere autoridade de um lugar para outro e não substitui a existência de conteúdo próprio. A leitura correta é a de um documento: uma lista de lugares onde a mesma entidade pode ser conferida. Como documento, ela deve ser conservadora.

Em nomes comuns, a desambiguação é o problema inteiro. Se duas organizações em países diferentes compartilham nome, o conjunto de identificadores externos é o que permite separá-las. É por isso que a parcimônia importa: quanto menor e mais verificável a lista, mais fácil é acertar a separação.

FAQPage e HowTo: quando não usar

Dois tipos de marcação concentram a maior parte dos abusos: FAQPage e HowTo. Ambos descrevem estruturas que o leitor reconhece imediatamente, e é justamente por isso que usá-los de forma decorativa é tão arriscado.

FAQPage exige que a página contenha, visivelmente, perguntas e respostas. Se não há perguntas na tela, não há o que declarar. A prática de criar um bloco de perguntas invisível, ou de reformular afirmações do texto em formato de pergunta só para preencher o campo, é uma declaração sem lastro, e o problema dela é o mesmo de qualquer divergência: o leitor humano e a marcação discordam.

HowTo exige um procedimento real, com passos que alguém possa executar em ordem e um resultado verificável. Texto analítico não é procedimento, e não se deve forçá-lo a virar um. Há uma diferença entre explicar como um mecanismo funciona e instruir alguém a fazer algo; o primeiro é análise, o segundo é tutorial. Confundir os dois produz uma marcação que descreve uma página que não existe.

Pela mesma razão, não declaramos avaliações onde não há avaliação. Review e agregação de notas são campos que descrevem um fenômeno específico, com fonte e método. Um editorial que não coleta notas de leitores não tem o que declarar ali, e inventar números nesse campo é uma das formas mais diretas de fabricar uma afirmação falsa em formato legível por máquina.

O maior modo de falha: o corpo diz uma coisa, o schema diz outra

Se existe um único erro que resume todos os outros, é a divergência. A página diz que a empresa foi fundada em um ano, a marcação diz outro. O texto diz que o autor é uma pessoa, a marcação nomeia outra. O corpo afirma uma coisa moderada e a marcação afirma uma versão mais forte da mesma ideia. Em todos esses casos, o sistema não escolhe o lado mais favorável; a resposta típica de um processo automatizado diante de duas fontes que discordam é reduzir a confiança nas duas.

É por isso que a ausência de marcação é preferível à marcação falsa. Sem marcação, a máquina precisa inferir, e a inferência tem um custo, mas não há contradição. Com marcação contraditória, há um custo de inferência e um custo de descrédito. Na prática, o segundo é maior, porque contamina as declarações que estavam corretas.

O princípio que organiza tudo isso é o que chamamos de marcação honesta: tudo o que está no bloco de dados precisa poder ser apontado no texto visível. Não é uma exigência de completude, é uma exigência de correspondência. Você pode marcar pouco; não pode marcar o que não sustenta.

Uma consequência direta dessa regra é sobre arquivos de instrução para agentes. Este site deliberadamente não publica um arquivo do tipo llms.txt. A nossa leitura é que um arquivo de instruções descreve intenção, enquanto a marcação e o conteúdo descrevem fatos, e quando os dois divergem o conflito é invisível para o leitor. Preferimos que a descrição da entidade venha do mesmo lugar de onde vem o texto.

Verificação antes de publicar

A verificação de marcação tem três camadas, e elas não são intercambiáveis. A primeira é sintática: o bloco é um objeto válido, os campos existem no vocabulário, os tipos estão onde deveriam estar. Isso se resolve com validação automática e é a parte mais fácil.

A segunda é de produto: os validadores de resultado rico indicam quais marcações foram reconhecidas e quais foram ignoradas, e por quê. Um campo reconhecido sintaticamente e ignorado por produto é um caso comum, e costuma indicar que algum campo obrigatório daquele tipo está faltando. Ver apenas a primeira camada dá a falsa sensação de que está tudo bem.

A terceira é a que quase ninguém faz e que consideramos a mais importante: uma leitura linha a linha de cada afirmação do bloco, conferindo se aquilo também aparece no texto.Nome da organização, ano, autoria, datas, afirmação de procedimento, existência de perguntas. É um trabalho manual e entediante, e é exatamente por ser entediante que a divergência sobrevive tanto tempo em sites grandes.

Um detalhe operacional ajuda: manter a marcação gerada a partir dos mesmos dados que alimentam o texto visível. Quando título, autor e data vêm do mesmo registro que aparece na página, a divergência se torna um erro de implementação pontual em vez de um hábito editorial.

O que a marcação honesta não compra

Precisamos ser explícitos sobre o limite. Marcação não garante citação por sistema de resposta, não garante posição em ranking e não garante inclusão em qualquer produto de inteligência artificial. A decisão de citar depende de fatores que estão fora do seu controle, e qualquer afirmação em contrário deve ser tratada com desconfiança. Nós não medimos efeito de marcação sobre citação e não temos como afirmar relação de causa.

O que a marcação reduz é o custo de ser mal lido. Um processo automático que precisa identificar a entidade, o autor e a data de um texto pode errar de várias formas: atribuir o texto à pessoa errada, tratar uma análise como tutorial, considerar recente o que é antigo, ou não conseguir dizer de qual organização se trata. Cada um desses erros tem um custo, e a marcação honesta reduz a probabilidade de cada um deles. Reduzir erro não é o mesmo que produzir ganho, mas em ambiente de alta competição por atenção, evitar o erro grosseiro já é uma vantagem.

A conclusão é deliberadamente modesta. Faça o grafo pequeno e verdadeiro: uma organização com identificador próprio, um site, uma trilha, e uma camada de tipo que corresponda ao que a página realmente é. Declare o autor como pessoa. Escolha poucos termos de conhecimento e defenda cada um com o seu acervo. Use verificação externa com parcimônia. E antes de publicar, leia a sua própria marcação como se fosse um documento assinado, porque é exatamente isso que ela é.