Na semana passada, um cliente perguntou-me: "Temos um ficheiro schemas.ts no nosso código, mas já ninguém sabe porque é que ele está lá nem o que faz cada bloco." Não é caso isolado. Em pelo menos metade dos projetos que analiso, há um ficheiro JSON-LD perdido algures que um developer deixou um dia — sem documentação, sem objetivo claro e, muitas vezes, sem que ninguém saiba se ainda está correto.
É uma pena, porque os dados estruturados são exatamente o tipo de informação que sistemas de IA como o ChatGPT, o Perplexity e as AI Overviews do Google procuram. É contexto legível por máquinas que diz: "isto é quem somos, isto é onde estamos, estas são as respostas às perguntas frequentes." Sem esse contexto, um modelo de linguagem tem de adivinhar a partir de texto não estruturado. Com esse contexto, recebe uma fonte direta e fiável.
Neste artigo explico os três tipos de schema mais utilizados — Organization, LocalBusiness e FAQPage — com exemplos concretos que você pode implementar hoje.
Porque é que os dados estruturados continuam a importar na era da IA
Os dados estruturados (JSON-LD, na maioria dos casos) existem desde 2011 graças ao schema.org, criado em conjunto pelo Google, Bing, Yahoo e Yandex. O objetivo na altura era simples: ajudar os motores de busca a compreender os conteúdos para poderem mostrar resultados enriquecidos — estrelas de avaliações, horários de funcionamento, FAQs expansíveis nos resultados de pesquisa.
O que mudou: quem "lê" os seus dados estruturados já não é apenas um crawler a indexar para uma lista de resultados. É também um modelo de linguagem que analisa o seu conteúdo para formular uma resposta a um utilizador que pode nunca chegar a visitar o seu site. Se alguém perguntar ao ChatGPT "que empresas em Lisboa fazem consultoria de IA", a probabilidade de o seu JSON-LD ser incluído na resposta é muitas vezes maior do que a de um texto de marketing ser corretamente interpretado.
Isto acontece porque os dados estruturados são inequívocos. Uma frase como "Estamos no coração de Lisboa" obriga um modelo a interpretar e a fazer suposições. Um objeto PostalAddress com addressLocality: "Lisboa" não precisa de interpretação — é um facto que pode ser extraído diretamente.
Para a estratégia mais ampla por trás deste tipo de otimização, recomendo também ler o que é exatamente o GEO — os dados estruturados são apenas uma peça de um puzzle maior.
Os três tipos de schema de que quase sempre precisa
Organization: quem é você, afinal?
O schema Organization é a base. Responde à pergunta que os sistemas de IA falham com mais frequência: o que é esta empresa e porque é que devo confiar nela? Este schema pertence à página inicial e, idealmente, deve ser repetido (ou referenciado) em todas as páginas através do layout.
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "WeArkMedia",
"url": "https://wearkmedia.nl",
"logo": "https://wearkmedia.nl/logo.png",
"description": "Desenvolvimento web nativo de IA e otimização GEO/AEO para empresas que querem ser encontradas pelo ChatGPT, Perplexity e Google AI Overviews.",
"sameAs": [
"https://www.linkedin.com/company/wearkmedia",
"https://twitter.com/wearkmedia"
],
"contactPoint": {
"@type": "ContactPoint",
"email": "hallo@wearkmedia.nl",
"contactType": "customer service"
}
}
O ponto importante aqui: sameAs não é decoração. Este campo liga a sua empresa a fontes externas verificáveis — o seu LinkedIn, a sua página na Wikipédia (se existir), o seu perfil no Crunchbase. Os modelos de IA usam este tipo de referências cruzadas para determinar se uma entidade "existe de verdade". Um schema Organization sem sameAs é como um perfil de LinkedIn sem contactos: tecnicamente válido, mas pouco convincente.
A description não deve ser copiada da meta description. Escreva uma frase específica sobre o que faz e para quem — não "somos uma agência de referência", mas algo concreto: o quê, para quem e por que razão é diferente.
Nota: se a sua empresa estiver registada nos Países Baixos, pode indicar o número de registo comercial neerlandês (KvK) em identifier ou taxID — é mais um sinal de verificação para os motores de busca.
LocalBusiness: essencial se quer ser encontrado fisicamente
Se tem um espaço físico — um escritório, uma loja, um consultório — o LocalBusiness (ou um subtipo mais específico como ProfessionalService, Restaurant, Store) é essencial. Este schema é a razão direta pela qual os assistentes de IA conseguem responder a perguntas do tipo "aqui perto".
{
"@context": "https://schema.org",
"@type": "ProfessionalService",
"name": "WeArkMedia",
"image": "https://wearkmedia.nl/kantoor.jpg",
"address": {
"@type": "PostalAddress",
"streetAddress": "Vredenburg 40",
"addressLocality": "Utrecht",
"postalCode": "3511 BD",
"addressCountry": "NL"
},
"geo": {
"@type": "GeoCoordinates",
"latitude": 52.0907,
"longitude": 5.1214
},
"telephone": "+31-30-1234567",
"openingHoursSpecification": [
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
"opens": "09:00",
"closes": "17:30"
}
],
"priceRange": "€€€"
}
Duas coisas que costumam correr mal. Primeiro: esquecem-se das coordenadas geo, quando é precisamente isso que os sistemas usam para calcular distâncias em pesquisas de "mais próximo". Segundo: o @type é muitas vezes demasiado genérico. Não use LocalBusiness por defeito se existir um subtipo mais específico — o Google e os sistemas de IA conseguem corresponder muito melhor à intenção com um tipo concreto (como Dentist, Accountant ou MarketingAgency, quando disponível).
Este é precisamente o tema que aprofundo em GEO para empresas locais — aí explico também como lidar com várias lojas ou escritórios.
FAQPage: o schema mais subestimado para AEO
Se há um tipo de schema com influência direta na probabilidade de ser citado numa resposta de IA, é o FAQPage. Porquê? Porque fornece literalmente a estrutura pergunta-resposta de que um modelo de linguagem precisa para reutilizar o seu conteúdo na própria resposta — muitas vezes palavra por palavra.
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "Quanto custa um site nativo de IA?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Um site nativo de IA é entregue por fases. O custo depende do número de páginas, do número de idiomas e das integrações com sistemas existentes. Peça um orçamento com base no seu próprio âmbito, com horas por fase."
}
},
{
"@type": "Question",
"name": "Os dados estruturados funcionam sem uma equipa técnica?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Sim. A maioria dos CMS e frameworks suporta JSON-LD através de plugins ou de pequenos blocos de código. Não precisa de um developer dedicado para implementar o schema Organization ou FAQPage."
}
}
]
}
A armadilha aqui é preencher o schema FAQPage com perguntas de marketing ("Porque é que deve escolher-nos?") em vez de perguntas que as pessoas realmente colocam a um motor de busca ou a um assistente de IA. Veja a secção "As pessoas também perguntam" no Google ou teste você mesmo no ChatGPT e no Perplexity quais são as dúvidas que surgem em torno do seu tema. Escreva respostas que funcionem sozinhas — uma resposta tem de ser compreensível sem reler a pergunta, porque é exatamente assim que um modelo de linguagem a vai recortar.
Desenvolvi este tema com mais detalhe no guia prático de AEO, incluindo como decidir quais perguntas vale a pena responder.
De um ficheiro isolado a um sistema a funcionar: implementação prática
Onde colocar isto no seu código?
Se já tem um lib/schemas.ts (ou algo semelhante), a estrutura lógica é esta: exportar funções que geram objetos JSON-LD a partir do seu conteúdo, e não strings estáticas. Algo assim:
// lib/schemas.ts
export function generateOrganizationSchema() {
return {
"@context": "https://schema.org",
"@type": "Organization",
name: "WeArkMedia",
url: "https://wearkmedia.nl",
// ...
};
}
export function generateFAQSchema(faqs: { question: string; answer: string }[]) {
return {
"@context": "https://schema.org",
"@type": "FAQPage",
mainEntity: faqs.map((faq) => ({
"@type": "Question",
name: faq.question,
acceptedAnswer: {
"@type": "Answer",
text: faq.answer,
},
})),
};
}
Isto evita que os schemas se desliguem do conteúdo — um problema muito comum, em que o texto da FAQ na página é alterado mas o schema por trás não acompanha. A inconsistência entre o conteúdo visível e os dados do schema é exatamente o que você não quer: mina a confiança tanto do Google como dos crawlers de IA.
Teste e valide antes de publicar
Use o Rich Results Test do Google e o validador do Schema.org antes de publicar seja o que for. Um erro frequente é um lapso no @type (por exemplo, Organisation com grafia britânica em vez de Organization) — o schema falha em silêncio, sem qualquer erro no site, e só descobre o problema quando se questiona porque é que nada funciona.
Não se esqueça também de verificar se o seu robots.txt está a bloquear crawlers de IA que deviam precisamente ler estes dados — consulte o guia de robots.txt e crawlers de IA se tiver dúvidas sobre a sua configuração.