Google-Agent: почему блокировка этого «бота» может стоить вам клиентов

Google-Agent стоит отдельного правила в антиботе — но не потому, что это нежелательный автоматический краулер, а потому что это принципиально новый тип посетителя: агент, который заходит на сайт по прямому запросу живого человека, а не по расписанию или из очереди задач. Google официально добавил Google-Agent в документацию по краулингу 20 марта 2026 года. Это идентификатор ИИ-агентов на инфраструктуре Google — в первую очередь Project Mariner от Google DeepMind, — которые по запросу конкретного пользователя заходят на сайты и выполняют задачи: заполняют формы, сравнивают товары, извлекают информацию, кликают по элементам страницы. Оператор: Google. Классификация: user-triggered fetcher — та же категория, что у Feedfetcher-Google. За каждым запросом Google-Agent стоит реальный пользователь, пытающийся выполнить задачу на вашем сайте через ИИ; это не автономный обход, и по умолчанию его не стоит банить так же, как случайный скрапер.

Что такое Google-Agent

Зачем Google-Agent приходит на сайт

Представьте: пользователь просит Project Mariner «найти рейсы в Берлин дешевле 400 долларов и сравнить три варианта». ИИ-агент открывает сайты, кликает по страницам, заполняет формы и извлекает данные — каждый такой запрос приходит на сайт с User-Agent Google-Agent.

• Какие зоны чаще трогает: любые страницы, с которыми пользователь попросил ИИ взаимодействовать — от каталога до форм оформления заказа
• Что ищет: конкретную информацию или действие, запрошенное пользователем именно на этом сайте
• Чем отличается от Googlebot: Googlebot непрерывно обходит веб для построения поискового индекса; Google-Agent появляется только тогда, когда живой человек попросил ИИ что-то сделать — принципиально разные категории с разными правилами

Объём трафика Google-Agent сейчас может быть близок к нулю для многих сайтов: Project Mariner пока доступен только в США и только подписчикам плана Google AI Ultra ($249.99/мес). Но документация закреплена как часть глобальной инфраструктуры краулеров Google, а не как региональный эксперимент — это сигнал, что трафик будет расти по мере расширения доступа.

Почему robots.txt здесь не сработает

Google явно относит Google-Agent к категории user-triggered fetchers — той же, что Feedfetcher, Google Read Aloud и NotebookLM. Официальная позиция Google: такие агенты в общем случае игнорируют robots.txt, поскольку запрос исходит не от автономного краулера, а от конкретного человека через стороннее приложение или сервис. Практическое следствие: если нужно ограничить доступ Google-Agent, обычные директивы Disallow могут не сработать. Управлять доступом нужно через серверную аутентификацию или контроль доступа — теми же средствами, которыми вы бы ограничивали обычного человека-посетителя, а не через robots.txt.

Кому выгодны визиты Google-Agent

Это ключевое отличие от большинства ботов в этой категории: пользы от блокировки Google-Agent «по умолчанию» может не быть вовсе — и наоборот, есть прямой риск.

• Если сайт продаёт товары или услуги, а пользователи всё чаще делегируют покупки и сравнения ИИ-агентам — блокировка Google-Agent означает потерю реальных потенциальных клиентов, которые физически не смогут завершить задачу на сайте через свой ИИ-инструмент
• Заметный объём взаимодействий Google-Agent — сигнал, что стоит рассмотреть внедрение структурированных интерфейсов для агентов (WebMCP и подобные машинно-читаемые протоколы), чтобы такие взаимодействия проходили эффективнее
• Блокировать имеет смысл точечно — например, закрыть агентам доступ к административным или платёжным разделам, а не к сайту целиком

Верификация

Google-Agent экспериментирует с протоколом Web Bot Auth — экспериментальным IETF-стандартом, по которому агент криптографически подписывает каждый HTTP-запрос под identity https://agent.bot.goog. Это более надёжный способ подтвердить подлинность, чем UA или IP по отдельности, хотя пока стандарт в статусе draft. Дополнительно можно сверяться с официальным списком user-triggered-agents.json от Google, публикуемым именно для этой категории.

grep -i "Google-Agent" /var/log/nginx/access.log

robots.txt и практический контроль доступа

# Формально можно прописать, но помните: как user-triggered fetcher,
# Google-Agent может это правило проигнорировать
User-agent: Google-Agent
Disallow: /admin/
Disallow: /account/
Disallow: /checkout/
Allow: /

Если действительно нужно ограничить доступ к конкретным разделам, а robots.txt не даёт гарантии — используйте серверную аутентификацию (логин, токен доступа) для чувствительных разделов, как для обычного пользователя. Это надёжнее, чем полагаться на добровольное соблюдение директив.

Рекомендации: что делать с Google-Agent

• Сайт ориентирован на потребителя (e-commerce, услуги, сравнение цен) — не блокируйте Google-Agent вслепую; оцените, не отсекаете ли вы реальных клиентов, использующих ИИ-агентов для покупок
• Нужно закрыть только чувствительные разделы (админка, личный кабинет, оформление заказа) — используйте серверный контроль доступа, а не только robots.txt
• Мониторьте объём в логах: рост взаимодействий Google-Agent — повод присмотреться к WebMCP и другим машинно-читаемым интерфейсам для агентов, а не сразу к блокировке
• Не путайте с Googlebot — это разные категории с разными правилами и разной пользой для сайта

С кем не путать Google-Agent