Правовые вопросы и условия при скрапинге: что решить заранее

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

Кратко

• Запишите четыре решения до первого запроса: какой источник и какие условия, какие данные, какая нагрузка и сколько всё хранится.
• Правило robots, ограничение частоты, вход в аккаунт и решение об авторизации - четыре разные вещи. Соблюдение одного ничего не говорит об остальных.
• Технический контроль - это свидетельство о поведении. Он не является лицензией, условием договора или правовым основанием.
• Записывайте версию условий источника и дату прочтения, чтобы последующее изменение было видно, а не вспоминалось.
• Эскалируйте юристу, если источник ограничивает автоматизированный доступ, если данные включают персональную информацию или если ответ зависит от юрисдикции. Не решайте эти вопросы настройкой браузера.

Содержание

• Четыре решения до первого запроса
• Читайте условия на уровне статьи
• Запись решений
• Технический контроль и разрешение
• Точка эскалации
• Практический вывод

Четыре решения до первого запроса

Первое решение - из какого источника идёт сбор и какие условия к нему применяются. Условия обслуживания, соглашение об API, политика для разработчиков и лицензия на открытые данные могут говорить разное и меняться без предупреждения. Запишите прочитанный документ, его версию или дату обновления и важную статью. «Сайт выглядел публичным» - это не запись решения.

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

Третье - нагрузка запросов. Параллелизм, политика повторов, окно обхода и частота на источник входят в запись вместе с опубликованными лимитами источника, если они есть. Ответ 429 - сигнал о нагрузке, и техническая возможность повторить запрос не делает более высокую частоту приемлемой. Статья о лимитах частоты и параллелизме для скраперов описывает механику; эта запись определяет бюджет, который механика должна соблюдать.

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

Решение	Запись	Неверный короткий путь
Источник и условия	Название документа, дата версии, важная статья, проверяющий	Считать, что публичный доступ означает неограниченное использование
Состав данных	Список полей, признак персональных данных, цель, заметка о минимизации	Выгружать всю страницу и решать потом
Нагрузка запросов	Параллелизм, частота, окно, предел повторов, лимит источника	Повторять, пока не заработает
Хранение	Место хранения, список доступа, условие удаления, дата проверки	Хранить всё бессрочно

Читайте условия на уровне статьи

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

Читайте по четырём пунктам. Во-первых, говорит ли документ об автоматизированном доступе и использует ли слова вроде crawl, scrape, робот, автоматические средства или частота? Во-вторых, ограничивает ли он повторное использование контента отдельно от доступа, например запрещая распространение или создание производной базы данных? В-третьих, требует ли он аккаунт, ключ API или письменное соглашение для нужных данных? В-четвёртых, оставляет ли он за собой право менять условия и указывает ли, как уведомляется об изменении? Каждый ответ входит в запись с номером статьи и датой версии.

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

Та же дисциплина применима к API. Соглашение об API может разрешать задокументированные вызовы и запрещать другой сбор, а лимит частоты в документации - это операционное ограничение, а не утверждение о правовом повторном использовании. Записывайте версию API, конечную точку, квоту и статью, разрешающую использование. Если задаче нужно поле, которое API не возвращает, это вопрос состава, а не причина возвращаться к скрапингу страниц без нового решения.

Правила robots тоже требуют точного чтения. RFC 9309 определяет механизм координации для краулеров, которые решают участвовать. Он не создаёт лицензию, договор или правовое основание и не отменяет страницу условий. Строка Disallow может указать объявленному краулеру не заходить в путь; строка Allow может сообщить, что путь не запрещён. Ни один из ответов не решает, разрешён ли сбор, поэтому решение по robots и решение о разрешении занимают отдельные строки.

Запись решений

Полезная запись достаточно коротка для проверки и достаточно конкретна для аудита. Одна строка на решение, один названный владелец, одна дата. Запись должна показывать, что решено, какие свидетельства это подтвердили и что осталось открытым. Открытый пункт - не провал; незаписанное допущение - провал.

project=price-watch
source=https://shop.example.test
terms_version=2026-11-02
terms_clause=sections 4 and 9
fields=sku,list_price,currency,observed_at
personal_data=false
load=2 concurrent, 1 request/second, window 02:00-04:00 UTC
retention=90 days, owner=data-platform, review=2027-02-01
counsel_review=not_required (no personal data, no access restriction)

