20 відсотків усіх вебвідповідей «ОК», які отримує ШІ, — неналежні

Мої нещодавні експерименти з вебскрейпінгом за допомогою ШІ наочно показали, наскільки поширеним стає «закриття» вебу. Звісно, поштовхом до такого відступу від відкритості стало приголомшливе зростання вебскрейпінгу за допомогою ШІ, чиїй невпинній потребі в нових даних зрештою під силу вивести домени з ладу.

Це чудова нагода для доменів зробити те, чого багато хто з них давно хотів: надавати доступ до свого вмісту лише користувачам, які ввійшли в систему (хоча, звісно, Googlebot зазвичай безперешкодно отримує доступ). Facebook завершив поступове впровадження цієї політики у 2023 році, а Twitter/X зробив те саме того ж року. Reddit запровадить її пізніше цього місяця.

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

Тим часом заходи, спрямовані саме на захист від ботів (а не на залучення користувачів), за рік зросли більш ніж на 58%, за даними Cloudflare. Уся ця дедалі активніша діяльність ботів закономірно спонукає вебсайти ретельніше перевіряти адреси VPN і проксі-серверів, через що легітимні користувачі, як і будь-який «шкідливий» трафік, можуть втратити доступ.

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

Капча на archive.is — одному з багатьох сайтів, які запровадили перевірки, часто у відповідь на надмірну кількість автоматизованих (а не людських) запитів.

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

Оскільки сканери ШІ мають працювати у великому масштабі, вони зазвичай використовують безголові екземпляри Chrome у межах фреймворку Playwright. Нині на дедалі більшій кількості доменів у відповідь ви отримаєте помилку 403 («заборонено») (тобто сервер розпізнав автоматизований трафік і наказує забиратися):

Локально встановлений changedetection.io намагається перевірити сайт, але сайт не приймає розпізнаний браузер, який використовує фреймворк, і повертає відповідь 403 («Заборонено»).

Потрібна відповідь клієнту «200» («ОК»), навіть якщо для її отримання доведеться викласти купу грошей фермі житлових проксі-серверів і вдатися до інших різноманітних хитрощів, щоб приховати автоматизований характер запитів.

Немає нічого кращого за відповідь 200; інакше кажучи, не існує коду відповіді клієнту з вищим рівнем позитивного сигналу. До того ж ця відповідь не двозначна: це ніколи не «майже добре», не «пізніше буде добре» і не «стає дедалі краще»; це «усе гаразд!». Якщо все не гаразд, це не відповідь 200.

Привіт! Іди геть

Однак, згідно з новою науковою статтею, через цю нестачу градацій набори даних для ШІ, статистичні оцінки та звіти можуть істотно викривлюватися, а статус помилково позначатися як «успішний».

Дослідження* показує, що приблизно п’ята частина відповідей із кодом 200 не містить узагалі жодного придатного до використання вмісту сторінки, а натомість повертає порожні каркаси сайтів, CAPTCHA-перевірки, обмеження доступу або сторінки-замінники.

У статті зазначено:

«20,9% сторінок, які статичний клієнт отримує зі статусом 200, не містять основного вмісту сторінки: це каркаси застосунків, перевірки для ботів, сторінки блокування, сторінки помилок і заповнювачі, а також неповний вміст».

У цьому сенсі нетерплячі автоматизовані системи спотикаються через власну обмеженість: відповідь «200» можна вважати ознакою успішного отримання даних, навіть якщо запит повертає лише CAPTCHA-перевірку, платний доступ або іншу перешкоду.

У статті описано сім типів вмісту, які часто ускладнюють отримання відповіді 200:

Сім категорій вмісту, який аж ніяк не свідчить про те, що з відповіддю 200 «усе гаразд». Джерело

У межах дослідження протягом трьох днів перевірили 10 307 вебадрес за допомогою базової програми для отримання вебсторінок і браузера, здатного завантажувати JavaScript. Результати класифікували за отриманим вмістом, а не за кодами стану HTTP.

Найбільшими категоріями «непридатних» відповідей 202 були порожні оболонки сайтів і сторінки з помилками або сторінки-підміни — разом на них припадало понад дві третини невдалих запитів.

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

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

Більш ресурсомісткі інструменти на основі браузера можна було б використовувати лише тоді, коли сторінка, схоже, завантажилася неправильно. Крім того, під час оцінювання ШІ можна було б перевіряти, чи справді містять цитовані джерела очікувану інформацію, а не припускати, що відповідь HTTP 200 означає успішне отримання вмісту.

