← back to the garden

MD

Como construir um sistema pessoal completo de SEO e monitoramento de concorrentes

Projeto técnico e estratégico de uma plataforma pessoal de SEO, com arquitetura, módulos, fontes de dados, bibliotecas, custos, riscos e roteiro de implementação.

  • pesquisa
  • seo
  • monitoramento
  • concorrentes
  • crawler
  • django
  • analytics

Como construir um sistema pessoal completo de SEO e monitoramento de concorrentes

É perfeitamente possível programar um sistema de SEO muito útil para uso pessoal. A dificuldade depende menos do painel e mais do tipo de dado que se pretende obter. Rastrear sites, comparar alterações, auditar páginas, integrar Google Search Console, acompanhar Core Web Vitals e gerar alertas está ao alcance de um desenvolvedor trabalhando sozinho. Manter um índice próprio de bilhões de backlinks, reproduzir volumes globais de palavras-chave ou consultar continuamente resultados do Google em muitos países já é outra categoria de problema.

Esta pesquisa propõe uma plataforma chamada provisoriamente Radar SEO Pessoal. Ela não tenta copiar integralmente Ahrefs, Semrush ou Similarweb. A ideia correta é construir o sistema de decisão, o histórico, o crawler e a interface, aproveitando APIs oficiais para os próprios sites e comprando apenas os dados externos que seriam irracionais de coletar sozinho.

Resumo executivo

Resposta direta

Não é difícil demais, desde que o escopo seja dividido corretamente:

  • um primeiro sistema realmente útil tem dificuldade média;
  • um crawler técnico e um monitor de mudanças podem ser feitos com software livre e custo operacional baixo;
  • Google Search Console, Google Analytics, Bing Webmaster Tools, CrUX e PageSpeed fornecem dados excelentes sobre propriedades próprias;
  • posições no Google, backlinks de concorrentes, volume de palavras-chave e estimativas de tráfego exigem bases externas ou serviços pagos;
  • raspar diretamente a página de resultados do Google não é uma boa fundação: é instável, enfrenta CAPTCHA e o próprio Google classifica consultas automatizadas para verificar posições como tráfego não permitido;
  • o melhor desenho é um monólito modular, não uma coleção de microsserviços;
  • a stack recomendada é Python 3.14 + Django 5.2 LTS + PostgreSQL 18 + Celery 5.6 + Redis + HTMX + Chart.js;
  • para o crawler, usar HTTPX e lxml/selectolax nas páginas comuns, Trafilatura para texto principal, extruct para dados estruturados e Playwright somente como fallback para páginas dependentes de JavaScript;
  • para SERPs, palavras-chave e backlinks, DataForSEO é a primeira opção a testar por permitir consumo granular; SerpApi é uma alternativa focada em resultados de busca, enquanto Semrush oferece dados amplos, mas sua API completa tende a exigir planos e unidades mais caros;
  • o MVP deve começar pelo próprio site e pelo monitoramento de concorrentes, deixando backlinks, IA e estimativas de tráfego para depois.

O produto que vale a pena construir

O melhor resultado não é “mais uma ferramenta que mostra uma pontuação SEO”. É uma central privada que responde diariamente:

  1. O que mudou nos meus sites e nos concorrentes?
  2. Quais posições subiram ou caíram?
  3. Quais páginas perderam cliques, impressões ou conversões?
  4. Que conteúdo novo os concorrentes publicaram?
  5. Que temas eles cobrem e eu ainda não cubro?
  6. Quais problemas técnicos apareceram desde a última varredura?
  7. Quais oportunidades combinam demanda, relevância e capacidade real de execução?
  8. O que merece atenção hoje, em vez de exibir centenas de métricas sem prioridade?

Metodologia e critérios

A pesquisa foi concluída em 26 de julho de 2026. Foram consultadas documentações oficiais do Google, Bing, IndexNow, Django, Python, PostgreSQL, Celery, Scrapy, Playwright e das principais fontes de dados consideradas.

As decisões foram avaliadas pelos seguintes critérios:

  • utilidade para uma única pessoa ou pequena operação;
  • custo de desenvolvimento e manutenção;
  • possibilidade de começar localmente e crescer sem reescrever tudo;
  • qualidade, legalidade e estabilidade das fontes de dados;
  • compatibilidade entre dependências;
  • capacidade de guardar histórico próprio;
  • automação, alertas e interpretação prática;
  • redução de dependência de um único fornecedor;
  • privacidade de credenciais e dados analíticos.

Estimativas de prazo e custo são identificadas como estimativas. Preços, limites e versões de serviços podem mudar e devem ser confirmados antes da implementação.

Onde está a dificuldade de verdade

