O Pipeline de SEO com n8n: Do Google Search Console ao WordPress
Arquitetura completa de um pipeline de SEO com n8n: extração de dados do GSC, análise de concorrência, scoring e rascunhos com IA direto no WordPress.
Antigamente, equipes de SEO precisavam de pesquisadores para achar palavras-chave, redatores para o conteúdo e designers para as imagens. Hoje, um dos meus clientes opera esse pipeline inteiro com apenas uma pessoa. Ela aprova as ideias, revisa os rascunhos antes da publicação e pronto.
Essa eficiência não veio de "jogar IA no problema" e torcer para o resultado ser bom, mas de construir uma automação estruturada.
Aqui está os bastidores de como esse sistema foi montado.
Por Que Dois Workflows, e Não Apenas Um?
O instinto ao montar um pipeline de SEO é fazer algo linear: dados entram, post sai. O problema é que a pesquisa de palavras-chave e a geração de conteúdo têm ritmos e modos de falha completamente diferentes.
A análise do GSC (Google Search Console) roda por agendamento: semanal ou mensal. Ela popula um backlog de ideias. Já a geração de conteúdo roda sobre esse backlog apenas quando alguém aprova um item. Se você unir tudo em um único workflow, ou o conteúdo rodará demais (gastando API com termos inúteis) ou de menos (atrasando o timing da pesquisa).
Por isso, usamos dois workflows: o primeiro cuida da estratégia e o segundo cuida da execução.
Workflow 1: Do GSC a um Backlog Priorizado
Este workflow começa com a API do Google Search Console, consultada em duas etapas.
Primeiro, extraímos as consultas reais do site em uma janela de 90 dias. Filtramos os termos de marca e o que sobra é o cenário orgânico real: o que as pessoas realmente buscam para chegar até você. Esses termos viram sementes para a fase de pesquisa.
A pesquisa roda no Perplexity (modelo sonar-pro). Escolhi o Perplexity em vez de um modelo de chat padrão pelo acesso à web em tempo real. Isso garante que as sugestões reflitam o que está ranqueando agora, e não o que estava nos dados de treinamento de meses atrás. Ele nos devolve uma lista de oportunidades de "cauda longa" com estimativa de intenção e dificuldade.
Aqui entra o filtro que a maioria das automações esquece: para cada sugestão, o workflow faz uma nova consulta ao GSC para ver se o site já ranqueia para aquele termo.
- Se o ranking for zero: Oportunidade de criação.
- Se já estiver bem ranqueado: Descartamos.
- Se estiver na posição 8+ ou com CTR baixo: Sinalizamos para atualização.
Os termos aprovados vão para uma planilha do Google com título sugerido, formato (guia, lista, etc.) e contagem de palavras. Status: AGUARDANDO.
O Filtro Humano: A Etapa Crucial
A planilha é onde o humano decide o que realmente será produzido.
Não adianta automatizar tudo se a IA não sabe que você vai lançar um produto novo semana que vem ou que a estratégia de links internos mudou. O cliente revisa a lista e altera o status para APROVADO. Só então o segundo workflow entra em cena.
Workflow 2: Da Planilha ao Rascunho no WordPress
Quando uma linha é aprovada, o segundo workflow assume. O Perplexity escreve o artigo em HTML, já estruturado para o WordPress (H2s corretos, links internos e sem "lixo" de formatação).
Em seguida, um modelo menor da OpenAI gera prompts para o DALL-E criar a imagem de destaque e imagens internas, que são enviadas direto para a biblioteca de mídia do WordPress.
O post aterrissa no WordPress como rascunho (draft). Nesse momento, um último passo da OpenAI lê o post pronto e gera os metadados de SEO (título e descrição) baseados no texto real, e não apenas no título inicial.
A planilha recebe o ID do post, a URL e o status muda para ESCRITO.
O Segundo Filtro Humano
O post está pronto, mas ainda é um rascunho. Nada vai ao ar sem um olhar humano. E esta é uma decisão de produto.
Conteúdo automatizado que se publica sozinho é um risco jurídico e de marca. Um erro factual, uma citação de fonte duvidosa ou um tom inadequado pode custar muito mais caro que o tempo economizado em dez posts. O passo de revisão é o que torna a automação confiável o suficiente para rodar em escala.
Na prática, essa revisão é leve. A estrutura do artigo veio de um briefing validado. O direcionamento de palavras-chave veio de dados reais do GSC. As diretrizes de tom de voz estão no prompt do sistema. O que o humano busca é correção e ajuste, não uma reescrita total. Na maioria das vezes, o editor apenas verifica se os links internos/externos estão corretos e clica em publicar.
A Divisão entre Dois Modelos
O Perplexity cuida da pesquisa de palavras-chave e da escrita do artigo. A OpenAI cuida da estratégia de títulos, da geração de prompts de imagem e dos metadados de SEO.
Cada um faz o que realmente é bom. A conexão com a web do Perplexity o torna superior para pesquisa e para escrever conteúdos que referenciam informações atuais — as citações que ele adiciona aos artigos são links reais, não inventados. O GPT-4o-mini da OpenAI é suficiente para a tarefa determinística de gerar prompts de imagem e barato o suficiente para rodar em lote sem pressão de custo. Um modelo menor da OpenAI produz saídas estruturadas limpas e com limite de caracteres de forma confiável, que é exatamente o que você precisa ao gerar metadados que devem caber em limites estritos de caracteres.
O Que Falha (e Como Corrigimos)
O ponto de falha mais comum é a etapa de conteúdo do Perplexity sob carga pesada — às vezes ele sofre timeout ou retorna um HTML truncado. O workflow possui lógica de repetição com atraso (retry with backoff), que resolve a maioria dos casos, mas um artigo cortado que chega ao WordPress é um problema. O filtro de revisão humana o captura, mas é algo que vale monitorar.
A lógica de pontuação (scoring) também precisa de calibração por site. Os limites padrão (descartar com 50+ impressões, atualizar se posição ≥ 8 ou CTR ≤ 2%) são pontos de partida razoáveis, não verdades universais. Um site que recebe 500 impressões por palavra-chave precisa de limites diferentes de um que tem média de 20. Vale a pena rodar algumas semanas apenas do workflow de análise, sem a parte de conteúdo, para auditar o que ele teria criado antes de automatizar tudo.
O pipeline de imagens ocasionalmente produz imagens que são tecnicamente corretas, mas com um tom errado para o conteúdo. Um blog de culinária que recebe uma imagem abstrata geométrica porque o prompt não foi específico o suficiente é um problema menor resolvido na revisão. Um site SaaS B2B que recebe a mesma imagem já exige um ajuste mais sério nos prompts do sistema.
O Que Este Pipeline NÃO É
Não é um sistema de "dispare e esqueça". Os dois filtros humanos são a parte principal da arquitetura. Removê-los para ganhar tempo é o caminho mais rápido para ter 200 posts publicados em um mês nos quais ninguém confia e ninguém lê — e você acaba penalizado pelo Google.
Também não é um substituto para uma estratégia de conteúdo. O pipeline é bom em identificar quais palavras-chave têm lacunas de oportunidade com base nos dados atuais do GSC. Ele não conhece o seu posicionamento, a distribuição das etapas do seu funil ou o que o seu público realmente se importa neste trimestre. Essas decisões ainda pertencem a um humano. O pipeline apenas as executa com eficiência.
Nas empresas onde implementei isso, uma única pessoa gerencia todo o fluxo de produção de conteúdo — revisando o backlog, aprovando itens e revisando rascunhos antes da publicação. O volume que eles conseguem sustentar com esse quadro de funcionários é o grande diferencial. Os padrões de automação com n8n por trás disso escalam para pipelines ainda mais complexos, mas o caso de uso de SEO é onde o ROI é mais imediato.
Estou transformando esses workflows em templates para equipes que querem rodar isso internamente. Se você precisa de algo similar ou quer entender como adaptar para o seu nicho, veja como eu trabalho.