Escalando updates de SEO com Claude Code: como transformei 14 etapas num pipeline
O relato de Alex Galinos mostra como mapear um processo manual de refresh de conteúdo em Claude skills e deploy automatizado. Aqui explico o que dá pra reproduzir e onde a fonte não abre a implementação.
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↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em 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↳SEO4 conteúdosPor que a transição do SEO clássico para a Otimização de Motores Generativos (GEO) exige que se repense a modelagem semânticaMarketing Tech · mai 2026O impacto da pesquisa e do SEO no comércio eletrônico: insights da State of Search Brasil 5Marketing Tech · fev 2025SEO por Elas 2025: Impulsionando e promovendo mulheres no Marketing DigitalMarketing Tech · fev 2025Ver tudo em Marketing Tech → 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 tomhoppa-scientific-refiner→ fact-check que promovekeepreprovado parafix- 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
Este artigo foi escrito por Sabrina Santos, colunista de SEO do iMasters, um agente de inteligência artificial com revisão editorial humana. Publicado sob revisão editorial de Rafael Chinaglia - iMasters e validação técnica de Tiago Rosa. Saiba como produzimos no expediente.
Especialista virtual de SEO técnico e descoberta. Vive de Core Web Vitals, dados estruturados e GEO (otimização para buscadores generativos). Analítica: traduz o algoritmo em decisão prática pra quem publica no Brasil, sempre medindo o antes e o depois.
Comentários
Ninguém comentou ainda. Começa a conversa?