Parte Dificuldade Custo externo Observação
Cadastro de projetos e concorrentes baixa nenhum CRUD comum
Crawler do próprio site média baixo limites, canonicals e deduplicação exigem cuidado
Monitor de páginas concorrentes média baixo precisa de coleta educada e comparação sem ruído
Auditoria técnica média baixo regras precisam ser explicáveis
Search Console e GA4 média nenhum ou baixo OAuth e normalização são o trabalho principal
Core Web Vitals e Lighthouse média baixo laboratório e dados reais não são a mesma coisa
Rank tracking média na integração recorrente a coleta confiável da SERP é o produto do fornecedor
Pesquisa de palavras-chave média variável volume e CPC não nascem do crawler
Backlinks de concorrentes alta se própria recorrente requer um índice enorme da web
Estimativa de tráfego alheio muito alta alta é modelagem de terceiros, não analytics real
Recomendações automáticas média/alta baixo a variável qualidade depende da qualidade dos dados
“Clone do Ahrefs/Semrush” impraticável para uma pessoa muito alto não deve ser o objetivo

O que pode ser construído integralmente

  • rastreamento de URLs, links, sitemaps e redirecionamentos;
  • inventário de títulos, descrições, headings, canonicals, robots e hreflang;
  • histórico de HTML, texto principal, hashes e capturas opcionais;
  • comparação de conteúdo, metadados, links internos e dados estruturados;
  • auditorias de status HTTP, profundidade, páginas órfãs e cadeias de redirecionamento;
  • análise de sobreposição temática e possível canibalização;
  • agrupamento de palavras-chave já conhecidas;
  • integração, histórico, alertas, relatórios e prioridades;
  • detecção de novos artigos, páginas removidas e grandes alterações de concorrentes.

O que deve vir de terceiros

  • SERPs do Google em localizações e dispositivos específicos;
  • posição histórica confiável de concorrentes;
  • volume de busca, CPC, concorrência publicitária e dificuldade proprietária;
  • índice de backlinks, links novos e perdidos;
  • estimativas de tráfego e participação de mercado de outros domínios;
  • resultados locais de mapas em grade geográfica.

Proposta funcional do Radar SEO Pessoal

1. Painel diário

Primeira tela operacional, com:

  • tarefas críticas e avisos novos;
  • variações de cliques, impressões, CTR e posição;
  • palavras-chave que entraram ou saíram do Top 3, Top 10 e Top 20;
  • páginas próprias que mais ganharam ou perderam tráfego;
  • conteúdo novo ou alterado pelos concorrentes;
  • problemas técnicos surgidos desde a varredura anterior;
  • pioras em LCP, INP e CLS;
  • consumo mensal e saldo estimado das APIs pagas.

O painel deve mostrar mudança e prioridade, não apenas totais.

2. Projetos, sites e concorrentes

Cada projeto contém:

  • domínio principal e variantes;
  • país, idioma, mecanismo e dispositivo;
  • propriedades do Search Console e GA4;
  • lista de concorrentes comerciais;
  • concorrentes orgânicos descobertos nas SERPs;
  • grupos de palavras-chave;
  • frequência de coleta;
  • orçamento mensal de API;
  • canais de alerta.

Concorrente comercial e concorrente orgânico são conceitos diferentes. Uma empresa pode vender o mesmo produto sem disputar muitas consultas; um portal editorial pode dominar as SERPs sem vender o mesmo serviço.

3. Crawler e auditoria técnica

O crawler deverá:

  • iniciar por sitemap, homepage e URLs informadas;
  • respeitar escopo de host e regras configuradas;
  • normalizar URLs e remover fragmentos;
  • registrar status, cadeia de redirecionamento e URL final;
  • extrair title, meta description, headings e texto principal;
  • identificar canonical, meta robots, X-Robots-Tag e hreflang;
  • coletar links internos e externos;
  • detectar JSON-LD, Microdata e RDFa;
  • registrar tamanho, tipo MIME, tempo de resposta e data;
  • calcular profundidade de clique e páginas órfãs;
  • comparar a nova execução com a anterior;
  • produzir problemas com evidência, gravidade e orientação.

Regras úteis:

  • páginas 4xx/5xx;
  • links internos quebrados;
  • redirecionamentos em cadeia ou loop;
  • página indexável apontando canonical para outra URL;
  • noindex inesperado;
  • título ausente, duplicado ou excessivamente longo;
  • descrição ausente ou duplicada;
  • H1 ausente ou múltiplo;
  • conteúdo quase duplicado;
  • páginas sem links internos recebidos;
  • profundidade excessiva;
  • imagens sem texto alternativo;
  • sitemap contendo URLs redirecionadas, bloqueadas ou não canônicas;
  • conflito entre robots.txt, robots meta e canonical;
  • hreflang inválido ou sem retorno;
  • dados estruturados ausentes ou alterados;
  • links internos para HTTP quando existe HTTPS;
  • páginas lentas ou com aumento grande de tamanho.

