---
title: "Захист від ботів, що виганяє живих: як фільтри ріжуть реальних клієнтів"
description: "Жорсткий захист від ботів часто блокує реальних клієнтів через повільний інтернет чи нестандартні браузери. Розбираємо, як знайти ці помилки до запуску сайту і чому синтетичні тести не бачать проблему."
date: 2026-11-14T20:22:39.681Z
lang: uk
url: https://xab.info/uk/posts/zahyst-vid-botiv-scho-vyhanyayut-zhyvyh
tags: [web-development, seo, traffic, bot-protection, web-analytics, user-experience]
author: "Олександр Буран"
publisher: "XAB.info"
---

# Захист від ботів, що виганяє живих: як фільтри ріжуть реальних клієнтів

![Колаж із шести зображень: дорога, старий ключ, ворота в тумані, ножиці, силует людини на тлі світла та ланцюг.](https://xab.info/media/2026/11/14/zashchita-ot-botov-kotoraya-rezet-zhivyh-klientov/zashchita-ot-botov-kotoraya-rezet-zhivyh-klientov-1.webp)

## Ключові тези

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

Ситуація знайома кожному, хто запускав сайт із формами, кошиками чи особистими кабінетами. Розробник робить усе за інструкцією: капча на форму, фільтр за частотою запитів, блокування підозрілих країн. Сайт захищений, боти не проходять. А за тиждень власник відкриває зворотний зв'язок і бачить: «Не можу оформити замовлення», «Капча не вантажиться», «Сайт не працює, хоча інтернет є».

Проблема в тому, що захист зазвичай тестує одна людина, в одному браузері, з одного міста, на одному пристрої. Для неї все працює. А клієнт з іншого регіону, на іншому телефоні, з іншим браузером — не проходить. І не тому, що він бот. А тому, що захист, налаштований на жорсткість, не розрізняє «дивний, але живий» запит і «дивний, бо автоматичний». Він просто ріже. І ріже тих, хто прийшов купити.

### Який вигляд має захист, що ріже живих

[

](/uk/images/zahyst-vid-botiv-scho-vyhanyayut-zhyvyh-4)

Найчастіший сценарій — капча, яку неможливо розв'язати. Не тому, що вона зламана загалом, а тому, що для конкретного користувача вона не вантажиться, вантажиться криво або просто не розпізнається. Людина тричі вводить символи, тричі отримує «невірно» і йде. Для власника сайту це виглядає як одна відмова. Для ринку — як втрачене замовлення. А якщо таких людей десять на день, то за місяць це вже відчутна діра у виручці, яку ніхто не помічає, бо в статистиці просто «низька конверсія».

Другий сценарій — жорсткий фільтр за частотою запитів. Сайт вважає, що якщо з однієї адреси за хвилину прийшло понад п'ять запитів, це бот. Але жива людина на повільному мобільному інтернеті відкриває сторінку, та не вантажиться, вона оновлює. Ще раз. Ще. За хвилину в неї вже сім запитів, і сайт її блокує. Людина бачить порожню сторінку або повідомлення «забагато спроб». Вона не бот. Вона просто на поганому покритті. Але захист не знає про це.

Третій — блокування за країнами. Розробник дивиться на статистику атак, бачить, що половина запитів з певних територій, і стає заборона. А потім з'ясовується, що в цих країнах живуть живі клієнти, які замовляли раніше. Або що в людини роумінг, і вона фізично в одній країні, а її запит йде через іншу. Захист не розбирає контекст. Він бачить країну і вирішує.

Четвертий, менш очевидний: скрипт, який перевіряє «живість» браузера. Він перевіряє наявність певних параметрів, версію рушія, набір функцій. І якщо браузер не відповідає — сторінка не рендериться. Людина бачить порожній екран або половину верстки. Для неї сайт «зламався». Для розробника — «браузер не підтримується». Але це не про підтримку. Це про те, що перевірка живісті написана так, що вона не проходить на нормальних, але нестандартних конфігураціях.

### Чому «на око» не перевірити

[

](/uk/images/zahyst-vid-botiv-scho-vyhanyayut-zhyvyh-5)

Головна пастка: розробник і власник сайту бачать усе нормально. Вони відкривають сайт у Chrome на десктопі, у своїй країні, на хорошому інтернеті. Все вантажиться, капча вирішується, форма відправляється. Тест пройдено. Сайт запущено. А потім приходят клієнти — з Android на слабкому покритті, з Safari на iPhone, з Firefox на ноутбуці, з іншої країни, з розширенням, яке змінює заголовок браузера. І для них сайт інший. Не тому, що він зламаний. А тому, що вони не ті, хто його перевіряв.

Синтетичні тести навантаження, які часто використовують для перевірки сервера, тут не допомагають. Вони надсилають запити на сервер і дивляться, як сервер відповідає. Але вони не виконують JavaScript, не вантажать сторінку повністю, не рендерять верстку, не розв'язують капчу. Для них сторінка — це набір байтів. А для живої людини — це те, що вона бачить на екрані. І якщо JavaScript не спрацював, якщо шрифт не підвантажився, якщо форма не ініціалізувалася — сервер при цьому може відповідати «200 OK» і вважати, що все гаразд. А людина бачить криву сторінку і йде.

Ще один момент: захист часто вмикається не одразу. Перші запити проходять нормально, а потім, коли лічильник запитів з однієї адреси перевищує поріг, вмикається блокування. Тестувальник робить п'ять запитів, все працює, він закриває браузер. А клієнт робить п'ятнадцять — і отримує стіну. Тест не відтворює реальну поведінку користувача, бо тестувальник не користувач. Він перевіряє функцію, а не сценарій.

### Що саме ламається і як це помітити

[

](/uk/images/zahyst-vid-botiv-scho-vyhanyayut-zhyvyh-6)

Список того, що може зламатися через занадто жорсткий захист, невеликий, але кожен пункт б'є по грошах. Верстка: сторінка не рендериться повністю, блоки не стають на місце, кнопки не клікаються. Лічильники: скрипт аналітики не може надіслати дані, бо запит заблокований фільтром, і власник бачить у статистиці діри — не тому, що людей немає, а тому, що їх відвідувань не записали. Форми: надсилання не проходить, бо запит із формою виглядає як «підозрілий» для фільтра. Кошики: сесія обривається, бо перевірка «живісті» не пройшла на другому кроці. Особисті кабінети: вхід не працює, бо авторизація вимагає певних параметрів, а захист їх не пропускає.

Як зрозуміти, що проблема саме в захисті, а не в сайті? Простий тест: вимкнути захист на десять хвилин і подивитися, що відбувається. Якщо форми знову працюють, якщо верстка встала, якщо лічильники пішли — отже, річ була у фільтрі. Але це тест «після», коли вже щось зламалося. А треба розуміти заздалегідь, до запуску або до зміни налаштувань. І для цього потрібен не один браузер в одному місті, а багато браузерів у різних точках.

### Прогнати сайт реальними браузерами: ідея

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

Чому це краще, ніж синтетичний тест навантаження? Тому що переглядач вантажить сторінку повністю. Він виконує JavaScript, рендерить верстку, завантажує шрифти, картинки, скрипти. Він поводиться як звичайний відвідувач, тільки без свідомості. І якщо захист його душить — значить, він душит і живих. Якщо ні — значить, живі проходять. Це не гарантія, що кожен конкретний користувач пройде, але це набагато ближче до реальності, ніж «сервер відповів 200».

Де взяти такий трафік для тесту? Джерело, яке для цього підходить, — [9Hits](https://9hits.com/?ref=276016). Це біржа обміну трафіком, яка працює з 2010-х років. Учасник ставить програму-переглядач, і вона сама, без людини, відкриває сайти в справжньому браузерному рушії, витримує заданий час і йде далі. За це нараховуються поінти. А поінти витрачають на свою кампанію: адреса сайту, час на сторінці, частота, країни. Сайт відкривається в переглядачах інших учасників по всьому світу. Є макроси — сценарії дій на сторінці: прокручування, кліки, заповнення полів. Для тесту захисту це рівно те, що потрібно: можна задати, щоб на сторінці була прокрутка, клік по кнопці форми, введення в поле. І подивитися, що відбувається.

### Поінти для разового тесту: збирати не обов'язково

[

](/uk/images/zahyst-vid-botiv-scho-vyhanyayut-zhyvyh-2)

Єдине, що може відлякати: «мені потрібно спочатку збирати поінти, щоб потім витрачати». Для регулярної роботи — так, учасник збирає, поки його переглядач відкриває чужі сайти. Але для разового тесту, який потрібен один раз — перед запуском або перед зміною налаштувань захисту, — збирати не обов'язково. Є варіант взяти [готові поінти](https://9hitshub.com/). Це не підписка, не абонемент, не «замовте пакет». Це просто кількість, яку можна взяти на один прогін. Запустив кампанію на свій сайт, подивився, що відбувається в різних країнах і на різних сценаріях, закрив. Поінти витрачено, тест зроблено.

Важливо розуміти, що це автоматичний трафік програм, не живі люди. Ніхто не сидить і не клікає. Це рушій браузера, який відкриває сторінку і виконує задані дії. Для тесту захисту це не недолік, а гідність: він не втомиться, не забуде натиснути кнопку, не закриє вкладку за три секунди. Він робитиме рівно те, що задано в макросі. І якщо на третьому кроці сторінка не завантажилася — це буде видно у звіті. Не «за відчуттями», а конкретно: сторінка X, час Y, статус Z.

### Що саме перевіряти після прогону

[

](/uk/images/zahyst-vid-botiv-scho-vyhanyayut-zhyvyh-3)

Чек-лист невеликий, але кожен пункт варто пройти. Перше: верстка. Чи відкривається сторінка повністю? Чи не обривається на півдорозі? Чи не «стрибає» контент? Якщо на якомусь сценарії сторінка вантажиться наполовину — це проблема. Не обов'язково в захисті, але перевірити варто.

Друге: форми. Чи заповнюються поля? Чи надсилається форма? Чи з'являється повідомлення про успіх або про помилку? Якщо форма не надсилається — це або захист, або баг. Але якщо вона не надсилається тільки в певних країнах або на певних сценаріях — це майже напевно захист.

Третє: капча. Чи з'являється вона? Чи вирішується? Якщо на одному сценарії капча є, а на іншому — ні, або вона вантажиться, але не відображається — це проблема. Жива людина в такій ситуації піде.

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

П'яте: швидкість. Не обов'язково, щоб сторінка вантажилася за 0,3 секунди. Але якщо на одному сценарії вона вантажиться за дві секунди, а на іншому — за вісім, і на восьмисекундній вона не довантажується — це проблема. Жива людина на повільному інтернеті не чекатиме вісім секунд. Вона оновить. А оновлення — це ще один запит. А ще один запит — це ще один крок до блокування.

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

### Як не перемудрувати із захистом

Захист потрібен. Боти є, і вони ріжуть репутацію, спамлять форми, вантажать сервер. Але захист, який не розрізняє бота і живу людину на поганому інтернеті, — це не захист. Це фільтр, який ріже всіх підряд. І головний принцип: захист має пропускати живих. Не «здебільшого пропускати», не «більшість проходять», а пропускати. Якщо жива людина не може пройти — це не її проблема. Це проблема налаштування.

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

І останнє. Захист — це не «поставив і забув». Браузери оновлюються, рушії міняються, нові розширення з'являються, нові країни підключаються. Те, що працювало три місяці тому, може не працювати сьогодні. Не тому, що сайт зламався. А тому, що світ змінився. І перевірка, яку один раз зробили перед запуском, за пів року вже не актуальна. Це не вирок. Це просто означає, що захист — не разова настройка, а процес. І чим раніше видно, що він ріже живих, тим менше втрачається. Не в статистиці. У грошах.

## Часті запитання

### А якщо на сайті лише статті і немає форм — мені це не загрожує?

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

### Чи можна просто вимкнути капчу чи фільтр, щоб перестати блокувати клієнтів?

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

### Скільки поінтів потрібно для одного прогону?

Точної цифри немає — вона залежить від параметрів кампанії: скільки країн, який час на сторінці та яка частота. Для разового тесту достатньо взяти кількість на один прогін, це не підписка і не накопичення.

### Клієнти вже скаржаться, що не можуть оформити замовлення. Що робити просто зараз?

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

### Мобільні пристрої — це окремий сценарій чи достатньо десктопа?

Окремий. На телефоні з повільним покриттям сторінка вантажиться довше і людина частіше оновлює, а отже частіше впирається в частотний фільтр. Мобільний сценарій варто прогнати окремо від десктопного.

### Чи потрібно повторювати прогін після кожного оновлення сайту?

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