Dados estruturados e JSON-LD: guia prático de implementação SEO

前端工程

Dados estruturados ajudam mecanismos de busca a entender do que uma página trata. JSON-LD é a forma mais comum de adicioná-los porque mantém dados legíveis por máquina separados do HTML visível.

Dados estruturados podem tornar uma página elegível para recursos de busca aprimorados, mas não garantem rich results. Google e outros mecanismos decidem o que exibir com base em qualidade da página, intenção da busca, regras de elegibilidade e muitos outros sinais.

Referências úteis:

O que dados estruturados fazem

Dados estruturados dão significado explícito ao conteúdo da página. Em vez de ver apenas texto, um mecanismo de busca pode entender que uma página é um artigo, produto, aplicativo de software, trilha de breadcrumbs, seção FAQ ou outro tipo de entidade reconhecida.

Bons dados estruturados devem:

  • Corresponder ao conteúdo visível da página.
  • Usar o tipo Schema.org mais específico e relevante.
  • Incluir propriedades obrigatórias e recomendadas.
  • Permanecer precisos quando o conteúdo muda.
  • Ser validados antes do deploy.

Não use dados estruturados para descrever conteúdo que usuários não conseguem ver. Esse é um problema comum de qualidade e pode tornar o markup inelegível.

Por que JSON-LD costuma ser o melhor formato

Existem vários formatos de dados estruturados, mas JSON-LD geralmente é o mais fácil de manter.

Formato Como é adicionado Manutenção
JSON-LD Bloco <script type="application/ld+json"> Limpo e separado do HTML
Microdata Atributos dentro de elementos HTML Fácil de quebrar em mudanças de template
RDFa Atributos dentro de elementos HTML Poderoso, mas mais complexo

Com JSON-LD, o markup frontend pode mudar sem reescrever cada atributo de dados estruturados.

Padrão básico de JSON-LD

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Structured Data and JSON-LD: Practical SEO Implementation Guide",
  "description": "Learn how to add JSON-LD structured data safely.",
  "author": {
    "@type": "Person",
    "name": "Sarah Miller"
  },
  "datePublished": "2026-07-16",
  "dateModified": "2026-07-16"
}
</script>

Os campos principais são:

  • @context: normalmente https://schema.org.
  • @type: o tipo Schema.org, como Article.
  • Propriedades: campos que descrevem a entidade, como headline, author ou datePublished.

Markup Article

Use Article, BlogPosting ou NewsArticle para conteúdo editorial. Escolha o tipo que melhor corresponde à página. Para posts comuns de blog, BlogPosting costuma ser adequado.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "How to Split a PDF Safely",
  "description": "A practical guide to extracting and splitting PDF pages.",
  "image": "https://example.com/images/pdf-split-guide.png",
  "author": {
    "@type": "Person",
    "name": "Rachel Kim"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Example Tools",
    "logo": {
      "@type": "ImageObject",
      "url": "https://example.com/logo.png"
    }
  },
  "datePublished": "2026-07-16",
  "dateModified": "2026-07-16",
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://example.com/blog/pdf-split-guide"
  }
}
</script>

Seja honesto com datas. Não atualize dateModified apenas para fazer o conteúdo parecer recente se a página não mudou de verdade.

Markup BreadcrumbList

Dados estruturados de breadcrumb ajudam mecanismos de busca a entender a hierarquia da página.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "Home",
      "item": "https://example.com/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "Blog",
      "item": "https://example.com/blog"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "PDF Split Guide",
      "item": "https://example.com/blog/pdf-split-guide"
    }
  ]
}
</script>

A trilha de breadcrumb no JSON-LD deve corresponder à navegação que usuários conseguem entender na página.

Markup FAQPage

Adicione FAQPage apenas quando a página realmente contém perguntas e respostas visíveis. Não adicione FAQs falsas só para mirar rich results.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Does structured data guarantee rich results?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "No. Structured data can make a page eligible, but search engines decide whether to show enhanced results."
      }
    },
    {
      "@type": "Question",
      "name": "Should JSON-LD match visible page content?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Yes. Markup should describe content that users can also see on the page."
      }
    }
  ]
}
</script>

