Скрапинг современных веб-сайтов без headless-браузеров

Автор оригинала: Aris Pattakos
  • Перевод


Многие разработчики считают скрапинг сложной, медленной и неудобной для масштабирования задачей, особенно при работе с headless-браузерами. По моему опыту, можно заниматься скрапингом современных веб-сайтов даже не пользуясь безголовыми браузерами. Это очень простой, быстрый и хорошо масштабируемый процесс.

Для его демонстрации вместо Selenium, Puppeteer или любого другого решения на основе безголовых браузеров мы просто используем запросы на Python. Я объясню, как можно скрапить информацию из публичных API, которые потребляет на фронтэнде большинство современных веб-сайтов.

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

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

Скрапинг публичных API


Давайте разберёмся, как можно использовать API, которые веб-сайты применяют для загрузки данных. Я буду скрапить обзоры продукта на Amazon и покажу, как вам сделать то же самое. Если вы повторите описанный мной процесс, то удивитесь, насколько просто его подготовить.

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


Скриншот продукта.

Наша задача — извлечь как можно больше информации. Помните, когда занимаетесь скрапингом данных, жадность наказуема. Если не извлечь какую-то информацию, то придётся выполнять весь процесс заново, просто чтобы добавить ещё немного данных. И поскольку самой тяжёлой частью скрапинга являются HTTP-запросы, обработка не должна занимать много времени, однако необходимо постараться минимизировать количество запросов.

Перейдя на страницу продукта и нажав на «ratings», а затем выбрав «See all reviews», мы увидим следующее:


Страница обзоров продукта

Это отдельные обзоры. Наша задача — извлечь информацию с этой страницы без использования безголового браузера для рендеринга страницы.

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

В данном случае я изменил сортировку с «Top Reviews» на «Most Recent». Взглянув на вкладку Network, я вижу только один новый запрос, то есть обзоры получаются из этого запроса.

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


Следующим шагом будет переход на вкладку Response, чтобы понять, в каком формате принимаются обзоры.

Часто запросы бывают в читаемом формате JSON, который можно легко преобразовывать и хранить.

В других случаях, например, в нашем, всё чуть сложнее, но задача всё равно решаема.


Этот формат непохож на HTML, JavaScript или JSON, но обладает очень понятным шаблоном. Позже я покажу, как мы можем использовать код на Python для его парсинга, несмотря на странность этого формата.

После первоначальной подготовки настала пора перейти к коду. Вы можете запросто писать код для запросов на любимом языке программирования.


Для экономии времени я люблю использовать удобный конвертер cURL. Сначала я копирую запрос как cURL, дважды щёлкнув на него и выбрав «Copy as cURL» (см. скриншот выше). Затем я вставляю его в конвертер, чтобы получить код на Python.

Примечание 1: Существует множество способов выполнения этого процесса, я просто считаю данный способ наиболее простым. Если вы просто создаёте запрос с использованными заголовками и атрибутами, то это вполне нормально.

Примечание 2: Когда я хочу поэкспериментировать с запросами, я импортирую команду cURL внутрь Postman, чтобы можно было поиграться с запросами и понять, как работает конечная точка. Но в этом руководстве я буду выполнять всё в коде.

import requests
import json
from bs4 import BeautifulSoup as Soup
import time

headers = {
    'authority': 'www.amazon.com',
    'dnt': '1',
    'rtt': '250',
    'user-agent': 'Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.111 Safari/537.36',
    'content-type': 'application/x-www-form-urlencoded;charset=UTF-8',
    'accept': 'text/html,*/*',
    'x-requested-with': 'XMLHttpRequest',
    'downlink': '6.45',
    'ect': '4g',
    'origin': 'https://www.amazon.com',
    'sec-fetch-site': 'same-origin',
    'sec-fetch-mode': 'cors',
    'sec-fetch-dest': 'empty',
    'referer': 'https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/product-reviews/0132350882/ref=cm_cr_arp_d_viewopt_srt?ie=UTF8&reviewerType=all_reviews&sortBy=recent&pageNumber=1',
}

post_data = {
  'sortBy': 'recent',
  'reviewerType': 'all_reviews',
  'formatType': '',
  'mediaType': '',
  'filterByStar': '',
  'pageNumber': '1',
  'filterByLanguage': '',
  'filterByKeyword': '',
  'shouldAppend': 'undefined',
  'deviceType': 'desktop',
  'canShowIntHeader': 'undefined',
  'reftag': 'cm_cr_getr_d_paging_btm_next_2',
  'pageSize': '10',
  'asin': '0132350882',
  'scope': 'reviewsAjax1'
}

