Как запретить парсинг сайта

Что такое парсинг и как от него защититься

Парсинг сайта — это процесс автоматического сбора информации, размещенной на веб-ресурсе в открытом доступе. Для этого используется специальная программа (парсер), которая действует по заданным параметрам: собирает, систематизирует и преобразовывает определенные виды данных с указанных веб-сайтов. Как правило, парсингом занимаются бизнес-конкуренты, а также недобросовестные веб-мастера и администраторы сомнительных интернет-проектов. Защищать сайт от парсинга непросто, но делать это нужно — хотя бы самыми примитивными методами. Также полезно знать, как решается проблема с украденным контентом. О парсинге, его целях и защите от копирования текста читайте в нашей статье.

Что такое парсинг сайта

Парсинг (от англ. parsing — разбор, анализ) представляет собой процедуру, направленную на сбор данных со страниц интернет-ресурса при помощи специализированного программного обеспечения. Как это происходит: человек задает боту условия для поиска информации (что и где искать), запускает его, после чего программа начинает отправлять запросы на целевые веб-сайты, имитируя поведение пользователя. Она посещает веб-страницы, копирует код, находит в нем данные, отвечающие заданным параметрам, извлекает их и сохраняет в своей базе. Так, например, можно оперативно собрать контакты организаций, с которыми сотрудничает бизнес — особенно это эффективно, если таких партнеров много. Другими словами, парсинг — это способ ускорить исследование большого количества ресурсов и автоматизировать сбор нужных сведений.

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

Иногда под этим понятием подразумевают также ручной копипаст, т. е. «кражу» информации без использования программных средств, силами человека. Формально это не то же самое, но в целом коррелирует с задачами парсинга и последствиями для SEO, с которыми сталкивается запарсенный сайт.

Зачем парсинг нужен и когда его используют

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

Мы выделим три основных задачи, которые он решает:

Анализ конкурентов. Сюда относятся парсинг цен, ассортимента, отслеживание динамики их изменения, а также изучение программного кода и SEO-данных: метатегов, семантического ядра и др. С помощью парсинга исследуют рынок перед формированием маркетинговой стратегии, нередко — перенимают какие-то функции и подходы к организации веб-проекта.
Анализ собственной площадки. Так называемый «самопарсинг» — распространенный метод обнаружения ошибок, битых ссылок, дублированных или несуществующих страниц, неполных описаний и т. п. Этот вид парсинга помогает улучшить СЕО-показатели своего ресурса.
Заимствование контента. Тот самый копипаст, которого опасается любой сайт. Статьи, описания товаров, авторские изображения и прочее парсится и переносится на другие площадки, из-за чего может нарушиться уникальность оригинального источника.

Какую информацию можно получить, используя парсер

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

Однако парсинг используют не только для кражи. С его помощью можно:

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

Любые сведения, которые находятся в открытом доступе, могут быть скопированы с помощью парсинга. В этом смысле возможности парсера (parser) ограничены не больше, чем возможности обычного пользователя.

Как защитить сайт от кражи текстов

Мы заостряем внимание на этом виде контента, поскольку он лежит в основе поискового продвижения и его парсинг негативно сказывается на первоисточнике самым прямым образом. Если тексты копируют, значит их куда-то вставляют — скорее всего, на другой сайт, который тоже будет проиндексирован. Речь идет не только об оригинальных статьях, но и об описаниях позиций и категорий в каталоге, об отзывах клиентов и комментариях, об информации в разделе «О нас» и другом уникальном текстовом контенте. К сожалению, полностью защититься от парсинга нельзя, ведь любое радикальное антипарсинговое решение так или иначе повлияет и на поисковых роботов, и на реальных посетителей. Тем не менее есть немало рабочих методов, которые если и не помогут уберечь сайт от профессионального парсинга, то хотя бы усложнят бездумный копипаст.

Запрет на выделение текста

Очевидный и довольно легкий в реализации способ — запретить выделять текст на странице. Если нет выделения — нет и автоматического копирования. Для этого достаточно внедрить в код отдельный CSS-стиль, который будет запрещать это действие. Вы можете добавить его на сайт самостоятельно, поскольку разобраться в таком микрокоде очень просто, или поручить соответствующее задание своему веб-мастеру — сложностей эта модификация не вызовет.

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

Запрет на копирование в буфер обмена

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

Эффективность такая же, как у предыдущего способа: от парсинга не защитит (ведь парсер извлекает данные из кода), но усложнит жизнь плагиаторам. Особенно тем, кто не поленится «гуглить» решение этой задачки.

Подключение reCAPTCHA

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

Стоит отметить, что защита от парсинга с помощью теста «на человечность» не лишена минусов. Если парсер более-менее серьезный, то он обратится за решением в соответствующий сервис. Кроме того, капча может раздражать посетителей, если появляется слишком часто или сложна в прохождении.

Блокировка ботов по IP

Действенный метод, но сопряжен с некоторым риском. Чтобы парсеры не собирали данные, можно заблокировать их IP-адреса, тогда сервер не будет реагировать на такие запросы и отдавать информацию. Но сказать легко, а сделать — не очень. Определить айпи, с которого ведется парсинг, — та еще задача. Во-первых, боты используют рандомные заголовки. Во-вторых, весьма убедительно имитируют живого пользователя. В-третьих, они часто меняют прокси-сервера, т. е. обращаются с разных IP-адресов. Обнаружить программу для парсинга легче, если рейды на ваш сайт совершаются регулярно и давно: можно отследить, с каких адресов поступают идентичные запросы (вплоть до места нажатия кнопки — обычно бот-шпион жмет в одну и ту же точку), и ограничить им доступ к содержимому ресурса. Однако все это довольно опасно с точки зрения SEO. Яндекс и Google тоже отправляют на ваш сайт роботов, и спутать их с парсерами нетрудно. В итоге, пытаясь остановить парсинг, вы вставите себе палки в колеса и вылетите из индекса поисковиков. С блокировкой IP нужно быть крайне осторожным, чтобы не «задеть» адреса реальных клиентов.

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