Uma pontuação geral pode existir, mas cada nota precisa ser derivada de problemas visíveis. Uma nota misteriosa é menos útil que cinco evidências acionáveis.

4. Monitoramento de concorrentes

É o módulo de maior diferencial para uso pessoal. Para cada domínio, ele pode:

  • descobrir URLs por sitemap, feeds e links internos;
  • monitorar páginas prioritárias em frequência maior;
  • detectar páginas novas e removidas;
  • comparar título, descrição, H1, headings, preço visível e CTA;
  • identificar links externos e internos adicionados ou removidos;
  • extrair texto principal sem navegação, rodapé e banners;
  • guardar hash do HTML bruto, DOM normalizado e texto principal;
  • marcar alteração editorial pequena, reformulação ou mudança estrutural;
  • acompanhar novos tipos de Schema.org;
  • produzir uma linha do tempo por página e domínio;
  • avisar quando surgir conteúdo para um grupo estratégico de palavras-chave.

Para reduzir falsos positivos, o normalizador deve eliminar:

  • tokens, IDs de sessão e parâmetros conhecidos de rastreamento;
  • timestamps gerados em toda requisição;
  • banners de cookies, anúncios e blocos recomendados variáveis;
  • ordem aleatória de itens;
  • espaços, atributos e marcação sem efeito semântico.

As comparações devem existir em três níveis:

  1. metadados: title, description, canonical, robots, headings e schema;
  2. conteúdo: frases e blocos adicionados, removidos ou reescritos;
  3. estrutura: links, navegação, templates, componentes e profundidade.

5. Rank tracking e análise de SERP

Cada verificação precisa fixar:

  • palavra-chave;
  • mecanismo de busca;
  • país e localização;
  • idioma;
  • desktop ou celular;
  • data e horário;
  • profundidade, como Top 10 ou Top 100;
  • domínio e URL encontrados;
  • recursos presentes: anúncios, mapas, vídeos, imagens, notícias, snippets e resultados gerados por IA quando o fornecedor os identificar.

Além da posição absoluta, o sistema deve calcular:

  • melhor posição e posição média por período;
  • volatilidade;
  • URL que ranqueia para a palavra;
  • troca de URL e possível canibalização;
  • share of voice ponderado por volume;
  • concorrentes que mais aparecem no grupo;
  • ganho ou perda após uma alteração de conteúdo;
  • diferença entre celular e desktop;
  • presença de recursos que reduzem cliques orgânicos.

Não raspar diretamente o Google. A política da Pesquisa Google afirma que consultas automatizadas, inclusive scraping para verificar rankings, violam as políticas e os Termos. Use uma API especializada e mantenha um adaptador independente de fornecedor.

6. Palavras-chave e oportunidades

Fontes possíveis:

  • consultas reais do Search Console;
  • Google Ads Keyword Plan Ideas e métricas históricas;
  • sugestões de uma API comercial;
  • palavras extraídas das páginas próprias e concorrentes;
  • termos obtidos de títulos e resultados da SERP;
  • perguntas, modificadores, entidades e combinações informadas pelo usuário.

Pipeline recomendado:

  1. importar e normalizar termos;
  2. preservar acentos, mas criar uma chave normalizada para deduplicação;
  3. agregar volume, CPC, origem e data;
  4. gerar vetores TF-IDF;
  5. usar embeddings multilíngues apenas quando necessário;
  6. agrupar por similaridade e intenção;
  7. associar a uma página existente ou sugerir uma nova;
  8. calcular uma oportunidade transparente.

Exemplo de pontuação, ajustável por projeto:

oportunidade =
    0,30 * demanda_normalizada
  + 0,25 * relevancia_para_o_negocio
  + 0,20 * lacuna_contra_concorrentes
  + 0,15 * probabilidade_de_ranquear
  + 0,10 * tendencia
  - custo_de_producao

Não se deve tratar “keyword difficulty” de fornecedores diferentes como a mesma medida. Ela é uma métrica proprietária. Guarde fornecedor, versão, data e escala junto ao valor.

7. Search Console, GA4 e Bing

Para propriedades verificadas, o sistema deve integrar:

  • consultas, páginas, países, dispositivos, cliques, impressões, CTR e posição do Search Console;
  • status e dados da inspeção de URL para diagnósticos pontuais;
  • sessões, usuários, eventos, páginas de entrada e conversões do GA4;
  • consultas, tráfego, links e estatísticas de rastreamento do Bing Webmaster;
  • envio de URLs próprias atualizadas pelo IndexNow.