response = requests.post('https://www.amazon.com/hz/reviews-render/ajax/reviews/get/ref=cm_cr_arp_d_paging_btm_next_2',
    headers=headers, data=post_data)

Давайте разберём, что здесь происходит. Я взял заголовки и тело post из запроса в браузере. Удалил ненужные заголовки и сохранил те, благодаря которым запрос выглядит реальным. Самый важный заголовок, о котором никогда нельзя забывать — это User-Agent. Без User-Agent ожидайте частого блокирования.

В данных, передаваемых в запросе post, мы передаём язык, ID продукта, предпочтительную сортировку и пару других параметров, которые я на буду здесь объяснять. Легко понять, какой способ сортировки нужно передать, поиграв с фильтрами на странице продукта и изучив, как изменяется запрос. Пагинация проста, она задаёт pageSize и pageNumber, назначение которых понятно из названий. Если пагинация непонятна, то можно поэкспериментировать со страницей и посмотреть, как меняются запросы.

В данных post мы передаём большинство параметров в неизменном виде. Вот одни из самых важных параметров:

  • pageNumber: номер текущей страницы
  • pageSize: количество результатов на страницу
  • asin: ID продукта
  • sortBy: активный тип сортировки

Названия параметров pageNumber и pageSize говорят сами за себя. Мы разберёмся, как работает сортировка, меняя её тип на реальной странице и наблюдая за изменениями запросов на вкладке Network. ID продукта (asin) можно найти в ссылке на страницу, он выделен жирным:

https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882/#customerReviews

Чтобы понять, что делает каждый параметр в недокументированном API, нужно вызвать обновления страницы и понаблюдать за изменениями каждого из параметров.

Важное примечание о pageSize: этот параметр позволяет нам снизить количество запросов, необходимых для получения нужной информации. Однако обычно никакой API не позволяет вводить произвольный размер страницы. Поэтому я начал с 10 и добрался до 20, после чего количество результатов перестало увеличиваться. То есть максимальный размер страницы равен 20, его мы и используем.

Примечание: При использовании нестандартных размеров страниц вы упрощаете веб-сайту задачу вашей блокировки, поэтому будьте аккуратнее.

Следующий шаг — понять, как работает пагинация и циклическая передача запросов. Существует три основных способа обработки пагинации:

  • Номер страницы: при таком способе в каждом запросе передаётся номер страницы, 1 — первая страница, 2 — вторая, и т.д.
  • Смещение: смещения тоже часто используют. Если каждая страница содержит по десять результатов, то вторая страница будет иметь смещение на десять, а третья — смещение на двадцать, пока вы не достигнете конца результатов.
  • Курсор: ещё один распространённый способ обработки пагинации — использование курсоров. У первой страницы его нет, но ответ на первый запрос даёт нам курсор для следующего запроса, пока мы не достигнем конца.

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

Для этого нам нужно добраться до последней страницы и посмотреть, что произойдёт. В нашем случае простым индикатором последней страницы является отключенная кнопка «Next Page», как видно на показанном ниже скриншоте. Мы запомним это, чтобы прерывать цикл при написании кода.


Теперь давайте пройдём по всем страницам и соберём информацию. Кроме того, я покажу, как парсить фрагменты HTML при помощи Beautiful Soup 4.

page = 1
reviews = []
while True:
  post_data['pageNumber'] = page
  response = requests.post('https://www.amazon.com/hz/reviews-render/ajax/reviews/get/ref=cm_cr_arp_d_paging_btm_next_2',
    headers=headers, data=post_data)
  data = response.content.decode('utf-8')
  for line in data.splitlines():
    try:
      payload = json.loads(line)
      html = Soup(payload[2], features="lxml")
      # Stop scraping once we reach the last page
      if html.select_one('.a-disabled.a-last'):
        break
      review = html.select_one('.a-section.review')
      if not review:
        # Skip unrelated sections
        continue
      reviews.append({
        'stars': float(review.select_one('.review-rating').text.split(' out of ')[0]),
        'text': review.select_one('.review-text.review-text-content').text.replace("\n\n", "").strip(),
        'date': review.select_one('.review-date').text.split(' on ')[1],
        'profile_name': review.select_one('.a-profile-name').text
      })
    except Exception as e:
      pass
  print(str(len(reviews)) + ' reviews have been fetched so far on page ' + str(page))
  page += 1
  time.sleep(2)

