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

Qualquer um dos dois funciona — a especificação não obriga. Em Next.js App Router, o pattern típico é injectar com um componente JsonLd dentro do return da page (no body, antes do conteúdo). Em estáticos, é mais limpo no head. Em ambos os 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://teu-site.com/#organization) podes referenciar a mesma entidade de várias páginas sem duplicar. Os motores e LLMs preferem fortemente grafos ligados.

Schema.org para SaaS B2B: o mínimo viável em JSON-LD

Q: Microdata, RDFa ou JSON-LD?

JSON-LD. É a única que o Google recomenda explicitamente, é a mais limpa para manter (separa 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.

Q: 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 pricing como Recipe é claramente errado; marcar como AggregateOffer faz sentido. Regra: se não consegues defender porque puseste, tira.

Resumo

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 @ids estáveis e ligações entre eles, são o mínimo viável para começar a ser citável por IA. Este post 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
@ids estáveis transformam entidades soltas em grafo
Validar em validator.schema.org e Rich Results Test
Schema irrelevante é pior do que ausência de schema

Porque 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>, classes CSS, contexto). Em schema, é explícito: @type: Organization.

Para motores tradicionais, schema desbloqueia rich results (estrelas, FAQ expandida, breadcrumbs visíveis). Para LLMs, schema é a única forma fiável de saber, sem ambiguidade, o que cada coisa é. Quando o ChatGPT cita “Acme é uma consultoria de cibersegurança em Lisboa”, está a inferir essas três coisas — o que é, o que faz, onde — e 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 EU.",
  "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 (links para perfis externos consistentes — LinkedIn, GitHub, Wikipedia 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 via 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, AggregateOffer com lowPrice sinaliza a entrada sem se comprometer com tabela exposta. Funciona bem para “a partir de €X” sem revelar o ceiling.

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 queries reais que os clientes fazem — não a queries inventadas pela equipa de marketing.

4. BreadcrumbList

Pequeno mas importante. Ajuda os crawlers a perceber a hierarquia das tuas páginas. Devolve resultado visível em 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: mainEntityOfPage deve apontar para um WebPage que tu efectivamente emites (não um @id que nunca existe). articleSection ajuda LLMs a categorizar. author e publisher referenciam o Organization via @id em vez de duplicar dados.

O conceito de @graph (e porque importa)

Se tiveres várias entidades na mesma página, podes embrulhá-las num @graph em vez de espalhar múltiplos blocos <script type="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",         ... }
  ]
}

Vantagem: menos parsing, contexto partilhado, ligações explícitas via @id. Para LLMs, um grafo coerente é significativamente mais legível que cinco scripts soltos.

Validação obrigatória

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

validator.schema.org — verifica conformidade com a especificação.
Rich Results Test — diz o que do teu schema é elegível para rich results no Google.
Inspecção manual no DevTools: copia o JSON, parseia, confirma @ids 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. Schema funciona, mas LLMs tratam cada bloco como entidade independente.
FAQPage com perguntas fabricadas. Equipa inventa perguntas “seo-friendly” em vez de copiar perguntas reais. Resultado: descredibiliza tudo.
Article sem dateModified. Modelos preferem citar conteúdo recente; sem dateModified, ficam sem sinal de actualização.

Perguntas frequentes

Microdata, RDFa ou JSON-LD?

JSON-LD. Único recomendado pelo Google, mais limpo de manter, e extracção mais fiel pelos LLMs.

Onde colocar o JSON-LD?

Head ou body funcionam. Em Next.js App Router, dentro do return da page com um componente JsonLd dedicado. Uma script tag por bloco semântico.

Quanto schema é demais?

Schema irrelevante é pior que ausência. Se não consegues defender porque puseste, tira.

Fontes

schema.org — vocabulário canónico
Google Search Central — Structured Data
validator.schema.org
Glossário GEO — schema.org / Structured Data