Planos de saúde Sorocaba: dados estruturados e E-E-A-T num site na 1ª página do Google

No meu artigo anterior contei como levei um site HTML estático de 64 para 97 no PageSpeed. Desta vez o assunto é outro: como o Google sabe quem escreveu o seu conteúdo.

Relembrando: não sou programador. Sou corretor de planos de saúde, sócio de uma corretora com seis consultores, e cuido dos nossos sites. Um deles, sobre planos de saúde em Sorocaba (SP), já aparece na 1ª página do Google para o termo principal. Eu achava que os dados estruturados dele estavam em ordem. Afinal, a home tinha um JSON-LD caprichado, com InsuranceAgency, FAQPage e até um Dataset com números do IBGE e da ANS.

Resolvi conferir página por página. Descobri que 83 das 96 páginas não tinham nenhum dado estruturado.

Transparência: fiz a auditoria e as correções com ajuda de IA (Claude). Os números são do meu site, e eu revisei cada decisão.

Por que isso pesa mais num site de saúde

O Google trata saúde e dinheiro como YMYL ("Your Money or Your Life"): assuntos em que uma informação ruim pode prejudicar a vida de alguém. Nesses temas, ele procura com mais rigor os sinais de E-E-A-T: experiência, especialidade, autoridade e confiabilidade.

Na prática, o Google quer responder a perguntas simples sobre cada página:

• Quem escreveu isto?
• Essa pessoa tem habilitação para falar do assunto?
• Qual empresa responde pelo conteúdo?
• Quando foi atualizado?

O leitor responde olhando a página. Os robôs (do Google e das IAs) respondem melhor quando você diz isso em JSON-LD, de forma explícita e igual em todas as páginas. Foi exatamente aí que o meu site falhou.

A auditoria: 20 linhas de Python

Baixei o site inteiro e rodei um script simples, que só conta o que existe em cada HTML:

import glob, re

paginas = [f for f in glob.glob('**/*.html', recursive=True)
           if len(open(f, 'rb').read()) > 400]  # ignora redirecionamentos

faltando = {'json-ld': 0, 'og:title': 0, 'canonical': 0, 'h1': 0}
ids_autor = set()

for f in paginas:
    s = open(f, encoding='utf-8').read()
    if 'application/ld+json' not in s: faltando['json-ld'] += 1
    if 'og:title' not in s:            faltando['og:title'] += 1
    if not re.search(r'rel=\s*"canonical"', s): faltando['canonical'] += 1
    if '<h1' not in s:                 faltando['h1'] += 1
    ids_autor |= set(re.findall(r'"@id":\s*"([^"]*emerson[^"]*)"', s))

print(len(paginas), faltando)
print(ids_autor)

O resultado, em 96 páginas:

E a última linha do script mostrou outro problema: dois IDs diferentes para a mesma pessoa.

Erro 1: o mesmo autor com dois IDs

Nas poucas páginas que tinham dados estruturados, o autor era declarado assim:

{
  "@type": "Person",
  "@id": "https://.../#emerson-lavieri",
  "name": "Emerson Lavieri",
  "url": "https://.../"
}

Já a página "Sobre a corretora" declarava assim:

{
  "@type": "Person",
  "@id": "https://.../sobre-a-corretora/#emerson",
  "name": "Emerson Lavieri",
  "sameAs": ["https://www.linkedin.com/in/...", "https://....jusbrasil.com.br/"]
}

O @id funciona como a "chave" de uma entidade no grafo. Com dois IDs, o Google pode entender que são duas pessoas diferentes com o mesmo nome: uma sem nenhuma prova de quem é, e outra com LinkedIn e Jusbrasil. A autoridade fica dividida ao meio.

A correção: escolhi um único ID, o da página Sobre (que é onde a pessoa é apresentada de verdade), e coloquei o mesmo nó completo em todas as páginas:

{
  "@type": "Person",
  "@id": "https://.../sobre-a-corretora/#emerson",
  "name": "Emerson Lavieri",
  "url": "https://.../sobre-a-corretora/",
  "jobTitle": "Corretor de seguros – SUSEP nº 201096017",
  "identifier": {
    "@type": "PropertyValue",
    "propertyID": "SUSEP",
    "value": "201096017"
  },
  "sameAs": [
    "https://www.linkedin.com/in/...",
    "https://....jusbrasil.com.br/"
  ],
  "worksFor": { "@id": "https://.../#consult-vida" }
}

O identifier com o registro na SUSEP (o órgão que fiscaliza corretores de seguros no Brasil) é o equivalente ao CRM de um médico: é verificável. E o sameAs liga a pessoa a perfis externos que confirmam quem ela é.

Erro 2: um autor "solto" justamente na home

A home, que é a página mais forte do site, tinha o autor declarado direto dentro do Article:

"author": {
  "@type": "Person",
  "name": "Emerson Lavieri",
  "url": "https://.../"
}

Sem @id, sem LinkedIn e com a URL apontando para a própria home. Também não havia dateModified. Troquei por uma referência ao nó único:

"author": { "@id": "https://.../sobre-a-corretora/#emerson" },
"dateModified": "2026-11-15"

💡 Dica: use @id para tudo que se repete (autor, empresa, site). Você declara o nó completo uma vez no @graph e, no resto, só aponta para ele. Fica mais curto e sem contradição.

Erro 3: 83 páginas sem nada

Aqui foi trabalho braçal, mas com um script dava para fazer com segurança. Cada página ganhou um @graph com cinco peças ligadas entre si:

{
  "@context": "https://schema.org",
  "@graph": [
    { "@type": "WebSite", "@id": "https://.../#website" },
    { "@type": "InsuranceAgency", "@id": "https://.../#consult-vida" },
    { "@type": "Person", "@id": "https://.../sobre-a-corretora/#emerson" },
    {
      "@type": "WebPage",
      "@id": "https://.../pagina/#webpage",
      "isPartOf": { "@id": "https://.../#website" },
      "breadcrumb": { "@id": "https://.../pagina/#breadcrumb" }
    },
    {
      "@type": "Article",
      "headline": "Texto do H1 da página",
      "author": { "@id": "https://.../sobre-a-corretora/#emerson" },
      "publisher": { "@id": "https://.../#consult-vida" },
      "mainEntityOfPage": { "@id": "https://.../pagina/#webpage" },
      "dateModified": "2026-10-07"
    }
  ]
}

(Encurtei os nós aqui. Nas páginas, WebSite, InsuranceAgency e Person vão completos, e entra também um BreadcrumbList.)

Algumas decisões que tomei no caminho:

• headline igual ao H1: o título do artigo nos dados estruturados é o mesmo que o leitor vê.
• dateModified honesto: o script usa a data mais recente que já estava escrita na própria página (por exemplo, "consulta realizada em 07/10/2026") ou a data do sitemap. Não inventei data nova só porque mexi no código.
• Páginas utilitárias à parte: contato e política de privacidade ganharam só WebPage e breadcrumb, sem Article nem autor. Já a página 404 e a página de "mensagem enviada" ganharam noindex.

O que está nos dados precisa estar na página

As diretrizes do Google pedem que os dados estruturados descrevam o que o leitor realmente vê. Não adianta declarar um autor no JSON-LD se a página não mostra quem escreveu.

Por isso, logo abaixo do H1 de cada página entrou uma assinatura visível:

<p class="cv-byline">
  Por <a href="../sobre-a-corretora/">Emerson Lavieri</a>,
  corretor de seguros SUSEP nº 201096017,
  responsável técnico da Consult Vida · Atualizado em outubro de 2026
</p>

Repare que o texto bate com o JSON-LD: o mesmo nome, o mesmo registro e a mesma data. E o link leva para a página Sobre, que é a URL do nó Person.

Hoje, cada página do nosso site de plano de saúde em Sorocaba diz a mesma coisa para o leitor e para o robô: quem escreveu, com qual registro, por qual corretora e quando foi atualizada.

O truque do H1 sem mudar o visual

Dez páginas não tinham H1. Em seis delas, o título real da página estava num <h2> estilizado por um seletor como este:

.especialidade-intro h2,
.bloco-especialidade h2 {
    margin: 0 0 18px;
    line-height: 1.25;
}

Trocar <h2> por <h1> mudaria o visual, porque o tema define h1 { font-size: 60px }. A solução foi incluir o h1 no mesmo seletor e fixar o tamanho:

.especialidade-intro h1,
.especialidade-intro h2,
.bloco-especialidade h2 { ... }

.especialidade-intro h1 { font-size: 36px; }

Para provar que nada mudou, tirei print de página inteira de todas as páginas antes e depois, no desktop e no celular, com o Playwright. Na versão "depois", escondi a assinatura nova com CSS e comparei pixel a pixel com o "antes". Tirando o que eu mudei de propósito, as imagens precisam bater.

E o FAQPage? Ainda vale a pena?

O site tinha FAQPage em várias páginas, e muita gente ainda coloca FAQ esperando aquele "acordeão" de perguntas no Google. Esse resultado acabou:

• Em agosto de 2023, o Google restringiu os resultados de FAQ a sites governamentais e de saúde muito conhecidos, e logo depois deixou de mostrar o HowTo.
• Em maio de 2026, o FAQ deixou de aparecer para todos os sites.

Mantive o FAQPage mesmo assim. Segundo o próprio Google, manter ou remover não afeta a visibilidade na busca, e ele continua descrevendo bem o conteúdo da página. Só não conto mais com ele para ganhar espaço no resultado.

Como validar

• Validador do Schema.org (validator.schema.org): mostra o grafo montado e aponta erros de tipo.
• Teste de resultados avançados do Google (Rich Results Test): mostra o que o Google consegue ler para resultados especiais, como breadcrumb.
• Um json.loads em todos os blocos: um erro de vírgula num JSON-LD invalida o bloco inteiro, e ninguém te avisa. Rodei isso nas 96 páginas antes de subir.

for bloco in re.findall(r'<script[^>]*ld\+json[^>]*>(.*?)</script>', s, re.S):
    json.loads(bloco)  # se quebrar, quebra aqui, e não no Google

Antes e depois

As duas páginas sem JSON-LD são a 404 e a de confirmação de envio do formulário, que agora estão com noindex. Sem H1 ficaram só a página de contato e a de confirmação.

Sobre o efeito no Google: ainda é cedo. O site já estava na 1ª página, e dados estruturados não são um botão de ranking. O que eles fazem é tirar dúvidas do Google sobre quem está por trás do conteúdo. Volto aqui em algumas semanas com o que mudou no Search Console.

Checklist para o seu site

• Rode uma auditoria em todas as páginas, não só na home: a home costuma ser a mais caprichada e esconder o resto.
• Use um @id único para o autor: de preferência a URL da página "Sobre" com um #.
• Ligue o autor a provas externas: sameAs para LinkedIn e outros perfis, e identifier para registros profissionais (SUSEP, CRM, OAB, CREA).
• Mostre na página o que você declara no JSON-LD: nome, registro e data de atualização.
• Não invente datas: dateModified é a data em que o conteúdo mudou, não a data em que você mexeu no código.
• Valide todos os blocos com um parser: um JSON-LD quebrado falha em silêncio.
• Não conte com FAQ para aparecer no Google: mantenha se quiser, mas o resultado especial acabou.

Você já auditou os dados estruturados do seu site página por página? Me conta nos comentários o que encontrou.