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 принимались за успешную загрузку независимо от их содержимого.

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

Просто скажите, что это так!

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

«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 года