Schema em landing page: o que marcar e o que ignorar

O que schema é, e o que ele não faz

Schema é um vocabulário padronizado para descrever coisas de um jeito que máquina entende sem ter que adivinhar. Você olha a página e sabe que "Rua Santa Cruz, 210" é um endereço e que "das 18h às 23h" é horário de funcionamento. O buscador precisa inferir isso do texto solto. Com dados estruturados, você diz explicitamente.

A implementação recomendada hoje é JSON-LD: um bloco de dados em formato JSON dentro de uma tag <script type="application/ld+json"> no HTML. Ele fica separado do conteúdo visível, então não quebra layout e não atrapalha nada.

Agora a parte que quase todo artigo sobre o assunto erra:

O que schema pode entregar são três coisas concretas: resultados enriquecidos (estrelas, horário, perguntas expandidas, migalhas de navegação no lugar da URL crua), elegibilidade para recursos específicos do buscador, e compreensão mais confiável por qualquer sistema que leia a página, incluindo assistentes de IA. Nada disso é ranqueamento. Se alguém te vender schema como técnica de subir posição, desconfie do resto do que essa pessoa disser.

Os quatro tipos que importam para negócio local

Schema.org tem centenas de tipos. Para uma landing page de serviço, quatro resolvem quase tudo.

LocalBusiness

É o principal para quem atende presencialmente ou numa região. Descreve o negócio: nome, endereço, telefone, horário, área atendida. Existem subtipos mais específicos que vale usar quando encaixam, como Restaurant, Dentist, LegalService ou HealthAndBeautyBusiness. Subtipo certo é mais informativo que o genérico.

Se o negócio não tem endereço físico de atendimento, por exemplo um encanador que vai até o cliente, o tipo correto não é LocalBusiness com endereço fictício. Use o campo de área atendida e omita o endereço, ou considere descrever o serviço em vez do estabelecimento.

Service

Descreve o que você vende, separado de quem vende. Serve bem quando a landing page é sobre um serviço específico e não sobre o negócio inteiro. Liga-se ao prestador, à área atendida e, quando existe, à faixa de preço.

FAQPage

Marca as perguntas e respostas que já estão visíveis na página. Aqui cabe uma correção importante, porque muito material em português ainda promete o que não existe mais: o Google restringiu bastante a exibição do resultado enriquecido de FAQ na busca comum. Marcar FAQ hoje quase nunca vai gerar aquele bloco expansível que você vê em prints antigos de artigo.

Isso não torna a marcação inútil. Ela continua ajudando qualquer sistema a identificar pares de pergunta e resposta na sua página, o que importa cada vez mais para quem é lido por assistente. Só não implemente esperando estrelinha na busca.

BreadcrumbList

Descreve o caminho da página dentro do site, do tipo Início, Serviços, Conserto de vazamento. É o tipo com o efeito visual mais confiável ainda hoje: substitui a URL crua no resultado de busca por uma trilha legível. Barato de implementar e útil quando o site tem mais de um nível.

O que é perda de tempo marcar

Existe uma tentação de marcar tudo que o vocabulário permite. Isso adiciona peso e risco sem adicionar benefício. Os casos mais comuns de esforço desperdiçado:

• WebPage e WebSite vazios. Só com nome e URL, não informam nada que o buscador já não tenha. O SearchAction dentro de WebSite, que gerava a caixa de busca no resultado, foi descontinuado pelo Google.
• Article numa landing page. A página não é um artigo. Marcar como se fosse não gera recurso nenhum e cria contradição entre o que você declara e o que a página é.
• Product sem oferta real. Serviço não é produto. Sem preço, disponibilidade e moeda, a marcação fica inválida ou ignorada.
• Vários blocos de Organization repetidos em cada seção. Um por página basta, e blocos conflitantes atrapalham mais que ajudam.
• Tipos duplicados que se contradizem. Declarar dois horários diferentes em dois blocos é pior que não declarar nenhum: você entregou informação errada com aparência de precisão.

A regra que evita penalidade: marque só o que está na página

Esta é a diretriz que mais gente quebra por descuido, e é uma das poucas áreas de SEO técnico com ação manual como consequência, não apenas com o recurso deixando de aparecer.

As diretrizes do Google para dados estruturados são explícitas: o conteúdo marcado precisa estar visível para o usuário na mesma página. Não vale marcar o que só existe no JSON. Os exemplos que aparecem na prática:

• Marcar FAQPage com perguntas que não existem no texto visível.
• Declarar horário de funcionamento diferente do horário escrito na página.
• Colocar aggregateRating com nota que não vem de avaliação nenhuma exibida ali.
• Marcar preço no schema e esconder o preço do visitante.
• Marcar endereço de uma cidade em que você não tem operação, para tentar aparecer lá.

Como o bloco fica, na prática

Como este site não usa bloco de código nos artigos, vai a estrutura descrita. O JSON-LD é uma tag <script type="application/ld+json"> colocada dentro do <head> ou no fim do <body>. Dentro dela vai um objeto JSON que sempre começa com dois campos: "@context": "https://schema.org" e "@type" com o tipo escolhido, por exemplo "LocalBusiness".

Depois disso, os campos do negócio. Para um LocalBusiness de serviço local, estes são os que valem preencher:

• name: o nome do negócio, exatamente como aparece na página e no perfil do Google.
• url: a URL da própria página.
• telephone: telefone em formato internacional, do tipo +55 12 98815-0491.
• address: um objeto PostalAddress, com streetAddress, addressLocality (a cidade), addressRegion (a sigla do estado), postalCode e addressCountry como BR.
• geo: um objeto GeoCoordinates com latitude e longitude, quando há endereço físico.
• openingHoursSpecification: uma lista de objetos com dayOfWeek, opens e closes em formato de 24 horas.
• areaServed: as cidades ou a região que você atende de verdade.
• priceRange: uma faixa curta, do tipo $$, se você exibe isso na página.
• image: URL absoluta de uma foto real do lugar ou do trabalho.
• sameAs: uma lista com os endereços dos seus perfis oficiais, como Instagram, LinkedIn e o perfil do negócio no Google. É como o buscador liga a página à mesma entidade em outros lugares.

Duas notas de sintaxe que costumam quebrar a validação: JSON não aceita vírgula sobrando depois do último item de uma lista, e todo texto entra entre aspas duplas. Se o seu texto tiver aspas dentro, escape com barra invertida. Um erro de vírgula invalida o bloco inteiro, silenciosamente.

Para juntar mais de um tipo na mesma página, o caminho limpo é usar um @graph: um único script com uma lista de objetos, cada um com seu @id, e as referências entre eles feitas por esse @id. Isso evita blocos soltos que se repetem e se contradizem.

Como testar, e o que cada ferramenta responde

São três ferramentas com finalidades diferentes, e confundir isso gera diagnóstico errado:

A ordem que economiza tempo: valide a sintaxe primeiro, cheque a elegibilidade depois, e só então espere o Search Console confirmar dias mais tarde. E um lembrete que parece bobo e não é: o rastreador precisa conseguir ler a página para ler o schema. Se a página não está indexada, ou se o JSON-LD é injetado por JavaScript depois do carregamento, a marcação pode simplesmente não existir do lado de lá. Quando o schema some sem explicação, vale rodar o diagnóstico de indexação antes de mexer no JSON.

Quem mais lê o seu schema

Dados estruturados nasceram para buscador, mas hoje o público mudou. Assistentes de IA leem HTML e se beneficiam muito de informação já desambiguada: telefone identificado como telefone, horário como horário, cidade como cidade. É a diferença entre extrair um dado com confiança e chutar a partir de um parágrafo.

Como esses rastreadores costumam não executar JavaScript, existe uma consequência prática direta: coloque o JSON-LD no HTML entregue pelo servidor, nunca via gerenciador de tags ou script que roda no navegador. Se o bloco só aparece depois da execução, ele existe para o seu navegador e não existe para eles. Esse assunto tem mais camadas, e reuni em como fazer sua página ser lida por IA.

Por onde começar, se for começar hoje

1. Um bloco de LocalBusiness, com o subtipo mais específico que couber, preenchido só com o que está visível na página.
2. BreadcrumbList, se o site tem mais de um nível de navegação.
3. Service, se a landing page é sobre um serviço específico.
4. FAQPage, se você já tem uma FAQ real e visível. Sem inventar pergunta para preencher.
5. Validar nas duas ferramentas, corrigir o que aparecer, e não olhar mais até mudar alguma informação do negócio.

Depois disso, pare. Schema é a parte mais fácil de fazer bem e a mais fácil de exagerar. Uma página com quatro blocos corretos está melhor servida que uma com doze blocos aproximados, e leva um décimo do tempo para manter.