---
title: "Como construir um sistema pessoal completo de SEO e monitoramento de concorrentes"
date: 2026-07-26
summary: "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."
tags: [pesquisa, seo, monitoramento, concorrentes, crawler, django, analytics]
flowerColor: "#72d6c9"
---

# 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:

```text
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

```mermaid
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:

```text
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:

```python
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:

```text
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

- [Google Search Console API](https://developers.google.com/webmaster-tools)
- [Cotas da Search Console API](https://developers.google.com/webmaster-tools/limits?hl=pt-br)
- [Google Analytics Data API](https://developers.google.com/analytics/devguides/reporting/data/v1/quickstart)
- [Cotas da Google Analytics Data API](https://developers.google.com/analytics/devguides/reporting/data/v1/quotas)
- [Google Ads: geração de ideias de palavras-chave](https://developers.google.com/google-ads/api/docs/keyword-planning/generate-keyword-ideas?hl=pt-br)
- [Google Ads: métricas históricas de palavras-chave](https://developers.google.com/google-ads/api/docs/keyword-planning/generate-historical-metrics)
- [Google Ads: visão geral do planejamento de palavras-chave](https://developers.google.com/google-ads/api/docs/keyword-planning/overview)
- [PageSpeed Insights API](https://developers.google.com/speed/docs/insights/v5/get-started?hl=pt-br)
- [Chrome UX Report API](https://developer.chrome.com/docs/crux/api?hl=pt-br)
- [Visão geral do Lighthouse](https://developer.chrome.com/docs/lighthouse/overview/)
- [Google Search: rastreamento e indexação](https://developers.google.com/search/docs/crawling-indexing)
- [Google Search: políticas de spam e tráfego automatizado](https://developers.google.com/search/docs/essentials/spam-policies?hl=pt-br)
- [Google Search: conteúdo útil e voltado às pessoas](https://developers.google.com/search/docs/fundamentals/creating-helpful-content)
- [Bing Webmaster API](https://learn.microsoft.com/en-us/bingwebmaster/)
- [Documentação do IndexNow](https://www.indexnow.org/documentation)

### Dados competitivos e web aberta

- [DataForSEO APIs](https://dataforseo.com/apis)
- [DataForSEO SERP API](https://docs.dataforseo.com/v3/serp/overview/)
- [DataForSEO Backlinks API](https://docs.dataforseo.com/v3/backlinks-overview/)
- [Preços da DataForSEO Backlinks API](https://dataforseo.com/pricing/backlinks/backlinks)
- [SerpApi Search API](https://serpapi.com/search-api)
- [Semrush API: visão geral](https://developer.semrush.com/api/v4/seo/overview/)
- [Semrush Projects API](https://developer.semrush.com/api/v3/projects/overview/)
- [Common Crawl: primeiros passos](https://commoncrawl.org/get-started)
- [Índice de URLs do Common Crawl](https://index.commoncrawl.org/)

### Stack e bibliotecas

- [Versões ativas do Python](https://www.python.org/downloads/)
- [Django 5.2 LTS](https://docs.djangoproject.com/en/5.2/releases/5.2/)
- [Versões suportadas do Django](https://www.djangoproject.com/download/)
- [Política de versões do PostgreSQL](https://www.postgresql.org/support/versioning/)
- [Celery: integração com Django](https://docs.celeryq.dev/en/latest/django/first-steps-with-django.html)
- [Celery 5.6](https://docs.celeryq.dev/en/stable/getting-started/)
- [Django Tasks e a necessidade de worker externo](https://docs.djangoproject.com/en/6.0/topics/tasks/)
- [Scrapy: arquitetura](https://docs.scrapy.org/en/latest/topics/architecture.html)
- [HTTPX: timeouts](https://www.python-httpx.org/advanced/timeouts/)
- [HTTPX: limites de recursos](https://www.python-httpx.org/advanced/resource-limits/)
- [Trafilatura](https://trafilatura.readthedocs.io/en/stable/index.html)
- [extruct](https://github.com/scrapinghub/extruct)
- [advertools](https://advertools.readthedocs.io/en/master/)
- [Playwright para Python](https://playwright.dev/python/docs/library)
- [HTMX](https://htmx.org/docs/)
- [Chart.js](https://www.chartjs.org/docs/latest/)
- [uv](https://docs.astral.sh/uv/)
- [scikit-learn: extração de atributos textuais](https://scikit-learn.org/stable/modules/feature_extraction.html)
- [Sentence Transformers](https://www.sbert.net/)
- [OWASP: prevenção de SSRF](https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html)

---

### 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.