Экспертиза

Ротация ключа IndexNow без потери push-сигналов

Ротация ключа IndexNow без потери push-сигналов
Содержание

Ротация ключа IndexNow — это процесс замены идентификатора безопасности, используемого для аутентификации push-уведомлений о новом контенте в поисковых системах. Процедура необходима для предотвращения несанкционированных запросов от имени владельца ресурса. Чтобы избежать потери сигналов и ошибок 403 или 422, замену проводят методом «мягкого переключения», сохраняя доступность старого ключа до полной верификации нового поисковыми ботами Bing и Яндекса.

Когда возникает необходимость в ротации ключа

Безопасность протокола IndexNow строится на владении секретным ключом, который размещается в корневом каталоге сайта. Существует три основных сценария, требующих генерации нового идентификатора.

  1. Компрометация ключа. Если файл ключа или сам код символьной последовательности попал в публичный репозиторий (например, GitHub), сторонние лица могут отправлять ложные сигналы об обновлении страниц. Это перегружает краулинговый бюджет и вводит поисковые системы в заблуждение.
  2. Кадровые изменения. При смене SEO-команды, веб-разработчиков или подрядчиков, имевших доступ к API-ключам и серверной части сайта, ротация является обязательным элементом гигиены информационной безопасности.
  3. Плановая проверка. Рекомендуется обновлять ключи раз в 6–12 месяцев. Это минимизирует риски использования устаревших протоколов доступа и гарантирует актуальность настроек в Search Console или Яндекс.Вебмастере.

Технические требования к структуре ключа

Согласно спецификации IndexNow, ключ должен представлять собой строку длиной от 8 до 128 символов. Допускается использование только латиницы и цифр (alphanumeric). Наиболее распространенный формат — шестнадцатеричный (hex), однако это не является жестким правилом.

Основное требование — криптографическая случайность. Недопустимо использовать в качестве ключа название домена, простые даты или последовательности вроде 12345678. Для генерации следует использовать системные инструменты вроде /dev/urandom в Linux или специализированные генераторы в интерфейсах поисковых систем (например, в инструментах Bing Webmaster Tools).

Алгоритм безопасной замены ключа

Главная ошибка при ротации — мгновенное удаление старого ключа и замена его на новый. Поисковые системы кэшируют местоположение ключа. Если отправить запрос с параметром нового ключа, а бот верификации придет на сайт и не обнаружит соответствующий .txt файл (или обнаружит старый), запрос будет отклонен.

Шаг 1: Генерация и размещение нового файла

Создайте новый ключ. Сформируйте текстовый файл, название которого совпадает со значением ключа, например new-secret-key-123.txt. Внутри файла должен находиться этот же текстовый код. Загрузите файл в корневой каталог сайта. Важно: старый файл ключа должен оставаться на сервере.

Шаг 2: Обновление системы отправки

Измените параметры в вашем скрипте, плагине (например, для CMS WordPress) или модуле, который инициирует HTTP-запросы к эндпоинтам https://www.bing.com/indexnow или https://yandex.com/indexnow. В API-запросе обновите параметр key на новое значение. Если вы используете параметр keyLocation, убедитесь, что он указывает на новый URL.

Шаг 3: Период сосуществования

В течение 48–72 часов на сервере должны находиться оба файла ключей. Это обеспечит бесперебойную обработку сигналов, если часть запросов в очереди ПС все еще связана со старым идентификатором или если боты Bing и Яндекса проводят повторную проверку прав собственности.

Шаг 4: Удаление устаревших данных

После того как отчеты в Bing Webmaster Tools или Яндекс.Вебмастере подтвердят успешный прием сигналов с использованием нового ключа, старый .txt файл можно удалить. Это завершает цикл безопасной ротации.

Диагностика ошибок 403 и 422

Если ротация проведена некорректно, серверы API IndexNow вернут стандартные коды ошибок:

  • HTTP 403 (Forbidden): Возникает, если ключ не соответствует тому, что поисковая система ожидает увидеть. Это часто случается при опечатках в параметрах запроса или если файл ключа недоступен для скачивания (например, закрыт в .htaccess или robots.txt).
  • HTTP 422 (Unprocessable Entity): Означает, что формат ключа неверен (слишком короткий/длинный) или возникло временное рассогласование между отправленным сигналом и файлом верификации на сервере.

Для проверки корректности текущего ключа рекомендуется обращаться к официальной документации Google Search Central или разделам помощи Bing, где описаны актуальные лимиты на количество запросов в сутки.

Чего нельзя делать при ротации

Критическая ошибка — одновременное удаление старого файла и включение нового ключа в коде. В этом случае возникает «окно недоступности». Любой сигнал, отправленный в момент, когда поисковый робот еще не просканировал новый проверочный файл, приведет к ошибке верификации. Частое получение ошибок 4xx может привести к временному снижению квоты (quota) на автоматическую индексацию вашего домена.

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

Связанные термины