Поради нижче не є 100% панацеєю від парсингу, але можуть ускладнити "життя" парсерам (особливо непрофесіоналам в цій справі). Плюс, швидкість парсингу теж має значення (особливо в сфері торгівлі) і якщо у вас на 1 товар буде йти, умовно кажучи, 20 секунд, то цінність збору даних за 2-3 тижні викликає питання. 

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

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

Як працюють парсери

Як правило, ці парсингові програми написані для того, щоб витягти конкретну інформацію з вашого сайту, таку як статті, результати пошуку, відомості про товари або інформацію про виконавця і цілі альбоми. Зазвичай люди парсять веб-сайти для отримання певних даних, щоб повторно використовувати їх на своєму власному сайті (і заробляти гроші на вашому контенті!) Або навіть просто для приватних досліджень або аналізу . 

Існують різні типи парсерів, і кожен працює по-своєму:

1. Пошукові боти, або "копіри" веб-сайтів, такі як HTtrack. Вони відвідують ваш сайт і рекурсивно переходять за посиланнями на інші сторінки для отримання даних. Іноді вони використовуються при цілеспрямованому парсингу для отримання конкретних даних, часто в поєднанні з аналізатором HTML для вилучення потрібних даних з кожної сторінки.
2. Сценарії командного рядка: іноді для парсингу використовуються загальні інструменти Unix: Wget або Curl для завантаження сторінок і Grep (Regex) для вилучення потрібних даних, зазвичай з використанням сценаріїв командного рядка. Це найпростіший тип парсеру, а також самий нестійкий (ніколи не намагайтеся аналізувати HTML за допомогою регулярних виразів!). Загалом, це найлегший для блокування вид парсеру.
3. HTML-сканери і парсери,засновані на Jsoup, Scrapy, а також безліч інших. Як і в сценаріях з використанням командного рядка на основі регулярних виразів, вони працюють, витягуючи дані з ваших сторінок на основі шаблонів у вашому HTML, при цьому ігноруючи все інше.

Наприклад: якщо на вашому сайті є функція пошуку, такий парсер може відправити HTTP-запит для пошуку (наприклад, підставити назву товару), а потім отримати всі посилання на результати і їх заголовки з HTML-сторінки пошукової видачі, іноді спрацьовує сотні разів для сотень різних пошуків, щоб отримати саме результати пошуку посилань і їх заголовки. 

1. Парсери екрану, зібрані на Selenium або PhantomJS, фактично відкривають ваш сайт в реальному браузері, запускають JavaScript, AJAX і т.д, а потім отримують бажаний текст з веб-сторінки. Як правило, вони діють одним із таких способів: 

• Отримання HTML-коду з браузера після завантаження вашої сторінки і запуску JavaScript, а потім використання аналізатора HTML для вилучення потрібних даних або тексту. Такі парсери є найбільш поширеними, і тому проти них є багато методів для захисту від HTML-парсерів/сканерів.
• Збереження знімків відрендерених сторінок, а потім використання оптичного розпізнавання символів для отримання потрібного тексту. Такий спосіб застосовується вкрай рідко і тільки спеціалізованими парсерами, яким дійсно потрібні ваші дані.

З парсером на основі браузера складніше мати справу, оскільки вони запускають скрипти, візуалізують HTML і можуть вести себе як справжня людина, яка переглядає ваш сайт.

1. Парсинг-сервіси, наприклад ScrapingHub або Kimono. Насправді, існують люди, чия робота полягає в тому, щоб з'ясувати, як парсити ваш сайт і отримати контент для використання третіми особами. Вони використовують великі мережі проксі-серверів і змінні IP-адреси, щоб обійти обмеження і блокування, тому захиститися від них особливо проблематично.

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

1. Інтеграція вашого сайту в сторінки інших сайтів за допомогою фреймів або вбудовування його в мобільні додатки.

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

1. Людина копіює і вставляє: люди будуть копіювати і вставляти ваш контент, щоб використовувати його в іншому місці. На жаль, ви нічого не можете з цим вдіяти.

Хоч і існують різні типи парсерів, тим не менш, у них є багато спільного. Багато парсерів будуть вести себе однаково, навіть якщо вони використовують різні технології і методи для отримання вашого контенту.

Як виявити і зупинити парсинг?

Деякі загальні методи виявлення і обмеження парсерів:

Слідкуйте за своїми логами і статистикою трафіку; обмежуйте доступ, при виявленні підозрілої активності:

Регулярно перевіряйте логи і, в разі підозрілої активності, що свідчить про автоматизований доступ (парсинг, наприклад), безлічі запитів з одного і того ж IP-адреси, блокуйте або обмежуйте доступ.

Ось деякі ідеї:

Обмеження трафіку

Дозвольте користувачам (і парсерам) виконувати обмежену кількість дій за певний проміжок часу. Наприклад, дозволяти тільки кілька пошукових запитів в секунду з однієї IP-адреси або від одного користувача. Це сповільнить роботу парсерів і суттєво знизить їх ефективність. Якщо дії виконуються дуже швидко або швидше, ніж діє реальний користувач, то можна запропонувати вирішити капчу.

Виявлення підозрілої активності

Якщо ви засікли незвичайну активність - багато схожих запитів з однієї IP-адреси, хтось переглядає надмірну кількість сторінок або відправляє велику кількість пошукових запитів, ви можете заблокувати доступ або показати капчу для подальших запитів.

Не обмежуйтеся ідентифікацією тільки по IP-адресі - використовуйте і інші індикатори

При блокуванні або урізання швидкості не варто грунтуватися тільки на IP-адресі. Ви можете використовувати інші індикатори і методи для ідентифікації конкретних користувачів або парсерів. Ось деякі маркери, які можуть допомогти вам ідентифікувати конкретних користувачів або парсери:

• Швидкість заповнення форми користувачем і місце натискання на кнопку;
• За допомогою JavaScript ви можете зібрати багато інформації, такої як розмір екрана, часовий пояс, встановлені шрифти і т.д. Все це можна використовувати для ідентифікації користувачів.
• Заголовки Http і їх порядок, особливо User-Agent.

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

Можна піти далі: ви можете виділити схожі запити, навіть якщо вони надходять з різних IP-адрес, що вказує на розподілений парсинг (парсер, який використовує ботнет або мережу проксі-серверів). Якщо ви отримуєте багато ідентичних запитів, але вони приходять з різних IP-адрес, їх теж можна заблокувати. Знову ж, майте на увазі, що завжди є ризик блокування реальних користувачів.

Замість тимчасового блокування доступу використовуйте капчу

Найпростіша реалізація обмеження трафіку - блокування доступу на певний час, однак капчу можна використовувати ефективніше, див. нижче розділ «Капчі».

Вимагайте реєстрацію та вхід

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

Якщо ви вимагаєте створити обліковий запис і увійти в систему, ви можете відстежувати дії користувача і парсера. Таким чином, ви можете легко визначити, коли конкретний обліковий запис використовується для парсингу, і заблокувати його. Обмежити трафік або виявити підозрілу активність, буде простіше, оскільки ви зможете ідентифікувати саме парсери, а не тільки IP-адреси.

Щоб уникнути заскриптованних реєстрацій безлічі облікових записів, вам необхідно:

• Вимагати адреси електронної пошти для реєстрації і перевіряти їх, відправивши посилання, через яке активується обліковий запис.
• Дозволити реєструвати тільки один обліковий запис на одну адресу електронної пошти.
• Вимагати вирішення капчі при реєстрації / створення облікового запису.

Але пам'ятайте: Необхідність реєстрації облікового запису для перегляду контенту відлякає користувачів і пошукові системи. Якщо для перегляду статті від користувача потрібна реєстрація, то він безумовно піде до іншого ресурсу.

Блокуйте доступ з IP-адрес хмарного хостингу і парсинг-сервісів

Іноді парсери запускаються з служб веб-хостингу, таких як Amazon Web Services, Google App Engine або VPS. Обмежте доступ до вашого веб-сайту (або поставте капчу) для запитів, що виходять з IP-адрес таких хостингів. Ви також можете заблокувати доступ з IP-адрес парсинг-сервісів.

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

Пам'ятайте, що, блокуючи доступ з проксі-серверів і VPN, ви будете негативно впливати на реальних користувачів.

При блокуванні, ваше повідомлення про помилку не повинно бути інформативним для парсера

Якщо ви блокуєте / обмежує доступ, вам слід переконатися, що ви не повідомляєте парсеру, чим саме викликана блокування, тим самим даючи підказки про те, як можна модифікувати парсер. Поганою ідеєю буде показувати сторінки помилок з текстом на кшталт:

• Занадто багато запитів з вашої IP-адреси, спробуйте ще раз пізніше.
• Помилка, заголовок User Agent відсутній!

