Schema.org para SaaS B2B: o mínimo viável em JSON-LD
Os cinco tipos de schema de que toda a empresa de SaaS B2B precisa, com snippets de JSON-LD prontos a colar: Organization, Service, FAQPage, BreadcrumbList e Article.
Para uma empresa de SaaS B2B, há cinco tipos de schema que valem mais do que todos os outros combinados: Organization, Service, FAQPage, BreadcrumbList e Article. Implementados em JSON-LD, com @id estáveis e ligações entre eles, são o mínimo viável para começar a ser citável por IA. Este texto tem o snippet de cada um, pronto a adaptar.
Key takeaways
JSON-LD é a serialização certa em 2026
cinco tipos resolvem 80% do upside: Organization, Service, FAQPage, BreadcrumbList, Article
@id estáveis transformam entidades soltas em grafo
validar em validator.schema.org e no Rich Results Test
schema irrelevante é pior do que ausência de schema
Porque é que o schema importa para GEO
Schema.org é o vocabulário standard de dados estruturados. Em HTML, descrever que algo é uma organização é implícito (a partir de tags como header, de classes CSS, do contexto). Em schema, é explícito: @type: Organization.
Para motores tradicionais, o schema desbloqueia rich results (estrelas, FAQ expandida, breadcrumbs visíveis). Para LLMs, o schema é a única forma fiável de saber, sem ambiguidade, o que cada coisa é. Quando o ChatGPT cita "a Acme é uma consultora de cibersegurança em Lisboa", está a inferir três coisas, o que é, o que faz, onde, e o schema reduz o espaço de erro.
Os cinco tipos, um por separador
O fundamento. Uma entidade Organization por empresa, com @id estável, referenciada por todas as outras entidades como provider, author, publisher.
Três campos críticos: sameAs (ligações para perfis externos consistentes, LinkedIn, GitHub, Wikipédia se existir), knowsAbout (3 a 10 tópicos que afirmam a expertise da empresa), e contactPoint com availableLanguage.
Um Service por serviço oferecido. Liga ao Organization através de provider:
Para SaaS B2B com preços variáveis, o AggregateOffer com lowPrice sinaliza a entrada sem se comprometer com tabela exposta. Funciona bem para "a partir de 99 EUR" sem revelar o topo.
Bloco de perguntas e respostas em formato estruturado. Os modelos de IA preferem citar este formato porque é trivial de extrair:
{
"@context": "https://schema.org",
"@type": "FAQPage",
"@id": "https://acme.com/#faq",
"isPartOf": { "@id": "https://acme.com/#website" },
"mainEntity": [
{
"@type": "Question",
"name": "A Acme integra com ERP?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Sim. Integração nativa com SAP B1, Primavera e PHC."
}
}
]
}
Regra prática: 5 a 10 perguntas por FAQPage. Mais do que isso é ruído. As perguntas devem corresponder a pesquisas reais que os clientes fazem, não a pesquisas inventadas pela equipa de marketing.
Pequeno mas importante. Ajuda os crawlers a perceber a hierarquia das suas páginas. Devolve resultado visível nos SERPs do Google e dá pistas estruturais aos LLMs:
Cada artigo do blog deve ter BlogPosting (mais específico do que Article) com os campos críticos:
{
"@context": "https://schema.org",
"@type": "BlogPosting",
"@id": "https://acme.com/blog/integrar-sap#article",
"headline": "Como integrar a Acme com SAP B1 em 30 minutos",
"description": "Guia técnico de integração via REST API.",
"image": "https://acme.com/og-image.png",
"datePublished": "2026-05-01",
"dateModified": "2026-05-01",
"author": { "@id": "https://acme.com/#organization" },
"publisher": { "@id": "https://acme.com/#organization" },
"mainEntityOfPage": {
"@id": "https://acme.com/blog/integrar-sap#webpage"
},
"articleSection": "Integrações",
"inLanguage": "pt-PT"
}
Três detalhes que muitos sites falham: o mainEntityOfPage deve apontar para um WebPage que é efetivamente emitido (não um @id que nunca existe). O articleSection ajuda os LLMs a categorizar. O author e o publisher referenciam o Organization através de @id em vez de duplicar dados.
O conceito de @graph (e porque importa)
Se tiver várias entidades na mesma página, pode embrulhá-las num @graph em vez de espalhar múltiplos blocos application/ld+json:
A vantagem: menos parsing, contexto partilhado, ligações explícitas através de @id. Para LLMs, um grafo coerente é significativamente mais legível do que cinco scripts soltos.
Como os cinco se ligam por @id
Tipo
@id
Liga a
Organization
#organization
Referenciada pelas outras como provider, author, publisher
Rich Results Test, diz o que do seu schema é elegível para rich results no Google.
Inspeção manual no DevTools: copie o JSON, faça o parse, confirme que os @id estão ligados.
Erros típicos que vemos
Duplicação de entidades. Organization redeclarada em cada página em vez de referenciada por @id.
@id em falta. O schema funciona, mas os LLMs tratam cada bloco como entidade independente.
FAQPage com perguntas fabricadas. A equipa inventa perguntas amigas do SEO em vez de copiar perguntas reais. Resultado: descredibiliza tudo.
Article sem dateModified. Os modelos preferem citar conteúdo recente; sem dateModified, ficam sem sinal de atualização.
Perguntas frequentes
JSON-LD. É a única que o Google recomenda explicitamente, é a mais limpa para manter (separa a marcação semântica do HTML de apresentação), e é o que os LLMs extraem com maior fidelidade. Microdata e RDFa ainda são suportados por compatibilidade, mas não vale a pena começar por aí em 2026.
Qualquer um dos dois funciona, a especificação não obriga. No App Router do Next.js, o padrão típico é injetar com um componente JsonLd dentro do return da página (no body, antes do conteúdo). Em estáticos, é mais limpo no head. Nos dois casos, usar uma só script tag por bloco semântico evita duplicação.
Não é obrigatório, mas é a diferença entre ter um conjunto de entidades soltas e ter um grafo coerente. Com @id estáveis (como https://example.com/#organization) pode referenciar a mesma entidade de várias páginas sem duplicar. Os motores e os LLMs preferem fortemente grafos ligados.
Schema irrelevante ou inventado é pior do que não ter schema. Cada tipo deve corresponder a algo real na página. Marcar uma página de preços como Recipe é claramente errado; marcar como AggregateOffer faz sentido. Regra: se não consegue defender porque o pôs lá, tire.
Diego MoraesCTO
Abrir no ChatGPT
Abrir no Claude