Dados estruturados para busca com IA: o que ainda importa

O que os dados estruturados realmente fazem pelos assistentes de IA

Todo assistente de IA que responde a uma pergunta como “melhor dentista perto de mim” ou “onde compro esta peça” primeiro envia um rastreador — um programa que visita páginas e copia o conteúdo delas — para ler o seu site. Sem rótulos, esse rastreador vê uma parede de texto e precisa inferir o significado: “555-0134” é um telefone ou um código de produto? Os dados estruturados eliminam o palpite ao embrulhar os fatos num pequeno bloco de código chamado JSON-LD, que fica discretamente na página e diz, na prática, este é o telefone, este é o preço, este é o horário de abertura.

A própria documentação da OpenAI confirma que o seu rastreador, o GPTBot, busca páginas públicas de forma muito parecida com a de um buscador tradicional OpenAI, e a orientação do Google sobre dados estruturados é explícita ao dizer que esses rótulos ajudam um programa a “entender o conteúdo da página” Google Search Central. Nenhuma das duas empresas afirmou que ignora essa rotulagem, então, na prática, o mesmo bloco JSON-LD que você adicionaria para a busca clássica continua sendo lido pelos assistentes para os quais os seus clientes estão migrando. Se você nunca adicionou, os assistentes que respondem hoje a perguntas sobre o seu negócio estão trabalhando com palpites, não com fatos.

Os quatro tipos de esquema que valem o seu tempo

O schema.org lista centenas de tipos de item, de Recipe a Movie e Airport, mas um negócio pequeno ou médio típico precisa de apenas quatro deles para cobrir quase todo fato que um assistente possa citar. Adicione estes e não se preocupe com o resto.

• Organization — estabelece o seu negócio como uma única entidade nomeada, com logotipo e links para os seus perfis sociais oficiais, para que um assistente perceba que a conta do Instagram e o site pertencem à mesma “Padaria da Dolores”.
• LocalBusiness — uma extensão de Organization feita para quem tem endereço físico ou área de atendimento; carrega horário, telefone e bairro, exatamente os detalhes de que um assistente precisa para responder “eles estão abertos agora?”.
• Product e Offer — associam preço real, moeda e disponibilidade ao que você vende, para que um assistente cite o seu número de verdade em vez de tirar uma média dos palpites de alguns concorrentes.
• FAQPage — um conjunto de pares de pergunta e resposta exatamente no formato que os assistentes já gostam de extrair e devolver ao usuário, palavra por palavra.

O que uma confirmação legível por máquina faz pela resolução de identidade

Imagine Dolores, dona de uma padaria em Austin. Ela tem um Perfil da Empresa no Google, uma página no Yelp, uma conta no Instagram e um site — quatro menções separadas à “Padaria da Dolores” espalhadas pela internet. Antes de recomendá-la com segurança, um assistente precisa resolver a identidade: decidir se as quatro menções descrevem o mesmo negócio real ou se uma delas é outra Padaria da Dolores, em outra cidade.

Os dados estruturados dão ao assistente um atalho. Uma propriedade do schema.org chamada sameAs permite que Dolores liste as URLs do seu Instagram, Facebook e Yelp diretamente dentro da marcação Organization do próprio site — uma confirmação legível por máquina, nas palavras dela, de que essas contas lhe pertencem schema.org. É um sinal mais forte do que o assistente inferir uma correspondência a partir de nomes e endereços parecidos em fontes nas quais ele não confia por completo; é a própria Dolores atestando a ligação, num formato que nada consegue ler errado.

Isso pesa mais conforme cresce a disputa por um nome. Uma única “Padaria da Dolores” numa cidade de oito mil habitantes se resolve sozinha. Uma “Riverside Dental” competindo com quatro clínicas de nomes parecidos precisa de cada detalhe que a distinga — o endereço exato, o telefone exato, os links sociais confirmados — para que um assistente não a misture com uma rival na mesma rua.

Um exemplo de JSON-LD para copiar e adaptar esta semana

