Schema markup para médicos em 2026: o código invisível que decide o ranking

Existe um código invisível que define grande parte do ranqueamento de sites médicos em 2026. Ele não aparece para o paciente, não muda o visual da página, não tem nada a ver com design ou copywriting. É o schema markup, um conjunto de tags em JSON-LD que adicionamos ao HTML para explicar ao Google e às IAs o que cada peça da página significa. Em sites médicos, schema deixou de ser detalhe técnico. É a fundação que separa quem o Google entende como entidade médica clara do que ele trata como mais um site sobre saúde.

Em 2026, com a integração das IAs ao ecossistema de busca, schema ganhou peso adicional. O ChatGPT Search, o Gemini, o Perplexity, todos leem schema markup com prioridade para identificar quem é o autor de cada conteúdo, qual a especialidade declarada, onde fica o consultório, qual a credencial. Sem schema, o site fica semanticamente mudo. Com schema bem implementado, ele fala claro o suficiente para ser citado em respostas geradas por IA.

Sou Fernanda Tavares, consultora SEO para médicos e clínicas. Este artigo é o guia técnico mais completo que escrevi até hoje. Vou explicar o que é schema markup, por que importa, quais são os 8 schemas essenciais para sites médicos em 2026, como implementar cada um, como validar, e quais são os erros mais comuns. É leitura técnica, mas vou manter linguagem acessível e exemplos concretos. Para o contexto mais amplo de como o Google avalia sites médicos, vale ler também o artigo sobre YMYL e E-E-A-T para médicos.

O que é schema markup e por que ele existe

Schema markup é um vocabulário comum criado pelas grandes empresas de busca (Google, Microsoft, Yahoo, Yandex) em parceria, hospedado no site Schema.org. O objetivo é dar aos algoritmos uma forma estruturada de entender o conteúdo das páginas web. Em vez de inferir, eles leem.

Imagine uma página com a biografia de um médico. Sem schema, o algoritmo precisa adivinhar: aquele texto que começa com "Dr. João Silva é cardiologista..." é uma biografia? Aquele número CRM 12345 é um identificador profissional? Aquele endereço é onde ele atende? Adivinhar funciona às vezes, mas é falível.

Com schema markup, você declara explicitamente. No JSON-LD, escreve: este objeto é do tipo Physician, o nome é João Silva, a especialidade é Cardiology, o CRM é 12345/SP, o endereço é Rua X, número Y. O algoritmo lê e entende sem ambiguidade.

Essa clareza tem três consequências práticas. Primeiro, eleva a chance de aparecer em rich results (resultados visuais avançados, painéis de conhecimento, FAQs expandidas). Segundo, fortalece a identidade do site no ecossistema semântico do Google e das IAs. Terceiro, melhora a probabilidade de ser citado em AI Overview e em respostas do ChatGPT, Gemini e Perplexity.

JSON-LD, microdata, RDFa: qual formato usar

Schema.org aceita três formatos de implementação: JSON-LD, microdata e RDFa. Em 2026, JSON-LD é a recomendação universal do Google e o padrão de fato da indústria. As razões são três.

JSON-LD fica em um bloco isolado no head ou body do HTML, separado do conteúdo visual. Isso facilita manutenção, validação e atualização. Microdata e RDFa misturam tags semânticas ao HTML do conteúdo, o que torna mais difícil manter consistência ao longo do tempo.

JSON-LD é mais legível para desenvolvedores e para IAs. A estrutura de chaves e valores é direta. Microdata exige interpretar atributos espalhados pelas tags HTML.

JSON-LD é mais flexível para múltiplas entidades. Em sites médicos, é comum ter na mesma página um Physician, uma MedicalBusiness, um Article e um FAQPage. Em JSON-LD, todas essas entidades convivem em um único bloco, conectadas por @id.

A partir daqui, todo exemplo neste artigo usa JSON-LD.

Os 8 schemas essenciais para sites médicos em 2026

Antes de mergulhar em cada um, vou listar os 8 schemas que considero fundamentais para qualquer site médico sério em 2026. Vou explicar cada um nas seções seguintes, com exemplos de implementação.

1. Physician. Identifica o profissional médico individual. Onde fica: na página Sobre, em rodapé global (versão resumida) e em páginas de autor.

2. MedicalBusiness ou MedicalClinic. Identifica a clínica como entidade. Onde fica: na Home, na página Contato, em rodapé global.

3. MedicalSpecialty. Indica a especialidade médica praticada. Vinculado ao Physician e à MedicalBusiness.

4. MedicalWebPage ou Article. Usado em artigos do blog. MedicalWebPage tem campos extras úteis (audience, lastReviewed, reviewedBy). Article é o fallback genérico.

