Ключ IndexNow лежит в открытом репозитории на GitHub с позапрошлого года, разработчик, который его генерировал, уволился, а push‑уведомления
в Bing и Яндекс всё ещё идут через тот же файл a1b2c3.txt в корне сайта (см. Как сообщить Яндексу о новой странице через Вебмастер и IndexNow
). Знакомая картина почти на каждом втором сайте, который попадает к нам на аудит. Проблема не в самом факте «ключ старый» — проблема в том, что при неаккуратной замене вы на несколько дней теряете push‑сигналы, а при ошибке в процессе получаете 403/422 и временное урезание квоты на автоматическую индексацию. Ниже — рабочий алгоритм ротации без простоя, разбор типичных ошибок и что делать, если своего разработчика для этого нет.
Когда ротация обязательна, а не «было бы неплохо»
Три ситуации, при которых менять ключ нужно без раздумий:
- Ключ утёк. Проверить это несложно: вбейте в поиск по коду
site:github.com "ваш-домен.ru" indexnowилиfiletype:txt "ваш-домен" key, посмотрите логи сервера на запросы к эндпоинту/indexnowс IP вне диапазонов Bing и Яндекса. Если находите совпадения — ключ скомпрометирован, кто‑то может слать от вашего имени ложные сигналы об обновлении несуществующих страниц, что сжигает краулинговый бюджет и путает поисковик. - Сменился подрядчик или разработчик. Если человек с доступом к серверу и API‑ключам уволился или закончил контракт — ротация обязательна в течение недели, а не «когда-нибудь». Это база инфобезопасности, а не паранойя.
- Плановая гигиена. Раз в 6–12 месяцев поставьте себе напоминание в календаре (привяжите к квартальному security‑ревью инфраструктуры). Так вы не забудете и не будете делать это в панике после инцидента.
Технические требования к ключу — не любая строка подойдёт
По спецификации IndexNow ключ — строка из 8–128 символов, только латиница и цифры. Формально можно использовать что угодно в этих рамках, но на практике:
- Нельзя: домен сайта, дату (
20260718), простую последовательность (12345678), пароль от админки. - Можно и нужно: криптографически случайную строку. Проще всего сгенерировать так:
- Linux/Mac:
openssl rand -hex 16— получите 32‑символьный hex‑ключ за секунду. - Windows PowerShell:
-join ((48..57)+(97..102)|Get‑Random -Count 32|%{[char]$_}). - Через панель поисковика: в Bing Webmaster Tools в разделе IndexNow есть встроенный генератор — жмите «Generate Key», он сразу создаёт валидную строку.
- Linux/Mac:
Формат hex — самый распространённый, но не жёсткое требование протокола. Главное — случайность и отсутствие связи с доменом или датой.
Пошаговый алгоритм замены без потери сигналов
Главная ошибка — удалить старый файл ключа в момент, когда выкладываете новый. Поисковики кэшируют путь к ключу, и если бот верификации придёт, а нужного файла ещё нет (или он уже удалён) — получите отказ. Делайте так:
Шаг 1. Сгенерируйте и разместите новый файл, не трогая старый
Создайте файл <новый-ключ>.txt, где имя файла точно совпадает со значением ключа (например, 4f8a2c19b7e6d3f1a0c9b2e5d7f4a1c8.txt), внутри — тот же код. Загрузите в корень сайта рядом со старым. Проверьте доступность командой:
curl -IL https://ваш-домен.ru/4f8a2c19b7e6d3f1a0c9b2e5d7f4a1c8.txt
Ожидаемый ответ — HTTP/1.1 200 OK. Если видите 403 или 404 — файл закрыт в .htaccess/robots.txt или загружен не в корень, а в подпапку. Это нужно исправить до перехода к шагу 2.
Шаг 2. Обновите отправляющий код или плагин
- Кастомный скрипт: замените значение переменной
keyв теле запроса к https://www.bing.com/indexnow илиhttps://yandex.com/indexnow. - WordPress с плагином вроде RankMath/Yoast IndexNow‑модуля: зайдите в настройки плагина, поле «IndexNow API Key», вставьте новое значение, сохраните.
- Если используете
keyLocation— убедитесь, что параметр указывает на URL нового файла, а не старого.
Шаг 3. Продержите оба файла 48–72 часа
Это окно нужно, чтобы боты Bing и Яндекса, которые ещё не перепроверили владение, не получили отказ. Одновременно оба ключа валидны — старые сигналы в очереди на обработку не потеряются.
Шаг 4. Удалите старый файл только после подтверждения
Проверьте отчёт в Bing Webmaster Tools (раздел IndexNow → History) или Яндекс.Вебмастере — там должны появиться успешные приёмы с новым ключом. Только после этого можно удалять старый .txt.
Диагностика ошибок 403 и 422 — что конкретно смотреть
| Код | Типичная причина в вашем случае | Что делать |
|---|---|---|
| 403 Forbidden | Файл ключа закрыт в .htaccess или robots.txt (директива Disallow: /*.txt) | Откройте доступ к конкретному файлу, проверьте curl -IL, что отдаёт 200, а не редирект на страницу логина |
| 403 Forbidden | Ключ в запросе не совпадает с тем, что лежит в файле (опечатка при копировании) | Сверьте байт в байт значение в API‑запросе и содержимое файла — часто лишний пробел или перенос строки в конце файла |
| 422 Unprocessable Entity | Длина ключа вне диапазона 8–128 символов или недопустимые символы (кириллица, дефис) | Перегенерируйте ключ строго alphanumeric нужной длины |
| 422 Unprocessable Entity | keyLocation указывает на другой домен/поддомен, чем URL из тела запроса | Проверьте, что keyLocation и url в одном host — протокол требует совпадения хоста |
| Сигналы принимаются, но индексации нет | Ключ технически валиден, но это не гарантия индексации — IndexNow только ускоряет обход, не гарантирует включение в индекс | Проверяйте сам факт индексации отдельно, ключ тут ни при чём |
Если после исправлений ошибка повторяется — сверьтесь с актуальным разделом помощи в Bing Webmaster Tools или документацией Google Search Central по лимитам запросов в сутки: там же указаны текущие на 2026 год пороги по количеству URL в одном батче.
Типичный сценарий, из‑за которого теряют недели push‑сигналов
Частая история: команда меняет ключ, но забывает про keyLocation в конфиге кастомного скрипта — он продолжает указывать на старый файл, который уже удалили «для порядка» сразу после генерации нового. Внешне всё выглядит рабочим: скрипт шлёт запросы, ошибок в логе нет, но поисковик при верификации получает 404 по keyLocation и молча дропает сигналы без явного алерта на стороне сайта. Обнаруживается это только через 2–3 недели, когда новые страницы индексируются медленнее обычного, а в отчёте Bing Webmaster Tools по разделу IndexNow ноль принятых сигналов за период. Урок: после каждой ротации проверяйте не только доступность файла ключа, но и то, что URL в keyLocation физически совпадает с адресом, куда вы этот файл выложили — руками, через тот же curl -IL.
Как убедиться, что ротация прошла и сигналы реально доходят
Мало отправить пуш — нужно проверить, что URL из очереди действительно попадают в индекс. Если у вас не 5 страниц, а несколько сотен URL после ротации ключа, гонять их вручную через «Проверка URL» в Search Console нереально. Для массовой проверки статуса индексации по списку адресов удобно взять Rush Analytics — загружаете список URL, получаете отчёт по каждому: в индексе или нет, без ручного клика по каждому адресу.
Если своего разработчика для поддержки IndexNow‑инфраструктуры нет вообще и генерировать/ротировать ключи самостоятельно неудобно, разумная альтернатива — сторонние индексаторы, которые управляют собственными ключами на своей стороне: вы просто передаёте им список URL по API или через интерфейс, а протокол IndexNow обслуживают они. IndexNow и AI‑поиск — проверенные варианты — SpeedyIndex и IndexMeNow: оба берут на себя пуш‑уведомления в Bing и Яндекс, снимая с вас заботу о ротации и хранении ключа на сервере.
Чек‑лист ротации без потерь
- Проверили, что ключ действительно нужно менять (утечка / смена команды / истёк срок 6–12 мес)
- Сгенерировали новый ключ криптографически случайным способом (не дата, не домен, не
12345678) - Выложили новый
.txtрядом со старым, проверилиcurl -IL→ 200 - Обновили
keyиkeyLocationв скрипте/плагине, сверили host вkeyLocation - Продержали оба файла 48–72 часа
- Дождались подтверждения приёма сигналов с новым ключом в Bing Webmaster Tools / Яндекс.Вебмастере
- Только после этого удалили старый файл
- Не меняем ключ чаще, чем раз в несколько месяцев — ежедневная ротация создаёт лишнюю нагрузку на краулеры вместо пользы