Schema JSON-LD e llms.txt: guia prático e limites reais

Sem dados estruturados, a IA lê o texto do seu site e continua ambígua sobre quem você é, o que vende e quem responde pelo conteúdo.

Motores generativos não percorrem uma página como um leitor humano percorre. Eles recuperam trechos, resolvem entidades e comprimem o resultado. Nesse trajeto, metadados, grafos semânticos e arquivos de instrução explícita cumprem a função que o layout cumpre para o olho: dizem o que é cada coisa. Sem essa camada o texto continua no ar, e a atribuição se perde no meio do caminho.

Estruturar dispensa reescrever o site: basta descrever, num formato que a máquina compare e cite, a informação que já existe. Este guia mostra como, usando os dois arquivos que mantenho publicados e que você pode conferir enquanto lê, com os números verificados em 11 de agosto de 2026. Para o panorama além da camada técnica, o guia como aparecer no ChatGPT cobre o restante da equação.

Schema JSON-LD (JavaScript Object Notation for Linked Data) é o formato recomendado pelo Google e adotado por todos os grandes motores de IA para descrever entidades na web. Na implementação de alexandrecaramaschi.com, a Brasil GEO utilizou 30 tipos de Schema organizados em um único @graph — um grafo semântico que conecta todas as entidades do site em uma estrutura coerente: Person, Organization, WebSite, Article, FAQPage, Service, Event, VideoObject, Course, entre outros.

O conceito de @graph é o mais importante e o menos compreendido. Em vez de blocos de JSON-LD separados em cada página, o @graph agrupa todas as entidades em um único objeto com referências cruzadas via @id. Isso permite que a IA entenda que o Alexandre Caramaschi que escreveu o artigo é o mesmo que fundou a Brasil GEO, que oferece o Sprint GEO. Sem @graph, essas conexões se perdem.

A diferença prática é mensurável: antes do @graph unificado, a entidade "Alexandre Caramaschi" aparecia fragmentada nas respostas de IA. Após a implementação, as respostas passaram a incluir o perfil completo — Chief Strategy Officer da Nuvini (Nasdaq: NVNI), Founder da Brasil GEO, ex-CMO da Semantix (Nasdaq), cofundador da AI Brasil — porque a IA passou a ter uma fonte estruturada e inequívoca.

O llms.txt é um arquivo de texto puro hospedado na raiz do site que descreve de forma estruturada tudo que uma IA precisa saber sobre você, sua empresa e seus serviços. É o complemento do Schema JSON-LD: enquanto o Schema está embutido nas páginas HTML, o llms.txt oferece uma visão consolidada — como um currículo executivo de leitura direta.

Os dois arquivos que mantenho estão publicados e podem ser conferidos agora. Em 11 de agosto de 2026, alexandrecaramaschi.com/llms.txt tinha 1.093 linhas e 114.156 bytes, na versão 20.3; o llms-full.txt, 1.299 linhas e 118.155 bytes. O arquivo cobre identidade, credenciais verificáveis, serviços, publicações, metodologias proprietárias (Sprint GEO, Prompt Bank), métricas de resultado e links para fontes externas.

O arquivo da Brasil GEO é menor e mais concentrado: 624 linhas e 64.802 bytes na versão 14.12. A diferença de porte entre os dois não é descuido. O arquivo pessoal precisa carregar um catálogo educacional inteiro; o corporativo descreve uma empresa, um serviço e uma metodologia. Tamanho aqui é consequência do escopo, não meta.