Добавление ссылки при копировании текста

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

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

Использование скрипта автозамены символов

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

Что делать при краже контента

Если защита от парсинга не сработала и ваши данные все же украли, есть несколько путей для решения этой проблемы. Для начала обратитесь к администраторам ресурса, на котором разместили украденный контент. Сообщите им, что вы можете доказать авторство текстов и воспользуетесь законом DMCA, если они не удалят их с площадки. Если сайт не участник «черных списков», это может сработать. В противном случае уведомите о факте кражи службы поддержки поисковых систем. К слову, если у вас спарсили весь проект или ресурс-плагиатор занял более высокую, чем ваша, позицию в выдаче, обращение к поисковикам обязательно. Процесс довольно долгий и малоэффективный, но лучше им не пренебрегать. Еще один вариант — связаться с хостинг-провайдером, обслуживающим вашего копипастера. Если последний нарушает авторское право систематически, а хостер дорожит своей репутацией, все может закончиться блокировкой домена-нарушителя.

В конце концов, вы действительно можете подать жалобу в соответствии с DMCA. Поскольку это американский закон, Google обязан будет отреагировать и почистить выдачу в пользу автора контента. Но дальнейший парсинг это, ясное дело, не остановит. Зачем и почему бы ни понадобилось парсить ваш веб-сайт, при должном уровне старания злоумышленник все равно добьется своего. Но вы можете максимально усложнить ему задачу.

SSL-сертификат: что это простыми словами

SSL-сертификат — это цифровая подпись сайта, благодаря которой между браузером пользователя и сервером, обслуживающим веб-ресурс, устанавливается безопасное соединение. «Secure Sockets Layer» (SSL) переводится как «уровень защищенных сокетов», это протокол безопасности, т. е. набор правил и стандартов, согласно которым осуществляется защита передачи данных. Сертификат SSL удостоверяет подлинность веб-сайта и сообщает клиентам, что информация, которую они ему передают, отправляется в зашифрованном виде. В статье мы объясним принцип работы сертификата безопасности, расскажем, какими они бывают, а также — зачем и как их приобретают.

Что такое CMS и как ее выбрать

CMS (Content Management System) — это программа, предназначенная для создания сайтов и управления их содержимым посредством графического интерфейса, без специальных знаний в области программирования. Системы управления контентом называют движками веб-ресурсов, поскольку с их помощью можно добавлять страницы и функции, настраивать технические параметры, публиковать контент любых форматов — в общем, полноценно работать с веб-сайтом, используя одну платформу для разных задач. CMS выбирают как альтернативу самописным проектам, где важнейшим инструментом являются языки программирования, и готовым конструкторам, обладающим скудным функционалом. В статье расскажем о CMS подробнее.

Защита от DDoS-атак на хостинге: почему это важно

Ежегодный ущерб, который DDoS-атаки наносят мировой экономике, оценивается примерно в миллиард долларов. В зависимости от своих масштабов, компании по всему миру теряют в среднем от 50 до 500$ тыс. в результате подобных нападений. Это один из опаснейших видов киберпреступности, поскольку атака проводится из множества источников одновременно. Она непредсказуема, и до сих пор не существует технической возможности полностью уберечь себя от нее. Однако это вовсе не означает, что не нужно пытаться. В статье мы расскажем о том, кто чаще других становится жертвой распределенных кибератак, какими они бывают, к чему могут привести и как можно выстроить от них защиту. Спойлер: без хостера не обойтись.

Нажмите дважды, чтобы увеличить

Что такое парсинг? Как бороться с парсингом?

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

Что такое — парсинг?
Парсинг — это сбор информации с других сайтов и сторонних ресурсов. Делают это либо специально нанятые люди, либо программы (парсеры).
Парсеры воруют содержимое кода, контент сайта и информацию, которая находится в общем доступе.

Какая цель парсинга?

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

Парсеры могут:

Красть товарные каталоги . Каждый товар в интернет-магазине имеет свое описание. Чтобы не заполнять карточки товара вручную, эту информацию парсят с других источников.
Собирать информацию по ценам . Конкуренты отслеживают изменение стоимости товаров на рынке, чтобы корректировать цены на своем ресурсе.
Заимствовать новые идеи и уникальные предложения конкурентов . При парсинге часто конкуренты присваивают ваши условия, идеи и новые предложения при продаже аналогичных товаров.
Красть базы данных клиентов с личной (конфиденциальной) информацией . С помощью парсинга можно сформировать свою базу клиентов . Для этого парсят контактные данные пользователей: социальные сети, электронные почты, телефоны. Данные должны находиться в открытом ресурсе, архиве или резюме.
Понижать позиции конкурентов в поисковой выдаче . Сайт конкурента, который скопировал у вас информацию, будет проиндексирован поисковыми системами. В результате в поисковой выдаче, ваш сайт может находиться ниже, чем сайт конкурента.

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

Как защититься от парсинга?
Ниже перечислены способы защиты от парсинга:

Способ 1. Для защиты сайта можно попробовать вычислить IP–адрес, с которого ваш сайт пытаются парсить и заблокировать его. Это занимает время и используется в редких случаях. Также есть риск заблокировать «хорошего» бота, который является индексатором поисковых систем. Такой способ не защитит ваш сайт от новых парсеров и каждый раз необходимо будет вручную блокировать подозрительные IP-адреса.

Способ 2. Внедрить сценарии JavaScript на страницах вашего сайта. JS-код может затормозить работу парсера, т. к. многие парсеры не обучены его игнорировать. К тому же скрипт может останавливать работу полезных роботов.

Способ 3. Самый действенный вариант — установить специальный скрипт, например, Antibot Pro . В защите сайта он переводит подозрительные IP–адреса на страницу проверки, а реальных пользователей пропускает на сайт. Antibot запоминает IP–адреса реальных пользователей и не беспокоит их при повторном посещении сайта.

