Escalando updates de SEO com Claude Code: como transformei 14 etapas num pipeline

Toda página que já ranqueia decai com o tempo. Nada dramático: sem penalidade, sem update de algoritmo pra culpar. Só uma deriva lenta. A posição cai um degrau, as impressões seguem estáveis enquanto os cliques somem em silêncio, e um AI Overview come o topo do resultado. O Google percebe antes do seu dashboard.

O ângulo é engenharia, não truque: atualizar uma página viva é diferente de criar uma do zero. Você tem links internos apontando pra ela, schema no lugar e um histórico que pode ser destruído por descuido. Alex Galinos, na Search Engine Land, conta ter visto times "refrescarem" uma página em decaimento reescrevendo tudo de cima a baixo e perderem todos os rankings. Isso não é refresh, é rebaixamento auto-infligido.

Aviso honesto sobre este texto: a fonte descreve a arquitetura do sistema (quais skills existem, o que cada uma faz, a integração via MCP com o Strapi), mas não publica o código das skills, o SKILL.md, os prompts nem o config do MCP server. Então isto aqui é um guia de arquitetura reproduzível na estrutura, não um copiar-e-colar. Onde a fonte não abre o código, eu digo explicitamente.

Por que a janela é de 56 dias

O diagnóstico começa numa janela fixa de 56 dias no Search Console. Não 90 dias, não um ano. É larga o bastante pra ser confiável e estreita o bastante pra ficar dentro de uma estação, o que importa em site sazonal (o exemplo é um marketplace de transfers com milhares de páginas em nove idiomas).

O número não é aleatório: 56 dias equivalem a 8 semanas, o período máximo de teste da ferramenta de SEO testing usada (SEOTesting). A mesma janela vira baseline travado antes de uma palavra mudar e é reusada quando a atualização vai ao ar. É a única forma honesta de saber se o update fez algo, em vez de ter dado sorte com a data de publicação.

Dentro dos dados, três coisas mandam:

• Top queries: têm que ser preservadas, custe o que custar.
• Striking-distance (posições 5 a 20, CTR fraco): as vitórias baratas.
• Zero-click (muita impressão, quase nenhum clique): a página aparece pra uma intenção que ela não responde.

O coração: taggear cada seção

Essa disciplina de rotular é praticamente o jogo inteiro. Cada bloco recebe uma etiqueta:

• Keep: ainda ranqueia, ainda correto. Não toca.
• Fix: ideia certa, execução velha. Reescreve no lugar.
• Remove: errado, redundante ou atrapalhando.
• Add: o dado diz que falta algo.

Só as seções fix e add são reescritas. Na página do aeroporto de Antalya, isso gerou copy atualizada e um único add: um seletor de personas, o "Expert Airport Transfer Finder". Detalhe: o componente não inventa informação nova, ela já existia espalhada pela página. Ele só dá a cada visitante um caminho direto pro pedaço que interessa.

Um passo que quase todo mundo pula: fact-check inclusive nas seções keep. Ficar não significa continuar verdadeiro. Distâncias, preços, tempos de trajeto, terminais, tudo é reverificado contra fontes atuais.

Preservar a equity de SEO

A regra é preservar por padrão, salvo motivo específico:

• O slug da URL nunca muda.
• O meta title fica se está ganhando CTR.
• Schema é estendido, não substituído.
• Links internos checados nos dois sentidos.

O resultado numa página

Na página de Antalya, medido contra o baseline de 56 dias travado antes de qualquer mudança:

• Cliques/dia: de 39,55 para 49,00 (+23,88%)
• Posição média: de 14,89 para 10,87
• CTR: de 1,49% para 1,79% (+0,30pp)
• Queries/dia: +6,28%

Todas as métricas se moveram na direção certa ao mesmo tempo, o que é raro: a maioria dos updates que sobe um número derruba outro em silêncio.

Transformando em sistema com Claude Code

Feito à mão, o processo dá cerca de dois dias por página. Multiplique por milhares de páginas e a conta não sobrevive à realidade. A solução foi mapear as 14 etapas em Claude skills e deixar o Claude Code rodar o processo. O julgamento não foi pra máquina, a aplicação desse julgamento foi.

A base é um projeto Claude pré-carregado com brand book, termos, política de preços e material de referência, pra que as restrições de marca estejam sempre em contexto. Segundo a fonte, cada etapa vira uma skill nomeada, com um encadeamento assim:

• hoppa-intelligence → puxa a janela GSC de 56 dias e trava o baseline
• Audit Skill → taggeia keep/fix/remove/add contra performance real de query
• Competitor-Gap Skill → puxa gaps do Ahrefs e leitura de SERP
• Editorial Intelligence → revalida personas com gates rígidos: sem persona validada, sem conhecimento local atual e sem ângulo definido, não avança
• hoppa-editorial → escreve só fix/add, calibrado contra benchmarks de tom
• hoppa-scientific-refiner → fact-check que promove keep reprovado para fix
• Image-Auditor → checa imagem (precisa, on-brand, spec)
• seo-preservation → trava slug, protege meta title e estende schema

O que a fonte não mostra (e você precisaria escrever): o conteúdo de cada SKILL.md, os prompts internos, como as skills são invocadas na CLI do Claude Code e como os resultados passam de uma pra outra. Se você for replicar, é aqui que mora o trabalho real, não é plug-and-play.

O deploy via MCP

O ciclo fecha com o Claude conectado ao CMS Strapi por um servidor MCP. O deploy roda em staging, faz diff seção a seção contra a página viva, verifica links internos e de âncora, e valida schema. Se algo falha, ele para e sinaliza em vez de publicar quebrado; quando tudo passa, gera um relatório único pra um humano aprovar.

De novo, a fonte descreve o comportamento mas não publica o config do MCP server nem o manifesto de conexão com o Strapi. Quem quiser reproduzir precisa montar o próprio servidor MCP apontando pra API do Strapi. É viável (o Strapi expõe REST/GraphQL), mas o código não veio no material.

O tropeço: paralelismo mata qualidade

A tentação óbvia foi rodar dois updates em paralelo. Tecnicamente funciona, nada dá erro. Mas a qualidade cai nos dois: os runs compartilham os mesmos agentes, os diagnósticos ficam rasos, os briefs frouxos e o texto precisa de mais edição. A decisão foi rodar um update por vez, sequencialmente. Mais lento no papel, mas é a diferença entre output confiável na primeira leitura e output que precisa de segunda passada.

Nos números agregados: 59 testes completos, 7 em cada 10 páginas com aumento de cliques orgânicos, 2.284 cliques adicionais líquidos, compras orgânicas +24,9% e receita orgânica +20% contra baseline. A lição pra quem publica no Brasil: automatize a execução, nunca o julgamento, e trave o baseline antes de mexer em qualquer coisa.

Fonte: Search Engine Land