Ротация прокси для парсинга Google SERPПарсинг результатов поиска без блокировок

Парсинг результатов поиска Google перестаёт работать по одной конкретной причине: Google воспринимает поток запросов с одного IP именно так, как есть, то есть как бота, и начинает выдавать CAPTCHA и 429 уже через несколько десятков запросов. Решение проблемы состоит не в хитром заголовке или более длинной задержке. Оно состоит в том, чтобы каждый запрос отправлять с другого IP, который читается как настоящий пользователь, и именно этим занимается ротация прокси. Правильно настройте модель ротации и тип IP, и парсинг SERP станет рутиной; ошибётесь, и будете тратить время на прохождение страниц согласия вместо разбора результатов.

Этот материал о практической стороне: почему Google блокирует именно так, почему ротация на каждый запрос лучше статичного пула для SERP, какой тип IP реально выживает, рабочий пример на Python и момент, когда управляемый SERP-эндпоинт просто потребует меньше усилий, чем поддержка собственной ротации. Если вы хотите сначала разобраться с основами прокси, что такое прокси-сервер охватывает тот единственный уровень косвенности, на котором строится всё остальное.

Почему Google так агрессивно блокирует парсеры

Весь бизнес Google построен на обслуживании людей, поэтому его защита от злоупотреблений настроена на выявление всего, что не является человеком. Парсер одновременно нарушает сразу несколько из этих условий. Наиболее очевидный сигнал, объём запросов с одного адреса: реальный пользователь делает несколько поисковых запросов в час, тогда как наивный парсер отправляет сотни в минуту с одного IP. Одной только этой скорости достаточно, чтобы получить страницу согласия sorry/index или CAPTCHA.

Сам IP является вторым сигналом. Google знает, какие диапазоны адресов принадлежат облачным и хостинговым провайдерам, поэтому трафик с IP датацентра начинается с дефицита доверия ещё до первого запроса. Поверх этого действуют проверки формы запроса: отсутствующие или роботизированные заголовки, TLS-отпечаток, не совпадающий с браузером, который вы декларируете в User-Agent, отсутствие cookie и одинаковые интервалы между запросами. Ротация IP устраняет первые два сигнала, но не остальные, что и делает ротацию необходимым, но недостаточным условием, о чём мы вернёмся позже.

Почему ротация на каждый запрос, правильная модель для SERP

Ротация означает смену выходного IP, чтобы последовательные запросы не исходили с одного и того же адреса. Существуют две модели доставки, и для Google разница принципиальна.

Sticky-сессия удерживает один IP для серии запросов, что нужно при работе с авторизованными потоками, где внезапная смена IP выглядит подозрительно. Ротация на каждый запрос меняет IP при каждом вызове. У Google Search нет логина и нет сессии для сохранения, поэтому нет смысла держать один IP, зато есть все основания распределять запросы по многим. Ротация на каждый запрос, это модель, которая подходит для SERP: тысяча запросов, распределённых по тысяче адресов, выглядит как тысяча любопытных пользователей, а не одна машина. Подробнее о механике встраивания ротации в парсер написано в как использовать ротирующие прокси, а концепция сама по себе разобрана в ротация IP-адреса.

Размер пула за ротацией составляет вторую половину уравнения. Ротация по десяти IP при высоком объёме просто медленнее исчерпывает лимиты этих десяти адресов. Большой пул, вот что удерживает любой отдельный адрес ниже порога Google на IP, поэтому ротация и размер пула, это фактически одно решение.

Тип IP определяет, помогает ли ротация вообще

Ротация имеет смысл только в том случае, если IP, по которым вы ротируете, пользуются доверием. Пройдитесь по тысяче IP датацентров, и Google заблокирует все тысячи по одному и тому же ASN-сигналу, просто растянув это на большее число запросов. Тип IP, это ключевой выбор для парсинга SERP.

