← Todos os posts
Caso de uso 6 min de leitura

Monitoramento de SERP em escala após o num=100

Rastrear rankings do Google em escala ficou mais difícil após o fim do num=100. Veja como equipes de engenharia de SEO estão reconstruindo a infraestrutura de monitoramento de SERP para 2026.

serp-monitoringrank-trackingseoweb-scrapinggoogle-search

O Desafio

Se a sua equipe desenvolve rastreadores de ranking, dashboards de SEO ou ferramentas de inteligência competitiva, 2026 quebrou a sua economia unitária. O Google descontinuou silenciosamente o parâmetro de URL num=100 na Busca do Google este ano, o truque que todo scraper de SERP usava para extrair 100 resultados em uma única request. Agora, a mesma cobertura exige dez requests em vez de uma.

Esse é o custo óbvio. Os custos ocultos são piores.

O rastreamento de ranking só funciona quando você visualiza a SERP que um usuário real veria no país, região e cidade corretos. Uma palavra-chave que ranqueia em 4º lugar em Londres pode ranquear em 11º em Edimburgo e em 19º em Belfast. Local 3-packs, carrosséis de shopping, caixas de notícias, painéis de conhecimento, AI Overviews. Cada recurso da SERP muda de acordo com a geografia e o dispositivo. (A Scrape.do mediu o texto de AI Overview aparecendo em cerca de 36% das consultas no início de 2026.) Se o seu scraper rotear por meio de um proxy na cidade errada, seus dados de ranking serão apenas ficção contada com confiança.

Portanto, um produto de SERP defensável em 2026 precisa de três elementos funcionando juntos: uma request que se pareça com um navegador real no nível da rede, um proxy localizado exatamente na cidade que você deseja monitorar e a capacidade de renderizar JavaScript quando o Google decidir carregar metade do resultado no lado do cliente. Falhe em qualquer um dos três e seus dados serão degradados silenciosamente.

A Abordagem da FourA

O gargalo no scraping de SERP em escala não é a request. É o roteamento.

A maioria dos pipelines internos começa com um pool de proxies fixo e trata a consulta como a variável. Com o direcionamento geográfico do Google, é o contrário. A consulta é o que você tem. O proxy é o que você precisa acertar.

Vimos equipes modelarem isso com base na FourA mais ou menos desta forma:

  1. Proxy Finder mantém um pool ativo de proxies validados por testes de atividade recentes e marcados com país, região, cidade e ASN. Quando uma request precisa vir de Manchester, Boston ou São Paulo, o Proxy Finder escolhe um que realmente esteja localizado lá e que esteja ativo na última verificação. A escolha acontece antes da busca, não durante ela. Para saber mais sobre a importância dessa camada de roteamento, veja nosso artigo sobre Smart Proxy Routing.

  2. Single lida com a própria busca da SERP. Para resultados orgânicos padrão, o HTML bruto é suficiente. Defina unblocker: true e a request passa por barreiras anti-bot no nível de handshake sem que você precise saber qual assinatura o Google está verificando naquela semana. Detalhamos o que essa flag faz na rede em nosso artigo sobre o Web Unblocker.

  3. Browser lida com SERPs onde o conteúdo crítico aparece após a execução do JavaScript. AI Overviews, pacotes de shopping expandidos, conteúdo de painel de conhecimento, Local 3-packs fixos. Mesma URL, mesmo destino, a request apenas roda em uma sessão de navegador completa e retorna a página totalmente renderizada. (Além de capturas de tela, que salvam o seu dia quando um líder de SEO pergunta por que seu dashboard mostra a 3ª posição, mas eles veem a 6ª no navegador deles.)

Uma única chamada para a API com roteamento de proxy:

curl -X POST "https://api.foura.ai/api/proxy" \
  -H "x-api-key: YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "maxTries": 3,
    "timeout_ms": 20000,
    "request": {
      "method": "GET",
      "url": "https://www.google.co.uk/search?q=plumber+manchester&hl=en-GB",
      "unblocker": true,
      "validate": {
        "status": { "accept": [200] },
        "data": { "fail": ["unusual traffic", "/sorry/", "captcha"] }
      }
    }
  }'

São três preocupações separadas de forma limpa: trabalho de proxy geograficamente correto (Proxy Finder), a request em si (Single) e renderização de JavaScript quando você precisa (Browser). Seu código não carrega lógica de integridade de proxy nem adivinha qual IP ainda está ativo às 3h da manhã. Isso é problema de outra pessoa.

E armazene cada response indexada por (keyword, location, device, timestamp). Essa é a verdadeira unidade de verdade para o rastreamento de ranking. Não "ranqueamos aqui para esta palavra-chave hoje", mas "ranqueamos aqui para esta palavra-chave, a partir desta cidade, neste dispositivo, neste minuto". Sem esse nível de atribuição, dois dias de dados podem se contradizer silenciosamente e você não terá como saber qual deles estava correto. Equipes de SEO que monitoram verticais protegidas já convivem com isso. Também escrevemos sobre como a detecção de bots se tornou comportamental, o que adiciona um quarto eixo (continuidade de sessão) para sites que analisam o sequenciamento de requests em vez de sinais por request.

Resultados

Um rastreador de ranking monitorando 5.000 palavras-chave em 12 cidades, duas vezes ao dia, gerava cerca de 120.000 requests por dia sob o antigo regime do num=100. Agora, está mais próximo de 1,2 milhão, pela matemática simples de paginação (cenário ilustrativo baseado em referências do setor).

Equipes que portaram essa estrutura para uma stack de três produtos costumam relatar:

  • Redução de 40% a 60% no custo por request em comparação com a operação de seu próprio pool de proxies, principalmente porque deixaram de pagar pela rotatividade de proxies, IPs inativos e pelas horas de engenharia para manter a rotação.
  • Precisão de localização no nível da cidade passando de ~70% para mais de 95%, porque o Proxy Finder filtra por cidade e verifica a atividade no último teste antes de entregar o proxy.
  • Sem caminho especial para AI Overviews. Uma palavra-chave cuja busca é feita via Single pode ser promovida para o Browser sem a necessidade de reescrever o pipeline. O contrato é idêntico: URL de entrada, response de saída.

Você não precisa de nada disso para dez palavras-chave e um notebook. Mas você precisa quando o pipeline estiver monitorando dezenas de milhares de palavras-chave em vários países, seus clientes atualizarem o dashboard às 9h de segunda-feira e os rankings precisarem ser reais.

Principal Conclusão

A parte difícil do monitoramento de SERP deixou de ser a request há muito tempo. Tem sido o roteamento. De qual cidade você está fazendo a busca? Esse IP está ativo? O Google retornou o layout que um usuário real nessa localização realmente veria ou o layout vazio que eles servem quando detectam um scraper?

Se você é uma equipe de SEO que executa rastreamento de ranking em uma stack própria, a pergunta para 2026 não é se deve fazer o scrape do Google. Você já faz. A pergunta é se a sua infraestrutura consegue continuar gerando rankings confiáveis quando as regras mudam sem aviso prévio, e quanto da sua equipe de engenharia você está disposto a gastar para mantê-la funcionando assim.