Раньше пользователь шёл за ответом в поисковик, открывал один из сайтов и находил нужную информацию. Сайт получал трафик, конверсии и рекламные показы. Конечно, это упрощённая модель, без оценки качества выдачи, SEO и других деталей, но понятная. За полезную информацию сайт получал аудиторию, а вместе с ней и выгоду.

С приходом ИИ эта схема начала меняться. Пользователь чаще спрашивает ChatGPT, Perplexity или Gemini и не доходит до исходного сайта. А вместе с трафиком пропадает смысл вкладываться в контент.

По статистике Chartbeat, с декабря 2024 по декабрь 2025 года на тысячах сайтов по всему миру переходы из Google упали на 34%. При этом сайты с аудиторией больше ста тысяч просмотров в день за два года потеряли 22% поискового трафика, а сайты до десяти тысяч просмотров в день просели аж на 60%.

ИИ-ответы в поисковой выдаче Google только усиливают этот эффект. Pew Research Center показал, что на страницах с AI summary пользователи почти в два раза реже кликали по обычной выдаче: 8% против 15%. И ссылки внутри AI summary совсем не спасали ситуацию. По ним переходили всего в 1% визитов.

Значит, сайты больше не нужны? Зачем компании, разработчику или редакции тратить время на статьи и документацию, если пользователь уходит в ChatGPT, Perplexity, Gemini и другие нейросети? Но если сайты перестанут публиковать контент, откуда сам ИИ будет брать информацию?

Старый договор веба больше не работает

Cloudflare сравнила, сколько раз сервисы запрашивают HTML-страницы сайтов и сколько переходов возвращают.

Чтобы дальше не смешивать сущности:

• Поисковый бот индексирует страницы для выдачи.

• ИИ-краулер собирает данные для поиска, обучения модели, обновления своего индекса.

• RAG-система достаёт фрагменты из источников под конкретный запрос.

• ИИ-агент может открыть сайт, нажать кнопку, заполнить форму, вызвать API или инструмент.

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

У Google, по данным Reuters, в середине 2025 года было около 18 запросов на один переход, у OpenAI соотношение составляло около 1 500:1. В отдельном разборе Cloudflare самый резкий перекос был у Anthropic: около 70 900 HTML-запросов на один реферальный переход. Позже цифры менялись, но сама асимметрия между краулингом и возвратом трафика сохранилась.

Поэтому Cloudflare начала давать владельцам сайтов инструменты для управления ИИ-краулерами. Их можно ограничивать, блокировать или пускать за плату по модели pay-per-crawl. Но вряд ли это решит проблему.

Так как доступ к актуальной, проверенной информации становится предметом сделки, часть источников неизбежно закроется, часть уйдёт в коммерческий краулинг, а часть достанется моделям, которые договорятся с владельцем контента. В итоге достоверность информации будет зависеть не только от качества источников, но и от того, к каким источникам у модели вообще будет доступ. И пользователь даже не узнает, что ответ собран только из фрагмента веба, а самые релевантные данные могли вообще в него не попасть.

Когда источник теряет доверие

Сейчас появляется всё больше сервисов, которые обходят сайты и собирают из них готовый ответ. Такие посредники хорошо показывают, что проблема гораздо глубже трафика и выгоды.

В 2024 году Forbes обвинил Perplexity Pages в том, что сервис пересказывал журналистские материалы и недостаточно явно показывал, откуда они взяты. Позже The New York Times подала иск против Perplexity из-за незаконного копирования и отображения материалов газеты, а также генерации выдуманного контента, ложно связанного с брендом. Britannica и Merriam-Webster тоже утверждали, что сервис ставит сгенерированный контент рядом с их брендами.

Для пользователя это выглядело как обычная ссылка на проверенный источник. Он не всегда видел, где заканчивается оригинальный материал и начинается интерпретация модели. А знакомое имя рядом с ответом создавало ощущение, что факт проверен.

Теперь модель решает, что прочитать и процитировать пользователю, а что оставить за кадром. Это ломает саму логику доверия и не просто ставит под удар репутацию энциклопедий и словарей. Пользователь перестаёт понимать, кто именно отвечает за утверждение.

Раньше пользователь видел контекст, детали, ограничения и сам решал, что важно. Теперь между ним и первоисточником появился гладкий, уверенный пересказ, который выглядит почти так же надёжно, но может содержать ошибку, которой не было в оригинале.

Веб перерождается

Сайты начинают говорить с моделями