FAQ markup não é atalho para ocupar mais espaço na busca. Use apenas quando melhora a clareza para usuários.

Markup SoftwareApplication

Para ferramentas online, apps ou software baixável, SoftwareApplication pode descrever o que a página oferece.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "SoftwareApplication",
  "name": "PDF Split Tool",
  "applicationCategory": "UtilitiesApplication",
  "operatingSystem": "Web",
  "url": "https://example.com/pdf/split",
  "description": "Split a PDF into selected pages or smaller files in the browser.",
  "offers": {
    "@type": "Offer",
    "price": "0",
    "priceCurrency": "USD"
  }
}
</script>

Inclua apenas campos verdadeiros. Se adicionar avaliações, reviews, preços ou claims de plataforma, eles devem ser sustentados por conteúdo visível e pelo estado real do produto.

Múltiplos blocos JSON-LD

Você pode incluir mais de uma entidade de dados estruturados em uma página. Por exemplo, um artigo de blog também pode ter breadcrumbs.

Use blocos script separados:

<script type="application/ld+json">{ "...Article data..." }</script>
<script type="application/ld+json">{ "...Breadcrumb data..." }</script>

Ou use um array:

<script type="application/ld+json">
[
  { "@context": "https://schema.org", "@type": "BlogPosting" },
  { "@context": "https://schema.org", "@type": "BreadcrumbList" }
]
</script>

Blocos separados costumam ser mais fáceis de gerar a partir de templates.

Fluxo de validação

Use um fluxo simples antes de publicar:

  1. Gere JSON-LD a partir dos mesmos dados fonte usados pela página.
  2. Verifique se o markup é JSON válido.
  3. Execute a URL ou código no Rich Results Test.
  4. Após indexação, monitore relatórios de dados estruturados no Search Console.
  5. Revalide templates após grandes mudanças de design, rotas ou CMS.

Passar na validação significa que a sintaxe e algumas regras de elegibilidade foram atendidas. Ainda assim não garante rich result.

Erros comuns

Markup não corresponde ao conteúdo visível

Se JSON-LD diz que a página tem reviews, FAQs, preços ou detalhes de autor, usuários devem conseguir verificar esses detalhes na página.

Tipo errado

Não use Product para toda página de ferramenta só porque rich results de produto parecem atraentes. Use o tipo que corresponde à página.

Avaliações falsas ou sem suporte

Markup de review e rating precisa de avaliações reais visíveis. Não invente aggregate ratings.

Datas inconsistentes

datePublished e dateModified devem corresponder ao ciclo real do conteúdo. Atualize datas modificadas apenas quando mudanças significativas acontecerem.

URLs quebradas

URLs de imagem, logo, canonical e página devem ser absolutas, rastreáveis e estáveis.

Incompatibilidade de idioma

Em sites multilíngues, cada página localizada deve ter dados estruturados no mesmo idioma da página, com canonical e alternate links corretos tratados em outra parte da página.

Dicas de implementação

  • Gere dados estruturados a partir do CMS ou metadados da página, não manualmente em cada página.
  • Faça escape correto de texto gerado por usuários para manter JSON válido.
  • Mantenha um template reutilizável para cada tipo de página.
  • Teste páginas representativas, não só a homepage.
  • Revalide após mudar rotas, slugs, perfis de autor ou geração de imagens.
  • Trate warnings como oportunidades de melhoria, mas priorize erros.

Checklist final

Antes de publicar JSON-LD, confirme:

  • O markup descreve conteúdo visível da página.
  • O tipo Schema.org combina com a página.
  • Campos obrigatórios estão presentes.
  • URLs são absolutas e rastreáveis.
  • Datas, autores, títulos e descrições correspondem à página.
  • A página passa no Rich Results Test quando aplicável.
  • Search Console é monitorado após deploy.

Dados estruturados não são truque para forçar resultados de busca mais ricos. São uma forma limpa de tornar explícito o significado da página. Quando são precisos, mantidos e alinhados ao conteúdo visível, aumentam a chance de mecanismos de busca entenderem corretamente o conteúdo.

Experimente estas ferramentas executadas localmente no navegador — nenhum cadastro necessário →

#JSON-LD#结构化数据#SEO#Schema.org#富摘要