Antibot Pro проверяет ваш IP-адрес:

Проверка IP-адреса Antibot Pro

Так выглядит проверка подозрительного IP-адреса:

Проверка подозрительного IP-адреса Antibot Pro

Когда на ваш сайт заходит робот-парсер, Antibot Pro блокирует для него вход:

Antibot Pro перед роботом-парсером

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

Избежать атаки можно защитив сайт специальными программами, например Antibot Pro .

Запись опубликована 07.12.2021 автором ArtisMedia в рубрике Безопасность, Полезные сервисы.

Архивы

Январь 2024 (5)
Декабрь 2023 (15)
Ноябрь 2023 (2)
Октябрь 2023 (8)
Сентябрь 2023 (2)
Август 2023 (2)
Июль 2023 (1)
Июнь 2023 (2)
Май 2023 (1)
Апрель 2023 (2)
Март 2023 (3)
Январь 2023 (2)
Декабрь 2022 (1)
Ноябрь 2022 (2)
Октябрь 2022 (2)
Сентябрь 2022 (2)
Август 2022 (2)
Июнь 2022 (1)
Май 2022 (1)
Апрель 2022 (1)
Март 2022 (7)
Январь 2022 (10)
Декабрь 2021 (3)
Ноябрь 2021 (5)
Октябрь 2021 (2)
Сентябрь 2021 (2)
Июль 2021 (1)
Июнь 2021 (1)
Май 2021 (3)
Февраль 2021 (3)
Январь 2021 (1)
Декабрь 2020 (1)
Ноябрь 2020 (3)
Октябрь 2020 (1)
Сентябрь 2020 (5)
Август 2020 (1)
Июль 2020 (3)
Июнь 2020 (1)
Май 2020 (3)
Апрель 2020 (1)
Март 2020 (2)
Февраль 2020 (1)
Декабрь 2019 (1)
Ноябрь 2019 (1)
Октябрь 2019 (3)
Сентябрь 2019 (3)
Июль 2019 (1)
Май 2019 (3)
Апрель 2019 (8)
Март 2019 (8)
Февраль 2019 (7)
Январь 2019 (9)
Декабрь 2018 (7)
Ноябрь 2018 (8)
Октябрь 2018 (8)
Сентябрь 2018 (8)
Август 2018 (7)
Июль 2018 (4)
Июнь 2018 (8)
Май 2018 (8)
Апрель 2018 (6)
Март 2018 (3)
Февраль 2018 (1)
Ноябрь 2017 (1)
Октябрь 2017 (2)
Август 2017 (4)
Июль 2017 (6)
Июнь 2017 (5)
Май 2017 (1)
Апрель 2017 (6)
Март 2017 (10)
Февраль 2017 (12)
Январь 2017 (8)
Декабрь 2016 (10)
Ноябрь 2016 (12)
Октябрь 2016 (11)
Сентябрь 2016 (11)
Август 2016 (13)
Июль 2016 (11)
Июнь 2016 (13)
Май 2016 (6)
Апрель 2016 (7)
Март 2016 (5)
Февраль 2016 (5)
Январь 2016 (5)
Декабрь 2015 (2)
Ноябрь 2015 (8)
Октябрь 2015 (1)
Сентябрь 2015 (4)
Август 2015 (7)
Июль 2015 (5)
Июнь 2015 (4)
Май 2015 (14)
Апрель 2015 (1)
Март 2015 (4)
Февраль 2015 (6)
Январь 2015 (1)
Декабрь 2014 (1)
Ноябрь 2014 (5)
Октябрь 2014 (9)
Сентябрь 2014 (9)
Февраль 2014 (1)
Ноябрь 2013 (2)
Сентябрь 2013 (4)
Август 2013 (7)
Июль 2013 (4)
Май 2013 (7)

Как организовать защиту от парсинга сайта?

Мне как то стал инересен этот вопрос. Обобщив информацию которую собрал и немного личного опыта дают понять что кому действительно нужно той стянет, но все же усложнить возможно. Я работаю веб-разработчиком PHP+JS в одной конторе, приходилось делать несколько парсеров под заказ.
Интересуют следующие вопросы:
Первый: Существует ли ПЗ которое позволяет тащить контент который сгенерирован динамически, так что обязательно нужно выполнение JS? И тут речь не просто про ajax, а про то что ссылка на требуемый контент генерируется сменной JS функцией.
Второй: Ключевые методики предотвращения автоматического копирования, которые показались мне полезными следующие:
1. Тот самый динамический контент о котором выше.
2. Динамическая смена верстки (что то слишал про бан от поисковиков за это).
3. Блокирование по ip если не поисковый бот.
Тут хотелось бы услышать ваши методики, идеи и возможные проблемы связанные с ними.
Забыл добавить вот 4-ий пункт: Выдавать поисковикам один контент, а клиентам другой.

Вопрос задан более трёх лет назад
28668 просмотров

1 комментарий

Оценить 1 комментарий

Хоть и старый вопрос но все же. Да смысла мало думать над защитой от парсинга. Можно к примеру парсить контент средствами jquery, выборка по частям, а потом собирать все на хостинге. Я так парсил и по 10к файлов.

Решения вопроса 0
Ответы на вопрос 12
starosta6123 @starosta6123

1. Сайт изначально предназначен для публикации, то есть он открыт.
2. Если вы не хотите чтобы информация была открыта, не публикуйте.

Из 1 пункта следует, что нет достаточных средств для защиты от парсеров.
Вопрос только в том, на сколько вы готовы и можете усложнить жизнь для парсеров.
А нужно ли это? Может вы — «неуловимый Джо»?
Все что может прочитать и распознать человек (а ведь именно для людей и делается сайт?) может быть воспроизведено. В части, где парсинг может быть автоматизирован, он будет автоматизирован.
Сейчас существуют мощные парсеры Яндекса и Гугла. Если они ваш сайт не смогут разобрать, то и в индексе его не будет, значит полезная информация не дойдет до конечного пользователя.
А тот, кто захочет, ее скопирует, если информация очень нужна. Если даже вы представите в виде мозаики из картинок и кусков, даже если зашифруете, но информация на экране должна все равно быть читабельной, а значит простой принтскрин и распознавание в FineReader будет быстрее, чем вы напишите защиту от него.

