Отправьте несколько запросов к поисковой системе, ничего не случится. Отправьте несколько тысяч так, как это делает скрипт, и где-то по пути ответы изменятся: сначала замедление, потом страница верификации, затем полная блокировка. Поисковые системы вроде Google, Bing и Yahoo располагают одними из самых зрелых систем обнаружения ботов в интернете, и они применяют их именно потому, что страницы результатов поиска постоянно становятся целью автоматизированного сбора данных.
Эта статья объясняет, как поисковые системы обнаруживают скраперы, сигнал за сигналом: частоту запросов, которую они отслеживают, репутацию IP, которую они оценивают, заголовки и отпечатки, которые они читают, и поведение, которое они ожидают от реального браузера. К концу вы поймёте, почему простой скрапер обнаруживается так быстро, что именно измеряет каждая защита и как легитимный сбор данных остаётся на правильной стороне черты.
Почему поисковые системы блокируют скраперы
Страница результатов поиска (SERP) дорого обходится в производстве и ценна для сбора, поэтому у операторов есть веские основания ограничивать автоматизированный доступ. Их условия использования, как правило, запрещают прямой парсинг SERP, а помимо политического вопроса есть и практический: интенсивный автоматизированный трафик конкурирует с реальными пользователями за пропускную способность. Чтобы защитить и то, и другое, они накладывают несколько сигналов обнаружения друг на друга. Ни один отдельный сигнал не решает, являетесь ли вы ботом. Каждый вносит свой вклад в оценку, и как только достаточное их число согласуется, вас замедляют, испытывают CAPTCHA или блокируют.
Важное следствие для тех, кто создаёт скрапер: пройти одну проверку недостаточно. Можно идеально ротировать IP и всё равно попасться на заголовках; можно задать безупречный User-Agent и всё равно попасться на частоте запросов. В разделах ниже основные сигналы разбираются по отдельности, чтобы вы понимали, что именно ищет каждый из них.
Частота и объём запросов
Первый и самый дешёвый сигнал, просто количество запросов, их скорость и регулярность. Человек, просматривающий результаты поиска, генерирует медленный, нерегулярный поток запросов с паузами для чтения. Скрапер генерирует быстрый, равномерный поток без пауз вообще. Когда один источник отправляет значительно больше запросов за короткий промежуток, чем это в принципе возможно для человека, этот всплеск, очевидный признак, и именно он, как правило, вызывает первую CAPTCHA.
Абсолютно равные интервалы сами по себе тоже выдают автоматизацию. Запрос ровно каждые 500 миллисекунд выглядит более очевидно механическим, чем тот же общий объём, распределённый неравномерно. Поверх этого работают ограничение частоты и троттлинг запросов: система отслеживает запросы с источника за временной период и начинает замедлять или отклонять ответы, как только счётчик превышает порог. Именно поэтому постепенное, неравномерное время запросов куда важнее сырой скорости для того, чтобы оставаться незаметным.
Репутация IP и диапазоны датацентров
Каждый запрос несёт исходный IP, и поисковые системы оценивают этот адрес ещё до того, как обращают внимание на содержимое запроса. Оценку формируют два фактора. Первый, поведение: IP, который недавно отправлял трафик, похожий на автоматизированный, имеет худшую репутацию, чем тот, который этого не делал. Второй, происхождение: сеть, которой принадлежит адрес, многое говорит о том, насколько вероятно, что за ним стоит реальный человек.
Адреса, принадлежащие известным диапазонам датацентров, хостингов, прокси и VPN, вызывают подозрение, поскольку реальные потребители редко просматривают сайты с них. Многие из этих диапазонов хорошо задокументированы и фактически помечены заранее, так что скрапер, работающий с облачного сервера, может быть отфильтрован до отправки второго запроса. Жилые адреса, привязанные к обычным домашним подключениям, воспринимаются как гораздо более правдоподобные. Это суть компромисса датацентровые vs жилые прокси: сам скрапер ведёт себя одинаково, но происхождение его трафика меняет то, как этот трафик оценивается. Общие и переработанные адреса также наследуют репутацию, оставленную предыдущими пользователями.
Отсутствующие или странные заголовки и User-Agent
Реальный браузер отправляет последовательный, предсказуемый набор HTTP-заголовков в каждом запросе: полную строку User-Agent, Accept, Accept-Language, Accept-Encoding и другие, в узнаваемом порядке. Простой HTTP-клиент отправляет меньше заголовков, зачастую в другом порядке, иногда с User-Agent по умолчанию, который называет саму библиотеку. Каждый из этих пробелов легко обнаружить.
User-Agent, наиболее отслеживаемый заголовок, поскольку его проще всего настроить неправильно. Оставить значение по умолчанию, значит напрямую объявить о скрапере. Задать одну фиксированную строку браузера для тысяч запросов лучше, но всё равно подозрительно, поскольку реальный трафик демонстрирует распределение браузеров и версий. Ротация User-Agent помогает запросам выглядеть как исходящие с разных устройств, но только если остальные заголовки соответствуют заявленному браузеру. Chrome User-Agent в сочетании с набором заголовков или Accept-Language, который ни один реальный Chrome не выдаст, является противоречием, и именно противоречия ищут системы обнаружения.
Отпечаток TLS и HTTP
Ещё до того как будет прочитан какой-либо заголовок, само соединение оставляет отпечаток. Когда ваш клиент открывает HTTPS-соединение, он отправляет TLS Client Hello, в котором перечисляет поддерживаемые наборы шифров, расширения и кривые в определённом порядке. Эта форма характерна для клиентской библиотеки и версии, и её хэширование даёт сигнатуру (обычно называемую JA3-отпечатком). Рукопожатие Chrome выглядит как Chrome; рукопожатие Python HTTP-клиента выглядит как Python, независимо от того, какой User-Agent он заявит позднее.
Это уровень, который нельзя исправить заголовком, и именно здесь многие скраперы раскрываются. Можно задать все заголовки, заявляя о себе как о браузере, но если TLS-рукопожатие соответствует скриптовой библиотеке, сетевой и прикладной уровни расходятся, и защитник, сравнивая их, немедленно видит несоответствие. Та же идея распространяется на уровень HTTP: согласованная версия, метод мультиплексирования соединения и порядок низкоуровневых фреймов, всё это добавляет детали, которые реальный браузер воспроизводит естественно, а простой клиент, нет. Подробнее о том, как эти сигналы уровня устройства сочетаются между собой, читайте в нашем руководстве по отпечатку браузера.
Поведенческие паттерны и отсутствие выполнения JavaScript
Современные страницы поиска запускают JavaScript, и этот скрипт одновременно решает две задачи: динамически загружает результаты и наблюдает за поведением посетителя. Реальный пользователь генерирует поток поведенческих сигналов, включая движения мыши, прокрутку, смену фокуса и нерегулярные интервалы между действиями. Скрапер, получающий сырой HTML, не генерирует ничего из этого. Само по себе отсутствие поведения является сигналом.
Здесь, как правило, проявляются два сбоя одновременно. Первый, вообще не выполнять JavaScript. Многие результаты вставляются на страницу после её загрузки, поэтому клиент, читающий только начальный HTML, может пропустить сами данные, которые ищет, а отсутствие какого-либо выполнения скриптов идентифицирует его как нечеловека. Второй, выполнять JavaScript, но вести себя роботоподобно: мгновенная навигация, никакой прокрутки, никакого курсора, абсолютно равномерные задержки. Безголовые браузеры, управляемые Puppeteer, Playwright или Selenium, умеют рендерить страницу и даже имитировать человекоподобное взаимодействие, что частично закрывает этот пробел, хотя плохо настроенный безголовый браузер рекламирует собственные флаги автоматизации и попадается иным способом. Если ваши цели интенсивно используют клиентский рендеринг, наше руководство по краулингу JavaScript-сайтов охватывает технические детали.
Ссылки-приманки
Некоторые защиты не ждут, пока скрапер нарушит правила, а сами его заманивают. Приманка, это ссылка или поле формы, размещённые на странице так, чтобы человек их никогда не увидел и не перешёл по ним: скрытые через CSS, расположенные за пределами экрана или помеченные так, чтобы реальные браузеры их игнорировали. Человек, ориентирующийся визуально, полностью пропускает их. Скрапер, обходящий все якоря в HTML, переходит по такой ссылке, и это единственное действие раскрывает, что посетитель читает сырую разметку, а не отрисованную страницу. Как только источник активирует приманку, система с высокой уверенностью определяет автоматизацию и может действовать напрямую.
Каждый из перечисленных сигналов указывает на один и тот же вывод: пройти одну проверку недостаточно, а поддерживать согласованность всех вручную, это и есть самая сложная часть. Crawling API обрабатывает всё это как один управляемый запрос. Он рендерит JavaScript, ротирует реальные пользовательские IP, чтобы ваше происхождение воспринималось как жилое, предоставляет согласованные заголовки и соответствующий отпечаток и поглощает CAPTCHA-вызовы, так что вы указываете на единственную конечную точку и получаете назад разобранные данные вместо страниц блокировки. Попробуйте на бесплатном тарифе.
CAPTCHA-вызовы
Когда перечисленные выше сигналы накапливают достаточно подозрений, но не уверенности, система не блокирует напрямую, а просит посетителя доказать, что он человек. reCAPTCHA или визуальный вызов дёшевы для реального пользователя и дороги для скрипта. CAPTCHA не случайны: они запускаются теми же паттернами, которые описаны выше, включая высокую частоту запросов, плохую репутацию IP, отсутствующие заголовки браузера и несогласованный отпечаток. Иными словами, CAPTCHA, это, как правило, видимый результат сигнала обнаружения, который был активирован ранее.
Для легитимного парсинга правильная реакция на CAPTCHA, не пытаться её обойти силой, а понять причину её появления и устранить её: замедлиться, улучшить источник, исправить заголовки. Сервисы решения CAPTCHA существуют и имеют своё место, но скрапер, постоянно натыкающийся на вызовы, это скрапер, требующий внимания на уровне вышестоящих сигналов. Подробнее о причинах и способах решения читайте в нашем руководстве по обходу CAPTCHA при веб-парсинге.
Почти каждая защита здесь по сути является проверкой согласованности. IP, заголовки, TLS-рукопожатие, отрисованное поведение и частота запросов, всё это должно описывать одного и того же правдоподобного человека. Скрапер редко обнаруживается по одному сигналу; он обнаруживается потому, что два его сигнала противоречат друг другу.
Что это означает для легитимного парсинга
Это не означает, что данные поисковых систем недоступны для легитимных сборщиков. Это означает, что наивный подход (быстрый цикл сырых HTTP-запросов с облачного сервера с заголовками по умолчанию) сразу же активирует почти все сигналы и быстро даёт сбой. Надёжный сбор данных работает, потому что сохраняет согласованность каждого сигнала: жилые IP, разумно ротируемые, чтобы ни один источник не нёс всю нагрузку; полный и согласованный набор заголовков, соответствующий заявляемому браузеру; отпечаток, согласующийся с этими заголовками; отрисованный JavaScript, чтобы динамические результаты действительно появились; и частота запросов, которая выглядит как человек, а не как метроном.
Поддерживать всё это согласованным вручную, настоящая инженерная работа, и она никогда не завершена, поскольку системы обнаружения развиваются, а версии браузеров меняются. Именно этот пробел восполняет управляемый подход. Сервис, который поддерживает за вас пул IP, рендеринг, согласованность отпечатков и обработку вызовов, превращает постоянно меняющуюся задачу поддержки в единственную конечную точку. Более широкий сценарий работы без блокировок, для поисковых систем и не только, описан в нашем руководстве о том, как парсить сайты без блокировок.
Ответственный парсинг
Обход обнаружения, техническая тема, но именно ответственный сбор данных обеспечивает его устойчивость. Соблюдайте условия использования каждого сайта и директивы его файла robots.txt и помните, что условия поисковых систем, как правило, ограничивают прямой парсинг SERP. Отдавайте предпочтение публичным данным перед теми, что за авторизацией или платным барьером, и никогда не собирайте персональные данные, для обработки которых у вас нет оснований. Держите частоту запросов разумной, чтобы не ухудшать сервис для реальных пользователей, честно идентифицируйте свой трафик там, где это ожидается, и агрессивно используйте кэширование, чтобы не повторять запросы к одним и тем же страницам. Сбор данных в вежливом темпе, это не только этичный выбор, но и наименее вероятный способ получить блокировку.
Ключевые выводы
- Обнаружение многоуровневое. Поисковые системы оценивают сразу много сигналов и действуют, когда их достаточно согласуется, поэтому прохождение одной проверки не сохраняет вас в системе.
- Частота и источник, на первом месте. Всплеск объёма запросов и IP датацентра или прокси, это самые дешёвые и быстрые признаки для обнаружения, часто ещё до прочтения содержимого.
- Заголовки и отпечатки должны согласовываться. Chrome User-Agent в сочетании с TLS-рукопожатием скриптовой библиотеки или тонким набором заголовков, это противоречие, которое раскрывает скрапер.
- Поведение и JavaScript важны. Отсутствие выполнения скрипта, прокрутки, роботоподобные задержки и переходы по приманкам, всё это идентифицирует посетителя как автоматизированного; CAPTCHA обычно является видимым результатом одного из этих факторов.
- Цель, согласованность. Надёжный и ответственный сбор данных сохраняет согласованность IP, заголовков, отпечатка, рендеринга и темпа, и именно это обеспечивает управляемый подход.
Часто задаваемые вопросы
Как поисковые системы обнаруживают скраперы?
Они объединяют несколько сигналов: количество запросов и их скорость, репутацию и сетевое происхождение исходного IP, соответствие заголовков и User-Agent реальному браузеру, TLS и HTTP-отпечаток соединения, наличие выполнения JavaScript и человекоподобного поведения, ссылки-приманки и CAPTCHA-вызовы. Ни одна проверка не является решающей. Как только достаточное число сигналов указывает на автоматизацию, посетитель замедляется, получает вызов или блокируется.
Почему мой скрапер блокируется, даже если у меня хороший прокси?
Потому что IP, только один из многих сигналов. Если источник чистый, но частота запросов роботоподобна, заголовки скудны или TLS-рукопожатие говорит о скриптовой библиотеке, в то время как User-Agent заявляет браузер, другие сигналы всё равно вас выявят. Обнаружение смотрит на всю картину и реагирует на противоречия между уровнями, а не на IP в изоляции.
В чём разница между датацентровыми и жилыми IP для парсинга?
Датацентровые IP принадлежат хостинг-провайдерам и облачным сетям, диапазонам, с которых реальные потребители редко просматривают сайты, поэтому они широко помечены заранее и оцениваются как подозрительные. Жилые IP привязаны к обычным домашним подключениям и воспринимаются как гораздо более правдоподобные. Один и тот же скрапер ведёт себя одинаково с любого из них, но его трафик оценивается по-разному в зависимости от того, откуда он, по всей видимости, исходит.
Почему скраперы вызывают CAPTCHA?
CAPTCHA, видимый результат более раннего сигнала обнаружения. Высокая частота запросов, плохая репутация IP, отсутствующие или несогласованные заголовки браузера и несвязный отпечаток повышают подозрение достаточно для выдачи вызова без прямой блокировки. Устойчивое решение, устранить первопричину, а не только решать вызов, поскольку скрапер, постоянно натыкающийся на CAPTCHA, имеет сигналы, требующие внимания.
Что такое ссылка-приманка?
Приманка, это ссылка или поле формы, размещённые на странице так, чтобы человек с ними никогда не взаимодействовал: скрытые через CSS, перемещённые за пределы экрана или иначе невидимые в отрисованном представлении. Реальный посетитель пропускает их; скрапер, обходящий все якоря в сыром HTML, переходит по ним. Это единственное действие раскрывает, что посетитель читает разметку, а не отрисованную страницу, давая сайту высокую уверенность в автоматизации трафика.
Возможен ли ответственный парсинг поисковых систем?
Да, при соблюдении следующих условий: сбор публичных данных в разумном темпе, соблюдение условий использования и robots.txt, исключение персональных и закрытых данных, кэширование для предотвращения избыточных запросов и отсутствие ухудшения сервиса для реальных пользователей. Ответственный и надёжный сбор данных, как правило, совпадают: трафик, который вежлив и последователен, также наименее вероятно будет помечен.
Обходите любой сайт в масштабе, без борьбы с инфраструктурой.
Crawlbase берёт на себя прокси, отпечатки и CAPTCHA, чтобы ваша команда выпускала конвейеры данных вместо поддержки обвязки краулинга. 1 000 запросов бесплатно, без карты.