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

Проблема

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

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

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

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

Подход FourA

Узкое место при масштабном скрейпинге SERP заключается не в самом request. Дело в маршрутизации.

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

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

Proxy Finder поддерживает рабочий пул proxy, проверенных свежими проверками доступности и размеченных по стране, региону, городу и ASN. Когда request должен прийти из Манчестера, Бостона или Сан-Паулу, Proxy Finder выбирает тот адрес, который действительно находится там и был активен при последней проверке. Выбор происходит до отправки запроса, а не во время нее. Подробнее о том, почему важен этот уровень маршрутизации, читайте в нашей статье о Smart Proxy Routing.
Single берет на себя получение самой выдачи SERP. Для стандартной органической выдачи сырого HTML более чем достаточно. Установите unblocker: true, и request получит актуальную сигнатуру браузера без необходимости выяснять, какую сигнатуру Google проверяет на этой неделе. Мы подробно разобрали работу этого флага на уровне сети в нашей статье о Web Unblocker.
Browser обрабатывает страницы SERP, где критически важный контент появляется после выполнения JavaScript. AI Overviews, расширенные товарные блоки, содержимое панелей знаний, фиксированные локальные 3-pack. Тот же 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, отслеживающие защищенные вертикали, уже живут в этой реальности. Мы также писали о том, как bot detection стал поведенческим, что добавляет четвертую ось (непрерывность сессии) для сайтов, анализирующих последовательность requests, а не сигналы отдельных 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. Вы уже это делаете. Вопрос в том, сможет ли ваша инфраструктура стабильно выдавать надежные данные по позициям при внезапном изменении правил, и сколько ресурсов инженерной команды вы готовы тратить на ее поддержание.