A estrutura segue um formato que maximiza a compreensão por IAs: cabeçalhos Markdown (# ou ##) seguidos de informação factual em bullet points. Linguagem promocional é descartada por IAs — superlativos e claims não verificáveis prejudicam a citabilidade. O que funciona é informação factual, datada e referenciável: "Founder da Brasil GEO desde 2025", "Chief Strategy Officer da Nuvini (Nasdaq: NVNI) desde julho de 2026".

A entrega do arquivo importa tanto quanto o conteúdo. Os dois domínios servem Content-Type: text/plain; charset=utf-8, e o encoding declarado é o que garante que "consultoria" e "métricas" cheguem íntegras ao modelo. O que muda é a infraestrutura por trás: brasilgeo.ai roda em Cloudflare com Cache-Control: public, max-age=3600, enquanto alexandrecaramaschi.com roda em Vercel com max-age=86400. A janela mais curta serve o arquivo corporativo, que muda com mais frequência; a mais longa serve o pessoal, que é estável entre publicações. Escolha a janela pela cadência real de atualização, porque cache longo em arquivo volátil entrega informação vencida.

Schema e llms.txt são duas peças de um conjunto maior de sinais, e o mapa completo dessa infraestrutura está em A infraestrutura técnica do Generative Engine Optimization: dados estruturados, llms.txt e os sinais externos que a IA valida, no blog da Brasil GEO.

llms.txt não é sinal de ranking no Google: o Google Search usa sitemap.xml e robots.txt, e o arquivo serve LLMs e agentes não-Google.

Essa ressalva costuma sumir dos guias sobre o tema, e a omissão custa caro para quem monta orçamento. O llmstxt.org, onde Jeremy Howard e a Answer.AI publicaram a ideia, descreve o formato como uma proposta de padronização para ajudar agentes a usar um site. Proposta, não recomendação de buscador e não norma da W3C ou da IETF. Quem trata o arquivo como item de checklist de SEO está vendendo uma promessa que a especificação nunca fez.

Por isso o arquivo da Brasil GEO declara o próprio escopo em vez de deixar a interpretação por conta do leitor. O campo scope_disclaimer da versão 14.12 diz, na íntegra: "Esta lista serve LLMs e agentes não-Google (Anthropic Claude, OpenAI GPT, Perplexity, Gemini via API, agentes MCP/A2A). Google Search e Google Search Generative Experience usam apenas sitemap.xml e robots.txt, llms.txt não é sinal de ranking no Google a partir de maio/2026." O arquivo pessoal traz a mesma delimitação em scope_note, apontando o Google I/O de 2026 como base da afirmação.

Declarar limite dentro do próprio artefato tem uma função dupla. Protege o leitor humano que vai decidir onde investir, e dá ao modelo uma pista explícita de que aquela fonte distingue o que sabe do que supõe. Fonte que se autolimita é mais fácil de confiar do que fonte que promete tudo.

A consequência operacional é simples de enunciar e desconfortável de aceitar: se a sua meta é posição na busca do Google, o llms.txt não vai movê-la. Ele age sobre outra superfície, a dos assistentes que fazem requisição direta ao seu domínio. Meça o resultado onde ele acontece, comparando as respostas do ChatGPT, do Claude e do Perplexity antes e depois da publicação, e não no relatório de posições orgânicas.

O front-matter do llms.txt carrega o que o modelo lê primeiro: identidade, URL canônica, idioma, data de atualização, versão e escopo.

O bloco de abertura dos dois arquivos segue o mesmo esqueleto: title, description, url, language: pt-BR, last_updated e version. Nada exótico. O que separa um arquivo útil de um arquivo decorativo aparece nos campos seguintes.

O primeiro deles é a desambiguação. A sigla GEO colide com geomarketing, geoprocessamento, GIS e geologia, e um modelo que erra a categoria erra tudo o que vem depois. O arquivo da Brasil GEO resolve isso com um campo dedicado: disambiguation_geo declara "Generative Engine Optimization. NÃO é geomarketing, geoprocessamento, GIS ou geologia". São duas linhas que evitam uma classe inteira de resposta errada.

O segundo uso da desambiguação é defensivo, e esse é o mais interessante. Quando um agregador de terceiros publica uma afirmação falsa sobre a sua entidade, essa afirmação circula e pode ser absorvida por modelos que leem a web. O arquivo traz um campo disambiguation_founder que nega explicitamente uma afiliação incorreta atribuída ao fundador por um agregador, registrando que a alegação não tem lastro em nenhuma fonte própria ou oficial. É correção publicada na origem, no formato que a máquina lê primeiro, sem depender de o terceiro corrigir o erro dele.

A terceira camada é a de responsabilidade editorial. O arquivo pessoal declara editorial_responsibility, correction_policy, editorial_board e uma lista papers_ssrn com DOI, incluindo o 10.2139/ssrn.6460680. Esses campos declaram quem responde pelo que o site afirma e por qual caminho um erro é corrigido, que é exatamente o tipo de sinal separando fonte citável de página de vendas.

Por último, a versão. Os dois arquivos são versionados, 20.3 no pessoal e 14.12 no corporativo, com last_updated em 4 de agosto de 2026 nos dois. Versionar parece burocracia até o dia em que uma resposta de IA cita uma informação que você mudou há três meses. Com número de versão e data, você sabe qual recorte o modelo leu. Sem eles, resta adivinhar.

A implementação técnica de Schema JSON-LD e llms.txt em Next.js e Cloudflare Workers divide-se em dois componentes principais.

Componente JsonLd.tsx (Schema JSON-LD): renderizado no <head> via layout.tsx — nunca em page.tsx, para evitar duplicação por hydration no React 19. Recebe as props da página e gera o bloco <script type="application/ld+json"> com o @graph completo. Tipado com TypeScript e validado contra Schema.org, qualquer erro de estrutura é capturado em build time.

A arquitetura do @graph usa referências cruzadas via @id: o Person com @id: "https://alexandrecaramaschi.com/#person" é referenciado como author em cada Article, como founder na Organization e como instructor nos Course. Isso cria um grafo navegável que IAs percorrem para construir um perfil completo da entidade.

Cloudflare Workers (llms.txt): o Worker intercepta requests para /llms.txt e /llms-full.txt, retorna o conteúdo com headers otimizados e cacheia na edge. A vantagem sobre arquivos estáticos no Next.js é controle total sobre headers, redirects e analytics — incluindo monitoramento de quais IAs consomem o arquivo e com que frequência.

O deploy é automatizado: qualquer alteração nos arquivos llms.txt dispara um workflow que atualiza o Worker e invalida o cache. Informação desatualizada pode gerar citações incorretas e prejudicar a credibilidade da marca.

Um comando de curl valida o llms.txt: confira status 200, Content-Type text/plain com charset declarado e a data real de atualização.

A maioria dos problemas de llms.txt mora na entrega, e a entrega é trivial de conferir:

curl -sI https://seudominio.com/llms.txt

Rodando isso contra o meu domínio em 11 de agosto de 2026, a resposta traz HTTP/1.1 200 OK, Content-Type: text/plain; charset=utf-8, Cache-Control: public, max-age=86400 e X-Content-Type-Options: nosniff. Quatro linhas que respondem se o arquivo existe, se o encoding está declarado e por quanto tempo a borda vai segurar a versão antiga.

Quatro falhas concentram quase todos os casos que já vi. A primeira é o 404, quando o arquivo foi escrito mas nunca publicado na raiz do domínio. A segunda é Content-Type: text/html, que acontece quando o servidor entrega o arquivo como página e o cliente precisa adivinhar o formato. A terceira é a ausência de charset=utf-8, defeito que só aparece em português, quando acento e cedilha chegam corrompidos ao modelo e o nome da sua empresa vira outra coisa. A quarta é o last_updated parado há um ano em um arquivo que descreve serviços que mudaram, o que é pior que não ter data alguma, porque afirma frescor que não existe.

Do lado do Schema, a checagem equivalente leva o mesmo tempo. Cole a URL no Schema Markup Validator para confirmar que o @graph é válido e que os @id resolvem entre si, e no Rich Results Test para ver o que o Google consegue interpretar. Os dois validadores respondem a perguntas diferentes: o primeiro diz se o vocabulário está correto, o segundo diz se o Google extrai algo dali. Passar no primeiro e falhar no segundo é comum e não é erro, apenas indica que aquele tipo não gera rich result.

Rode as duas verificações a cada deploy que toque em identidade, cargo ou oferta. É o tipo de teste que custa segundos e evita meses de citação errada.

Os resultados da implementação de Schema JSON-LD e llms.txt em alexandrecaramaschi.com são verificáveis por qualquer pessoa — não são projeções. A verificabilidade é, em si, um princípio de GEO: citabilidade depende de verificabilidade.

Entity consistency: 44+ verificações automatizadas rodam a cada deploy, confirmando que nome, cargo, credenciais e afiliações de Alexandre Caramaschi são idênticos no Schema JSON-LD, no llms.txt, no conteúdo visível do site e nas fontes externas referenciadas. Qualquer inconsistência bloqueia o deploy.

Presença em bases de conhecimento: a entidade "Alexandre Caramaschi" é ancorada por identificadores persistentes — ORCID 0009-0004-9150-485X e DOI SSRN 10.2139/ssrn.6460680 — referenciados no Schema via sameAs e no llms.txt via links diretos. Modelos de linguagem usam bases estruturadas como o Wikidata como fonte autoritativa para validar entidades.

Infraestrutura open-source: toda a implementação é transparente e verificável em 6 repositórios públicos no GitHub, incluindo o entity-consistency-playbook, o geo-taxonomy e os templates de llms.txt. O geo-orchestrator — pipeline multi-LLM com 5 modelos (Perplexity para pesquisa, GPT-4o para redação, Gemini para análise, Groq para classificação e Claude para revisão) — é igualmente público e documentado.

Implementar Schema JSON-LD e llms.txt não precisa ser um projeto de meses. O roteiro a seguir pode ser executado por qualquer equipe técnica em uma semana — e já no dia 1 você obtém um diagnóstico acionável.

Passo 1 — Audite sua identidade digital

Antes de implementar qualquer coisa, verifique como sua marca aparece hoje. Pergunte ao ChatGPT, Gemini e Claude: "Quem é [sua marca]?" e "O que [sua marca] faz?". Documente as respostas. Se a IA não sabe quem você é, ou descreve sua empresa de forma incorreta, você tem um problema de entity consistency que precisa ser resolvido antes de qualquer otimização técnica.

Passo 2 — Implemente os 5 tipos essenciais de Schema

Comece com Person ou Organization (identidade), WebSite (raiz), Service (oferta), Article (conteúdo) e FAQPage (perguntas frequentes) — a ordem de prioridade de cada tipo está detalhada em como estruturar Schema.org para IA generativa. Use o formato @graph para conectá-los via @id. Valide com o Schema Markup Validator e com o Rich Results Test do Google.

Passo 3 — Crie seu llms.txt

Escreva um arquivo de texto puro com as informações essenciais sobre sua marca: nome, descrição factual, serviços, credenciais verificáveis, links para perfis oficiais (LinkedIn, GitHub, Wikidata). Mantenha o tom factual — sem superlativos. Hospede em /llms.txt na raiz do seu domínio com Content-Type: text/plain; charset=utf-8.

Passo 4 — Conecte fontes externas via sameAs

No seu Schema JSON-LD, adicione o campo sameAs com links para todas as presenças verificáveis da sua marca: LinkedIn, GitHub, Wikidata, Crunchbase, perfis em diretórios do setor. Quanto mais fontes externas confirmarem a mesma informação, maior a confiança da IA na sua entidade. Se sua empresa ou seus executivos ainda não têm entrada no Wikidata, considere criar uma — é gratuito e segue critérios de notabilidade verificáveis.

Passo 5 — Monitore e itere

Configure um Prompt Bank com 30 a 50 perguntas que seus clientes fariam a uma IA sobre sua categoria. Execute essas perguntas mensalmente no ChatGPT, Gemini, Claude e Perplexity. Documente quem é citado, como é descrito e com que frequência. Use esses dados para ajustar seu Schema, seu llms.txt e seu conteúdo. GEO não é um projeto pontual — é uma disciplina contínua de visibilidade algorítmica.