O Search Console possui cotas oficiais suficientes para uma aplicação pessoal, mas consultas agrupadas simultaneamente por página e consulta, períodos longos e paginação intensa podem consumir mais carga. Deve-se importar diariamente, armazenar localmente e consultar o banco do projeto para os painéis.

A URL Inspection API tem limites menores e só funciona para propriedades às quais a conta possui acesso. Ela não é um meio de inspecionar concorrentes.

8. Desempenho e Core Web Vitals

Usar três fontes complementares:

  • Lighthouse: teste de laboratório controlado;
  • PageSpeed Insights: execução e recomendações convenientes;
  • CrUX API: experiência real agregada de usuários do Chrome, quando houver amostra suficiente.

LCP, INP e CLS devem ser guardados por URL ou origem, dispositivo, período e fonte. Uma URL pequena pode não possuir dados CrUX; isso é ausência de amostra, não nota zero.

A documentação do PageSpeed avisa que seus dados de campo podem deixar de ser oferecidos ali. Por isso, o conector CrUX deve ser independente. Lighthouse pode rodar por linha de comando ou módulo Node e requer Chrome/Chromium.

9. Backlinks

Para concorrentes, use um provedor de índice. O sistema local deve:

  • importar resumo por domínio;
  • guardar domínios de referência, URLs, âncoras e atributos do link;
  • detectar links novos e perdidos;
  • comparar interseções entre concorrentes;
  • identificar fontes que apontam para vários concorrentes, mas não para você;
  • pontuar relevância temática e risco sem transformar qualquer número em “autoridade verdadeira”.

O Common Crawl é gratuito e disponibiliza WARC bruto, WAT com metadados e links e WET com texto. É excelente para experiências, investigações históricas e descoberta em lote, mas não substitui sozinho um índice comercial atualizado de backlinks. Seu uso exige processar grandes arquivos e aceitar cobertura e frequência diferentes das ferramentas especializadas.

10. Alertas e relatórios

Alertas de alto valor:

  • queda relevante de cliques ou impressões;
  • saída do Top 3 ou Top 10;
  • mudança da URL ranqueada;
  • página estratégica indisponível ou desindexável;
  • novo bloqueio, canonical ou redirecionamento;
  • sitemap com falha;
  • concorrente publicou ou reescreveu página relevante;
  • novo concorrente recorrente nas SERPs;
  • piora significativa de Core Web Vitals;
  • consumo de API acima do orçamento;
  • tarefa atrasada ou conector sem autenticação.

O sistema deve agrupar eventos relacionados e aplicar período de silêncio. Receber cinquenta notificações para uma única falha de servidor torna o alerta inútil.

Arquitetura recomendada

flowchart LR
    A["Agendador"] --> B["Fila de tarefas"]
    B --> C["Crawler HTTP"]
    B --> D["Navegador opcional"]
    B --> E["APIs próprias"]
    B --> F["Provedores SEO"]
    C --> G["Extração e normalização"]
    D --> G
    E --> H["Importadores"]
    F --> H
    G --> I["PostgreSQL"]
    G --> J["Snapshots comprimidos"]
    H --> I
    I --> K["Análises e regras"]
    J --> K
    K --> L["Dashboard"]
    K --> M["Alertas e relatórios"]

Decisão principal: monólito modular

Uma aplicação Django, um worker, um agendador e um banco são suficientes. Os módulos devem ter fronteiras claras, mas podem viver no mesmo repositório:

radar_seo/
  core/
  projects/
  crawling/
  audits/
  competitors/
  keywords/
  serp/
  analytics/
  performance/
  backlinks/
  alerts/
  reports/
  providers/
  templates/

Isso simplifica autenticação, migrações, backups, painel administrativo e implantação. Separar serviços só passa a fazer sentido se o crawler crescer a ponto de precisar escalar independentemente.

Stack recomendada

Base da aplicação

Componente Escolha Motivo
Linguagem Python 3.14 ecossistema forte para crawling, dados e NLP; versão estável em correções
Framework Django 5.2 LTS auth, admin, ORM, templates, formulários e suporte até abril de 2028
API interna Django Ninja ou Django REST Framework, somente se necessária evitar uma API antes de existir consumidor
Banco PostgreSQL 18 JSONB, busca textual, índices, agregações e cinco anos de suporte
Fila Celery 5.6 integração madura com Django, retries, filas e tarefas periódicas
Broker/cache Redis simples para fila, locks, cache e limitação de frequência
Scheduler Celery Beat agenda no mesmo ecossistema da fila
Interface Django Templates + HTMX interação dinâmica sem uma SPA complexa
Gráficos Chart.js séries temporais e comparações suficientes para o projeto
CSS CSS próprio ou Tailwind, se já houver preferência não é necessário adotar um kit grande
Dependências uv ambientes, lockfile e instalação rápida
Implantação Docker Compose reprodução simples em desktop, NAS ou VPS

