SEO Técnico

Guia de programmatic SEO em WordPress

Programmatic SEO em WordPress feito com disciplina, não planilha exportada pro formulário do plugin. Arquitetura em 4 camadas, importer PHP idempotente e os erros que transformam escala em thin content.

· 12 min de leitura

Programmatic SEO, quando funciona, é uma das alavancas de crescimento mais eficientes que existem. Você gera dezenas ou centenas de páginas a partir de uma fonte estruturada (planilha, banco, API), cada uma atacando uma cauda longa específica, e o tráfego orgânico escala não-linearmente depois que o Google indexa.

Quando não funciona, é um desastre em câmera lenta. O Google detecta thin content, rebaixa o domínio inteiro, e 3 meses depois você está tentando entender por que o blog principal também caiu.

A diferença entre os dois cenários é arquitetura. Este guia descreve o motor que eu rodo em WordPress pra publicar a escala sem queimar domínio.

Quando programmatic SEO faz sentido

Três pré-condições. Se uma falta, procure outro alavanca.

  1. Você tem dado estruturado que vira conteúdo útil. Catálogo de produtos com especificações, lista de cidades com dados oficiais de saúde, 114 exames laboratoriais com preparo e valores de referência. Dado cru + template de boa qualidade vira página útil. Planilha de palavras-chave aleatórias vira spam.
  2. Cada página tem valor próprio. Se você não consegue explicar em uma frase por que um usuário humano acharia útil visitar aquela página, o Google também não vai achar.
  3. Volume ≥ 100 páginas e crescendo. Pra menos que isso, não vale o overhead. Escreve à mão.

No case 6 (SanarMed Exames) publicamos 114 páginas A-Z de exames laboratoriais, cada uma com preparo, indicação, valores de referência, interpretação. Três pré-condições atendidas. Resultado, +295% em keywords orgânicas e 5,6K sessões/mês no hub /exames/.

A arquitetura em 4 camadas

Arquitetura de programmatic SEO em quatro camadas Quatro camadas empilhadas que, juntas, produzem centenas de páginas a partir de uma planilha-fonte. A camada 1 é a planilha como fonte da verdade, a 2 é o importer PHP idempotente que converte linhas em posts, a 3 é o CPT com schema.org, e a 4 é o sistema de internal linking que conecta as páginas geradas. PROGRAMMATIC SEO · 4 CAMADAS · PLANILHA → 100+ PÁGINAS CAMADA 01 · SINGLE SOURCE OF TRUTH Planilha-fonte (Google Sheets ou Excel, 6 abas tipadas) CAMADA 02 · IDEMPOTÊNCIA VIA HASH Importer PHP via wp-cli (hash por linha, reexecutável N vezes) CAMADA 03 · CONTEÚDO ESTRUTURADO CPT + taxonomias + schema.org automático (Article, MedicalWebPage, Product) CAMADA 04 · INTERNAL LINKING QUE FECHA O LOOP template hubs + spokes + embeddings (fecha com o case 7)

Quatro camadas empilhadas. Cada uma tem uma responsabilidade clara e não invade as outras. Desenho assim é o que permite manter o motor ao longo de anos sem virar espaguete.

Camada 01, a planilha como single source of truth

Google Sheets ou Excel com 6 abas tipadas. No caso dos Exames:

  • aba exames, uma linha por exame. Colunas, slug, title, indication, preparation, reference_values, category, body.
  • aba categorias, a taxonomia que agrupa os exames (hematologia, bioquímica, etc). Uma linha por categoria.
  • aba subcategorias, 2ª camada de agrupamento se necessária.
  • aba sinonimos, mapping de nomes alternativos pro nome canônico (pra internal linking).
  • aba referencias, bibliografia citada no corpo. Referência é tabela à parte, FK por id.
  • aba changelog, o que foi revisado quando e por quem. Fica versionado implicitamente pelo próprio Google Docs.

Três coisas importam nessa camada. Primeiro, o time editorial edita aqui, não no WordPress. A planilha é autoritativa. Segundo, os dados têm tipo (enum pra categoria, texto longo pro body, lista pra referências). Terceiro, há um pipeline que exporta a planilha pra um JSON normalizado toda vez que alguém edita. Esse JSON é o input do próximo estágio.

Camada 02, o importer PHP idempotente

Essa é a parte técnica chave. Script PHP rodado via wp-cli, lê o JSON, converte cada linha em um post do CPT correspondente, aplica schema.org. Idempotente significa que pode rodar N vezes sem efeito colateral. O importer detecta o que mudou (via hash MD5 da linha) e só atualiza o que de fato precisa.

// Trecho do importer, hash da linha como checksum
$hash = md5( serialize( $row ) );
$existing = get_page_by_path( $row['slug'], OBJECT, 'exame_medico' );

if ( $existing && get_post_meta( $existing->ID, '_source_hash', true ) === $hash ) {
    continue; // Nenhuma mudança, pula
}

$id = wp_insert_post( $this->map_fields( $row, $existing->ID ?? 0 ) );
update_post_meta( $id, '_source_hash', $hash );
$this->apply_taxonomy( $id, $row['category'] );

