← 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 rank trackers, painéis 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 rank tracking só funciona quando você vê a SERP que um usuário real veria no país, na região e na cidade corretos. Uma palavra-chave que ranqueia em 4º lugar em Londres pode ficar 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 varia com a geografia e o dispositivo. (A Scrape.do mediu que o texto de AI Overview apareceu em cerca de 36% das consultas no início de 2026.) Se o seu scraper for roteado por um proxy na cidade errada, os seus dados de ranqueamento serão uma ficção contada com confiança.

Portanto, um produto de SERP consistente em 2026 precisa de três fatores trabalhando juntos: uma request idêntica a um navegador real no nível da rede, um proxy localizado na cidade exata que você quer monitorar e a capacidade de renderizar JavaScript quando o Google decide carregar metade do resultado no client-side. Se você errar qualquer um dos três, seus dados se degradam silenciosamente.

A Abordagem da FourA

O gargalo na raspagem de SERP em escala não é a request. É o roteamento.

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

Vimos equipes estruturarem isso no FourA de forma parecida com esta:

  1. O Proxy Finder mantém um pool funcional de proxies validados com verificações recentes de disponibilidade e etiquetados 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 proxy que realmente fica lá e está ativo na última verificação. A seleção acontece antes da busca, não durante ela. Para saber mais sobre a importância dessa camada de roteamento, consulte nosso artigo sobre Smart Proxy Routing.

  2. O Single lida com a busca da SERP em si. Para resultados orgânicos padrão, o HTML bruto é suficiente. Defina unblocker: true e a request carregará uma assinatura de navegador atualizada sem que você precise saber qual assinatura o Google está verificando naquela semana. Detalhamos o que essa flag faz na rede em nosso post sobre Web Unblocker.

  3. O Browser gerencia 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, mas a request roda em uma sessão completa de navegador e retorna a página totalmente renderizada. (Além de capturas de tela, que salvam você no dia em que um líder de SEO pergunta por que seu painel indica a posição 3, mas ele vê a posição 6 no próprio navegador.)

Uma única chamada para a API com roteamento por 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 responsabilidades separadas de forma limpa: trabalho de proxy com precisão geográfica (Proxy Finder), a request em si (Single) e renderização de JavaScript quando você precisa (Browser). O seu código não precisa carregar lógica de integridade de proxy nem adivinhar qual IP ainda está ativo às 3h da manhã. Esse problema é de outra pessoa.

E armazene cada response indexada por (keyword, location, device, timestamp). Essa é a unidade real da verdade para rank tracking. Não "ficamos nesta posição para esta keyword hoje", mas "ficamos nesta posição para esta keyword, 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 estava correto. Equipes de SEO que monitoram verticais protegidas já convivem com isso. Nós 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 individual.

Resultados

Um rank tracker monitorando 5.000 keywords em 12 cidades, duas vezes ao dia, gerava cerca de 120.000 requests por dia sob o antigo regime de num=100. Agora está mais próximo de 1,2 milhão, por pura matemática de paginação (cenário ilustrativo baseado em benchmarks do setor).

Equipes que migraram 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 um pool de proxy próprio, principalmente porque pararam de pagar por churn de proxy, IPs inativos e pelas horas de engenharia necessárias para manter a rotação.
  • Aumento da precisão de localização no nível de cidade de ~70% para mais de 95%, pois o Proxy Finder filtra por cidade e verifica o status ativo na última checagem antes de entregar o proxy.
  • Nenhum caminho especial para AI Overviews. Uma keyword coletada via Single pode ser promovida para Browser sem reescrever o pipeline. O contrato é idêntico: URL de entrada, response de saída.

Você não precisa de nada disso para dez keywords e um notebook. Mas você precisa assim que o pipeline passa a monitorar dezenas de milhares de keywords em vários países, seus clientes atualizam o dashboard às 9h da manhã de segunda-feira e os rankings precisam ser reais.

Principal Conclusão

A parte difícil do monitoramento de SERP deixou de ser a request há muito tempo. Tornou-se o roteamento. De qual cidade você está fazendo a coleta? Aquele IP está ativo? O Google retornou o layout que um usuário real naquele local veria, ou aquele vazio exibido quando detecta um scraper?

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