IndexNow: как сообщать поисковикам об изменении страниц и проверять отправку
Чтобы настроить IndexNow, нужно связать публикацию изменений с отправкой URL, разместить файл проверки на нужном хосте и обрабатывать ответы API. Успешный HTTP-ответ подтверждает приём уведомления, а не появление страницы в поиске. Надёжная интеграция также сохраняет неотправленные изменения, различает временные отказы и ошибки настройки, учитывает удаление страниц.
Ниже — практическая схема для действующего сайта. Адреса страниц на example.com, ключ, объёмы очереди и интервалы повторов в примерах учебные. Запросы приведены для объяснения формата; это не результаты реальной отправки.
1. Определите, кому и о чём вы сообщаете
В актуальном FAQ IndexNow перечислены Amazon, Bing, Naver, Seznam.cz, Яндекс и Yep. Google в этом перечне отсутствует: рассчитывать на его уведомление через описанную схему нельзя. Участники обмениваются полученными URL, поэтому не требуется создавать отдельный одинаковый поток отправки каждому из них.
Для общей точки приёма используется https://api.indexnow.org/indexnow. Можно выбрать и документированный endpoint участника. Это адрес API, которому направляют уведомление; не путайте его с адресом изменившейся страницы вашего сайта. Выбранный вариант сохраните в конфигурации отправителя, чтобы журнал позволял понять, куда ушёл запрос.
Bing отдельно предупреждает: IndexNow не гарантирует последующий обход или индексирование. Разделите три состояния: изменение опубликовано, уведомление принято, результат отражён поисковой системой. Между ними нет обещанного универсального срока. Если API ответил 200, но страница не появилась в выдаче, многократная отправка того же адреса не доказывает и не устраняет причину.
2. Отправляйте реальные изменения после публикации
Яндекс рекомендует сообщать о новых, изменившихся и удалённых страницах, а не отправлять весь старый архив при подключении. Для интернет-магазина полезными событиями могут быть публикация карточки, изменение содержательного описания, цены или наличия, окончательное удаление материала. Список событий должен соответствовать тому, что действительно меняется по публичному URL.
Не привязывайте отправку к каждому нажатию «Сохранить черновик». Редактор может несколько раз поправить текст до публикации; поисковику пока нечего перечитывать. Событие должно возникать после успешного сохранения и выхода нужной версии на публичный сайт. Если CDN ещё показывает старую копию, сначала завершите предусмотренное обновление кеша.
Перед собственной разработкой проверьте, не отправляет ли уведомления уже установленный модуль CMS или платформа. Два независимых отправителя легко превращают одно изменение в несколько одинаковых запросов. Назначьте один основной механизм и владельца его настроек; при замене интеграции согласуйте передачу накопленных событий.
Не включайте в поток личные кабинеты, черновики, ссылки с пользовательскими токенами и другие непубличные адреса. Отбор выполняется до формирования пакета. Сам факт появления URL в базе ещё не означает, что он предназначен для уведомления поисковых систем.
Одно изменение данных иногда затрагивает несколько публичных адресов. В учебном магазине новая цена появилась в карточке и в выдаче категории, а текст инструкции остался прежним. Определите зависимые страницы по фактическому содержимому, а не отправляйте весь сайт вслед за любым изменением товара. Для каждой группы событий зафиксируйте правило отбора. Это помогает редактору понять, почему уведомление возникло, а разработчику — проверить, что важная связанная страница не пропущена и лишние адреса не добавлены.
3. Подготовьте отдельный IndexNow key
По требованиям Яндекса к ключу допустимы 8–128 символов из a-z, A-Z, 0-9 и дефиса. Файл должен содержать текст ключа в UTF-8 без HTML-разметки. Для корневого размещения имя имеет вид {key}.txt.
Учебный ключ ниже содержит 32 символа. Для своего сайта создайте собственное случайное значение:
0123456789abcdef0123456789abcdefЕго корневой файл в примере расположен по адресу https://example.com/0123456789abcdef0123456789abcdef.txt. В ответе должен находиться именно текст ключа, а не страница CMS, экран входа или сообщение защитного сервиса.
Это специальный ключ проверки владения: файл размещается на сайте и должен читаться поисковиком без авторизации. Не подставляйте вместо него секретный токен платёжного сервиса, облачного аккаунта или другого API. При этом доступность файла не означает, что значение стоит распространять в публикациях и общих журналах: документация советует ограничивать сведения о ключе и его расположении.
Проверьте файл из внешней сети без входа в административную панель. Затем сравните его содержимое со значением в настройках отправителя. Успешное открытие у разработчика с сохранённой сессией ещё не подтверждает доступность для поисковика.
Проверка файла должна учитывать тело ответа. В учебном сбое правило приложения возвращает HTML главной страницы для любого неизвестного пути, включая имя ключа. Браузер получает 200, но проверочного значения в нужном виде нет. Сравните конечный адрес, содержимое ответа и настройки маршрута файла. Если файл выдаёт CDN, убедитесь, что там уже появилась нужная версия; локальное наличие файла на сервере ещё не доказывает, что именно её получает внешний запрос.
4. Согласуйте хост и область keyLocation
Документация протокола разрешает альтернативное размещение файла на том же хосте с передачей keyLocation в каждом уведомлении. При размещении внутри каталога область ключа ограничивается соответствующим путём. Корневое размещение обычно проще для сайта с несколькими разделами.
Например, файл https://example.com/catalog/indexnow-key.txt подходит для адресов внутри https://example.com/catalog/, но не подтверждает область https://example.com/help/. Сам параметр keyLocation не расширяет полномочия: он лишь сообщает, где находится проверочный файл.
Хосты с www и без него также нельзя смешивать по привычке. Для поддоменов Яндекс предусматривает отдельные ключи; заведите для каждой области собственную конфигурацию и очередь отправки. При переносе на новый хост пересмотрите эти настройки вместе с публикацией страниц.
В журнале полезно сохранять имя конфигурации ключа, хост и путь файла. Тогда ошибка одного раздела не приведёт к бесцельной замене ключа всего сайта. Не меняйте ключ при каждом повторе запроса: это создаёт новые проверки вместо исправления исходного несоответствия.
5. Проверьте одиночную отправку
Для одного адреса используется GET с параметрами url и key; при альтернативном расположении файла добавляют keyLocation. Ниже учебный запрос к общей точке приёма. Он относится к корневому файлу ключа из предыдущего примера:
GET /indexnow?url=https%3A%2F%2Fexample.com%2Fcatalog%2Flamp-a&key=0123456789abcdef0123456789abcdef HTTP/1.1
Host: api.indexnow.orgЗначение url здесь закодировано как параметр внешнего запроса. Особенно внимательно обрабатывайте адреса с собственными параметрами: их знак амперсанда не должен случайно стать разделителем параметров IndexNow. Используйте стандартный построитель URL в выбранном языке вместо ручного соединения строк.
Для первой проверки выберите действительно опубликованный изменившийся материал. Запишите адрес, время, конфигурацию ключа, HTTP-код и полезное сообщение ответа. Не проверяйте интеграцию отправкой случайного чужого URL: такой результат не подтвердит работоспособность вашей области.
Различайте ответ endpoint IndexNow и ответ страницы. Код 403 от API относится к обработке уведомления; код 403 от проверочного файла или самой страницы относится к доступу к вашему сайту. Эти наблюдения могут быть связаны, но требуют разных исправлений.
6. Соберите корректный пакет URL
Для пакета отправляют POST с Content-Type: application/json; charset=utf-8. Протокол допускает до 10 000 URL за запрос. Это верхняя граница размера пакета, а не рекомендация ждать накопления десяти тысяч изменений или гарантия допустимой частоты запросов.
Учебное JSON-тело с тремя адресами:
{
"host": "example.com",
"key": "0123456789abcdef0123456789abcdef",
"keyLocation": "https://example.com/0123456789abcdef0123456789abcdef.txt",
"urlList": [
"https://example.com/catalog/lamp-a",
"https://example.com/guides/lamp-care",
"https://example.com/archive/old-offer"
]
}В host находится имя хоста без схемы и пути. В urlList — массив полных адресов этого хоста. Для JSON не нужно превращать весь адрес в строку вида https%3A%2F%2F..., как значение внешнего GET-параметра: сериализатор должен сформировать корректные JSON-строки с самими URL.
Перед отправкой проверьте структуру, непустой список, область ключа и отсутствие дублей в пакете. Условный перечень из 10 001 адреса уже превышает лимит; разделите его заранее. Не рассчитывайте на то, что получатель автоматически обработает допустимую часть ошибочного тела.
7. Обрабатывайте ответы 200, 202, 400, 403, 422 и 429
Основные значения определены в протоколе; справочник API Яндекса дополнительно раскрывает причины ошибок параметров. Сохраняйте код вместе с пояснением конкретного endpoint: одинаковый класс ответа не заменяет диагностику.
| Код | Что означает | Действие отправителя |
|---|---|---|
| 200 | Уведомление успешно получено | Зафиксировать приём отправленной версии |
| 202 | URL получен, проверка ключа ожидается | Сохранить отдельное состояние ожидания |
| 400 | Некорректный формат запроса | Исправить формирование тела или параметров |
| 403 | Ключ не подтверждён или не подходит | Проверить файл, содержимое и доступ |
| 422 | Нарушена схема или область URL | Проверить host, keyLocation, ключ и список |
| 429 | Слишком частые обращения | Приостановить поток и снизить частоту |
Для IndexNow ошибка 403 или 422 — повод разобрать данные до повтора. В Яндексе 422 также встречается при неверной длине ключа, отсутствующих полях и превышении размера списка. Бесконечная переотправка неизменного тела только воспроизводит неисправность.
Не записывайте 202 как «страница проиндексирована» или окончательно подтверждённый ключ. Проверьте конфигурацию и дождитесь последующих наблюдений с разумной паузой. Если ожидание затянулось, создайте задачу на проверку; не запускайте непрерывный опрос одним и тем же адресом.
8. Свяжите очередь с жизненным циклом страницы
Практичная схема начинается с надёжной записи события после изменения публичного состояния. Отправитель забирает накопленные URL отдельно от редакторского запроса. Недоступность внешнего API тогда не должна превращать обычное сохранение материала в долгую операцию, а событие не теряется после закрытия страницы редактором.
Для записи достаточно URL, хоста, внутренней версии изменения, времени публикации, состояния доставки, числа попыток и времени следующей попытки. Причину «добавлено», «изменено» или «удалено» храните для собственного разбора. В показанном API передаётся сам URL, без отдельного поля команды удаления.
Объединяйте несколько ожидающих изменений одного адреса до отправки, сохраняя его последнее публичное состояние. Но не подавляйте этот URL навсегда: после следующего существенного изменения он снова должен попасть в поток. Дедупликация относится к накопленному состоянию доставки, а не ко всей истории страницы.
Учтите конкуренцию: пока отправляется версия 7, редактор публикует версию 8. Подтверждение отправки версии 7 не должно удалить из очереди новое событие. Отмечайте обработанной именно отправленную версию, оставляя более свежую ожидающей. Иначе интеграция выглядит успешной в журнале, но систематически пропускает изменения.
Продумайте момент записи события. Если задание создаётся до завершения сохранения, оно может описывать изменение, которое затем отменилось. Если событие записывается отдельным ненадёжным действием после сохранения, авария между двумя шагами способна его потерять. Разработчику нужен согласованный способ фиксировать изменение и намерение отправки, например запись события в той же транзакции, когда архитектура это допускает. После восстановления обработчик продолжит работу по сохранённым записям, а не будет пытаться угадать пропуски по времени последнего запуска.
9. Проверьте очередь на учебной арифметике
За час в условном магазине возникли следующие события. Три группы URL не пересекаются:
| Группа | События | Уникальные URL |
|---|---|---|
| Новые страницы | 60 | 60 |
| Повторные изменения существующих страниц | 210 | 90 |
| Удалённые страницы | 30 | 30 |
| Всего | 300 | 180 |
После объединения ожидающих изменений остаётся 180 URL вместо 300 событий. Исключены 120 повторных включений, то есть 40% первоначального числа. Это уменьшение количества уведомляемых позиций в нашей очереди, а не измеренная экономия обхода поисковика.
Выберем локальный размер пакета 100 URL. Получатся два запроса: 100 и 80 адресов. Первый вернул 200, второй завершился таймаутом. Не ставьте второму отметку «не доставлено»: запрос мог быть принят, а ответ потерян. После предусмотренной паузы повторяется только неопределённый пакет из 80 адресов.
Если повтор получил 200, журнал содержит три попытки и 260 включений URL: 100 + 80 + 80. Уникальных адресов по-прежнему 180. Сколько уведомлений получатель успел принять до таймаута, из этих данных неизвестно. Такая запись честнее, чем отчёт «отправили 260 новых страниц».
10. Ограничьте повторы и контролируйте частоту
Ошибки формата и области отправляйте на разбор, временные сетевые отказы — в отложенный повтор. При 429 учитывайте Retry-After, если получатель его вернул. Не предполагайте одинаковые ограничения у всех участников. Яндекс рекомендует при необходимости повторной отправки одного URL выдерживать десятиминутную паузу.
Учебная локальная политика для временных ошибок: после первой попытки не более трёх повторов с паузами 10, 30 и 90 минут. Более длительное указание получателя имеет приоритет. Значения выбирает команда под свою интеграцию; они не являются обещанием API или способом обходить ограничение.
После исчерпания попыток сохраняйте событие и причину для ручного разбора. Не удаляйте его молча и не оставляйте в бесконечном цикле. Для массовой ошибки ключа остановите соответствующую конфигурацию, иначе тысячи URL породят одинаковые неудачные обращения.
При возобновлении сначала проверьте небольшой пакет, затем постепенно обработайте накопившееся. Если у страницы за время ожидания появилась новая версия, отправляйте актуальное состояние очереди. Не воспроизводите каждое промежуточное редакторское действие как отдельное уведомление.
11. Сохраните уведомления об удалениях
Яндекс допускает уведомления об адресах, возвращающих 404, 410 и перенаправления. Не отбрасывайте удалённый URL только потому, что проверка успешной страницы требует 200. Для удаления ожидаемый HTTP-ответ другой, а сообщение поисковику относится к прежнему публичному адресу.
Сохраните URL события до удаления записи из CMS либо вместе с записью факта удаления. Иначе фоновый обработчик получит идентификатор объекта, которого больше нет, и не узнает, какой адрес передавать. Поле причины поможет отличить штатное удаление от случайного сбоя маршрута.
Не обозначайте временный 503 как удаление. И наоборот, сообщение через IndexNow не исправит сайт, который после удаления продолжает выдавать старое содержимое или общую заглушку с 200. Сначала обеспечьте предусмотренный ответ публичного URL, затем отправьте уведомление об изменении.
Если материал перенесён, сохраняйте согласованные перенаправления и уведомляйте об изменившихся адресах по принятой схеме. IndexNow не заменяет сам редирект и не гарантирует мгновенное исчезновение прежнего результата из поиска.
12. Принимайте интеграцию по доставке и наблюдаемым результатам
Для проверки настройте несколько разрешённых публичных случаев: новую страницу, обновление, удаление, повторный запуск обработчика и временный отказ доставки. Убедитесь, что черновик не создаёт отправку, свежая версия не теряется, а ошибка настройки останавливает повторы до исправления.
В журнале связывайте событие с пакетом и ответом: URL, версия, время, endpoint, номер попытки, код, краткая причина и следующее действие. Для ключа обычно достаточно идентификатора конфигурации. Не считайте число строк журнала числом уникальных страниц и не называйте принятые уведомления проиндексированными URL.
Bing предлагает проверять получение адресов через инструменты вебмастера. Состояние в поиске исследуйте отдельно от HTTP-приёма: пригодность страницы к обходу, её фактическое содержимое и решения поисковой системы лежат за пределами подтверждения доставки. Успешная настройка даёт управляемый канал сообщений об изменениях, без гарантии позиции или срока индексации.
Для ежедневного контроля полезны возраст самого старого ожидающего события, число ошибок по причинам и количество уникальных URL с подтверждённым приёмом. Резкий рост повторов при неизменном числе публикаций требует разбора отправителя. Владелец интеграции должен знать, где находятся остановленные события и как их вернуть после исправления. При смене CMS, домена или защитных правил повторите проверку ключа и небольшой контрольный сценарий: прежний успешный запуск не подтверждает новую конфигурацию.
Подключите SiteGuard для внешнего контроля HTTP-доступности важных страниц. Доставку IndexNow и состояние индекса проверяйте отдельно.