Você não precisa de um desenvolvedor para escrever isso do zero; precisa preencher um modelo. Um bloco JSON-LD para um negócio local fica dentro de uma única tag script, marcada com o tipo application/ld+json, e começa com uma linha que declara o vocabulário como o contexto do schema.org. Dentro dele, o tipo é definido como LocalBusiness, seguido de um campo name com o nome exato do negócio e um campo image apontando para o seu logotipo.

Em seguida vem o endereço, escrito como um objeto aninhado do tipo PostalAddress, dividido em streetAddress, addressLocality (a sua cidade), addressRegion (o seu estado) e postalCode — quatro campos rotulados separados em vez de uma linha de texto, porque é isso que permite ao assistente responder “isso é perto de mim?” sem confundir o CEP com o número da sala. Depois vêm um campo telephone e um campo priceRange (algo tão simples quanto “$” para preços moderados). Um campo openingHoursSpecification lista os seus dias e horários em formato estruturado em vez de numa frase, para que “fechado aos domingos” não vire “fechado às segundas”. Por fim, um campo sameAs guarda um conjunto de URLs: o seu Instagram, a sua página no Facebook, o seu registro no Yelp e qualquer outro perfil que seja inconfundivelmente você.

Uma vez escrito, esse bloco é colado uma única vez, perto do topo do código da sua página inicial, e deixado em paz. Se você usa um construtor de sites como Squarespace, Wix ou Shopify, a maioria hoje oferece um campo de configuração para código personalizado ou dados estruturados onde isso pode ser adicionado sem mexer no resto do site.

O que dá para pular

Nem todo tipo do schema.org vale o seu tempo, e correr atrás de todos desperdiça um esforço mais bem gasto nos quatro acima.

• A marcação BreadcrumbList, que descreve a estrutura de pastas do seu site (Início > Cardápio > Bolos), ajuda os resultados de busca clássicos a exibir uma trilha de navegação, mas não diz nada a um assistente sobre os fatos do seu negócio — pule, a menos que você já a tenha de um projeto antigo.
• AggregateRating sem avaliações reais por trás. As próprias diretrizes de dados estruturados do Google proíbem explicitamente marcações que deturpem notas que você não tem de fato Google Search Central, e um assistente repetindo uma nota inflada que você não consegue sustentar é risco de reputação, não uma vitória.
• Marcação profundamente aninhada ou duplicada em cada página. A sua identidade Organization só precisa ser declarada com clareza uma vez, normalmente na página inicial; repeti-la de forma inconsistente em dezenas de páginas cria versões conflitantes para o assistente conciliar, o que é pior do que declará-la uma só vez, corretamente.
• Tipos do schema.org novíssimos e raramente suportados. O próprio vocabulário lista centenas de tipos criados para usos estreitos, como receitas ou aeroportos schema.org; se um tipo não está entre o punhado que buscadores e assistentes têm documentado que realmente usam, o rótulo não faz nada por você hoje.

Como verificar se os seus dados estruturados estão realmente funcionando

Adicionar o código é só metade do trabalho; confirmar que ele é legível é a outra metade. O Teste de Resultados Aprimorados, gratuito do Google, permite colar a URL de uma página ou o próprio código e ver exatamente quais tipos ele detecta e quais campos faltam Google. Rodá-lo depois de cada mudança pega um erro de digitação — uma vírgula ausente pode quebrar um bloco inteiro em silêncio — antes que isso lhe custe algo.

Esse teste diz que o código é válido. Ele não diz se o ChatGPT realmente usou o seu horário confirmado numa resposta, nem se o Perplexity ainda lista um concorrente antes de você. Essa é outra pergunta, e é a que a Growli foi criada para responder: acompanhamos o que os assistentes de fato dizem sobre um negócio nas várias plataformas e apontamos onde a distância entre o código correto e a resposta correta ainda existe. Veja como funciona se você prefere conferir os seus resultados a supor que a marcação está cumprindo o papel dela.

FAQ