Бросьте это занятие!

Не существует защиты созданной человеком, которую не возможно сломать, вопрос времени.
Единственный путь, это шифрование с выдачей ключа клиенту. Но клиент — человек не надежен, и информация уплывет, вопрос цены!

И еще раз бросьте это!

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

Последний совет: бросьте это!

Единственное что может вам помочь, это не раскрывать полностью всю информацию о предмете, или разделить на несколько частей, но при этом не должно быть неудобства для посетителя. К примеру, скройте «количество зубцов в шестеренке», любую ключевую информацию, без которой «самолет не взлетит».

А если хотите поиграться, то пришла в голову идея: перемешивание по определенному алгоритму текста, который потом восстанавливается, применение стилей для скрытия «фальшивых» слов или фраз. Например, задать стиль, который скрывает каждое второе предложение или слово. Но к сожалению, это ломается на ура! Но доставит радости для взломщиков 🙂

Извините, за столь большой сумбур!

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

2. Верстка. Не знаю про бан от поисковиков, но это тоже ломается. Просто убираете теги и все. Просто в парсер добавляется «умный» фильтр. Можно конечно где-то картинку заменить фоном, или часть текста картинкой, но и на это можно сделать разборщик.

3. Блокировка по IP не прокатит, так как могут пострадать реальные люди, достаточно применять динамический IP.

А вообще, если хотите спастись от простых парсеров, то комплекс мер может помочь. Так же могу натолкнуть на идею, того, что парсеры обычно очень активны, и по количеству запросов с одного IP, по USER_AGENT, и другим меткам, а так же по отсутствию javascript, по обработке тега redirekt.info/article/redirekt-na-html-s-zaderzhko. (отложенный редирект) и другим признакам. Можно запихнуть скрытую картинку (style=»display: none»), большинство парсеров ее могут дернуть (зависит от настроек).

В общем, можно поставить задачу в другом ключе: «Расстановка ловушек для парсеров». То есть ловить на том, чего обычные люди и браузеры делать не будут. Например, заполнять «скрытое поле пароль». Удачные ловушки дадут вам возможность выявить подставных, но лучше делать несколько проверок, а то можно и реального пользователя забанить. А я бы не стал банить, а сливал бы немного или частично измененную инфу. Эта инфа может стать маркером для выявления того, кто действительно желает с вас «слить».

Как защитить свой сайт от парсинга данных. Практические советы

Меня зовут Максим Кульгин и моя компания xmldatafeed занимается парсингом сайтов в России порядка четырех лет. Ежедневно мы парсим более 500 крупнейших интернет-магазинов в России и на выходе мы отдаем данные в формате Excel/CSV и делаем готовую аналитику для маркетплейсов.

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

Отдельно хочу подчеркнуть, что 100% защиты от парсинга открытых данных в природе, наверное, не существует. Но используя комбинацию подходов вы можете очень сильно усложнить процесс сбора данных. Если данных много и они часто меняются (попробуйте парсить, например, АлиЭкспресс), то парсинг может стать просто нецелесообразным (или очень затратным мероприятием). Перечисленные ниже методы бесплатные в реализации (разве что оплата труда программиста вашего сайта), но на рынке есть и платные варианты. Например, вы можете потратить 10 минут и включить CloudFlare (тариф 20$, защита от ботов включена). В этом случае особо назойливые парсеры будут получать капчу (кстати, CloudFlare использует hCaptcha, которая, как считаю наши разработчики, более сложная чем reCaptcha). В конечном счете, совокупность механизмов защиты поможет защитить сайт от паразитной нагрузки, которые зачастую создают сотни парсеров, написанных малограмотными студентами-программистами, не думающих о последствиях.

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

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

Парсинг также известен как: веб-парсинг (webscraping), считывание данных с экрана (screenscraping), добыча веб-данных (web data mining), сбор веб-данных (web harvesting) или извлечение веб-данных (web data extraction). Чтобы препятствовать парсингу, полезно знать, как работают парсеры и что мешает им работать эффективно — об этом и пойдет речь в данной статье.

Как правило, эти программы для парсинга данных разработаны для извлечения определенной информации из вашего сайта, как например: статей, результатов поиска, подробных данных о товарах или информации об альбомах и артистах. Обычно люди парсят сайты ради получения определенных данных, чтобы повторно использовать их на своем собственном сайте (и таким образом делать деньги на вашем контенте!), разработать альтернативную клиентскую часть (так называемый «фронтенд») или даже просто для частного исследования или в целях анализа данных.

По сути дела, существуют разнообразные типы парсеров, и каждый работает по-разному:

Программы-обходчики, или «пауки», как например поисковый робот Google, или программы вроде HTtrack для копирования сайтов, которые посещают ваш сайт и рекурсивно переходят по ссылкам на другие страницы, чтобы собирать на них данные. Программы-обходчики иногда используются для целенаправленного парсинга определенных данных зачастую в сочетании со средством анализа HTML-кода для извлечения требующихся данных из каждой веб-страницы.
Скрипты командной оболочки: иногда популярные инструменты для Unix используются для парсинга: Wget или Curl — для скачивания веб-страниц, а Grep (Regex) — для извлечения нужных данных. Обычно для этих целей пишется скрипт командной оболочки. Они представляют собой простейший тип парсеров. Но при этом и самый ненадежный тип, поэтому никогда не пытайтесь анализировать HTML-код с помощью регулярных выражений для извлечения необходимых данных! Таким образом, скрипты относятся к такому типу парсеров, с которыми легче всего бороться, ломать и даже обманывать их.
Многочисленные HTML-парсеры и HTML-анализаторы, как например основанные на Jsoup, Scrapy и других программных средствах. Подобно парсерам на основе регулярных выражений и скриптов командной оболочки, такие парсеры работают посредством извлечения данных из ваших веб-страниц, ориентируясь на шаблоны в HTML-коде и игнорируя всё остальное.

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