Для Google Search практический ответ, резидентские прокси: IP, которые интернет-провайдеры назначили реальным домохозяйствам, поэтому ротированный запрос читается как обычный посетитель, а не сервер. IP датацентров подходят для менее защищённых целей, но быстро помечаются на SERP, а мобильные дают больше доверия (и стоят дороже), чем обычно требуется для поисковых результатов. Полный анализ компромиссов содержится в датацентр против резидентских прокси, а статическая резидентская альтернатива рассмотрена в ISP против резидентских прокси. Цифры здесь описывают типичный случай; ваш точный процент блокировок зависит от объёма запросов, региона и степени защиты конкретных страниц результатов.

Настройка ротации прокси на Python

Самый чистый способ ротировать, направить клиента на единый ротирующий эндпоинт и дать ему менять выходной IP на каждый запрос, вместо того чтобы самостоятельно поддерживать и проверять список сырых IP. Для вашего кода это просто прокси: один хост, один порт, ваш токен как учётные данные. Smart AI Proxy Crawlbase работает именно так, поэтому интеграция занимает несколько строк.

Установите единственную зависимость:

pip install requests

Затем направьте запросы через ротирующий эндпоинт. В примере выполняется несколько запросов, интервалы между ними варьируются, и выводится результат каждого:

import requests
import random
import time
from urllib.parse import quote_plus

# One rotating endpoint swaps the exit IP per request.
proxy_url = "http://[email protected]:8012"
proxies = {"http": proxy_url, "https": proxy_url}

headers = {
    "User-Agent": (
        "Mozilla/5.0 (Windows NT 10.0; Win64; x64) "
        "AppleWebKit/537.36 (KHTML, like Gecko) "
        "Chrome/124.0 Safari/537.36"
    ),
}

queries = ["web scraping", "residential proxies", "serp api"]

for query in queries:
    url = "https://www.google.com/search?q=" + quote_plus(query)
    resp = requests.get(url, proxies=proxies, headers=headers, verify=False)
    print(query, resp.status_code, "blocked" if "/sorry/" in resp.url else "ok")

    # Vary timing so requests do not arrive on a fixed clock.
    time.sleep(random.uniform(2, 5))

Замените _USER_TOKEN_ токеном из вашего аккаунта Crawlbase. Обратите внимание, что код делает помимо ротации: он отправляет реалистичный User-Agent, рандомизирует паузу между запросами и проверяет наличие редиректа /sorry/, который Google использует для страниц с вызовами. Именно эти детали отличают ротацию, которая работает, от ротации, которая молча возвращает страницы согласия, воспринимаемые затем как результаты.

Лучшие практики для устойчивой ротации

Несколько привычек поддерживают работоспособность ротирующего SERP-парсера в долгосрочной перспективе, а не только в первый час.

• Ограничивайте нагрузку на IP, а не только суммарную. Большой пул позволяет удерживать высокую общую пропускную способность, пока ни один отдельный адрес не видит больше, чем тоненький ручеёк. Пул поглощает объём, а нагрузка на IP остаётся человекообразной.
• Рандомизируйте задержки и заголовки. Фиксированные паузы и один статичный User-Agent, это отпечаток. Варьируйте и то, и другое. Ротация User-Agent вместе с IP описана в как парсить сайты без блокировок.
• Обнаруживайте блокировки, не парсите сквозь них. Следите за редиректом /sorry/, разметкой CAPTCHA и пустыми контейнерами результатов. Воспринимайте их как ошибки для повтора на свежем IP, а не как данные.
• Делайте паузу при проверках. Если доля блокировок растёт, замедляйтесь и расширяйте пул, а не усиливайте давление. Агрессия после срабатывания флага только усугубляет ситуацию.
• Используйте браузер только когда страница этого требует. Обычный HTTP быстрее и дешевле; оставляйте headless-рендеринг для типов результатов, загружаемых на стороне клиента. Веб-скрапинг с Python и Selenium показывает этот путь.

Если ваша цель, ранжирование и исследование ключевых слов, SEO-прокси охватывает аспект геотаргетинга, поскольку SERP различаются по стране, а расположение выходного IP определяет, какие результаты вы видите.

Когда управляемый SERP-эндпоинт лучше собственной ротации

