Блог Froxy | Новости, полезные статьи о использовании прокси

Этичный скрапинг: robots.txt, TOS и законы о персональных данных

Written by Команда Froxy | 02.10.2025 7:00:01

Вы уже точно знаете, что такое веб-скрапинг, если задаетесь вопросами об этике. 

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

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

Сейчас разберемся, как соблюдать этику сбора данных — с уважением к людям, сайтам и законам. 

Почему вы должны задумываться об этике веб-скрапинга?

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

Кроме этики, есть и очень практичные причины. 

  • Нарушите правила сайта — получите бан IP или судебный иск. 
  • Зацепите чувствительные данные — попадете под действие GDPR или аналогичных законов.
  • Начнете парсить слишком активно — уроните сервер и лишитесь хорошей репутации.

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

Далее — основные моменты этичного веб-скрапинга, которые вы должны знать. 

Роль robots.txt в этичном сборе данных

Файл robots.txt лежит в корне сайта и сообщает ботам, какие страницы можно сканировать, а какие — нет. Этот файл читают поисковые системы, и его же должны читать все приличные скраперы.

Пример простого файла:

User-agent: *

Disallow: /private/

Это значит: «всем ботам запрещено ходить в /private/». Дальше уже на совести бота — соблюдать это или нет. В техническом плане robots.txt не остановит ваш скрипт, но с точки зрения этики (и иногда закона) — игнорировать его плохо.

Нужно понимать, что robots.txt не говорит: «можно парсить всё, что не запрещено». Он говорит: «вот, что точно нельзя». Этический подход — не выискивать лазейки, а принимать ограничения всерьёз.

Как правильно читать директивы

Основные инструкции в robots.txt:

  • User-agent — к какому боту применима директива (например, * — ко всем);
  • Disallow — какие пути запрещены;
  • Allow — какие разрешены (чаще используется вместе с Disallow);
  • Crawl-delay — просьба не торопиться (не всеми ботами поддерживается, но уважать стоит).

Если видите Disallow: / — это полное табу на обход сайта. Если Disallow: без пути — значит, ограничений нет. Главное: не врать, кто вы. Не притворяйтесь Googlebot’ом. Указывайте честный User-Agent, чтобы сайт понимал, кто к нему пришёл. Это минимальное проявление уважения.

Также важно учитывать, что некоторые сайты настраивают отдельные правила для разных user-agent’ов. Например:

User-agent: Googlebot

Disallow: /nogoogle/

User-agent: *

Disallow: /allbots/

В этом случае ваша программа (если вы используете кастомный User-Agent) должна следовать правилам из блока User-agent: *, а не тем, что прописаны для Google.

Если в robots.txt указан Crawl-delay, даже если ваша библиотека не обрабатывает его автоматически, имеет смысл добровольно ограничить скорость запросов. Это снизит риск блокировки и покажет вашу добросовестность.

Соблюдение пользовательских соглашений

Если robots.txt — это вежливое «не надо», то пользовательское соглашение сайта — это уже юридическое «нельзя». И вы, заходя на сайт, автоматически соглашаетесь с его условиями.

Ограничения на парсинг в соглашениях

Во многих TOS (Terms of Service) можно встретить прямые запреты:

  • «Запрещено автоматизированное извлечение данных»;
  • «Доступ к сайту только через официальные интерфейсы (API)»;
  • «Сбор контента возможен только с разрешения администрации».

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

Более того, в некоторых юрисдикциях нарушение TOS может интерпретироваться как нарушение закона о несанкционированном доступе (например, CFAA в США). 

Реальные последствия игнорирования соглашений

Некоторые компании не церемонятся. Facebook (теперь Meta), например, подали и выиграли несколько дел против скраперов.

В октябре 2020 года Meta подала судебные иски против компаний BrandTotal Ltd. и Unimania Inc., которые через браузерные расширения собирали данные пользователей (имена, ID, пол, дату рождения, статус отношений, местоположение и др.) с Facebook, Instagram и других соцсетей без разрешения и в нарушение условий использования. 

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

Другой знаковый пример — дело hiQ Labs против LinkedIn.

hiQ Labs собирала данные из публичных профилей LinkedIn для анализа трудовых тенденций (retention, skills mapping и др.). LinkedIn попытался остановить скрапинг и выслал уведомления о нарушении пользовательского соглашения.

