← Все статьи
Вариант использования 5 минут чтения

Масштабируемый мониторинг SERP после отмены num=100

Отслеживать позиции в Google в больших масштабах стало сложнее после отключения параметра num=100. Рассказываем, как инженерные SEO-команды перестраивают инфраструктуру мониторинга SERP для 2026 года.

serp-monitoringrank-trackingseoweb-scrapinggoogle-search

Проблема

Если ваша команда создает инструменты отслеживания позиций, SEO-дашборды или платформы конкурентной разведки, 2026 год разрушил вашу юнит-экономику. В этом году Google незаметно отключил параметр URL num=100 в Google Search, трюк, который использовал каждый парсер SERP для получения 100 результатов за один request. Теперь для того же охвата требуется десять requests вместо одного.

Это очевидные расходы. Скрытые издержки гораздо неприятнее.

Отслеживание позиций работает только тогда, когда вы видите SERP, который реальный пользователь увидел бы в нужной стране, регионе и городе. Ключевое слово на 4-м месте в Лондоне может оказаться на 11-м в Эдинбурге и на 19-м в Белфасте. Локальные блоки (local 3-packs), товарные карусели, блоки новостей, панели знаний, AI Overviews. Каждый элемент SERP меняется в зависимости от географии и устройства. (Scrape.do зафиксировал появление текста AI Overview примерно в 36% запросов в начале 2026 года.) Если ваш парсер направляет трафик через proxy в неправильном городе, ваши данные о позициях становятся уверенно поданной выдумкой.

Поэтому жизнеспособный продукт для работы с SERP в 2026 году требует совместной работы трех компонентов: request, который выглядит как реальный браузер на сетевом уровне, proxy, находящийся именно в том городе, который вы пытаетесь отслеживать, и возможность рендеринга JavaScript, когда Google решает загрузить половину результатов на стороне клиента. Упустите любой из этих трех элементов, и ваши данные начнут незаметно портиться.

Подход FourA

Узким местом при парсинге SERP в больших масштабах является не request. Проблема в маршрутизации.

Большинство самописных конвейеров данных начинают с фиксированного пула proxy и относятся к запросу как к переменной. С географическим таргетингом Google все обстоит иначе. Запрос у вас уже есть. А вот с proxy нужно не ошибиться.

Мы видели, как команды выстраивали этот процесс на базе FourA примерно следующим образом:

  1. Proxy Finder поддерживает рабочий пул proxy, проверенных на работоспособность и помеченных страной, регионом, городом и ASN. Когда request должен прийти из Манчестера, Бостона или Сан-Паулу, Proxy Finder выбирает тот proxy, который действительно находится там и был активен при последней проверке. Выбор происходит до отправки запроса, а не во время нее. Подробнее о том, почему этот уровень маршрутизации так важен, читайте в нашей статье о Smart Proxy Routing.

  2. Single отвечает за само получение SERP. Для стандартных органических результатов достаточно чистого HTML. Установите unblocker: true, и request обойдет системы защиты от ботов на уровне рукопожатия (handshake) без необходимости выяснять, какую сигнатуру Google проверяет на этой неделе. Мы подробно разобрали работу этого флага на сетевом уровне в нашей статье о Web Unblocker.

  3. Browser обрабатывает SERP, в которых важный контент появляется только после выполнения JavaScript. AI Overviews, расширенные товарные блоки, контент панелей знаний, закрепленные локальные блоки (local 3-packs). Тот же URL, та же цель, только request выполняется через полноценную сессию браузера и возвращает полностью отрисованную страницу. (Плюс скриншоты, которые спасут вас в день, когда руководитель SEO-направления спросит, почему на дашборде отображается 3-е место, а в своем браузере он видит 6-е.)

Один вызов API с маршрутизацией через 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"] }
      }
    }
  }'

Это чистое разделение трех задач: геолокационно точная работа proxy (Proxy Finder), сам request (Single) и рендеринг JavaScript при необходимости (Browser). Ваш код не содержит логики проверки работоспособности proxy и не пытается угадать, какой IP все еще активен в три часа ночи. Это забота другой системы.

И сохраняйте каждый response с ключом (keyword, location, device, timestamp). Это настоящая единица истины для отслеживания позиций. Не "сегодня мы были на этой позиции по этому ключевому слову", а "мы были на этой позиции по этому ключевому слову из этого города, на этом устройстве, в эту минуту". Без такого уровня детализации данные за два дня могут тихо противоречить друг другу, и вы никак не сможете определить, какие из них верны. SEO-команды, отслеживающие защищенные ниши, уже живут в таких реалиях. Мы также писали о том, как анализ поведения заменил простое обнаружение ботов, что добавляет четвертую ось (непрерывность сессии) для сайтов, которые анализируют последовательность requests, а не сигналы отдельных запросов.

Результаты

Инструмент отслеживания позиций, контролирующий 5 000 ключевых слов в 12 городах дважды в день, совершал около 120 000 requests в сутки при старом режиме num=100. Теперь, по простой математике пагинации, это число приближается к 1,2 миллиона (иллюстративный сценарий на основе отраслевых стандартов).

Команды, перенесшие эту схему на стек из трех продуктов, обычно отмечают следующие результаты:

  • Снижение стоимости одного request на 40-60% по сравнению с поддержкой собственного пула proxy, в основном за счет отказа от оплаты отваливающихся proxy, неактивных IP и инженерных часов на поддержку ротации.
  • Повышение точности геолокации на уровне города с ~70% до более чем 95%, так как Proxy Finder фильтрует по городу и проверяет активность в момент последнего запроса перед передачей proxy.
  • Отсутствие отдельного пути для AI Overviews. Ключевое слово, получаемое через Single, можно перевести на Browser без переписывания конвейера данных. Контракт идентичен: на входе URL, на выходе response.

Вам все это не нужно для десяти ключевых слов и ноутбука. Но это становится необходимым, когда конвейер данных отслеживает десятки тысяч ключевых слов в разных странах, ваши клиенты обновляют дашборд в 9 утра в понедельник, а позиции должны быть реальными.

Главный вывод

Сложная часть мониторинга SERP уже давно не в самом request. Она заключается в маршрутизации. Из какого города вы делаете запрос? Активен ли этот IP? Вернул ли Google макет, который действительно увидел бы реальный пользователь в этой локации, или пустую страницу, которую они отдают, когда обнаруживают парсер?

Если вы SEO-команда, выполняющая отслеживание позиций на собственном стеке, вопрос на 2026 год заключается не в том, парсить ли Google. Вы уже это делаете. Вопрос в том, сможет ли ваша инфраструктура продолжать выдавать надежные данные о позициях, когда правила изменятся без предупреждения, и сколько ресурсов вашей инженерной команды вы готовы тратить на поддержание этой работоспособности.