Periscopy
Artigos
Metodologia9 min de leitura

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.

1. Organization

O fundamento. Uma entidade Organization por empresa, com @id estável, referenciada por todas as outras entidades como provider, author, publisher.

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://acme.com/#organization",
  "name": "Acme SaaS",
  "url": "https://acme.com",
  "logo": "https://acme.com/logo.png",
  "description": "Plataforma de gestão de inventário para retalhistas da UE.",
  "foundingDate": "2021",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "Rua X, 42",
    "postalCode": "1234-567",
    "addressLocality": "Lisboa",
    "addressCountry": "PT"
  },
  "contactPoint": {
    "@type": "ContactPoint",
    "contactType": "sales",
    "email": "contacto@acme.com",
    "availableLanguage": ["pt-PT", "en", "es"]
  },
  "sameAs": [
    "https://www.linkedin.com/company/acme-saas",
    "https://github.com/acme-saas"
  ],
  "knowsAbout": ["Inventory Management", "Retail Tech", "ERP"]
}

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.

2. Service

Um Service por serviço oferecido. Liga ao Organization através de provider:

{
  "@context": "https://schema.org",
  "@type": "Service",
  "@id": "https://acme.com/#service-inventory",
  "serviceType": "Inventory Management Platform",
  "provider": { "@id": "https://acme.com/#organization" },
  "areaServed": [
    { "@type": "Country", "name": "Portugal" },
    { "@type": "Country", "name": "Spain" }
  ],
  "audience": {
    "@type": "BusinessAudience",
    "audienceType": "Retail SMB"
  },
  "description": "Plataforma SaaS de gestão de inventário em tempo real.",
  "offers": {
    "@type": "AggregateOffer",
    "priceCurrency": "EUR",
    "lowPrice": "99",
    "offerCount": 3
  }
}

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.

3. FAQPage

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.

4. BreadcrumbList

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:

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "@id": "https://acme.com/produto/inventario#breadcrumb",
  "itemListElement": [
    { "@type": "ListItem", "position": 1, "name": "Início",     "item": "https://acme.com" },
    { "@type": "ListItem", "position": 2, "name": "Produto",    "item": "https://acme.com/produto" },
    { "@type": "ListItem", "position": 3, "name": "Inventário", "item": "https://acme.com/produto/inventario" }
  ]
}

5. Article (ou BlogPosting)

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:

{
  "@context": "https://schema.org",
  "@graph": [
    { "@type": "Organization", "@id": "https://acme.com/#organization", ... },
    { "@type": "WebSite",      "@id": "https://acme.com/#website",     ... },
    { "@type": "WebPage",      "@id": "https://acme.com/#webpage",     ... },
    { "@type": "Service",      "@id": "https://acme.com/#service-inv", ... },
    { "@type": "FAQPage",      "@id": "https://acme.com/#faq",         ... }
  ]
}

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.

A validação não é opcional

Schema sem validação é cilada. Antes de fazer deploy, três ferramentas:

  • validator.schema.org, verifica a conformidade com a especificação.
  • 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

Microdata, RDFa ou JSON-LD?

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.

Onde colocar o JSON-LD: no head ou no body?

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.

Tenho de ter @id em todas as entidades?

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.

Quanto schema é demais?

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.

Fontes

Publicado primeiro em destaque.ai/blog/schema-org-saas-b2b-minimo-viavel