hiQ подал в суд, заявив, что сбор публичной информации законен и не нарушает CFAA — федеральный закон США о компьютерном мошенничестве (Computer Fraud and Abuse Act).

В 2019 году суд встал на сторону hiQ, указав, что доступ к публичным профилям не является «неавторизованным доступом» по CFAA.

Однако позже суд признал нарушение условий использования LinkedIn, и дело завершилось мировым соглашением с запретом парсить и уничтожением данных.

Кроме судебных последствий, бывают и технические: бан по IP, блокировка аккаунта, внесение в чёрный список. Для исследователя или стартапа это может быть фатально: ни данных, ни доверия, ни будущих партнёров.

Законы о защите персональных данных (GDPR и CCPA)

GDPR (ЕС) и CCPA (США) — два мощных закона, регулирующих сбор и обработку персональных данных. И они касаются даже «открытых» данных.

По GDPR (General Data Protection Regulation) персональными считаются любые данные, по которым можно идентифицировать человека: имя, фото, email, IP-адрес, аккаунт в соцсети и т.д. GDPR требует наличия законного основания для их сбора — «они лежали в открытом доступе» не считается таким основанием.

Публичность данных не отменяет обязанности по соблюдению закона. Если вы собираете такие данные, вы обязаны указать цель, минимизировать объём, хранить безопасно и удалить после использования. Иначе штраф.

CCPA (California Consumer Privacy Act) чуть мягче: он делает исключение для информации, которую пользователь сам сделал публичной (например, открытая запись в Twitter). Но даже в этом случае использование данных должно соответствовать разумным ожиданиям пользователя. Скрапинг приватных профилей или данных из закрытых групп точно за гранью.

Важно: законы действуют не только на компании, находящиеся в ЕС или США. Если вы собираете данные граждан ЕС — GDPR распространяется и на вас. То же самое с США и CCPA.

Персональные данные и их чувствительность

К данным группы PII (Personally Identifiable Information) относятся имена, email, телефонные номера, IP-адреса, геолокация, аккаунты в социальных сетях, фотографии и видео.

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

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

В 2023 году сразу несколько стран — Великобритания, Канада, Австралия и другие — выпустили совместное заявление: массовый сбор данных с публичных страниц в соцсетях без согласия может рассматриваться как нарушение закона. Особенно если используются фото, комментарии и другая контекстная информация.

Тут как раз нужно рассказать про пример из ИИ-мира.

Компания Clearview AI собрала миллиарды лиц из открытых источников для обучения распознавания лиц. В итоге — иски, запреты в ЕС, Австралии и Канаде. Даже если фото лежали «в открытом доступе», массовый сбор и новая цель (идентификация) сделали это незаконным.

NL DPA (Нидерланды) оштрафовал Clearview AI на €30,5 млн за незаконный сбор изображений граждан и нарушение GDPR.

Резидентные прокси

Идеальные прокси-серверы для доступа к ценным данным со всего мира.

Выбрать прокси $1.99, 100Mb

Хорошие и плохие практики веб-скрапинга

Это просто быстрая самопроверка.

Пример «хорошего» парсинга

Так выглядит этичный парсинг: минимальный вред, прозрачность, соответствие правилам и законам.

  • Вы собираете данные с сайтов городских администраций.
  • У всех сайтов есть открытые CSV-файлы и лицензии на использование.
  • Вы проверили robots.txt и TOS — всё разрешено.
  • Запросы идут медленно, с User-Agent’ом вида ResearchBot (email@example.com).
  • Вы не берёте персональные данные, не храните их дольше, чем нужно, и указываете источник.

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

Пример «плохого» парсинга

Это не просто неэтично, это вполне может быть незаконно (особенно в ЕС). И это точно удар по репутации и доверию к вам как к специалисту или проекту.

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

Хуже всего, когда такие проекты маскируются под «инновации» или «исследования», но по сути занимаются массовым сбором личной информации без контроля. Такие действия подрывают доверие к отрасли в целом.

Чек-лист перед началом скрапинга

  1. Проверили ли вы robots.txt сайта? Если да, то уважаете ли ограничения, заданные в нём?
  2. Ознакомились с пользовательским соглашением? И нет ли в нём явных запретов на автоматизированный доступ?
  3. Есть ли у сайта официальный API или открытые данные? Если есть, то лучше использовать их.
  4. Собираете ли вы персональные данные? Если да — у вас есть законное основание? Согласие? Механизмы защиты?
  5. Соблюдаете ли вы принцип минимизации? Вы точно берёте только то, что нужно для вашей цели?
  6. Настроен ли лимит скорости запросов? Есть ли User-Agent, указывающий на вас честно и явно?
  7. Планируете ли вы публикацию, монетизацию, передачу данных? Если да, точно уверены, что не нарушаете ничьих прав?
  8. Готовы ли вы, чтобы кто-то поступил так же с вашими данными? Если ответ «не очень», стоит пересмотреть подход.

