Toda equipe de SEO faz a mesma coisa toda semana: abre planilha, lista keywords candidatas, busca volume no Keyword Planner, abre top 10 do Google em cada uma, anota gaps, prioriza por intuição. Leva 4-8 horas, depende de uma pessoa específica, e o resultado é inconsistente entre semanas. Quase ninguém mantém esse ritmo por mais de 3 meses.
A alternativa é um radar SEO automatizado — um sistema que faz essa pesquisa sozinho, semanal ou diário, e te entrega uma lista priorizada de oportunidades novas. Não substitui o estrategista (ainda precisa de alguém decidindo o que publicar), mas elimina o trabalho braçal de descoberta. Este artigo descreve a arquitetura do radar que rodamos na ZAP API: pipeline de 4 camadas com SerpAPI, Google Ads Keyword Planner, LLM scoring e cache Redis.
O que um radar SEO precisa entregar
Antes da arquitetura, o output. Um radar útil entrega, por execução:
- Lista de oportunidades novas — não keywords já publicadas, não keywords obviamente ruins
- Volume estimado real — não chute do LLM, número do Keyword Planner
- Dificuldade aproximada — quão competitivo é, em escala simples (Baixa/Média/Alta)
- Intenção — informacional, comercial, navegacional, transacional
- "Por que agora" — uma linha justificando por que essa oportunidade vale a pena (gap, tendência, etc.)
- Top-N ordenado por score — não 200 sugestões; 10-15 priorizadas
Se o radar te dá isso semanalmente, você economiza ~5h/semana de trabalho de pesquisa e ganha consistência. Se te dá 200 sugestões sem priorização, você economiza 0h — só transferiu o trabalho para "ler a lista".
Pipeline de 4 camadas
Camada 1: Seed keywords + base publicada
O radar precisa de dois inputs estáticos:
- Seed keywords do seu nicho — 6-10 termos guarda-chuva. No nosso caso: "api whatsapp", "whatsapp api", "chatbot whatsapp", "automação whatsapp", "whatsapp business api", "integração whatsapp", "enviar mensagem whatsapp programaticamente", "whatsapp bot".
- Slugs já publicados — lista do que você já tem no ar. Crucial para o radar não sugerir o que você já cobriu.
Esses dois inputs ficam hardcoded ou em config — não mudam toda semana. A cada execução do radar, ele expande os seeds e cruza com a base publicada.
Camada 2: SerpAPI — descoberta lateral
SerpAPI é um serviço que retorna o SERP do Google estruturado em JSON. Para o radar, usamos 4 endpoints:
- autocomplete — sugestões do Google search quando você começa a digitar a seed. Cada seed gera 8-15 sugestões.
- related searches — bloco "Pesquisas relacionadas" no rodapé do SERP. Outras 8-12 keywords por seed.
- people also ask (PAA) — caixa "As pessoas também perguntam". Perguntas reais dos usuários, geralmente boas long-tails.
- top 10 organic results — para análise dos H1/H2 dos concorrentes em cada keyword candidata.
// Pseudocódigo da coleta SerpAPI
async function fetchSerpInsights(seed: string) {
const [autocomplete, search] = await Promise.all([
fetch(`https://serpapi.com/search?engine=google_autocomplete&q=${encodeURIComponent(seed)}&hl=pt-br&gl=br&api_key=${SERP_KEY}`),
fetch(`https://serpapi.com/search?engine=google&q=${encodeURIComponent(seed)}&hl=pt-br&gl=br&api_key=${SERP_KEY}`),
]);
const ac = await autocomplete.json();
const s = await search.json();
return {
autocompleteSuggestions: ac.suggestions.map((x: { value: string }) => x.value),
relatedSearches: (s.related_searches ?? []).map((x: { query: string }) => x.query),
peopleAlsoAsk: (s.related_questions ?? []).map((x: { question: string }) => x.question),
topOrganic: (s.organic_results ?? []).slice(0, 10),
};
}Com 8 seeds, você recolhe ~150-250 keywords candidatas por execução. É muito — daí a necessidade das camadas seguintes para filtrar e priorizar.
Camada 3: Google Ads Keyword Planner — volume real
SerpAPI te dá ideias; KP te dá números. Para cada candidata, você consulta:
avgMonthlySearches— média mensal de buscas (Brasil, pt-BR)competition— Baixa / Média / Alta (para SEM, mas é proxy razoável para dificuldade orgânica)competitionIndex— score 0-100 para granularidade
// Pseudocódigo (Google Ads API v15)
async function fetchKeywordVolumes(keywords: string[]) {
const adsClient = new GoogleAdsApi({
client_id: process.env.GOOGLE_ADS_CLIENT_ID,
client_secret: process.env.GOOGLE_ADS_CLIENT_SECRET,
developer_token: process.env.GOOGLE_ADS_DEVELOPER_TOKEN,
});
const customer = adsClient.Customer({ /* manager account ID */ });
const response = await customer.keywordPlanIdeas.generateKeywordIdeas({
keyword_seed: { keywords },
geo_target_constants: ["geoTargetConstants/2076"], // Brasil
language: "languageConstants/1014", // Português
});
return response.results.map(r => ({
keyword: r.text,
avgMonthlySearches: Number(r.keyword_idea_metrics?.avg_monthly_searches ?? 0),
competition: r.keyword_idea_metrics?.competition,
competitionIndex: r.keyword_idea_metrics?.competition_index,
}));
}Detalhe importante: nem toda keyword candidata tem volume mensurável no KP. Keywords ultra-long-tail ou de nicho muito específico aparecem como zero. Isso não significa que não há tráfego — apenas que o KP não tem dado suficiente. Tratamos volume zero como "Long-tail experimental" no scoring, não descartamos.
Camada 4: LLM scoring + gap analysis
Você tem agora ~200 candidatas com volume e dificuldade. Hora de priorizar. Esta é a camada onde o LLM brilha — não para inventar volumes (já temos), mas para fazer julgamento qualitativo que humano faria: "essa keyword combina com nosso produto?", "essa intenção converte?", "gap real ou só barulho?".
const prompt = `
Você é estrategista de SEO especializado no nicho de [seu produto].
Base já publicada (NÃO sugerir variações destas):
${publishedSlugs.join("\n")}
Candidatas para análise (com volume real):
${candidates.map(c => `- "${c.keyword}" (${c.avgMonthlySearches}/mês, competição: ${c.competition})`).join("\n")}
Análise:
1. Filtre candidatas que já são variações triviais da base publicada
2. Score cada uma de 0-100 considerando: volume + intenção comercial + gap real
3. Devolva top 15 ordenadas, com "why" explicando por que é boa oportunidade
JSON output:
{
"opportunities": [
{
"rank": 1,
"topic": "tópico descritivo do artigo",
"keyword": "keyword principal",
"volumeEstimate": "X/mês",
"difficulty": "Baixa|Média|Alta",
"intent": "informacional|comercial|transacional",
"why": "por que vale a pena AGORA",
"alreadyCovered": false
}
]
}
`;O LLM faz duas coisas que humano faria: filtra ruído (variações como "api whatsapp 2026" se você já cobriu "api whatsapp") e prioriza por intenção comercial (uma keyword com 100 buscas/mês mas intenção transacional pura vale mais que 5000/mês informacional difusa).
Modelo recomendado: Claude Haiku ou GPT-4o-mini. Não precisa de Sonnet — é tarefa estruturada (JSON), não prosa. Custo baixíssimo, ~$0.01-0.05 por execução.
Cache Redis 24h
SerpAPI custa por chamada (~$0.005-0.015 cada). Google Ads KP tem cota diária. LLM custa por token. Se você roda o radar 100 vezes no dia, queima dinheiro à toa — os SERPs não mudam dramaticamente em 24h.
Solução: cache Redis em três níveis:
// Pseudocódigo de cache layered
async function runSeoRadar() {
const cacheKey = "seo-radar:result";
const cached = await redis.get(cacheKey);
if (cached) return JSON.parse(cached); // hit no resultado final
const candidates: KeywordCandidate[] = [];
for (const seed of SEED_KEYWORDS) {
const serpKey = `seo-radar:serp:${seed}`;
let serp = await redis.get(serpKey);
if (!serp) {
serp = JSON.stringify(await fetchSerpInsights(seed));
await redis.set(serpKey, serp, "EX", 86400); // 24h
}
candidates.push(...extractCandidates(JSON.parse(serp)));
}
const volumesKey = `seo-radar:volumes:${hash(candidates)}`;
let volumes = await redis.get(volumesKey);
if (!volumes) {
volumes = JSON.stringify(await fetchKeywordVolumes(candidates.map(c => c.keyword)));
await redis.set(volumesKey, volumes, "EX", 86400);
}
const result = await scoreWithLLM(candidates, JSON.parse(volumes), publishedSlugs);
await redis.set(cacheKey, JSON.stringify(result), "EX", 86400);
return result;
}Cada camada tem cache independente — se você só quer forçar refresh do scoring (mexeu nos seeds ou na base publicada), invalida só a chave de scoring e mantém SerpAPI/volumes cachados. Economia direta.
Endpoint público de refresh: POST /seo/radar/refresh com auth (super-admin no nosso caso) limpa as 3 chaves e força execução fresca. Útil quando o admin vê que algo mudou no SERP (concorrente lançou algo novo) e quer dados frescos.
Para mais sobre o stack de coleta SERP integrado ao pipeline editorial, veja também como rodamos o pipeline editorial IA multi-agente em produção.
Adaptando para outro nicho
O radar é arquiteturalmente nicho-agnóstico. O que você troca para adaptar:
- SEED_KEYWORDS — 6-10 termos guarda-chuva do seu nicho
- PUBLISHED_SLUGS — lista do que você já publicou
- Prompt do LLM scoring — descreve seu produto, seu ICP, sua oferta. Quanto mais específico, melhor o scoring.
- Geo/language nos endpoints — Brasil pt-BR vs EUA en-US vs UE multi-lang
O resto — SerpAPI client, KP client, LLM adapter, cache Redis, response shape — é genérico. Em volume de código real, ~80% é reutilizável.
O radar gera as oportunidades; nosso conteúdo nasce dele. Quer ver o produto que esse pipeline serve? Crie sua conta grátis na ZAP API — 7 dias de trial, sem cartão.
Limitações e quando NÃO usar
Sendo honesto sobre onde o radar quebra:
- Nicho com baixíssimo volume de busca — se seu mercado total fica em 100-500 buscas/mês para todas as keywords relevantes, SerpAPI + KP não vão te dar sinal útil. Volume zero domina, scoring fica chutado. Nesse caso, descoberta manual em comunidades do nicho (Reddit, Discord, fóruns) bate qualquer radar.
- Mercado regulado com terminologia muito específica — saúde, jurídico, financeiro. Termos técnicos não aparecem em autocomplete (volume baixo no público geral) mas convertem alto no público certo. LLM scoring genérico vai sub-pontuar essas keywords. Solução: fine-tune do prompt com exemplos do seu domínio.
- Conteúdo de notícia / breaking news — radar diário é tarde demais para news. Você precisa de monitoramento real-time (Google Trends API, Twitter API, etc.), não pipeline de descoberta.
- Volume real de publicação muito baixo — se você só publica 1 artigo por mês, fazer radar semanal é desperdício. Faz mais sentido pesquisar manual e profundo para esse 1 artigo.
Custo operacional realista
Para um nicho médio (8 seeds, ~200 candidatas por execução, 1 execução/dia), aproximado:
- SerpAPI: ~$30-50/mês (plano de 5k searches)
- Google Ads KP: gratuito (precisa conta Google Ads ativa, mas não precisa rodar campanhas)
- LLM scoring (Haiku): <$5/mês
- Redis: ~$5/mês (managed) ou self-hosted
Total: ~$40-60/mês para o stack. Compare com salário de SEO junior dedicado a descoberta (~R$3-5k/mês) e a matemática fecha em qualquer projeto sério. Importante: o radar não substitui o estrategista (quem decide o quê publicar, edita o tom, garante qualidade do output) — substitui só o trabalho braçal de descoberta.
FAQ — Radar SEO automatizado
Vocês open-source o radar?
O código que rodamos é integrado ao nosso stack (DB, auth, cache Redis específico). Não faz sentido open-source o codebase como está. Mas o pattern arquitetural está descrito neste artigo — você consegue replicar em qualquer stack moderna. Bibliotecas necessárias: SDK SerpAPI, Google Ads Node lib, adapter LLM (veja nosso artigo), driver Redis.
Posso rodar sem SerpAPI? É caro?
Pode, scraping direto do Google funciona — mas atenção a três armadilhas: (1) Google bloqueia datacenters agressivamente, você precisa de proxies residenciais (que custam mais que SerpAPI); (2) parsing do HTML do SERP muda toda semana, manutenção é dor de cabeça; (3) People Also Ask, Featured Snippets e Related Searches são componentes que mudaram de layout 5 vezes em 2 anos. SerpAPI mantém o parser para você. ~$50/mês é barato pelo headache que economiza.
Quantas keywords o radar pode processar por execução?
Sem cache, ~200 candidatas em ~90 segundos (gargalo é SerpAPI + Google Ads KP). Com cache hit, ~5 segundos (só o LLM scoring roda). Não recomendamos processar mais que 500 por execução — perde foco e o LLM scoring fica pior em volume alto. Melhor rodar 2x com seeds diferentes que 1x com seeds duplicados.
O radar funciona para conteúdo em inglês?
Sim, mudando 3 coisas: (1) hl=en-us&gl=us nos endpoints SerpAPI; (2) language=languageConstants/1000 no Google Ads KP; (3) prompt do LLM scoring em inglês. Para EUA + Brasil ao mesmo tempo, rode duas vezes em paralelo com configs diferentes — não tente unificar, intenção comercial varia por país.
Como integrar o radar com o pipeline editorial?
Output do radar é input do pipeline. Topo da lista (rank 1-3) vai automaticamente para a fila de geração. Posição 4-15 fica em backlog para revisão humana. Quando admin aprova um item do backlog, dispara runSeoOrchestrator(item.topic) e o pipeline editorial assume. Loop completo: radar descobre → admin prioriza → pipeline gera → revisão edita → publica.
O radar consegue detectar quando uma keyword nova começa a subir?
Não no design básico mostrado aqui — radar é fotografia, não filme. Para detecção de tendência, precisa de série histórica: rode o radar diariamente, persista os volumes de cada keyword no DB, compare semana atual com semana anterior. Keywords com delta positivo >30% são tendências emergentes. Esse é trabalho de uma camada adicional, não complexa mas precisa ser projetada desde o início.
Existe risco de viés do LLM no scoring?
Existe. LLM treinado com dados americanos pode subestimar keywords brasileiras de nicho. Forma de mitigar: (1) prompt explícito sobre o mercado-alvo; (2) revisão humana semanal nos top 5 sugeridos — se aparecer padrão de erro, ajuste o prompt; (3) métrica de qualidade pós-publicação — keyword sugerida pelo radar virou artigo, depois de 90 dias mediu tráfego orgânico. Score de acerto histórico do radar te ajuda a calibrar confiança nas próximas sugestões.
A ZAP API é construída com o mesmo nível de automação interna. Conteúdo, deploy, monitoramento — tudo pipeline. Crie sua conta e veja como funciona uma API de WhatsApp construída por engenheiros. Comece grátis — 7 dias sem cartão.