Запись - утверждение о решении, а не доказательство его правильности. Если источник позже добавляет статью или задача начинает собирать неутверждённое поле, запись устаревает, и задачу следует приостановить до её пересмотра.

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

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

Поле	Тип	Назначение
source	URL	Точный источник и набор путей, которые задача может запрашивать
termsVersion	date	Версия или дата обновления прочитанного документа
termsClause	string	Статья, регулирующая автоматизированный доступ или повторное использование
fields	list	Утверждённый набор полей, а не вся страница
personalData	boolean	Может ли утверждённое поле относиться к человеку
load	object	Параллелизм, частота, окно и предел повторов
retentionDays	integer	Сколько могут храниться собранные данные
owner	string	Ответственная роль, а не общий ящик
reviewDate	date	Когда запись нужно перечитать
counselStatus	enum	not-required, requested, answered или stop

Поле counselStatus команды чаще всего пропускают. Без него задача может незаметно перейти от «мы один раз спросили» к «мы предположили, что всё в порядке». Записывайте заданный вопрос и полученный ответ, включая ответ «стоп». Ответ «стоп» - допустимый результат, и он должен завершать задачу, а не запускать новый технический обход.

Технический контроль и разрешение

Инженеры часто хватаются за технический сигнал, как будто он решает вопрос разрешения. Он не решает. Успешный запрос показывает, что сервер отдал ответ. Пройденная проверка robots показывает, что говорят опубликованные правила для объявленного токена. Вход показывает, что аккаунт аутентифицировался. Ни одно из этого не является лицензией, договорным правом или правовым основанием, и каждое может быть верным, пока сбор остаётся неуместным.

Верно и обратное. Заблокированный запрос не доказывает, что сбор запрещён, а ограничение частоты не устанавливает правовой предел. Технический результат и вопрос разрешения требуют отдельных владельцев и отдельных свидетельств. Запись решений по robots.txt разбирает сторону правил краулера, а границы скрапинга джоб-бордов показывают то же разделение для конкретного источника; она явно держит разрешение и HTTP-доставку отдельными решениями, и это разделение важно здесь так же.

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

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

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

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

Точка эскалации

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

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

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

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

Триггер	Свидетельства	Кто решает
Условия запрещают автоматизированный доступ	Статья, дата версии, предполагаемое использование	Юрист вместе с владельцем продукта
Утверждённые поля могут идентифицировать человека	Список полей, цель, план хранения	Юрист и ответственный за приватность
Задаче нужен вход или контроль доступа	Роль аккаунта, объём прав, статья источника	Юрист и владелец аккаунта
Источник относится к нескольким юрисдикциям	Расположение источника, команды и субъектов данных	Юрист
Источник предлагает API для тех же данных	Условия API, квота, отсутствующие поля	Владелец продукта, затем юрист при конфликте условий

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

Есть второй триггер эскалации, который команды пропускают: изменение в источнике. Новая статья, новый вход, новая версия API или изменение возвращаемых данных могут сделать недействительным решение, верное в прошлом квартале. Внесите дату проверки в запись и считайте запись истёкшей в эту дату, пока кто-то не перечитает источник. Истёкшая запись - не причина продолжать; это причина приостановиться.

Практический вывод

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

Вопросы и ответы

Означает ли публичная страница, что данные можно свободно собирать?

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

Может ли правило Allow в robots.txt служить разрешением?

Нет. Правило robots - инструкция координации краулеров для объявленного токена продукта. Оно не даёт лицензию, право использования данных или правовое основание и ничего не говорит о персональных данных. Держите решение по правилу и решение о разрешении в отдельных полях записи.

Достаточно ли остановиться, когда сайт возвращает 403?

Остановка - правильная операционная реакция, но это не анализ разрешения. 403 показывает, что сервер отказал в запросе; он не устанавливает причину и не говорит, уместен ли другой маршрут. Диагностируйте отказ, затем вернитесь к решению о разрешении, а не пробуйте варианты, пока один не сработает.

Когда команде нужно привлекать юриста?

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

Источники

• RFC 9309: протокол исключения роботов
• Google Search Central: введение в robots.txt
• Ответственное использование BotBrowser
• Юридическая оговорка BotBrowser