Давайте разобьём этот код на части и посмотрим, что он делает:

# Мы каждый раз задаём новую страницу
post_data['pageNumber'] = page
# ...
# А в конце цикла увеличиваем счётчик страниц
page += 1

Итак, нам нужно разделить строки, чтобы можно было их парсить. Изучив ответ API, можно понять, что каждая строка — это или массив, или строка, содержащая &&&. Я решил воспользоваться принципом «лучше просить прощения, чем разрешения» и обернул каждый json.loads в блок try/except. Мы будем игнорировать строки &&& и сосредоточимся на тех, которые являются массивами JSON.

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

# Загружаем строку как JSON
payload = json.loads(line)
# Парсим HTML с помощью Beautiful Soup
html = Soup(payload[2], features="lxml")
# Прекращаем скрапить, когда достигнем последней страницы
if html.select_one('.a-disabled.a-last'):
  break
review = html.select_one('.a-section.review')
# Если раздел обзоров не найден, мы переходим к следующей строке
if not review:
  continue

Теперь настало время объяснить, как можно парсить тексты из HTML, для чего потребуется знание селекторов CSS и простейшей обработки.

reviews.append({
# Для получения количества звёзд мы разделяем текст, в котором, например, написано "1.0 out of 5" и просто сохраняем первое число
'stars': float(review.select_one('.review-rating').text.split(' out of ')[0]),
# Текст извлекается легко, но нам нужно избавиться от окружающих его новых строк и пробелов
'text': review.select_one('.review-text.review-text-content').text.replace("\n\n", "").strip(),
# Для получения даты нужно провести такое же простое разделение
'date': review.select_one('.review-date').text.split(' on ')[1],
# А имя профиля - это простой селектор
'profile_name': review.select_one('.a-profile-name').text
})

Я не буду вдаваться в подробности, моя задача — объяснить процесс, а не конкретную реализацию с Beautiful Soup или Python. Этот процесс можно повторить на любом языке программирования.

Текущая версия кода обходит страницы и извлекает звёзды, имя профиля, дату и комментарий из каждого обзора. Каждый обзор хранится в списке, который можно сохранить или подвергнуть дальнейшей обработке. Поскольку скрапинг запросто в любой момент может прерваться, важно часто сохранять данные и обеспечить удобный перезапуск скраперов с места, где произошёл сбой.

Если бы это был реальный пример для работы, то нужно было бы добавить довольно много других аспектов:

  • Использовать более надёжное решение для скрапинга (например, scrapy), поддерживающее паралелльные запросы, прокси, конвейеры обработки и сохранения данных, а также многое другое.
  • Парсить даты, чтобы иметь стандартный формат.
  • Извлекать все возможные элементы данных.
  • Создать систему для запуска обновлений страниц и обновления данных.

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

  • API меняется не слишком часто
  • Вам нужны данные только один раз
  • Скорость очень важна
  • API предоставляет больше информации, чем сама страница

Существует множество веских причин применения API для веб-скрапинга. Можно даже сказать, что этот способ более уважителен к серверу, поскольку требует меньшего количества запросов и не обязывает загружать статические ресурсы.

Не забывайте скрапить с уважением — добавляйте задержки между запросами и минимально используйте параллельные запросы к одному домену. Цель веб-скрапинга — доступ к информации и её анализ, чтобы создать на её основе что-то полезное, а не вызвать проблемы и торможение серверов.



На правах рекламы


Серверы для парсинга или любых других задач на базе новейших процессоров AMD EPYC. Создавайте собственную конфигурацию виртуального сервера в пару кликов.

VDSina.ru — хостинг серверов
Серверы в Москве и Амстердаме