Экранные парсеры, как например основанные на Selenium или PhantomJS, которые фактически открывают ваш сайт в настоящем браузере, запускают JavaScript, отправляют AJAX-запросы и выполняют прочие действия, а затем получают из веб-страницы необходимый текст, обычно используя для этого следующие операции: Получение HTML-кода из браузера после завершения загрузки вашей веб-страницы и выполнения JavaScript-кода с последующим применением анализатора HTML-кода для извлечения необходимых данных или текста. Это наиболее распространенные операции, и поэтому многие методы вывода HTML-анализаторов из строя в этом случае тоже применимы. Формирование снимка экрана, на котором отображаются полностью загруженные в браузере («отрендеренные») веб-страницы, и последующие использование OCR для извлечения необходимого текста из снимка. Такой подход используется очень редко и только специализированные парсеры с подобным функционалом могут вам это устроить.

С экранными парсерами на основе браузера справиться трудно, поскольку они выполняют скрипты, формируют HTML-код и могут вести себя как живые люди, просматривающие ваш сайт.

Веб-сервисы для парсинга данных из сайтов, как например ScrapingHub или Kimono. Фактически есть люди, работа которых — разобраться в том, как собрать данные на вашем сайте и вытащить контент для дальнейшего использования другими людьми. Эти веб-сервисы иногда применяют крупные сети прокси-серверов и постоянно меняют IP-адреса, чтобы обходить ограничения и запреты доступа, поэтому защищаться от них особенно проблематично.

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

Встраивание вашего сайта в веб-страницы другого сайта с помощью фреймов и встраивание вашего сайта в мобильные приложения.

Хотя технически это не парсинг, но всё равно проблема, так как мобильные приложения (для Android и iOS) могут встраивать ваш сайт и даже внедрять свой код на языках CSS и JavaScript, таким образом полностью меняя внешний вид вашего сайта и показывая только нужную им информацию, как например сам контент статьи или список результатов поиска, и скрывая такие элементы, как например заголовки, подвалы или рекламные объявления.

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

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

Как защищаться от парсинга?

Вот несколько общих подходов для обнаружения парсеров и противодействия им:

Отслеживайте свои журнальные записи (логи) и шаблоны трафика; ограничивайте доступ, если видите необычную активность

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

А именно следующие идеи:

Ограничение скорости получения данных:

Разрешайте пользователям (и парсерам) выполнять ограниченное количество действий за определенное время. Например, разрешайте какому-либо конкретному пользователю или посетителю с каким-либо конкретным IP-адресом искать что-либо только несколько раз в секунду. Это замедлит парсеры и сделает их неэффективными. Также вы могли бы отображать капчу, если действия осуществляются слишком быстро или быстрее, чем мог бы их совершать настоящий пользователь. Да, есть сервисы для решения капчи, но это стоит денег и замедляет сбор данных.

Обнаруживайте необычную активность:

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

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

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

Насколько быстро пользователи заполняют формы и в какое место на кнопке они кликают.
Вы можете собирать много информации с помощью JavaScript, как например: размер или разрешение экрана, часовой пояс, установленные шрифты. Всё это вы можете использовать для обнаружения пользователей.
HTTP-заголовки и их порядок, особенно заголовок User-Agent.

Например, если вы получаете много запросов из одного IP-адреса, во всех из которых используется один и тот же User-Agent и размер экрана (определяется с помощью JavaScript), а пользователь (в этом случае — парсер) всегда кликает по кнопке в одном и том же месте и через равные промежутки времени, то, скорее всего, это экранный парсер, и вы можете временно заблокировать подобные запросы, то есть заблокировать все запросы с таким пользовательским агентом и размером экрана, которые отправляются из этого конкретного IP-адреса. Так вы не доставите неудобств настоящим пользователям, у которых тот же IP-адрес, потому что, например, эти люди пользуются общим интернет-соединением.

Кроме того, можно пойти еще дальше, поскольку вы можете обнаружить схожие запросы, даже если они исходят из разных IP-адресов, а значит имеет место распределенный парсинг данных (парсер, использующий бот-сеть или сеть прокси-серверов). Если вы получаете много запросов, приходящих из разных IP-адресов, но идентичных по всем остальным признакам, то можете заблокировать их. Опять же, будьте осторожны и случайно не заблокируйте настоящих пользователей сайта.

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

Вопросы на Security Stack Exchange, связанные с этой темой:

Как однозначно обнаружить пользователей с одним и тем же внешним («белым») IP-адресом? — если хотите узнать больше.
Почему люди используют блокировки IP-адресов («баны»), если IP-адреса часто меняются? — если хотите узнать о ограничениях этих методов.

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

Требуйте от пользователей проходить регистрацию и авторизацию, то есть вход на сайт

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

Если вы требуете от посетителей сайта создавать учетные записи и проходить процедуру входа на сайт, то сможете отслеживать действия пользователей и парсеров. Таким образом, вы сможете легко замечать, когда определенная учетная запись используется для парсинга данных, и блокировать («банить») ее. Такие приемы, как ограничение скорости или обнаружение чрезмерного обращения к сайту (наподобие использования функции поиска огромное количество раз за короткое время) становится проще использовать, поскольку вы можете обнаруживать конкретные парсеры, а не просто IP-адреса.

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

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

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

Запрещайте доступ к сайту, если запросы идут из облачного хостинга и IP-адресов парсинговых веб-сервисов

Иногда парсеры будут размещаться и функционировать на веб-хостингах, например на Amazon Web Services, Google app Engine или виртуальных выделенных серверах (VPS). Ограничивайте доступ к вашему сайту или показывайте капчу для запросов, которые исходят из IP-адресов, используемых такими веб-сервисами облачного хостинга. Также вы можете запрещать доступ к сайту IP-адресам, используемым веб-сервисами парсинга данных.

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

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