Чтобы снизить риск искажений, сайту уже недостаточно быть понятным только человеку. Информацию чаще приходится готовить так, чтобы её мог прочитать краулер, модель или ИИ-агент.

В 2024 году Джереми Ховард из Answer.AI предложил для этого формат llms.txt. Это Markdown-файл в корне сайта, который подсказывает LLM, где лежит важная информация. Это не замена сайту или новый SEO-трюк, а просто карта для модели, которая указывает, где искать документацию, ключевые разделы и подробную версию для контекста.

Это может выглядеть так:

# Example Product Docs

> Документация Example Product: API, SDK, интеграции и changelog.

## Основные разделы

- [Quickstart](https://example.com/docs/quickstart.md): быстрый запуск и первый запрос к API
- [API Reference](https://example.com/docs/api.md): методы, параметры, ошибки и лимиты
- [Authentication](https://example.com/docs/auth.md): токены, ключи доступа и обновление сессий
- [Changelog](https://example.com/changelog.md): изменения по версиям продукта

## Дополнительный контекст

- [Architecture](https://example.com/docs/architecture.md): как устроена система
- [Known limitations](https://example.com/docs/limitations.md): ограничения и частые проблемы
- [Full docs](https://example.com/llms-full.txt): полная Markdown-версия документации

Это удобный вход для модели без лишнего HTML, навигационного шума и риска взять старую или второстепенную страницу вместо актуальной. Но llms.txt не возвращает старую экономику веба. Он не гарантирует, что модель процитирует источник или приведёт пользователя на сайт. Это просто техническая подсказка, а не механизм проверки достоверности.

В 2026 году Vercel предложил Agent Readability. Этот набор практик должен помогать ИИ-агентам отличать актуальный текст от устаревших блоков. Он может снизить риск неправильного чтения страницы, но не гарантирует того, что модель верно передаст смысл, процитирует источник или вернёт пользователя на сайт.

Anthropic развивает свой подход через MCP. Он рассчитан уже не на краулеры, которые просто читают страницы, а на агентов. Если им дать права, они могут обращаться к инструментам и сервисам через стандартный протокол. Поэтому вместе с удобством появляются требования по авторизации, ограничению доступа, защите от prompt injection и подтверждению опасных операций. Так модель получает прямой способ работать с внешними данными, но возникают новые риски безопасности.

В идеале всё это должно улучшить качество ИИ-ответов и уменьшить количество неверных интерпретаций. Но, во-первых, это только немного повышает достоверность, а не полностью решает проблему. А во-вторых, непонятно, насколько далеко может зайти такая оптимизация. Если сайт постепенно превратится в набор Markdown-файлов, JSON, служебных описаний и API для агентов, человеку станет сложнее проверить, что именно там написано. Поэтому сайт должен говорить на двух языках, но смысл в обоих слоях должен совпадать. Иначе вместо источника истины получится ещё один пересказ, только специально подготовленный для ИИ.

Агенты ведут себя как пользователи

На практике не каждый сайт будет готовить этот слой, и не у каждого сервиса есть API. Поэтому вокруг агентов появляется другой рынок, где модель не ждёт специального входа.

Browserbase формулирует это как инфраструктуру для ИИ-агентов, которые должны научиться делать в браузере то же, что и человек: нажимать на кнопки, заполнять формы, проходить сценарии. Например, Browserbase создаёт удалённую браузерную сессию, Playwright подключается к ней, а дальше код работает с сайтом почти как пользователь. Упрощённо такая схема взаимодействия может выглядеть так:

import { chromium } from "playwright-core";
import Browserbase from "@browserbasehq/sdk";

const bb = new Browserbase({
  apiKey: process.env.BROWSERBASE_API_KEY,
});

const session = await bb.sessions.create();

const browser = await chromium.connectOverCDP(session.connectUrl);
const page = await browser.newPage();

await page.goto("https://example.com/login");

await page.fill("#email", process.env.USER_EMAIL);
await page.fill("#password", process.env.USER_PASSWORD);
await page.click("button[type='submit']");

await page.click("text=Billing");
await page.click("text=Invoices");

const invoiceText = await page.locator(".invoice-row").first().innerText();

console.log(invoiceText);

await browser.close();

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

Browser Use идёт в ту же сторону и описывает себя как API для любого сайта. Смысл в том, что агенту не нужно ждать, пока компания сделает отдельную интеграцию. Это меняет роль интерфейса на сайте. Страницы начинают оптимизировать не только под читателя, но и под действия агента. Риск тот же, что и с избыточной Markdown- и JSON-изациями. Чем удобнее сайт для машины, тем легче забыть, что человеку тоже нужно всё понимать, чтобы проверить источник. А если пользователь видит один смысл, а агент из-за скрытых состояний или промежуточных экранов получает другой, сайт перестанет быть проверяемым источником.

Но в этом заложен ещё один риск. Если довести оптимизацию до абсурда, веб вообще перестанет обслуживать пользователей.

Крайний сценарий

Уже есть радикальные эксперименты. Moltbook — соцсеть для ИИ-агентов, где они публикуют посты, голосуют и взаимодействуют друг с другом, а люди в основном наблюдают за процессом. Пока это карикатурный пример оптимизации под машины, но показывает зарождение ещё одной проблемы.

Если модели начнут активно заполнять веб, определить источник и качество информации станет ещё сложнее. Появится замкнутый контур: одна модель создала текст, другая сделала на его основе ответ, третья интерпретировала этот ответ и добавила новый слой. Через несколько таких циклов отличить первичный факт от генерации станет почти невозможно.

И что же тогда со всем этим делать?

Цепочка доверия

Абсолютного источника истины для веба, скорее всего, не будет. Официальный сайт может ошибиться, подписанный документ устареть, а научная статья быть опровергнута. Поэтому задача не в том, чтобы найти волшебную кнопку «подтверждено», а в методике проверки. Сейчас ИИ-сервисы часто заменяют последовательную проверку единым ответом, хотя исторически доверие строилось как цепочка: кому доверяем, кто утверждает, откуда взялись данные, можно ли повторить результат, есть ли независимые подтверждения и что изменилось со временем.

Часть такой цепочки уже собирается из существующих технологий:

• Verifiable Credentials помогают подтвердить, кто выпустил утверждение и не было ли оно изменено.

• C2PA и Content Credentials показывают происхождение файла и историю его изменений.

• Knowledge graphs позволяют хранить не просто текст, а связи между сущностями, источниками и датами.

• RAG и multi-source verification дают возможность не ограничиваться одним удобным фрагментом, а искать несколько подтверждений и возможные противоречия.

Конечно, тут тоже могут возникать ошибки. Неверный вывод в файле с прозрачной историей изменений или устаревшие данные, связанные между собой в knowledge graph. Часть таких недочётов со временем можно будет учесть и исправить. Но главная проблема в том, что некоторые участки этой цепочки пока остаются плохо покрытыми. Пользователю вообще не видно, почему модель отбросила какие-то материалы, где закончился факт и началась интерпретация, насколько независимы подтверждения и что надо проверять самому. Получается игра вслепую. Пользователю остаётся либо просто верить модели, либо перепроверять каждый её ответ. Чтобы этого не делать, пользователь должен понимать, как и из чего получился ответ и иметь возможность пройти по всей цепочке доверия до источника.

Здесь пригодятся старые научные и исторические практики. Например, воспроизводимость как правило, которое сохраняет путь от вопроса к выводу. Версионирование, которое помогает понять, с какой редакцией знания работала модель и почему прежний ответ мог устареть. Проверка независимости источников, чтобы отделять реальное подтверждение от цепочки перепечаток.

Например, у платформы микроблогинга X уже появился фактчекинг. Инструмент Community Notes позволяет добавить пояснение к спорному посту. Если пояснение наберёт высокий рейтинг полезности среди пользователей, которые обычно не соглашаются друг с другом при оценке других заметок, оно будет автоматически опубликовано под постом. Но проблема в том, что пояснение может появиться слишком поздно, не набрать нужного согласия или вообще не быть показано пользователям до того, как фейк разойдётся по сети.

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

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

В 2026 году пользователи начали просить поиск вести себя как Google из нулевых, чтобы получить старую выдачу с обычным списком ссылок. Так получается эмулятор Google внутри Google, который исключает из выдачи AI-ответы.

Сайт как доказательство

Поэтому можно быть уверенным, что сайты не исчезнут, по крайней мере в ближайшие годы. Но страницы, написанные только ради трафика, будут всё меньше нужны и людям, и моделям. А вот документация, changelog, репозитории, исследования, FAQ, публичные базы знаний и честные инженерные разборы станут важнее, потому что на них можно будет опереться.

Главным станет не «понравиться ChatGPT» или пройти новую SEO-игру, а публиковать знания так, чтобы модель могла их правильно интерпретировать, а человек – проверять.

Также можно прочитать статьи о том, как превращать ИИ из гладкого ответа в проверяемую инженерную систему:

– Построение инфраструктуры для работы с языковыми моделями: опыт X5 Tech
– Разметка данных с использованием LLM