Комментарии 31

    +22
    По моему опыту, можно заниматься скрапингом современных веб-сайтов даже не пользуясь безголовыми браузерами.
    Я очень много и долго этим занимаюсь, поэтому могу ответить, почему headless так популярен.
    Проблема в том, что современный веб основан на фреймоврках и зачастую реверс для скарпинга становится очень сложным — контент запрашивается по частям с бэкэнда, как-то модифицируется и лишь потом превращается в то, что необходимо вытащить.

    Да, можно раскрутить все запросы, в том числе и JS-обработчик который все это собирает потом в то, что нужно. Но это долго + зачастую это еще и меняется со временем.

    Отсюда и популярность headless — запросил и потом просто забрал готовое с веб-страницы.

    Однако да, если это можно вытащить простыми запросами и объем большой — то проще и быстрее заюзать обычные запросы.
      +3
      некоторые сайты имеют защиту от скрапинга, например если вы запрашиваете только данные но не картинки и html то вас заблокируют по ip
        0
        Скиньте пример сайта, который блокирует свою работу, если вы не загрузили картинки. Хотя на самом деле попахивает не установленным заголовком User-Agent
          +2
          Алишечка, например. Если запрашивать с их CDN картинки и ничего другого то быстро наступает бан. ЕМНИП они шарят ваш IP и при отдаче проверяют проценты запросов от него на другие ресурсы. Там достаточно сложная эвристика, к тому-же они постоянно ее меняют. Может сейчас они все это убрали — не знаю, проверялось в июне прошлого года.
            +1
            Бан наступает всегда, если квоту по запросам превысил. Здесь эвристики никакой и не нужно. Более 100 запросов в минуту — бан. Самое простое, что можно сделать со стороны сервера
              0
              Бан по частоте запросов и их количеству — это другое (но оно там тоже есть), тут фишка в том, что нужно в процессе запроса картинок время от времени запрашивать что-то еще, чтобы квота по запросам сбрасывалась. Грубо говоря, если вы запросили 50 картинок подряд и при этом ни одного запроса к апи/за html/стилями — бан, а если сделаете запрос — то можете следующие 50 грузить точно также. Это очень простое объяснение, там все сложнее. Они там вообще параноики, причем в ущерб удобства своих пользователям.
                0
                Да уж) Наверное эти расширения для «улучшения процесса покупок» их здорово бесят, раз они так загоняются
                  0

                  Вы очень странно рассуждаете. Нельзя сравнивать мелкий сайт с 1000 пользователями в месяц и мега площадку с сотнями миллионов пользователей в день. Первые конечно не будут придумывать как вам помешать скачать картинку с их сервера, это просто экономически не целесообразно, а вот вторые это совсем другая история. Представьте себе, каждый запрос от пользователя стоит реальных денег, тк использует реальные ресурсы (процессорное время, место на жёстком диске, амортизация сервера, электричество, работа персонала и даже уборщицы тёти Зины), компания за всё это платит и не понятно почему она вдруг должны отдавать вам (другой компании) эти ресурсы, за которые они заплатили, бесплатно. Вы думаете что вы один хотите бесплатно забрать картинки, описание, отзывы и прочую инфу? Таких как вы очень много. Компании на этом теряют деньги, хоть и косвенно. По этому вынуждены защищаться.

                    +1
                    Публичный API. Вот решение для компаний, у которых есть каталогизированная информация. Борьба со скрапингом путём усложнения сайта, это путь в никуда. Вы тратите больше ресурсов для придумывания логик запросов и интерфейсов, и это никак не спасает вас, а только увеличивает финансовое сопровождение сайта. А ведь можно просто создать публичный АПИ, даже платный, установив на него такую цену, что-бы было проще купить АПИ, чем скрапить сайт. Так вы и свои сервера разгрузите и ещё денежку заработаете на трудах по каталогизированию.

                    Многие этого не понимаю и продолжают вливать деньги в борьбу со скрапингом, а могли как минимум экономить, как максимум зарабатывать.
                      +2

                      Но вы же в статье не писали про получение данных из open api за деньги, а предлагаете скрапить их за даром, да ещё и из апи которое предназначено для сайта компании, для клиентов, а не для вас))) более того при наличии платного апи, большинство все равно выберет путь стыбрить за бесплатно...

                        0
                        Я увы ещё ни одной статьи на Хабре не написал)

                        Платное АПИ должно быть сбалансировано_платным (возможно бесплатным) относительно скрапинга веб версии. То есть лимиты к Веб версии должны быть такими, что-бы разделять реального пользователя и скрапера.
                  0
                  а если это был кэширующий прокси?
              0

              Вот вам в копилку ещё один кейс copart.com У них данные можно скрапить через их API к серверу, подсмотрев запросы на фронтенде. Но стоит защита. Если пользователь раз 2 минуты не обновит кукиес с помощью обфусцированного JS скрипта на сайте, то бан по IP на полчаса. Паппитир Js библиотека хэдлесс браузера эту проблему и решает.

            +1
            По моему опыту, можно заниматься скрапингом современных веб-сайтов даже не пользуясь безголовыми браузерами. Это очень простой, быстрый и хорошо масштабируемый процесс.
            Можете, пожалуйста, показать, как мне, например, получить номер телефона из объявления на авито или юле без использования headless-браузера? Там для получения номера надо, во-первых, авторизоваться (на юле ещё и код из смс ввести, для чего надо, например, писать скрипт для мобилки, который читает смс и отправляет код на на сервер),
            во-вторых, для получения номера телефона там генерируется каждый раз специальный ключ на клиенте, и этот ключ передаётся как get-параметр при ajax-запросе номера. Js-код обфусцирован, поэтому найти алгоритм и научиться генерировать этот ключ самому непросто. А даже если получится, завтра они поменяют алгоритм генерации и спрячут его в другое место, и придется опять начинать сначала.
            Можно ковырять код сайтов, ковырять их апи, искать способы обхода защиты от скраппинга… а можно просто поставить puppeteer и не париться.

            P.S. Скраппинг номеров осуждаю.
              0

              в данном случае без headless-браузера не обойтись. В статье речь именно о простых случаях, когда достаточно сформировать правильно запросы и получить нужные данные, не занимаясь лишней работой — рендерингом, исполнением JS и выжирая память.

                0
                А кто-то для простого парсинга/скраппинга использует headless-браузеры? Зачем? Это же из пушки по воробьям. Могу ошибаться, но обычно про headless-браузеры начинают гуглить и интересоваться, когда обычным парсингом не получается решить задачу.
                  +4

                  Я с вами согласен. В статье почему то этот подход преподносят как откровение.

                    +1
                    Дело в том, что когда появился Селениум и ФантомЖС, в скрапинг нахлынуло много новых «пользователей», которые сам скрапинг узнали как раз как связка Selenium+Browser, оттуда пошли монструозные конструкции для скрапинга банального ответа GET'у. Так что в принципе польза от статьи есть, как раз для той категории, которые кроме как через браузер раньше не скрапили

                    Вторая стадия монструозности началась с момента, когда в браузерах реализовали собственные headless режимы (тогда PhantomJS закончился). Это развязало руки даже тем скрипткидди, которые раньше этого сторонились. Стало же так просто, открыл браузер, записал действия с помощью расширения Selenium'а, скопировал в скрипт, добавил headless и всё, можно в прод.
              0
              Можно ковырять код сайтов, ковырять их апи, искать способы обхода защиты от скраппинга… а можно просто поставить puppeteer и не париться.

              Поддерживаю, к тому же вычислительные ресурсы стоят не так дорого (а иногда даже можно бесплатно, AWS Lambda дает бесплатно 400 000 ГБ‑секунд вычислений в месяц, 3 ГБ-секунд в среднем на одну страницу, а это ~133333 страниц бесплатно), да и vps никто не отменял, чем тратить рабочее время на обратный инжиниринг API, что может быть оправдано только при больших объемах данных и частой выгрузке.

              P.S. Скраппинг номеров и каких либо перс. данных тоже осуждаю
              0
              Еще можно подключить aiohttp чтобы парсить много запросов асинхронно. Ускоряет солидно, если горлышко в ожидании запросов (а обычно оно там и есть).
                0
                Лучше перейти сразу на scrapy. Асинхронность там из коробки. Можно настроить максимальное количество запросов на домен, умеет фильтровать запросы дубли и многое другое. Плюс отличная масштабируемость — добавил spider, добавил pipeline — готово. Если надо лезть глубже менять логику обработки ответов или отправки запросов — пишешь свой middleware. Раньше писал свои велосипеды для парсинга, на scrapy уже год как и доволен как слон.
                –2
                Ох вдсина, уже забанил несколько подсетей ваших за скрапинг. Что дальше, будете рекламировать как эффективно дудосить с ваших серверов?
                  0
                  Недавно в США скраперы выиграли дело против сайта, который их банил. Суд постановил, что скрапинг легален, а чинить ему препятствия незаконно
                  0
                  Я довольно долго работаю над срэпингом страниц и тоже некоторое время пытался съехать с Selenium на реверс инжиниринг запросов к бекэнду.
                  Но, несмотря на уверения автора далеко не многие сайты используют запросы для вытаскивания информации с бэка. Есть еще старый добрый JSP, JSF, PHP-генерация и тд.
                  Это первое. А второе — поддержка функционала становится головной болью. Каждый раз, когда что-то меняется в принимаемых/отдаваемых данных, надо начинать процесс заново. В то время, если меняется UI, то работоспособность скрэпера восстановить можно довольно быстро и несложно.
                  Но если надо что-то собрать быстро и много, то конечно через реверс-инжиниринг запросов это будет работать намного быстрее.
                    +1
                    Подскажите неспециалисту в этой области. Во тут в статье и в комментариях пишут, что владельцы крупных сайтов всячески сопротивляются скрейпингу данных. Но ведь есть поисковые роботы, которые в автоматическом режиме обходят весь сайт и скачивают с него весь контент. Почему их не банят?

                    Чем вообще поисковые роботы отличаются от роботов-скрейперов? И где граница между добросовестным поисковиком и недобросовестным скачивателем чужих данных?
                      +2
                      Почему их не банят?

                      1. IP-подсети поисковых ботов, с которых идет «благой» скрейпинг заранее известны и они могут добавляться в список разрешенных без ограничений на количество запросов.
                      2. Пункт 1. сочетается с полем User-Agent, в котором прописывается например Mozilla/5.0 (compatible; YandexBot/3.0; +http://yandex.com/bots)
                      3. Поисковыми ботами учитывается директива Crawl-delay, что так скажем «смягчает» нагрузку на целевой сайт и позволяет тем самым сделать так, чтобы боты не упирались в лимиты запросов.

                      Чем вообще поисковые роботы отличаются от роботов-скрейперов?

                      По своей сути, технически, практически ничем. Отличаются конечной целью использования данных. Например гуглу интересны данные с целью продажи рекламы, а производителям/продавцам например интересны площадки конкурентов, которые демпингуют цены на товары, тем самым вытесняют их с рынка и т.д.

                      И где граница между добросовестным поисковиком и недобросовестным скачивателем чужих данных?

                      ИМХО граница в нарушении интеллектуальных прав первоисточника. Т.к. ты например тратил свои деньги или время на написание статей, а какой-то ушлый скраперщик спарсил все твой статьи за 5 минут и опубликовал на своем сайте под видом своих, а из-за того, что у него например сайт выше в поиске и/или имеет хорошую поисковую оптимизацию, то твои статьи «выстрелили» на его сайте. Он получил прибыль за рекламу, а ты только разочарование. Поисковики не скрывают ссылки на источник информации, в отличие от недобросовестных скраперщиков.
                        0
                        1. IP-подсети поисковых ботов, с которых идет «благой» скрейпинг заранее известны и они могут добавляться в список разрешенных без ограничений на количество запросов.

                        То есть, если кто-то создаст новую поисковую систему, то у него будут проблемы с индексацией сайтов — его будут принимать за скрейпера и блокировать?

                        Поисковики кроме ссылок на найденный сайт показывают часть контента — кусок статьи, картинки. Есть какие-нибудь нормы, какую часть контента имеет право показывать поисковик на своей странице?
                          0

                          С виду просто, но есть нюансы: вроде поисковик это то кто легально показывает содержимое вашего сайта на своём сайте, не раскрывая полностью текст и заставляя переходить людей по ссылкам. А вот скрейпер это тот кто выдаёт ваш контент за свой, всячески скрывая источник.
                          Но что если скрейпер вообще не публикует ваш уникальный контент, но собирает базу для анализа конкурентов? Ведь Гугл тоже продаёт информацию о сканированных страницах. Я уже не говорю про Яндекс Турбо или Google AMP где вообще весь контент показывается с серверов поисковика, тем самым отбирая посетителей у вас. С юридической точки зрения любая автоматизация сбора информации это скрейпинг. Следовательно разделить добросовестность их использования можно только по конечному результату. Поисковики приводят к вам посетителей, это плюс, продают информацию о вас — это минус. От скреперов только минусы.

                          0
                          Добросовестный поисковик приносит пользу сайту, приводя ему трафик. Недобросовестный скрапер никакой пользы сайту не приносит
                          +1
                          я делаю high-performance скрапинг с одной биржи и там только через реверс-инжиниринг бекенда.
                          пишу скрапер для одного потока, потом просто создаю 20-30-100 потоков и выжимаю все из I/O и их бекенда.
                          проблема это отслеживать их многие фишечки а-ля CSRF токены и кукисы, которые следят что это пользователь в броузере, а не бот — с опытом приходит понимание всех их защит и их становится легко победить.
                          Также хотелось бы узнать кто как делает ip masquerading? это если вы скрапите в 100 потоков, чтобы запросы шли через 100 разных прокси по всему миру

                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                          Самое читаемое