Сделайте свое сообщение об ошибке неявным, если действительно запрещаете доступ к сайту

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

Из вашего IP-адреса поступает слишком много запросов, пожалуйста, повторите попытку позже.
Ошибка, заголовок User-Agent отсутствует!

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

Извините, что-то пошло не так. Вы можете связаться со службой поддержки через [email protected] в случае, если проблема никуда не уйдет.

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

Используйте капчи, если подозреваете, что к вашему сайту обращается парсер

Капчи («Completely Automated Test to Tell Computers and Humans apart» — «Полностью автоматизированный публичный тест Тьюринга для различения компьютеров и людей») очень эффективны против парсеров. К несчастью, они при этом очень эффективно раздражают пользователей.

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

Моменты, о которых нужно помнить при использовании капч:

Не изобретайте «велосипед», а используйте что-нибудь вроде reCaptcha от Google: это будет гораздо проще, чем реализовывать капчу самостоятельно, и гораздо удобнее для пользователей, чем решение на основе размытого и искаженного текста, которое вы могли бы создать сами. Кроме того, разработчику скриптов гораздо сложнее решить готовую стороннюю капчу, чем простое изображение, формируемое и отправляемое вашим сайтом.
Не включайте решение капчи (ответ на нее) в HTML-разметку. Например, во «Всемирной паутине» есть сайт, на котором решение капчи находится на самой веб-странице. Хотя оно довольно хорошо спрятано, такой подход делает капчу в значительной степени бесполезной. Не делайте что-нибудь вроде этого. Опять же, используйте веб-сервис наподобие reCaptcha, и вы не столкнетесь с такого рода проблемой, если конечно будете пользоваться им правильно.
Решение капч может быть поставлено на поток: существуют веб-сервисы для решения капч, где реальные люди решают капчи в больших количествах и за небольшую плату. С другой стороны, в этом случае использование reCaptcha — хорошая идея, поскольку у них есть средства защиты, как например относительно короткий промежуток времени, который есть у пользователя на решение капчи. Маловероятно, что подобного рода веб-сервис кто-то будет использовать применительно к вашему сайту, если только ваши данные не представляют большую ценность.

Отправляйте свой текстовый контент в виде изображения

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

Однако такой подход плох с точки зрения программ для чтения с экрана, поисковых систем, производительности и, скорее всего, всего остального. Кроме того, поступать так не всегда законно из-за проблем с доступностью контента, например в связи с Законом об американцах с ограниченными возможностями (Americans with Disabilities Act), хотя для России подобного закона нет. Также парсеры могут легко обойти такую защиту с помощью оптического распознавания символов, поэтому не используйте такой подход.

Вы можете осуществить что-то подобное с помощью CSS-спрайтов, но в этом случае имеют место быть те же проблемы.

Не давайте доступ ко всем своим данным

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

Это будет неэффективным, если:

Бот или скрипт в любом случае не хочет получить весь набор ваших данных, или же такой набор ему не нужен.
Ваши статьи передаются пользователям по URL-адресу, который выглядит наподобие example.com/article.ph? articleId=12345. Такая подача статей (и схожих данных) позволит парсерам просто перебрать все articleId-ы, то есть идентификаторы статей, и таким образом запросить у сайта все статьи.
Есть другие способы в конечном итоге найти все статьи, как например создание скрипта, который бы посещал ссылки в статье, которые ведут на другие статьи.
Поиск чего-нибудь наподобие «и» или «это» позволяет найти почти всё что угодно, поэтому учтите этот момент. Однако вы можете защититься от такого приема, возвращая только 10 или 20 результатов.
Вам нужно, чтобы поисковые системы находили ваш контент.

Не разглашайте сведения о ваших API, конечных точках обработки запросов и подобных вещах

Убедитесь, что вы не выставляете напоказ любые свои API, даже если делаете это непреднамеренно. Например, если вы используете AJAX или сетевые запросы из Adobe Flash или Java-приложения для загрузки своих данных, что крайне не рекомендуется, то постороннему не составит никакого труда посмотреть на сетевые запросы из веб-страницы и разобраться в том, куда эти запросы идут, а затем выполнить обратный инжиниринг и использовать эти конечные точки обработки запросов в парсере. Убедитесь, что ваши конечные точки обработки запросов трудны для понимания (обфусцированы), и усложните их использование посторонними, как это описано выше.

Что можно сделать для борьбы с HTML-анализаторами и парсерами

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

Часто редактируйте свой HTML-код

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

Если вы будете часто менять HTML-код и структуру своих веб-страниц, то такие парсеры не смогут продолжить свою работу.

Вы можете часто, может быть даже автоматически, менять идентификаторы и классы элементов в своей HTML-разметке. Таким образом, если ваш div.article-content станет чем-то вроде div.b1c32dea53faf8 и будет меняться каждую неделю, парсер сначала будет работать прекрасно, но через неделю сломается. Позаботьтесь о том, чтобы длина ваших идентификаторов или классов тоже менялась, ведь в противном случае парсер в качестве альтернативного подхода будет использовать шаблон div.[14-любых-символов] для поиска нужного div. Также опасайтесь других подобных уязвимостей в защите от парсинга…
Если нет никакого способа найти необходимый контент в HTML-разметке, парсер сделает это, отталкиваясь от ее структуры. Таким образом, если все ваши веб-страницы со статьями структурно схожи в том отношении, что каждый div внутри другого div, идущего после тега h1, представляет собой контент статьи, то парсеры на основе этой структурной закономерности смогут заполучить контент статьи. С другой стороны, для борьбы с этим вы можете периодически или время от времени добавлять или удалять дополнительную разметку в своем HTML-коде. Например, добавлять дополнительные теги div или span. С современной обработкой HTML на стороне сервера эта задача не должна быть слишком сложной.

Нужно иметь в виду следующее:

Такую защиту от парсинга будет утомительно и сложно реализовать, поддерживать и отлаживать.
Вы будете препятствовать кэшированию. А именно, если вы меняете идентификаторы или классы своих HTML-элементов, то это потребует внесения соответствующих изменений в ваши файлы со стилями и в файлы с JavaScript-кодом, а значит, что каждый раз, когда вы редактируете их, браузеру придется скачать их повторно. Это приведет к более долгой загрузке веб-страниц у постоянных посетителей сайта и к возросшей нагрузке на сервер. Если вы меняете разметку только раз в неделю, то такая операция не приведет к появлению серьезной проблемы.
Более продвинутые парсеры всё равно смогут заполучить ваш настоящий контент, делая выводы о том, где он находится. Например, зная, что крупный и единственный блок текста на странице, скорее всего, и есть настоящая статья. Такой прием делает всё же возможным обнаружение и извлечение необходимых данных из вашей веб-страницы. Boilerpipe занимается именно такими вещами.

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

Кроме того, обратите внимание на вопрос Как помешать зависимым от XPath сборщикам данных собирать контент веб-страниц, чтобы подробно узнать о том, как это можно реализовать на PHP.

Редактируйте свою HTML-разметку на основе местоположения пользователя

Этот совет похож на предыдущий. Если вы отправляете посетителям сайта разную HTML-разметку в зависимости от местоположения или страны (это определяется по IP-адресу), то такой подход может сломать парсеры, которые доставляют собранный контент каким-либо пользователям. Например, если кто-то разрабатывает мобильное приложение, которое собирает данные на вашем сайте, то поначалу оно будет работать отлично, но сломается на этапе его распространения пользователям, так как эти пользователи могут находиться в другой стране и поэтому получат другую HTML-разметку, на работу с которой встроенный парсер не рассчитан.

Часто редактируйте свою HTML-разметку и таким образом активно обманывайте парсеры!

Пример: на вашем сайте есть функция поиска, расположенная по URL-адресу example.com/searc? query=somesearchquery и возвращающая следующий HTML-код:

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

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

Обманывайте парсер: вставляйте поддельные скрытые данные в свою веб-страницу в качестве приманки

В дополнение к предыдущему примеру вы можете добавить невидимые элементы-приманки в свою HTML-разметку, чтобы «ловить» парсеры. Пример разметки, которую можно было бы добавить к описанной ранее веб-странице с результатами поиска:

Парсер, разработанный для получения всех результатов поиска, соберет и этот результат, как и любой из других, настоящих результатов на веб-странице, а затем перейдет по ссылке в поисках необходимого ему контента. Реальный человек никогда не увидит этот располагающийся в начале результат-ловушку благодаря тому, что он скрыт с помощью CSS, и не перейдет по ссылке. Настоящая программа-обходчик, работа которого вами приветствуется, как например поисковый робот Google, тоже не будет переходить по такой ссылке, потому что вы можете запретить доступ к /scrapertrap/ в своем файле robots.txt. Но только не забудьте сделать это!

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

Не забывайте запретить доступ к своей приманке (/scrapertrap/) в своем файле robots.txt, чтобы поисковые роботы не попадали в нее.
Вы можете или даже должны сочетать этот совет с предыдущим, связанным с частым редактированием HTML-кода.
В данном случае частое изменение тоже актуально, так как парсеры в конечном счете научатся обходить такую защиту. Меняйте URL-адрес и текст ловушки. Кроме того, стоит подумать об изменении встроенного CSS, применяемого для сокрытия ловушки, и вместо этого использовать атрибут id и внешний файл со стилями, поскольку парсеры научатся избегать любого элемента с атрибутом style, в котором прописан CSS для сокрытия контента. Также попробуйте включать эту ловушку время от времени, чтобы парсер поначалу работал, но через некоторое время ломался. К тому же это применимо и к предыдущему совету.
Остерегайтесь того, что злоумышленники могут публиковать на форуме или где угодно что-нибудь вроде [img]http://yoursite.com/scrapertrap/scrapertrap.php[img] и таким образом атаковать добропорядочных пользователей, когда они посещают такой форум и их браузер переходит по URL-адресу вашей ловушки, из-за чего ваш сайт будет отказывать пользователям в обслуживании и испытывать повышенную нагрузку. Поэтому предыдущий совет об изменении URL-адреса важен вдвойне. Также вы можете проверить заголовок Referer.

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

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

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

Не принимайте запросы, если User-Agent пустой или отсутствует

Зачастую недостаточно качественно разработанные парсеры не будут отправлять заголовок User-Agent в своих запросах, в то время как все браузеры и поисковые роботы делают это.

Если вы получаете запрос, в котором отсутствует заголовок User-Agent, то можете отображать капчу, просто запрещать или ограничивать доступ, отправлять фальшивые данные, как описано выше, или поступать как-то иначе.

Данный заголовок не составит труда подделать, но в качестве меры защиты от некачественно написанных парсеров эту проверку стоит реализовать.

Не принимайте запросы, если их User-Agent используется одним из популярных парсеров; заносите такие характерные для парсеров заголовки в черный список

В некоторых случаях парсеры будут использовать User-Agent, который не использует ни один реальный браузер или поисковый робот, как например:

«Mozilla”. Именно так — больше никаких других символов. Реальный браузер никогда не будет использовать просто “Mozilla» в пользовательском агенте.
«Java 1.7.43_u43». По умолчанию HttpUrlConnection, доступный в языке программирования Java, использует что-то наподобие такого User-Agent.
«BIZCO EasyScraping Studio 2.0»
«wget”, «curl», “libcurl» и прочие. Wget и cURL иногда используются для примитивного парсинга данных.

Если вы обнаружите, что определенная строка пользовательского агента используется на вашем сайте парсерами, и ее не используют настоящие браузеры или «добропорядочные» программы-обходчики, то вы можете тоже добавить такой User-Agent в свой черный список.

Проверьте заголовок Referer