Замість цього покажіть просте повідомлення про помилку, яка не повідомить парсеру, чим саме він себе видав. Наприклад так:

Вибачте, щось пішло не так. Ви можете звернутися до служби підтримки через helpdesk@example.com, якщо питання залишається невирішеним.

Для реальних користувачів також набагато зрозуміліше побачити таку сторінку з помилкою. 

Використовуйте капчі

Капчі (CAPTCHAs, «повністю автоматизовані тести для розпізнання комп'ютерів і людей») дуже ефективні проти парсерів. На жаль, вони також дуже ефективні для роздратування ваших користувачів.

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

Що потрібно знати при використанні капчі:

• Немає необхідності самостійно розробляти капчі. Скористайтеся reCaptcha від Google - це набагато простіше і зручніше для користувача, ніж якесь розмите і спотворене текстове рішення, яке ви можете придумати самостійно (користувачам часто потрібно тільки поставити галочку). 
• Не вносьте рішення для капчи в розмітку HTML - ми бачили один сайт, який мав рішення для капчі на самій сторінці (хоча і досить добре приховане), що робило її марною. Не варто робити щось подібне. Знову ж таки, використовуйте сервіс а-ля reCaptcha, і у вас не буде таких проблем (за умови його правильного використання).
• Капчі можуть бути вирішені масово: існують сервіси для рішення, де реальні люди за низьку плату вирішують капчі. Знову ж, використання reCaptcha є хорошою ідеєю, оскільки у них є захист (наприклад, відносно короткий час, за який треба вирішити капчу). Такий вид сервісу навряд чи буде використовуватися, якщо тільки ваші дані не є справді цінними.

Подавайте текстовий контент у вигляді зображення

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

Однак це погано для програм читання з екрану, пошукових систем, продуктивності і майже всього іншого. Також це незаконно в деяких країнах (через обмеження доступності, наприклад, закону про американців-інвалідів). Такий спосіб захисту легко обійти за допомогою OCR.

Не розкривайте свій повний набір даних

Якщо можливо, не надавайте скрипту / боту можливість отримати всі ваші дані разом. Наприклад: у вас є інформаційний сайт з безліччю окремих статей. Ви можете зробити ці статті доступними тільки через пошук по сайту. Це означає, що парсер, який бажає отримати всі статті з вашого сайту, повинен буде виконати пошук всіх можливих фраз, які можуть з'явитися в ваших статтях, щоб знайти їх  що буде займати багато часу, жахливо неефективно і, будемо сподіватися, змусить парсер відступити.

Це буде неефективно, якщо:

• Бот / скрипт не потребує повного набору даних.
• Ваші статті обслуговуються з URL-адреси, яка виглядає приблизно так example.com/article.php?articleId=12345. Ця адреса (і подібні) дозволить парсеру просто перебирати всі articleIds і, таким чином, запрошувати всі статті.
• Існують і інші способи знайти всі статті, наприклад, написати скрипт для переходу по посиланнях, які ведуть до інших статей.
• Пошук щось на кшталт «і» або «а» може виявити майже всі статті, так що про це потрібно знати. 
• Вам необхідні пошукові системи для пошуку вашого контенту.

Приховуйте свої API, endpoints тощо

Переконайтеся, що ви, навіть ненавмисно, не виставляєте будь-який API. Наприклад, якщо ви використовуєте AJAX або мережеві запити з Adobe Flash або Java-аплетів (не дай Бог!), то для завантаження ваших даних досить просто переглянути мережеві запити зі сторінки і з'ясувати, куди вони спрямовані, а потім перепроектувати їх і використовувати ці кінцеві точки (endpoints, робочі станції та інші кінцеві точки своєї мережі) в програмі парсеру. 

Протидія парсерам і сканерам

З огляду на, що HTML-парсери при добуванні контенту спираються на шаблони в HTML, можна навмисно змінювати ці шаблони, щоб зламати парсери або заплутати їх. 

Частіше міняйте HTML-код

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

Якщо ви часто міняєте HTML і структуру своїх сторінок, такі парсери можуть не спрацювати.

Ви можете часто змінювати ідентифікатори і класи елементів в своєму HTML, причому автоматично. Так що, якщо ваш div.article-content перетворюється у щось на кшталт div.a4c36dda13eaf0 і змінюється щотижня, парсер спочатку буде працювати нормально, але через тиждень зламається. Обов'язково міняйте довжину ваших ідентифікаторів / класів, інакше парсер буде використовувати div. [Any-14-characters] для пошуку потрібного елемента. Остерігайтеся інших подібних дірок.

Якщо неможливо знайти бажаний контент за структурою розмітки, парсер зробить це за структурою всього HTML-коду. Якщо всі ваші сторінки статті спрямовано по одному шаблону, що кожен div всередині div, який йде після тега h1, є вмістом статті, то на основі цього парсери легко отримають вміст статті. Знову ж таки, щоб уникнути цього, ви можете додавати / видаляти додаткову розмітку вашого HTML, періодично і випадково. Наприклад, додавання додаткових divs або spans. При сучасній обробці HTML на стороні сервера це не складе великих труднощів.

Однак не слід забувати:

• Такий процес буде складно реалізувати, підтримувати і налагоджувати.
• Ви будете заважати процесу кешування. Особливо, якщо ви зміните ідентифікатори або класи ваших елементів HTML, це зажадає відповідних змін до ваших файлів CSS і JavaScript. А, значить, вони будуть повторно завантажуватися браузером після кожної зміни. Це призведе до збільшення часу завантаження сторінки і збільшення навантаження на сервер. 
• "Розумні" парсери все одно зможуть отримати ваш контент, зробивши висновок, де фактично знаходиться вміст. Наприклад, припускаючи, що великий окремий блок тексту на сторінці, ймовірно, є цією статтею, можна знаходити і витягати потрібні дані зі сторінки. Boilerpipe робить саме так.

Міняйте HTML-код в залежності від місця розташування користувача

В принципі, ця порада схожа на попередню. Використання різного HTML-коду для різного розташування (визначається за IP-адресою) порушить роботу парсерів. 

Приклад: на вашому веб-сайті є функція пошуку example.com/search?query=somesearchquery, яка повертає наступний HTML-код:

<div class = "search-result">
<h3 class = "search-result-title"> Stack Overflow став найпопулярнішим в світі веб-сайтом для запитань і відповідей з програмування </h3>
<P class = "search-result-excerpt"> В даний час веб-сайт Stack Overflow став найпопулярнішим веб-сайтом для запитань і відповідей з програмування, в якому міститься 10 мільйонів питань і безліч користувачів, які ... </ p>
<a class"search-result-link" href="/stories/stack-overflow-has-become-the-most-popular"> Детальніше </ а>
</div>

(І далі безліч ідентично структурованих div з результатами пошуку.)

Як ви вже здогадалися, такі дані легко витягти: все, що потрібно зробити парсеру - це натиснути на URL-адресу пошуку за допомогою запиту і витягти потрібні дані з HTML-коду. На додаток до періодичної зміни HTML, як описано вище, ви також можете залишити стару розмітку зі старими ідентифікаторами і класами, приховати її за допомогою CSS і заповнити її неправдивими даними, тим самим заплутавши парсер. Ось як можна змінити сторінку результатів пошуку:

<div class = "the-real-search-result"<h3 class = "the-real-search-result-title"> Stack Overflow став найпопулярнішим в світі веб-сайтом для запитань і відповідей з програмування </ h3><p class = "the-real-search-result-excerpt"> В даний час веб-сайт Stack Overflow став найпопулярнішим веб-сайтом для запитань і відповідей, в якому міститься 10 мільйонів питань і багато користувачів, які ... </ p >

<a class"the-real-search-result-link" href="/stories/stack-overflow-has-become-the-most-popular"> Детальніше </a>

</div>
<div class = "search-result" style = "display: none">
<h3class = "search-result-title"> Відвідайте example.com зараз, щоб дізнатися всі останні новини, пов'язані з Stack Overflow! </ H3>
<p class = "search-result-excerpt"> EXAMPLE.COM НАСТІЛЬКИ ДИВОВИЖНИЙ, ВІДВІДАЙТЕ ЗАРАЗ! (Реальні користувачі вашого сайту ніколи не побачать цього, тільки парсери.) </ P>
<a class"search-result-link" href ="http://example.com/"> Відвідайте зараз! </a>
</div>

Це означає, що парсери, написані для отримання даних з HTML на основі класів або ідентифікаторів, як і раніше будуть працювати, але отримають підроблені дані або навіть рекламу, дані, які реальні користувачі ніколи не побачать, оскільки вони приховані за допомогою CSS.

Заплутати парсер: вставте підроблені, невидимі дані-приманку на свою сторінку

Щодо минулого прикладу, ви можете додати невидимі елементи-приманки в ваш HTML-код, щоб ловити парсери. Наприклад, такий елемент можна додати на раніше описану сторінку результатів пошуку:

<div class = "search-result" style = "display: none">
<h3 class = "search-result-title"> Цей результат пошуку тут для запобігання парсингу </ h3>
<P class = "search-result-excerpt"> Якщо ви людина і бачите це, будь ласка, ігноруйте його. Якщо ви парсер, натисніть на посилання нижче
Зверніть увагу, що натискання на посилання нижче заблокує доступ до цього сайту на 24 години. </ P>
<a class"search-result-link" href="/scrapertrap/scrapertrap.php"> Я парсер! </a>
</div>


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

Ви можете зробити scrapertrap.php, це буде щось на зразок блокування доступу IP-адреси, або примусово встановити капчу для всіх подальших запитів з цієї IP-адреси.

• Не забудьте заборонити ваш honeypot (/ scrapertrap /) в файлі robots.txt, щоб роботи пошукових систем не потрапляли в нього.
• Для підвищення ефективності найкраще поєднувати цей спосіб з частою зміною HTML-коду.
• Постійно змінюйте пастки, інакше парсери навчаться уникати їх. Змініть адресу приманки і текст. Необхідно розглянути можливість зміни вбудованого CSS, що використовується для приховування, і використовувати замість цього атрибут ID і зовнішній CSS, оскільки парсери навчаться уникати всього, що має style атрибут з CSS, який використовується для приховування вмісту. Спробуйте періодично вмикати-вимикати приманку, щоб парсер виходив з ладу не відразу, а через якийсь час..

"Згодовуйте" парсеру підроблені дані

Якщо ви виявите, що на сайті явно знаходиться парсер, ви можете відправити йому підроблені дані; це пошкодить дані, які парсер отримує з вашого сайту. Необхідно зробити фальшиві дані, які не відрізняються від справжніх, щоб парсери не знали, що їх обдурили.

Наприклад: у вас є новинний сайт і ви виявили парсер, замість того, щоб блокувати доступ, просто подайте йому підроблені, випадково згенеровані статті, і це зіпсує весь пакет даних, які отримує бот.

Не приймати запити, якщо User Agent порожній або відсутній

Часто "ліниво" написані парсери, не відправляють заголовок User Agent разом зі своїм запитом, на відміну від браузерів і сканерів пошукових систем. Якщо ви отримали запит, в якому відсутній заголовок User Agent, можна показати капчу або просто заблокувати або обмежити доступ. 

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

Можна перевірити наявність [Referer], так як погано написані парсери можуть його не відправляти або завжди відправляйте одне і те ж (іноді це "google.com"). Наприклад, якщо користувач заходить на сторінку статті зі сторінки результатів пошуку, переконайтеся, що заголовок Referer присутній і вказує на цю сторінку результатів пошуку.

Остерігайтеся наступного:

• Реальні браузери теж не завжди відправляють його;
• Referer легко підробити.
• Знову ж таки, добре підійде в якості додаткової міри проти погано написаних парсерів.

Якщо браузер не запитує ресурси (CSS, зображення) - це не справжній браузер

Справжній браузер (практично завжди) запрошує і завантажує ресурси, такі як зображення і CSS. HTML-парсери і сканери цього робити не будуть, оскільки їх цікавлять тільки реальні сторінки і їх вміст.

Ви можете реєструвати запити до своїх ресурсів, і якщо ви бачите багато запитів тільки для HTML, це може бути парсер.

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

Використовуйте і запитуйте cookies; це стане в нагоді для відстеження дій користувачів і парсерів

Ви можете запитувати cookies для перегляду вашого сайту. Це буде стримувати недосвідчених і початківців розробників парсерів, але бот легко може їх відправити. 

Наприклад: коли користувач виконує пошук, встановіть унікальний ідентифікаційний файл cookies. При перегляді сторінок результатів перевірте цей файл cookie. Якщо користувач відкриває всі результати пошуку (це можна дізнатися з cookies) - це парсер.

Зверніть увагу, що якщо ви використовуєте JavaScript для установки і отримання cookie, ви заблокуєте парсери, що не запускають JavaScript, так як вони не можуть отримати і відправити cookies за допомогою свого запиту.

Використовуйте зв'язок JavaScript + Ajax для завантаження контенту

Ви можете використовувати JavaScript + AJAX для завантаження вашого контенту після завантаження самої сторінки. Це зробить контент недоступним для аналізаторів HTML, які не підтримують JavaScript. Досить часто такий спосіб є ефективним стримуючим фактором для початківців і недосвідчених програмістів, які пишуть парсери.

Необхідно знати:

• Використання JavaScript для завантаження реального контенту знизить зручність використання і продуктивність
• Пошукові системи можуть не запускати JavaScript, що не дозволить їм проіндексувати ваш контент. 
• Програміст-автор бота, який знає, що він робить, може виявити кінцеві точки, звідки завантажується контент, і скористатися ними для обходу заходів захисту.

Маскуйте свою розмітку, мережеві запити від скриптів і все інше

Якщо для завантаження даних ви використовуєте Ajax і JavaScript, замаскуйте передані дані. Наприклад, ви можете кодувати свої дані на сервері (за допомогою чогось простого, наприклад base64 або більш складного, з кількома рівнями маскування, зсуву бітів і, можливо, навіть шифрування), а потім після отримання декодувати і відображати їх через Ajax на клієнті. Це буде означати, що хтось, перевіряючий мережевий трафік, не відразу побачить, як працює ваша сторінка і завантажує дані, і комусь буде складніше безпосередньо зробити запит у ваших кінцевих точок, оскільки їм доведеться перепроектувати ваш алгоритм маскування даних.

Якщо ви використовуєте Ajax для завантаження даних, вам буде складно використовувати кінцеві точки без попереднього завантаження сторінки, наприклад, вимагати ключ сеансу в якості параметра, який ви можете вбудувати в свій JavaScript або HTML.

Ви також можете вбудувати свої закодовані дані безпосередньо в вихідну HTML-сторінку і використовувати JavaScript для дешифрування і її відображення, що дозволить уникнути додаткових мережевих запитів. Це значно ускладнить отримання даних за допомогою парсера, заточеного під HTML.

І все-таки у цього способу є кілька недоліків:

• На практиці це буває досить складно реалізовувати, підтримувати і налагоджувати.
• Це буде неефективно проти парсерsв і сканерів, які запускають JavaScript, а потім витягають дані. (Більшість простих HTML-парсерsв не підтримують JavaScript)
• Це зробить ваш сайт нефункціональним для реальних користувачів, якщо у них відключений JavaScript.
• Постраждає продуктивність і час завантаження сторінки.

Нетехнічні способи боротьби:

Ваш хостинг-провайдер може надавати захист від ботів і парсерsв

Наприклад, популярний CloudFlare забезпечує захист від ботів і злому, як і AWS. Існує також mod_evasive, модуль для Apache, який дозволяє легко реалізувати обмеження швидкості.

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

Ви можете попросити не сканувати ваш сайт, наприклад, в вашому положенні про надання послуг. Або виразом про авторські права. Деякі люди насправді будуть поважати це, і не будуть збирати дані з вашого сайту без дозволу (рідкість, на жаль).

Знайти адвоката 

Вони знають, як боротися з порушенням авторських прав, і можуть відправити лист про припинення та відмову від них. Також в цьому відношенні допомагає DMCA. Такий підхід використовують Stack Overflow і Stack Exchange (це в основному рекомендація для США).

Інші способи:

• Знайдіть баланс між зручністю використання для реальних користувачів і стійкістю до ботів: все, що ви робите, так чи інакше негативно вплине на роботу реальних користувачів, тому вам потрібно буде шукати компроміс.
• Не забувайте про свій мобільний сайт і додатки: якщо у вас є мобільна версія вашого сайту, будьте обережні, боти теж можуть її парсити. Якщо у вас є мобільний додаток, він також може потрапити під атаку парсерів. Можна перевірити мережевий трафік, щоб визначити кінцеві точки REST, які він використовує.
• Якщо ви використовуєте спеціальну версію вашого сайту для конкретних браузерів, наприклад, урізану версію для старіших версій Internet Explorer, не забувайте, що боти теж можуть її бачити і сканувати.

Який найефективніший спосіб захисту від парсингу?

З досвіду написання парсерів, найбільш ефективними методами є:

1. Часта зміна розмітки HTML
2. Пастки і підроблені дані
3. Використання замаскованого JavaScript, AJAX і файлів cookie
4. Обмеження швидкості при виявленні парсеру і подальше блокування.