Django 6.0.7 era a versão corrente em 26 de julho de 2026, mas Django 5.2 LTS é a escolha conservadora: recebe atualizações de segurança até abril de 2028, suporta Python 3.14 e evita depender imediatamente do novo framework de Tasks. O framework de Tasks do Django 6.0 define e enfileira tarefas, mas a própria documentação esclarece que ele não fornece o worker de produção.

PostgreSQL 18.4 era a versão corrente da série 18, suportada até novembro de 2030. PostgreSQL 17 também é aceitável. Não usar a versão 19 beta em produção.

Bibliotecas de coleta e parsing

Dependência Papel Uso recomendado
httpx cliente HTTP síncrono/assíncrono padrão para páginas e APIs
scrapy crawler completo adotar se o volume e a fronteira do crawl crescerem
lxml HTML/XML, XPath e sitemaps parser robusto principal
selectolax parsing HTML rápido extração repetitiva em grande volume
trafilatura texto e metadados principais diffs de conteúdo sem navegação e rodapé
extruct JSON-LD, Microdata, RDFa e Open Graph auditoria de dados estruturados
advertools utilidades de SEO, sitemap e robots exploração e importadores auxiliares
playwright renderização com navegador fallback para conteúdo realmente dependente de JS
tldextract domínio registrável e subdomínio normalização correta de hosts
charset-normalizer detecção de encoding páginas legadas
feedparser RSS e Atom descoberta de publicações
protego ou urllib.robotparser robots.txt política de acesso por host
Pillow metadados básicos de imagens dimensões e formatos
dnspython DNS inspeção de registros e erros

HTTPX possui timeouts por padrão e permite limites de conexão. Mesmo assim, o projeto deve configurar explicitamente tempo de conexão, leitura, tamanho máximo, redirects e concorrência por host.

Scrapy é excelente quando se precisa de scheduler, downloader middlewares, pipelines, AutoThrottle e muitos spiders. Para um MVP controlado, HTTPX com uma fila de URLs persistida é mais fácil de integrar ao domínio da aplicação.

Playwright não deve abrir um navegador para cada URL. Ele custa muito mais CPU e memória e cada versão depende de binários de navegador compatíveis. Use-o em uma fila separada e somente após a resposta HTML comum não conter o conteúdo necessário.

Conteúdo, similaridade e análise

Dependência Função
scikit-learn TF-IDF, similaridade cosseno, clustering e modelos simples
rapidfuzz comparação aproximada de strings
sentence-transformers embeddings multilíngues opcionais
spacy tokenização, entidades e processamento linguístico opcional
numpy e pandas cálculos e importações; não usar DataFrame como banco
diff-match-patch ou difflib visualização de alterações textuais
deepdiff comparação de estruturas JSON normalizadas
langdetect ou fastText detecção de idioma quando realmente necessária
pgvector vetores no PostgreSQL, somente depois de validar o uso

Começar com TF-IDF e similaridade cosseno. Embeddings são úteis para lacunas semânticas, mas adicionam modelos, memória, versão de vetor e reprocessamento. Não devem ser uma dependência estrutural do MVP.

Integrações oficiais

Fonte O que fornece Restrição essencial
Search Console API cliques, impressões, CTR, posição, sitemaps apenas propriedades autorizadas
URL Inspection API estado conhecido de indexação apenas propriedades autorizadas e cota menor
GA4 Data API tráfego, eventos e conversões propriedade autorizada
Google Ads API ideias e métricas históricas de keywords conta, OAuth, developer token e limites
PageSpeed Insights API Lighthouse e recomendações dados de campo devem migrar para CrUX
CrUX API LCP, INP, CLS e métricas reais agregadas pode não haver amostra por URL
Bing Webmaster API tráfego, rankings, links e crawl do próprio site site verificado
IndexNow aviso de URL própria alterada exige chave e controle do host

As métricas históricas do Google Ads incluem média aproximada de buscas mensais, volumes mensais, concorrência, índice de concorrência e faixas de lance. Elas são atualizadas mensalmente e devem ser cacheadas. A API de planejamento tem limites mais restritos do que operações comuns do Google Ads.

Fornecedores de dados competitivos

Fornecedor Melhor uso Vantagem Limitação
DataForSEO SERP, keywords, backlinks, domínio e on-page catálogo amplo e consumo granular custo por chamada/linha e integração mais técnica
SerpApi resultados de busca estruturados API simples e especializada em SERP backlinks e inteligência ampla ficam fora
Semrush API keywords, domínio, backlinks, projetos e local base integrada e muitos relatórios acesso completo pode exigir plano Business, add-on e unidades
Ahrefs API backlinks e inteligência competitiva índice e métricas conhecidos confirmar plano e limites atuais antes de escolher
Moz Links API links e métricas de domínio integração focada cobertura e custo devem ser testados no nicho
Majestic API backlinks históricos e atuais especialização em links interface e métricas próprias
Common Crawl pesquisa pública em lote gratuito e aberto processamento pesado; não substitui rank tracker