В дополнение к предыдущему параграфу вы можете также проверить заголовок Referer (да, именно Referer, а не Referrer), так как некачественные парсеры могут не отправлять его или всегда отправлять один и тот же — иногда это может быть «google.com». К примеру, если пользователь приходит на веб-страницу статьи со страницы результатов поиска по сайту, проверьте, что заголовок Referer присутствует и указывает на эту страницу с результатами поиска.

Обратите внимание, что:

Реальные браузеры тоже не всегда его отправляют.
Его несложно подделать.

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

Если пользователь сайта не запрашивает ресурсы (CSS, изображения), то, возможно, его нельзя считать реальным браузером

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

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

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

Используйте и запрашивайте файлы cookie, а также применяйте их для отслеживания действий пользователей и парсеров

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

Например, когда пользователь выполняет поиск, вы можете установить куки, идентифицирующий пользователя. Когда пользователь просмотрит страницы с результатами поиска, вы сможете проверить этот куки. Если пользователь открывает все результаты поиска (вы сможете определить это благодаря куки), то, скорее всего, это парсер.

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

Обратите внимание, что если вы используете JavaScript для установки и извлечения куки, то таким образом вы заблокируете парсеры, которые не исполняют JavaScript-код, поскольку они не могут извлекать и отправлять куки в своих запросах.

Используйте JavaScript и AJAX для загрузки своего контента

Вы можете использовать JavaScript в сочетании с AJAX для загрузки своего контента после загрузки самой веб-страницы. Такой прием сделает контент недоступным для HTML-анализаторов, которые не исполняют JavaScript-код. Зачастую это эффективный способ борьбы с начинающими и неопытными разработчиками парсеров.

Имейте в виду, что:

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

Сделайте запутанными и непонятными свою HTML-разметку, сетевые запросы, отправляемые с помощью скриптов, и всё остальное

Если вы используете AJAX и JavaScript для загрузки своих данных, то сделайте передаваемыми данные непонятными для постороннего, то есть обфусцируйте их. Например, вы можете закодировать свои данные на сервере при помощи чего-нибудь простого наподобие base64 или более сложного с несколькими слоями обфускации, побитовым сдвигом и, возможно, даже шифрованием, а затем декодировать и отобразить эти данные клиенту после их извлечения из сервера с помощью AJAX. Благодаря такому подходу кто-либо, изучающий сетевой трафик, не сразу разберется в том, как работает ваша веб-страница и как загружаются данные. Кроме того, посторонним будет труднее напрямую запрашивать данные из ваших конечных точек обработки запросов, потому что им придется заниматься обратным инжинирингом вашего алгоритма дешифрования.

Если вы используете AJAX для загрузки данных, то рекомендуется усложнить использование конечных точек обработки запросов без предварительной загрузки веб-страницы. Сделать это можно, например, при помощи запрашивания сеансового ключа в качестве параметра, который вы можете встроить в свой JavaScript-код или HTML-разметку.
Кроме того, во избежание отправки дополнительных сетевых запросов вы можете встраивать свои запутанные (обфусцированные) данные прямо в исходную HTML-страницу и использовать JavaScript для приведения данных в нормальное состояние и их отображения пользователю. Используя такой прием, вы существенно усложните извлечение данных, осуществляемое при помощи парсера, который работает только с HTML-кодом и не выполняет JavaScript-код, так как разработчику парсера придется выполнять обратный инжиниринг вашего JavaScript-кода, а его вам тоже рекомендуется сделать запутанным и непонятным.
Возможно, вам захочется регулярно менять свои методы обфускации, чтобы ломать парсеры, которые уже разгадали ваши нынешние методы.

Однако у подобных приемов есть несколько недостатков:

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

Советы нетехнического характера
Возможно, что ваш поставщик хостинга предоставляет защиту от роботов и парсеров

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

Попросите людей не собирать данные, и некоторые отнесутся к этому с уважением

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

Найдите адвоката

Адвокаты знают, как бороться с нарушением авторских прав, и могут отправить соответствующее письменное предупреждение. DMCA тоже полезен в решении этого вопроса. Учтите, что в России вопросы с правомерностью парсинга очень сложные и скорее всего адвокат будет работать с точки зрения нарушения авторского права.

Сделайте свои данные доступными — предоставьте API

Такая идея может показаться неразумной, но вы можете сделать свои данные легкодоступными и требовать, чтобы при использовании ваших данных был указан их источник и ссылка на ваш сайт. Может быть, даже брать за это деньг… Более того, Stack Exchange предоставляет API, но требует указывать источник данных.

Прочие советы

Найдите баланс между удобством использования сайта реальными пользователями и защитой от парсеров: всё, что вы делаете, так или иначе негативно повлияет на пользовательский опыт, поэтому вам нужно будет находить компромиссы.
Не забывайте про свой сайт и приложение для мобильных устройств: если у вас есть мобильная версия вашего сайта, остерегайтесь того, что парсеры могут собирать на ней данные. Если у вас есть мобильное приложение, оно тоже может стать целью парсинга, и посторонние могут изучить сетевой трафик, чтобы разобраться в конечных точках обработки запросов, которые связаны с REST и используются приложением.
Если вы поддерживаете специальную версию своего сайта для определенных браузеров, например «урезанную» версию для ранних версий Internet Explorer, то не забывайте о том, что парсеры также могут собирать там данные.
Используйте эти советы в сочетании друг с другом и выберите те из них, которые лучше всего вам подходят.
Парсеры могут собирать данные у других парсеров: если существует сайт, который показывает контент, собранный на другом сайте, то другие парсеры тоже могут собирать данные на сайте этого парсера.

Какой способ — самый эффективный?

Наиболее эффективными методами считаются:

Частое изменение HTML-разметки.
Ловушки и поддельные данные.
Использование запутанных и трудных для понимания JavaScript-скриптов, AJAX-запросов и файлов cookie.
Ограничение скорости получения данных, а также обнаружение парсеров и последующий запрет доступа к данным.