5. FAQPage. Para perguntas frequentes. Forma direta de aparecer em rich results de FAQ e em AI Overview.

6. BreadcrumbList. Estrutura de navegação. Ajuda o Google a entender hierarquia do site.

7. Review e AggregateRating. Para avaliações dos pacientes. Em conformidade com o CFM, podem fortalecer Trustworthiness, como detalhei em publicidade médica e CFM em 2026.

8. Place ou LocalBusiness. Para localização física. Conecta o site ao Google Meu Negócio e à busca local. Detalhei a parte de GMN no artigo de 15 categorias do Google Meu Negócio para médicos.

Physician: identificando o profissional médico

O schema Physician é a peça central da identidade do médico individual no ecossistema semântico do Google. Os campos obrigatórios e recomendados em 2026 são:

name (nome completo), image (foto profissional, URL absoluta), telephone, address (endereço estruturado), medicalSpecialty (uma ou mais especialidades), availableService (lista de serviços oferecidos), worksFor (clínica onde atua, com link para MedicalBusiness), alumniOf (instituição de formação), memberOf (sociedades médicas), description (biografia curta), url (URL canônica do perfil).

Exemplo de Physician em JSON-LD básico:

{
  "@context": "https://schema.org",
  "@type": "Physician",
  "@id": "https://siteexemplo.com.br/sobre.html#medico",
  "name": "Dr. Nome Sobrenome",
  "image": "https://siteexemplo.com.br/foto.jpg",
  "telephone": "+55-11-99999-9999",
  "url": "https://siteexemplo.com.br/sobre.html",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "Rua Exemplo, 123, sala 45",
    "addressLocality": "São Paulo",
    "addressRegion": "SP",
    "postalCode": "01234-567",
    "addressCountry": "BR"
  },
  "medicalSpecialty": "Cardiovascular",
  "alumniOf": [
    {"@type": "EducationalOrganization", "name": "Universidade Exemplo"}
  ],
  "memberOf": [
    {"@type": "Organization", "name": "Sociedade Brasileira de Cardiologia", "url": "https://www.cardiol.br"}
  ],
  "description": "Médico cardiologista com 16 anos de prática clínica..."
}

Pontos críticos: o medicalSpecialty deve usar um dos valores do enum MedicalSpecialty do Schema.org (Cardiovascular, Dermatology, Gynecology, etc.). O CRM e o RQE podem ser representados via campo identifier com um schema secundário, ou via description. O Google ainda não tem campo nativo para CRM brasileiro, mas pode-se complementar com dados estruturados extras.

MedicalBusiness e MedicalClinic: a clínica como entidade

MedicalBusiness é a categoria genérica, e MedicalClinic é uma subclasse mais específica para clínicas. Para a maioria dos sites médicos brasileiros, MedicalClinic é a escolha mais precisa.

Campos essenciais: name, image, address (com mesmo formato do Physician), telephone, url, openingHoursSpecification (horário de funcionamento estruturado), priceRange (faixa de preço, opcional, usar com cuidado), paymentAccepted (formas de pagamento), medicalSpecialty (especialidades atendidas), department (médicos do corpo clínico, opcional).

Exemplo de MedicalClinic em JSON-LD:

{
  "@context": "https://schema.org",
  "@type": "MedicalClinic",
  "@id": "https://siteexemplo.com.br/#clinica",
  "name": "Clínica Exemplo",
  "image": "https://siteexemplo.com.br/clinica.jpg",
  "url": "https://siteexemplo.com.br/",
  "telephone": "+55-11-99999-9999",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "Rua Exemplo, 123",
    "addressLocality": "São Paulo",
    "addressRegion": "SP",
    "postalCode": "01234-567",
    "addressCountry": "BR"
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday"],
      "opens": "08:00",
      "closes": "18:00"
    }
  ],
  "medicalSpecialty": ["Cardiovascular","Dermatology"]
}

Importante: o openingHoursSpecification deve refletir exatamente o horário do Google Meu Negócio. Inconsistência entre site e GMN é uma das causas mais comuns de queda de Trustworthiness em sites médicos.

MedicalSpecialty: o tag da especialidade

MedicalSpecialty no Schema.org é, na verdade, um enum (lista fixa de valores válidos) usado dentro de outros schemas, principalmente Physician e MedicalBusiness. Não é um schema standalone, é um campo.

Os valores aceitos pelo Schema.org seguem nomenclatura americana, então é preciso fazer a correspondência. Cardiovascular para Cardiologia, Dermatology para Dermatologia, Gynecology para Ginecologia, Obstetric para Obstetrícia, Pediatric para Pediatria, Orthopedic para Ortopedia, e por aí vai.