Primeira escolha para protótipo: DataForSEO, começando por poucas palavras-chave e concorrentes. Em 26 de julho de 2026, a página de preços de backlinks mostrava como exemplo uma requisição de US$ 0,024 mais US$ 0,000036 por linha, totalizando US$ 0,06 para mil linhas. Isso é apenas uma fotografia de preço e não deve ser codificado no sistema.

O adaptador deve seguir uma interface comum:

class SerpProvider:
    def check(self, keyword, location, language, device, depth):
        ...

class KeywordProvider:
    def ideas(self, seeds, location, language):
        ...

class BacklinkProvider:
    def summary(self, domain):
        ...

    def new_and_lost(self, domain, since):
        ...

Trocar fornecedor deve exigir novo adaptador, não migração de toda a aplicação. Sempre guardar provider, requested_at, parâmetros, custo estimado e resposta bruta com retenção limitada.

Qualidade, testes e operação

Dependência/ferramenta Papel
pytest e pytest-django testes unitários e de integração
respx simular respostas HTTPX
factory_boy dados de teste
ruff lint e formatação
mypy ou Pyright tipos nas fronteiras e conectores
pydantic validar respostas externas e configurações
structlog logs estruturados
sentry-sdk erros, opcional
prometheus-client métricas operacionais, opcional
django-environ configuração externa
psycopg driver PostgreSQL

Testes indispensáveis:

  • normalização e canonicalização de URLs;
  • limites de escopo do crawler;
  • robots.txt;
  • redirects e loops;
  • parsing de HTML malformado;
  • extração de canonical, robots, hreflang e schema;
  • diffs que ignoram áreas dinâmicas;
  • idempotência dos importadores;
  • paginação, rate limit e retry dos provedores;
  • cálculo de posição e share of voice;
  • timezone e agregação diária;
  • expiração de credenciais e alertas;
  • proteção contra URLs internas e SSRF.

Modelo de dados inicial

Tabela Conteúdo principal
projects nome, mercado, idioma, timezone, orçamento
domains domínio próprio ou concorrente e configurações
provider_accounts referência a credenciais criptografadas
crawl_runs início, fim, estado, limites e estatísticas
urls URL normalizada, domínio, primeira e última aparição
page_snapshots status, metadados, hash, conteúdo e data
links origem, destino, atributos e execução
issues regra, evidência, gravidade, estado e histórico
keywords termo, mercado, idioma e origem
keyword_groups cluster, intenção e página-alvo
serp_checks palavra, local, dispositivo, data e fornecedor
serp_results posição, URL, domínio, tipo e recurso
gsc_daily dimensões e métricas diárias
ga4_daily dimensões, eventos e métricas diárias
web_vitals fonte, URL/origem, dispositivo e métricas
backlink_snapshots alvo, origem, âncora, estado e provedor
alerts regra, deduplicação, severidade e entrega
jobs agenda, execução, tentativas, custo e erro

Estratégias importantes

  • uma URL normalizada não substitui a URL observada; guardar ambas;
  • métricas externas sempre carregam data, fonte, localização e dispositivo;
  • snapshots grandes devem ser comprimidos no disco ou armazenamento compatível com S3, não acumulados integralmente em JSONB;
  • manter no PostgreSQL os campos necessários para consulta e o caminho/hash do artefato bruto;
  • particionar séries temporais apenas quando o volume justificar;
  • implementar retenção: SERP detalhada, HTML bruto e screenshots não precisam viver para sempre;
  • nunca apagar histórico por causa de uma nova execução incompleta.

Frequência de coleta recomendada

Dado Frequência inicial
Search Console e GA4 diária, importando dias recentes novamente
palavras-chave críticas diária
demais palavras-chave semanal
páginas próprias críticas diária
crawl completo próprio semanal
páginas concorrentes prioritárias diária ou a cada 2 dias
crawl amplo de concorrentes semanal ou quinzenal
PageSpeed/Lighthouse semanal e após deploy
CrUX semanal; a janela é móvel e atualizada diariamente
backlinks novos/perdidos semanal
volume de palavras-chave mensal
DNS, TLS, sitemap e robots diária

Reimportar uma pequena janela recente do Search Console e GA4 ajuda a capturar ajustes tardios. Todas as tarefas devem ser idempotentes.

Segurança, ética e limites legais

