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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Все, удачи!

Написал довольно много различных парсеров и автоматизаций веб разной сложности, и могу сказать, что единственный вариант - это не публиковать информацию вообще. Думаю следующее поможет отбить желание парсить сайт или как минимум повысит стоимость разработки\поддержки парсера:
1. Система мониторинга поведения пользователя (движение мышки, координаты нажатия на кнопки и т.п.) для того чтобы вычислять ботов.
2. Не использовать Id и name или другие атрибуты, по которым можно вычислить контент.
3. Обфусцировать СSS и делать имена классов динамическими.
4. Динамически добавлять различный мусор в разметку.
5. Использовать веб-фреймворк, и не светить методы наружу.
6. Использовать капчу, от разных вендоров и с динамически генерируемым url, причём загружать её так, чтобы её нельзя было вытащить из кэша браузера (от перехвата запроса это не спасёт, но жизнь автоматизаторам подпортит).
7. Переодически менять вёрстку.

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

Кому надо тот и ручками спарсит и этим все сказано.

Первый: да. Еще и скриншоты параллельно снимать можно.
Кстати, за динамические ссылки вас убьют сеошники.

Второй:
1. нет
2. потенциальный бан/пессимизация
3. не сработает, поскольку парсинг давно уже делается через огромный список прокси
4. клоакинг в чистом виде, бан сразу

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

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

Пользовался вот такими методами для защиты небольших фрагментов текста:
1. Генерация текстов в виде изображений - обычно раньше так имейлы скрывали, но можно что угодно генерировать. Можно накладывать водяные знаки, использовать многоцветную подложку, а лучше всего вставлять произвольные символы в произвольных местах тем же цветом, что и основной текст - при распознавании в результатах будет мусор.
2. Вставка в текст мусорных тегов c динамическими случайными стилями
<style>.GHJbk.KLJHK { display: none; }</style>

<span class="ADsdas POxlka3">note</span>
<span class="GHJbk KLJHK">x862</span>
<span class="j38jdJ Uu300D">book</p>

При этом текст выглядит как notebook, а если через буфер обмена скопировать, то notex862book.

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

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

Если вы публикуете что то в огромной сети, и хотите запрещать что то там копировать - это глупость полнейшая.
У себя использую водяные знаки на картинках и простейщую защиту от селект-копи-паств (защита от пионеров, но для робота это не проблема).
Логи просматириваю переодически и самых активных "искателей" рано или поздно редирекчу на сайт майкрософта. Это отвадило нескольких усердствующих в поиске того же phpMyAdmin, которым не пользуюсь. Подумываю о том, как расставлять им баны с помощью iptables.

Выполнение JS и динамический контент - не препятствие (именно для этого юзают Headless browsers - PhantomJS/CasperJS/etc).
Также удобно парсить и с помощью связки IE+AutoIt.
Если информацию с сайта действительно надо получить, то будут парсить осторожно - месяц, два, полгода. Поэтому, как советовали выше, либо забейте, либо к каждому случаю подходите индивидуально.

Уже давно yandex ввел такую полезную функцию, как подтверждение авторства контента. Но для этого ресурсу необходим ТИЦ не менее 10.
А для google вроде как необходимо указать ссылку на свой аккаунт в google pluse и статья автоматически считается вашей. Даже в выдаче с вашей аватаркой из этой соц.сети сайт будет отображаться.

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

Вывод: защита от пасинга сомнительная затея, сеошники вас за это возненавидят.

1 Загрузка контента через Ajax перед этим генерация токена. Но поисковики могут взбесится.
2 верстка должна быть не просто динамической а для каждой записи своя чтобы поисковики были добрее. Например :

switch($news['id']%10) {
     case 1 : echo "<div>".$news['content']."</div>"; break; 
     case 1 : echo "<p>".$news['content']."</p>"; break; 
     case 1 : echo "<span>".$news['content']."</span>"; break; 

// ...........

}

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

1. Поместить информацию в закрытый раздел.
2. Регулярно добавлять новые статьи, засылать тексты поисковикам.
3. Поставить javascript защиту от копирования домохозяйками.
4. Профит.

Остальные действия по нагромождению костылей просто не имеют смысла.

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

Браузеры кэшируют изображения. А под изображения можно замасировать PHP скрипт.
Например обращаешься по site.ru/image/logo.png, а он при помощи правил веб-сервера (например в Apache - RewriteRule) по URL этой картинки выдает результат работы PHP скрипта (который в свою очередь через себя выдает уже реальную картинку). НИКТО этого не заметит. А PHP скрипт запишет факт загрузки изображения в БД.

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