Por que idempotência é não negociável no programmatic SEO? Porque o editor vai querer rodar o script 50 vezes durante a vida do projeto. Corrigiu um preparo? Rodou o script. Adicionou 20 exames novos? Rodou. Mudou o template de valores de referência? Rodou. Se cada run pudesse duplicar ou sobrescrever tudo, ninguém usaria.

O guia de importer idempotente entra em mais profundidade nas três estratégias (chave natural, hash, log auditável).

Camada 03, CPT + schema automático

Cada linha da planilha vira um post num Custom Post Type específico (exame_medico, no caso), com taxonomia aplicada, permalink amigável e schema.org injetado pelo próprio importer.

Schema é onde a mágica de AEO acontece. Pra cada tipo de página, um schema adequado:

  • Exames, MedicalWebPage + MedicalTest.
  • CID-10, MedicalWebPage + MedicalCondition.
  • Cidades em catálogo de serviço, Service + areaServed.
  • Produtos, Product com offers, review, aggregateRating.

O schema não é nice-to-have em programmatic SEO. É o que faz o Google distinguir sua página de 100 páginas genéricas com o mesmo template. É também o que faz os AI engines (ChatGPT, Claude, Gemini) citarem sua página como fonte quando o usuário pergunta algo relacionado.

Um detalhe operacional, valide o schema com o Rich Results Test no primeiro post gerado antes de deixar o importer processar os 114. Schema quebrado em escala é dor de cabeça cara.

Camada 04, internal linking que fecha o loop

Sem internal linking, programmatic SEO vira cemitério de páginas órfãs. Cada página precisa ter um caminho de entrada do restante do site, e cada página precisa linkar pra páginas relacionadas.

Dois padrões complementares:

1. Hub + spokes. A página-categoria (/exames/hematologia/) é o hub. Todas as páginas de exame daquela categoria são spokes, linkam de volta pro hub, e o hub linka pra todos. Site map visual, estrela.

2. Linkagem semântica por embeddings. No topo de cada página de exame, um bloco "Exames relacionados" puxado via similarity search no pgvector. Isso escala sem marcação manual e cruza naturalmente entre categorias (o que é ouro pra cobertura de cauda longa).

O case 7 entra nesse detalhe, e a combinação de programmatic SEO + linkagem por embeddings é o que transforma um "banco de páginas" num ecossistema navegável.

Os quatro erros que transformam escala em thin content

  1. Template com 80% de conteúdo repetido. Se o cabeçalho, o disclaimer, a seção "sobre este exame" e os CTAs são idênticos em todas as páginas, e só o nome do exame muda, o Google detecta template-heavy content. Solução, coloque conteúdo variável em maior proporção. Valores de referência específicos, casos de uso, indicações clínicas, bibliografia.
  2. Sem dado único por página. Se a página de "Exame X" não tem nenhum dado que só ela tem, não existe razão pra ela existir. Thin content é Google-speak pra "essa página não agrega nada que outras 50 não agregariam".
  3. Geração a partir de LLM sem revisão humana. LLM gera conteúdo competente mas genérico. Pro Google, genérico é morte. O motor que roda no Sanar tem revisão médica obrigatória antes da publicação, case 1.
  4. Indexação precipitada. Publicar 500 páginas de uma vez e deixar o Google descobrir é pior que publicar em ondas de 50 com 2 semanas entre cada. O crawl budget é finito e o Google penaliza sites que parecem ter spam em massa. Publica aos poucos, monitora qualidade por coorte.

Métricas que importam

  1. Indexação rate por coorte. Dos 50 publicados na semana X, quantos estão indexados em 30 dias? Se menos de 70%, algo no template está sinalizando thin.
  2. Impressões médias por página indexada. Meta realista, 5 a 50 impressões/mês por página programática. Se for abaixo, a cauda longa não está sendo capturada (problema de title, schema ou linkagem).
  3. Sessões orgânicas no hub. O hub (categoria) deve concentrar 30-40% do tráfego agregado das páginas-filho. Se for menos, internal linking está fraco.
  4. Keywords únicas cobertas. Proxy de cauda longa. O case 6 entregou +295% de keywords em produção.

Ordem recomendada pra implementar

  1. Defina a planilha-fonte com 2-3 abas pequenas e valida com 10 linhas.
  2. Escreve o importer PHP rodando via wp-cli em ambiente de staging. Testa idempotência rodando 5 vezes.
  3. Gera 10 páginas em staging. Valida schema no Rich Results Test. Abre no browser e confere se o conteúdo é útil.
  4. Aplica internal linking básico (hub + spokes). Ainda em staging.
  5. Sobe pra produção com as primeiras 30-50 páginas. Publica no sitemap, aguarda Google descobrir.
  6. Monitora indexação por 15 dias. Se > 70% indexou e está aparecendo em impressão, publique a próxima onda.
  7. Itere. Adiciona embeddings pro internal linking quando o volume justificar (>500 páginas).

Programmatic SEO em WordPress não é simples mas é sistemático. Com as 4 camadas certas, a planilha vira página útil, o Google confia, e o gráfico de keywords orgânicas cresce em curva não-linear. Sem elas, vira o pesadelo de thin content que todo mundo já viu.

Projetos relacionados: Arquitetura de conteúdo e scaffold PHP para import em escala e Linkagem semântica por embeddings em 5 propriedades Sanar.

Continuar lendo