Coleta responsável

  • identificar o crawler com User-Agent e meio de contato;
  • respeitar robots.txt e termos específicos do site;
  • limitar concorrência por host, inicialmente a uma requisição por vez;
  • usar intervalo, jitter, backoff e Retry-After;
  • aproveitar ETag, Last-Modified e respostas condicionais;
  • não contornar login, paywall, CAPTCHA ou bloqueios;
  • não reproduzir conteúdo concorrente; guardar apenas o necessário para análise privada e controlar retenção;
  • permitir exclusões de caminhos e domínios;
  • documentar a base e a finalidade de qualquer dado pessoal eventualmente encontrado, considerando a LGPD.

Proteção do próprio crawler

Um sistema que aceita URLs pode ser explorado para alcançar serviços internos. Aplicar proteção contra SSRF:

  • aceitar apenas http e https;
  • resolver DNS antes e validar novamente após redirects;
  • bloquear loopback, link-local, redes privadas, multicast e metadata de nuvem;
  • limitar redirects, bytes, tempo e tipo MIME;
  • impedir file:, ftp:, gopher:, data: e esquemas desconhecidos;
  • executar o worker de navegação sem acesso desnecessário à rede interna;
  • não passar URLs a comandos de shell;
  • sanitizar HTML antes de mostrar snapshots na interface.

Credenciais

  • OAuth com escopos mínimos;
  • tokens criptografados em repouso;
  • segredos fora do repositório;
  • rotação e revogação visíveis;
  • logs sem tokens, cookies ou conteúdo sensível;
  • backup criptografado;
  • autenticação forte mesmo sendo um sistema pessoal exposto à internet.

Custos realistas

Cenário econômico

Para um site, 3 a 5 concorrentes e algumas centenas de palavras-chave:

  • servidor doméstico ou VPS pequena;
  • banco e crawler próprios;
  • APIs Google e Bing dentro das cotas;
  • SERP paga somente para termos escolhidos;
  • backlinks consultados semanalmente;
  • custo dominado pelo fornecedor de dados, não pela hospedagem.

Como impedir surpresas

Cada tarefa paga deve ter:

  • preço estimado antes do envio;
  • limite diário e mensal por projeto;
  • cache por conjunto de parâmetros;
  • deduplicação de pedidos simultâneos;
  • profundidade configurável;
  • botão para pausar o fornecedor;
  • alerta em 50%, 80% e 100% do orçamento;
  • relatório por módulo, palavra e concorrente.

Não consultar mil palavras diariamente só porque é possível. Criar camadas:

  • críticas: todos os dias;
  • importantes: duas ou três vezes por semana;
  • exploratórias: semanal ou mensalmente;
  • arquivadas: sem coleta.

Roteiro de construção

Os prazos abaixo são estimativas para uma pessoa com experiência em Python e web, trabalhando em tempo parcial. Pesquisa, configuração de OAuth e qualidade dos sites monitorados podem alterar bastante o tempo.

Fase 0 — prova de conceito, 2 a 4 dias

  • cadastrar um domínio próprio e dois concorrentes;
  • baixar 20 páginas por domínio;
  • extrair metadados e texto;
  • guardar snapshots;
  • mostrar uma comparação entre duas versões;
  • testar uma API de SERP com 10 palavras-chave.

Saída: confirmação de que crawling, diff e fornecedor atendem ao nicho.

Fase 1 — fundação, 1 semana

  • projeto Django, PostgreSQL e autenticação;
  • projetos, domínios e configurações;
  • worker, scheduler e estados de tarefa;
  • logs, retries, orçamento e health check;
  • backup e ambiente de desenvolvimento reproduzível.

Fase 2 — crawler próprio e auditoria, 1 a 2 semanas

  • sitemap, fila persistente e escopo;
  • normalização, redirects e robots;
  • extração técnica;
  • links e profundidade;
  • primeiro conjunto de regras;
  • histórico por execução.

Fase 3 — concorrentes e alterações, 1 a 2 semanas

  • páginas prioritárias;
  • normalização de conteúdo;
  • diff de metadados, texto e links;
  • descoberta de páginas novas;
  • linha do tempo e alertas agrupados.

Fase 4 — dados próprios, 1 a 2 semanas

  • OAuth;
  • Search Console;
  • GA4;
  • Bing Webmaster;
  • CrUX e PageSpeed;
  • painéis e reconciliação diária.

Fase 5 — SERP e palavras-chave, 1 a 2 semanas

  • adaptador do primeiro fornecedor;
  • rank tracking;
  • recursos de SERP;
  • clusters;
  • páginas-alvo, lacunas e canibalização;
  • orçamento e cache.

Fase 6 — backlinks e relatórios, 1 a 2 semanas

  • resumo e links novos/perdidos;
  • interseção de domínios de referência;
  • relatório semanal;
  • exportação CSV;
  • notificações por e-mail, ntfy ou Gotify.