Автор нової роботи також зазначає, що «прості евристичні методи» можуть без зусиль виявити близько 86% непридатних відповідей за допомогою базових перевірок довжини сторінки, перенаправлень і схожості зі сторінками, яких не існує:

Порівняння стратегій отримання вебсторінок: рендеринг лише сторінок, позначених як підозрілі, дав змогу отримати трохи більше придатного вмісту (81,4%), ніж рендеринг усіх сторінок (80,3%), і водночас скоротив середній час отримання сторінки з 20,6 до 5,8 секунди.

Чому так багато помилкових відповідей 200?

У спільнотах розробників уже не раз точилися суперечки про те, чи може помилка 202 («Прийнято») («Запит прийнято, але ще не виконано») допомогти розрізнити такі «невдалі» запити зі статусом 200. Однак насправді код 202 не охоплює всіх випадків, описаних у новій статті, та й відповідного коду поки не існує.

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

Однією з причин може бути те, що будь-яка відповідь, відмінна від 200, по суті, означає сторінку помилки або перешкоду, зокрема найпоширенішу помилку 404 («не знайдено»), коли потрібного вмісту просто немає. Дехто вважає, що надмірна кількість таких помилок призведе до санкцій у SEO (і, ймовірно, у GEO), хоча Google це заперечує.

Google вважає помилкові відповіді 200 так званими «м’якими» помилками 404. Очевидно, вони можуть створювати більше проблем, ніж звичайні помилки 404, адже по суті є «оманливими» результатами — навмисно чи ні.

Дрейф цитувань

Якщо все це здається прискіпуванням до дрібниць, варто зважити на петабайтні обсяги даних, які регулярно збирають (або намагаються зібрати) для навчання ШІ. Якщо ціла п’ята частина таких даних ненадійна або відверто оманлива, наслідки цього важко списати на «супутню неточність»: такі хибні відповіді можуть істотно й негативно вплинути на розподіл даних у наборах і на результати навчання моделей ШІ на цих даних.

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

Нове дослідження виявило, що частка випадків, які видаються дрейфом цитувань, зросла з 5,8% до 21,9%, коли всі відповіді HTTP 200 вважали успішним отриманням даних, незалежно від їхнього вмісту.

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

Просто скажіть, що це так!

Проблему також продемонстрували випробування з навмисно неіснуючими вебадресами. Коли сайти отримували запити до випадкових вигаданих шляхів, 13,1% тих, що відповіли, повертали статус 200 («OK»), хоча запитаних сторінок не існувало^†.

«13,1% сайтів, що відповіли на запит із випадковим шляхом, повернули статус 200 (S1 — 10,5%, S2 — 13,3%, S3 — 17,3%, S4 — 13,7%, S5 — 13,1%). Кожна така відповідь за визначенням є м’якою помилкою 404, але не кожна про це повідомляє.»

«Під час дослідницького аналізу 172 відповідей із м’яким статусом 404 розмітник класифікував 98 із них як сторінки помилок або сторінки-заміни, 32 — як порожні оболонки, а 28 — як контент: головна сторінка чи перелік, відображені за випадковою адресою, сприймаються як звичайна сторінка».

Висновок

Якби проблему розпізнавали на вищому рівні, IANA теоретично могла б створити новий і доречніший код стану HTTP, наприклад [X] («Запит успішно оброблено, але запитаний вміст не надано»). Хоча це справді описувало б те, що відбувається, для цього хосту, природно, довелося б мати малоймовірно глибоке розуміння транзакції.

Подібні коди вже існують, хоча жоден із них не підходить цілком: 451 («Недоступно з юридичних причин») — неоднозначний і доволі тривожний (!); 206 («Частковий вміст») технічно доречний, але призначений для неповних даних (під час отримання); а несподівано наявний код 203 («Неавторитетна інформація»), створений у 1997 році, лише побічно стосується розглядуваного випадку.

Можливо, найближчим відповідником насправді є код 103 («Ранні підказки») з неочевидною назвою: він указує, що ще не всі ресурси URL-адреси завантажено (хоча це, безперечно, було б грубим хибним тлумаченням призначення цього коду).

* Під назвою «Коли 200 OK — це не відповідь: непомітні збої отримання вебконтенту агентами». Зверніть увагу: статтю, очевидно, написано насамперед для машинного зчитування, можливо, щоб ШІ міг надсилати до неї запити, тож її нелегко читати й самій по собі.

^† Перепрошую за механістичну цитату, але, як я зазначив вище, усю статтю написано саме так — для машинного зчитування, а не для сприйняття людиною, хоча її й не подано у форматі JSON.

Уперше опубліковано в середу, 4 листопада 2026 року