Всё перечисленное выше реализуемо, и при небольших объёмах это имеет смысл. Затраты проявляются при масштабировании. Одна лишь ротация оставляет на вашей ответственности остальную часть задачи: поддержание работоспособности пула, согласование TLS-отпечатков, решение CAPTCHA или маршрутизация в обход них, рендеринг страниц результатов, загружаемых на стороне клиента, и повторные попытки при каждом вызове. Это большая часть стека для SERP-скрапинга, а ротация была лишь первым её слоем.

Управляемый эндпоинт сворачивает всю эту работу в один запрос. Вы отправляете URL или запрос; он выбирает доверенный резидентский IP, посылает правдоподобный отпечаток, рендерит при необходимости, повторяет попытку на стороне сервера при блокировке и возвращает готовый результат. Crawling API создан именно для этого: там, где сырой ротирующий прокси даёт вам чистый IP и отступает в сторону, API поглощает блокировки и возвращает успех. Сравнение двух подходов приведено в backconnect-прокси против Crawling API.

Часто задаваемые вопросы

Почему Google так быстро блокирует парсеры?

Google настраивает защиту от злоупотреблений для выявления всего, что не является человеком-браузером. Один IP, генерирующий множество поисковых запросов в минуту, нарушает лимит на уровне IP, а трафик с известного диапазона датацентров начинается с низкого доверия ещё до первого запроса. Добавьте роботизированные заголовки, отсутствие cookie и одинаковые интервалы, и результатом станет CAPTCHA или страница согласия /sorry/ уже через несколько десятков запросов.

Сколько прокси нужно для надёжного парсинга Google?

Достаточно, чтобы ни один IP не превышал человекоподобную скорость запросов при вашем целевом объёме. Фиксированного числа не существует: оно масштабируется вместе с количеством запросов в минуту. Ротация по десяти IP при высоком объёме просто медленнее исчерпывает лимиты этих десяти адресов, поэтому большой ротирующий пул, а не горстка статичных адресов, удерживает каждый IP ниже радара Google.

Какой тип прокси лучше для парсинга результатов Google Search?

Резидентские прокси. Они выходят с IP, которые провайдеры назначили реальным домохозяйствам, поэтому ротированный запрос читается как обычный посетитель, а не сервер. IP датацентров распознаются по ASN и быстро блокируются на SERP, а мобильные прокси обычно дают больше доверия (и стоят дороже), чем требуется для поисковых результатов. Начинайте с резидентских и эскалируйте только если конкретные страницы результатов всё равно создают препятствия.

Sticky-сессии или ротация на каждый запрос для SERP?

Ротация на каждый запрос. Sticky-сессии существуют для удержания одной идентичности в рамках авторизованного потока, а Google Search не имеет логина или сессии для сохранения. Смена выходного IP на каждый запрос распределяет ваши запросы по пулу, и каждый адрес выглядит как один случайный пользователь, а не одна машина.

Достаточно ли ротации прокси для обхода CAPTCHA Google?

Само по себе нет. Ротация нейтрализует лимит на уровне IP и проверку ASN датацентра, но ничего не делает с роботизированным TLS-отпечатком, отсутствующими cookie или фиксированными интервалами между запросами. Чистый резидентский IP с очевидно автоматизированным запросом всё равно вызовет CAPTCHA. Сочетайте ротацию с реалистичными заголовками, варьируемыми задержками и реальным отпечатком браузера при клиентском рендеринге страниц.

Когда SERP или Crawling API лучше, чем своя ротация?

Как только объём превысит несколько тысяч запросов или страницы результатов рендерятся на стороне клиента. Ротация, только первый слой; вы по-прежнему отвечаете за работоспособность пула, отпечатки, обработку CAPTCHA, рендеринг и повторные попытки. Управляемый эндпоинт сворачивает всё это в один запрос: вы отправляете запрос и получаете разобранный результат, а ротация и антибот-обработка выполняются на стороне сервера.

HR

Hassan Rehan

Инженер-программист · Crawlbase

Инженер-программист в Crawlbase, пишет практические руководства по ротирующимся прокси, скрейпингу и тонкостям подключения прокси к реальному коду.