Em 2026, o Google passou a aceitar também especialidades não enumeradas como string livre, mas a recomendação ainda é usar o enum quando há correspondência. Para especialidades muito específicas (por exemplo, Cirurgia plástica reparadora pediátrica), a string livre é aceita.

MedicalWebPage vs Article: o que usar em cada caso

Para os artigos do blog, há duas opções principais. Article é o schema genérico, aplicável a qualquer conteúdo editorial. MedicalWebPage é a subclasse específica para conteúdo médico, com campos extras úteis.

MedicalWebPage tem três campos extras importantes: audience (público-alvo, geralmente Patient para conteúdo educativo aberto), lastReviewed (data da última revisão clínica do conteúdo), reviewedBy (médico que revisou). Esses três campos são lidos pelo Google como sinais fortes de qualidade YMYL.

Recomendação prática: use MedicalWebPage para artigos do blog que tratam de tema médico específico (descrição de doença, sintomas, exames, procedimentos). Use Article para conteúdo institucional ou editorial não-clínico (notícias da clínica, perfis profissionais, conteúdo de marketing).

Exemplo de MedicalWebPage:

{
  "@context": "https://schema.org",
  "@type": "MedicalWebPage",
  "@id": "https://siteexemplo.com.br/blog/refluxo.html",
  "name": "Refluxo gastroesofágico: sintomas, causas e tratamento",
  "url": "https://siteexemplo.com.br/blog/refluxo.html",
  "audience": {"@type": "MedicalAudience", "audienceType": "Patient"},
  "lastReviewed": "2026-06-23",
  "reviewedBy": {"@type": "Physician", "@id": "https://siteexemplo.com.br/sobre.html#medico"},
  "datePublished": "2024-08-15",
  "dateModified": "2026-06-23"
}

FAQPage: a peça que mais aparece em rich results e AI Overview

FAQPage é, em 2026, o schema com melhor relação esforço/resultado para sites médicos. Implementação simples, impacto alto. Aparece em rich results expandidos no Google, em AI Overview médico, em respostas do ChatGPT Search e do Perplexity.

A estrutura é direta: um FAQPage contém um mainEntity, que é uma lista de Question, cada um com seu acceptedAnswer.

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "O que é refluxo gastroesofágico?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Refluxo gastroesofágico é a passagem..."
      }
    }
  ]
}

Boas práticas: cada pergunta deve ter resposta com 40 a 100 palavras (curto demais não aparece em rich result, longo demais é truncado). Cada pergunta deve corresponder a uma pergunta real do paciente. Não inventar perguntas para inflar o schema. O Google detecta e penaliza FAQs inflados.

BreadcrumbList: a estrutura de navegação invisível

BreadcrumbList é a hierarquia de navegação do site representada em schema. Em sites médicos, ajuda o Google a entender como cada página se posiciona na estrutura geral.

Exemplo para um artigo de blog:

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {"@type": "ListItem", "position": 1, "name": "Home", "item": "https://siteexemplo.com.br/"},
    {"@type": "ListItem", "position": 2, "name": "Blog", "item": "https://siteexemplo.com.br/blog/"},
    {"@type": "ListItem", "position": 3, "name": "Refluxo gastroesofágico"}
  ]
}

O último item geralmente não tem campo item (porque é a página atual). Aparece como pão de migalha em rich results e ajuda navegação dentro do Google.

Review e AggregateRating: avaliações em compliance com CFM

Review é o schema para uma avaliação individual. AggregateRating é o schema para a média de várias avaliações. Em sites médicos, é possível usar ambos, com cuidado para respeitar o CFM.

Importante: as avaliações exibidas com schema Review devem ser sobre atendimento, infraestrutura, pontualidade, organização. Avaliações que envolvem descrição de resultado clínico ou diagnóstico do paciente não devem aparecer publicamente, como detalhei em publicidade médica e CFM em 2026.

Exemplo de AggregateRating no MedicalBusiness:

"aggregateRating": {
  "@type": "AggregateRating",
  "ratingValue": "4.9",
  "reviewCount": "127",
  "bestRating": "5",
  "worstRating": "1"
}

O Google verifica plausibilidade. Perfis com 200 avaliações 5 estrelas sem nenhuma 3 ou 4 estrelas geram alerta de manipulação e podem perder rich result.

Place e LocalBusiness: conectando ao mundo físico

Place é o schema genérico para localização. LocalBusiness é a subclasse para negócios locais. Para clínicas médicas com endereço físico fixo, MedicalClinic já cobre LocalBusiness, então geralmente não é preciso adicionar separado.

O ponto crítico aqui é consistência. O endereço, telefone e horário declarados no schema do site precisam ser idênticos aos do Google Meu Negócio. Qualquer divergência é interpretada como sinal de fraqueza institucional.

Como implementar schema markup no site

