Старый токен Google-NotebookLM скоро перестанет работать — вот что менять

Google-NotebookLM — не «ещё один hit» в логах и не автоматический обход сайта, а след совершенно конкретного действия: кто-то добавил URL вашей страницы как источник в свой проект NotebookLM (сервис Google, который сейчас переименован в Gemini Notebook). Важно на старте: сам токен сейчас в процессе замены. Google официально поддерживает старое имя Google-NotebookLM только до августа 2026 года — если вы читаете это позже, велика вероятность, что старый токен в ваших правилах robots.txt или на сервере уже ничего не блокирует, потому что реальный трафик идёт под новым именем Google-GeminiNotebook.

Что такое Google-NotebookLM / Google-GeminiNotebook

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

Логика простая: пользователь Gemini Notebook (бывший NotebookLM) вставляет ссылку на вашу страницу как источник для своего исследовательского проекта — например, готовит конспект, сравнивает несколько статей или собирает материал для отчёта. Сервис делает разовый запрос именно к этой странице, чтобы обработать её содержимое.

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

Хиты от этого фетчера — сигнал, что кто-то использует ваш контент в личном исследовательском процессе, а не признак того, что Google массово сканирует сайт.

Переименование: что конкретно нужно поправить

Google обновил документацию вместе с ребрендингом сервиса: старое название токена (Google-NotebookLM) заменено на новое (Google-GeminiNotebook), и старое имя официально поддерживается только до августа 2026 года.

• Если в robots.txt или на сервере прописано правило только под Google-NotebookLM — оно скоро (или уже) перестанет ловить реальный трафик
• Нужно продублировать или заменить правило на новый токен Google-GeminiNotebook
• На переходный период имеет смысл держать оба варианта в конфигурации, пока не убедитесь по логам, что старый токен больше не встречается

Почему robots.txt здесь работает не так, как ожидается

Google делит клиентов, обращающихся к сайтам, на категории: автономные краулеры (Googlebot и подобные, которые «охотятся» за контентом по инициативе Google и обязаны уважать robots.txt), и user-triggered fetchers — куда входит Gemini Notebook вместе с Feedfetcher, Google Read Aloud и Google-Agent. Логика простая: если запрос сделан по явному действию конкретного человека, а не автономным решением краулера, обычные директивы исключения к нему не применяются. Практически это означает: robots.txt можно прописать, но полагаться на него как на единственный механизм контроля не стоит — для гарантированного ограничения нужен контроль на уровне сервера (firewall-правило, серверная логика ответа).

Кому и зачем блокировать (или не блокировать)

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

Как найти в логах

# Ищите оба варианта токена — старый и новый
grep -iE "Google-NotebookLM|Google-GeminiNotebook" /var/log/nginx/access.log

# Топ URL, которые запрашивали
grep -iE "Google-NotebookLM|Google-GeminiNotebook" /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head

# Суточная активность — ожидайте всплески, а не ровный фон
grep -iE "Google-NotebookLM|Google-GeminiNotebook" /var/log/nginx/access.log | awk '{print $4}' | cut -d: -f1 | sort | uniq -c

robots.txt и серверный контроль

# Указывайте оба токена на переходный период
User-agent: Google-NotebookLM
Disallow: /

User-agent: Google-GeminiNotebook
Disallow: /

if ($http_user_agent ~* "Google-(NotebookLM|GeminiNotebook)") {
    return 403;
}

Если задача — гарантированно закрыть доступ (а не просто формально попросить), полагайтесь на серверное правило, а не только на robots.txt: как user-triggered fetcher, соблюдение директив здесь не гарантировано документацией Google.

Рекомендации

• Обновите правила блокировки/аллоулиста с учётом переименования — добавьте Google-GeminiNotebook рядом со старым токеном, не полагаясь только на legacy-имя
• Не относитесь к этому трафику как к типовому нежелательному скраперу — оцените, действительно ли есть причина закрывать точечные, пользовательски инициированные запросы
• Если решили блокировать — используйте серверный уровень, а не только robots.txt, поскольку формальное соблюдение директив здесь не гарантировано
• Не смешивайте с Googlebot: это разные категории с разной логикой и разными последствиями блокировки

С кем не путать