Технические нюансы в дополнение к чек-листу:

  • Использование User-Agent с контактной информацией.
  • Установка Crawl-delay вручную, если сайт явно слабый.
  • Автоматическое чтение и парсинг robots.txt перед началом сбора.
  • Ограничение количества одновременных соединений.
  • Настройка логов и отслеживание исключений (например, 403 или 429).
  • Добавление капчи-детектора и реакция на блокировку — не как вызов, а как «всё, стоп».

Заключение

Собирайте данные этично и все будет хорошо.

Уважайте robots.txt. Читайте пользовательские соглашения. Не лезьте за данными, которые явно не для вас. И особенно будьте аккуратны с персональной информацией. Это не только про законы, но и про уважение к людям и сообществу в целом.

Если сомневаетесь — скорее всего, лучше не скрапить. Или спросить разрешения. Лучше потратить лишний час на проверку, чем месяцы на разборки.

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

Что если я собираю данные только для себя?

Допустим, вы — исследователь, студент или просто энтузиаст, который собирает данные «в стол», без публикации, без монетизации. Это снимает часть рисков, но не все:

  • Если вы собираете персональные данные, даже для некоммерческого использования, всё равно действует GDPR или аналогичные нормы. Сам факт хранения чувствительной информации обязывает вас обеспечить её безопасность.
  • Некоторые сайты прямо запрещают автоматический сбор независимо от цели. Нарушение TOS может иметь последствия, даже если вы не публикуете результаты.
  • В случае утечки (например, из-за взлома ноутбука) ответственность может наступить даже за «личную» базу.

Так что «для себя» — это не абсолютная защита. Лучше действовать аккуратно, как если бы вы работали с продакшн-проектом.

Как оформлять результаты скрапинга этично?

Если вы планируете использовать собранные данные в отчётах, дашбордах, научных публикациях или даже просто показывать результаты коллегам — вот несколько рекомендаций:

  • Агрегируйте данные, если можно обойтись без PII.
  • Удаляйте поля, которые не нужны для анализа, но могут идентифицировать человека (имя, email, фото, handle соцсети).
  • Указывайте источник с датой и URL, особенно если данные могли измениться.
  • Не публикуйте дампы персональных данных, даже если они получены легально.
  • Обеспечьте хранение данных в соответствии с нормами безопасности, если в них есть чувствительные поля.

А если я просто анализирую страницы, не сохраняя данные?

Если вы делаете это вручную — вопросов нет. Если используете бота, даже без сохранения, — вы всё равно технически залазите глубже. Поэтому всё то же: robots.txt, TOS и ограничения важны. К тому же, лог-файлы сайта всё равно фиксируют ваш трафик — и если он чрезмерен, вас могут заблокировать.

Нужно ли читать TOS, если сайт государственный?

Да, обязательно. Даже если сайт принадлежит органу власти, на нём может быть размещено пользовательское соглашение или политика в отношении автоматизированного доступа. Некоторые государственные порталы прямо запрещают массовый сбор без согласования. К тому же, такие сайты могут использовать нестандартные правила доступа или предусматривать API, которые нужно использовать вместо парсинга.

Что делать, если в robots.txt всё запрещено, но данные отображаются в поиске?

Если страницы индексируются поисковыми системами, но в robots.txt стоит Disallow: /, это может быть результатом устаревших настроек или разночтений. Но, если в момент вашего сбора запрет явно указан, то лучше его соблюдать. Исключение — только если у вас есть письменное разрешение владельца ресурса или вы используете официальный API, который не подпадает под ограничения robots.txt.

Как быть, если у сайта нет API, а данные нужны срочно?

Это типичная ситуация. Вот что можно сделать:

  • Проверить наличие открытых данных в других форматах (XML, CSV, RSS, Open Data портал);
  • Написать администратору с просьбой о временном доступе или выгрузке;
  • Использовать парсинг с максимальной деликатностью: один запрос в несколько секунд, только по разрешённым URL, без PII;

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