A implementação técnica de schema markup em JSON-LD é direta. Você adiciona um bloco script no head ou body do HTML:

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

O bloco pode estar em qualquer lugar do HTML, embora o head seja a convenção. Você pode ter múltiplos blocos JSON-LD na mesma página (um para Physician, outro para MedicalBusiness, outro para Article, outro para FAQPage). Ou pode combinar tudo em um único bloco usando @graph.

Para sites estáticos, o JSON-LD é editado diretamente no HTML. Para sites em WordPress, plugins como Yoast SEO ou Rank Math geram automaticamente os schemas básicos, e plugins específicos (Schema App, Schema Pro) permitem customização avançada para sites médicos.

A consistência entre páginas é crítica. O @id de cada entidade deve ser único e estável. Se o Physician tem @id "https://siteexemplo.com.br/sobre.html#medico", esse mesmo @id deve aparecer quando o Physician for referenciado em outra página. Isso permite ao Google entender que se trata da mesma entidade.

Como validar schema markup

Duas ferramentas oficiais para validação. Rich Results Test (search.google.com/test/rich-results) testa se a página é elegível para resultados visuais avançados do Google e aponta erros. Schema Markup Validator (validator.schema.org) valida a estrutura técnica do JSON-LD independentemente da elegibilidade.

Fluxo recomendado: implemente o schema, cole a URL no Rich Results Test, corrija os erros que aparecem, cole no Schema Markup Validator, faça os ajustes finais. Esse processo de 10 a 15 minutos por página garante implementação correta.

Para monitoramento contínuo, o Google Search Console reporta erros de schema nos sites já indexados, na seção Aprimoramentos. Sites bem implementados não devem ter erros ali. Erros recorrentes indicam problema estrutural que precisa ser corrigido.

Os 7 erros mais comuns em schema markup médico

Em auditorias que faço, vejo os mesmos erros se repetirem. Os sete mais comuns:

Erro 1, schema ausente. Site médico sem nenhum schema markup. Em 2026, é equivalente a estar invisível para o Google estruturado.

Erro 2, schema genérico em vez de médico. Usar Organization em vez de MedicalClinic. Funciona, mas perde os campos médicos específicos e o sinal de identidade médica.

Erro 3, MedicalSpecialty errada ou ausente. Cardiologista com medicalSpecialty vazio ou com valor não-padrão. Perde elegibilidade para painel de conhecimento.

Erro 4, inconsistência entre páginas. Endereço diferente no schema da Home e no schema da página Contato. Sinaliza fraqueza institucional.

Erro 5, FAQPage inflado. Perguntas fabricadas só para inflar schema. Detectado e penalizado.

Erro 6, Review fabricado. Avaliações inventadas no schema. Penalização severa, em alguns casos manual.

Erro 7, schema não validado. Implementação cheia de erros sintáticos que invalidam o JSON-LD inteiro. Site fica como se não tivesse schema. Valide sempre.

Schema markup avançado: a próxima fronteira

Para médicos que querem ir além do básico, em 2026 há três frentes avançadas que valem investimento.

Encadeamento de entidades. Usar @id para conectar Physician à MedicalBusiness, à MedicalSpecialty, ao Article, ao Review. O Google entende a rede de relações e fortalece a identidade do médico no grafo de conhecimento.

Schema MedicalCondition e MedicalProcedure. Para artigos que tratam de condição médica específica (refluxo, hipertensão, diabetes) ou procedimento (rinoplastia, ablação cardíaca, cesariana), adicionar schema específico do tema reforça relevância semântica.

Schema Person para autoria. Mesmo dentro de Article, adicionar Person para o autor com sameAs apontando para perfis verificáveis (LinkedIn, Lattes, perfil no CFM, sociedade médica). Em 2026, esse encadeamento de autoria é um dos sinais mais fortes para citação em ChatGPT, Gemini e Perplexity.

Perguntas frequentes sobre schema markup médico

O código invisível que separa quem aparece de quem desaparece

Schema markup é a peça menos visível e mais decisiva do SEO médico em 2026. O paciente nunca vê o JSON-LD. O Google e as IAs leem tudo. Sites que tratam schema como detalhe técnico ficam invisíveis. Sites que implementam schema com seriedade ganham visibilidade duradoura.

A boa notícia é que schema markup é trabalho pontual com efeito contínuo. Uma boa implementação leva entre 8 e 20 horas de trabalho (dependendo do tamanho do site), valida-se uma vez, e passa a render por anos. É um dos investimentos com melhor retorno em SEO médico de longo prazo.

Se você quer implementar schema markup completo no seu site médico, ou auditar o que já existe, posso ajudar. Atendo médicos e clínicas em todo o Brasil com estratégia SEO técnica integrada à construção de presença em IAs.