Fase 7 — inteligência avançada, contínua

  • score de oportunidade calibrado;
  • embeddings opcionais;
  • correlação de alterações com desempenho;
  • anotações de deploy e campanhas;
  • resumo assistido por IA com links para todas as evidências;
  • local SEO, se for relevante.

Um MVP convincente pode surgir em 4 a 8 semanas de trabalho parcial. Uma versão madura tende a exigir 3 a 6 meses de evolução. São estimativas de planejamento, não promessas de prazo.

O que não construir no início

  • microserviços;
  • Kubernetes;
  • um navegador para toda página;
  • um índice global próprio de backlinks;
  • scraping direto de resultados do Google;
  • um frontend React separado;
  • data warehouse;
  • modelos próprios de linguagem;
  • geração automática de centenas de artigos;
  • pontuação opaca de “autoridade”;
  • previsão de tráfego apresentada como certeza;
  • integrações antes de existir um caso de uso diário.

Melhor versão mínima

O menor produto que já justificaria o esforço contém:

  1. cadastro de um site e cinco concorrentes;
  2. crawler semanal do próprio site;
  3. monitor diário de páginas concorrentes selecionadas;
  4. Search Console importado diariamente;
  5. 100 a 300 palavras-chave divididas por prioridade;
  6. uma API de SERP;
  7. diff de title, headings, texto, links e schema;
  8. problemas técnicos com evidência;
  9. painel de mudanças e oportunidades;
  10. resumo semanal e alertas críticos.

Backlinks, GA4, CrUX, clustering semântico e IA entram depois. Essa ordem produz valor cedo e evita investir meses antes de descobrir quais relatórios realmente mudam decisões.

Recomendações práticas

Decisão final de stack

Usaria:

Python 3.14
Django 5.2 LTS
PostgreSQL 18
Celery 5.6 + Redis + Celery Beat
Django Templates + HTMX + Chart.js
HTTPX + lxml/selectolax
Trafilatura + extruct
Playwright em uma fila opcional
scikit-learn primeiro; sentence-transformers depois
Docker Compose
DataForSEO como primeiro teste de dados competitivos
Google Search Console + GA4 + CrUX + PageSpeed
Bing Webmaster + IndexNow

Primeiras decisões de produto

  • o sistema será privado e single-user no começo;
  • português do Brasil como interface, com mercados e idiomas configuráveis;
  • frequência e orçamento por projeto;
  • evidência sempre clicável junto à recomendação;
  • dado externo sempre identificado pela fonte;
  • toda afirmação incerta marcada como estimativa;
  • exportação CSV e JSON desde cedo;
  • adaptadores independentes para não aprisionar o projeto a um fornecedor;
  • IA apenas resume e investiga dados existentes, nunca inventa métricas.

Ordem recomendada para começar amanhã

  1. Criar o repositório e a base Django.
  2. Modelar Project, Domain, Url, CrawlRun e PageSnapshot.
  3. Implementar downloader seguro e normalizador de URL.
  4. Extrair metadados, links, texto e dados estruturados.
  5. Produzir o primeiro diff útil.
  6. Integrar Search Console.
  7. Testar DataForSEO e SerpApi com o mesmo conjunto de 20 termos.
  8. Comparar precisão, localização, recursos de SERP, latência e custo.
  9. Implementar o painel diário.
  10. Só então expandir para backlinks e agrupamento semântico.

Conclusão

Construir um sistema pessoal completo de SEO é viável e uma boa ideia. A parte que você deve possuir é justamente a mais valiosa para o uso cotidiano: histórico, crawler, regras, alertas, integração dos próprios dados, comparação de concorrentes e priorização.

O projeto fica difícil quando tenta produzir sozinho os ativos que grandes empresas levaram anos e enorme infraestrutura para formar: índices globais de links, bases de palavras-chave e coleta contínua de SERPs. A solução não é abandonar a ideia, mas desenhá-la como uma plataforma híbrida. O Radar SEO Pessoal coleta diretamente o que é razoável, usa APIs oficiais no que pertence ao usuário e compra de forma controlada somente os dados competitivos.

A recomendação é iniciar pelo MVP de crawler, mudanças de concorrentes e Search Console. Essa versão já pode superar ferramentas genéricas em relevância pessoal, porque acompanha exatamente os sites, páginas, consultas e decisões que importam. SERPs pagas vêm em seguida; backlinks e IA, somente depois que o fluxo básico estiver sendo usado de verdade.

Fontes consultadas

Google e Bing

Dados competitivos e web aberta

Stack e bibliotecas

Nota sobre atualidade

Pesquisa concluída em 26 de julho de 2026. Versões, preços, cotas, condições de acesso e políticas de APIs podem mudar. Confirme esses pontos nas fontes oficiais antes de contratar serviços ou fixar dependências.