IndexNow — это способ сказать поисковику «вот этот адрес изменился» в момент выкладки, не дожидаясь, пока робот дойдёт до страницы сам. Один HTTP-запрос, никакой авторизации, ключ лежит файлом в корне сайта. У нас он отправляется автоматически при каждом деплое, и вот что мы про него выяснили за неделю возни, включая ошибку, из-за которой три дня казалось, что ключ не работает.
Чем IndexNow отличается от карты сайта
Оба решают одну задачу — донести до робота новое на сайте, — но с разных сторон. Разница в том, кто делает первый шаг и по какому поводу: карта ждёт, когда за ней придут, уведомление уходит само и по конкретной правке.
| sitemap.xml | IndexNow | |
|---|---|---|
| Кто начинает | робот приходит сам | сайт отправляет сам |
| Что передаёт | весь список адресов | только изменившиеся |
| Когда сработает | когда робот дойдёт | сразу после запроса |
| Обратная связь | в Вебмастере, с задержкой | код ответа сразу |
Карта сайта — опись: 191 страница у нас на сегодня, каждая с датой последнего изменения. Робот сверяется с ней в своём темпе. IndexNow — это стук в дверь по конкретному поводу.
Одно другого не отменяет. Без sitemap.xml поисковик не узнает о страницах вне ссылок; без уведомлений правка на живой странице пролежит незамеченной неделями. Что такое карта сайта и как она устроена — в словаре, проверить свою можно бесплатной проверкой.
Как выглядит заявка
Минимальный вариант — обычный GET, его удобно запускать руками для проверки:
https://yandex.com/indexnow?url=https://example.ru/page/&key=<ключ>
Пакетный — POST с JSON, до 10 000 адресов за раз:
{
"host": "example.ru",
"key": "<ключ>",
"keyLocation": "https://example.ru/<ключ>.txt",
"urlList": ["https://example.ru/a/", "https://example.ru/b/"]
}
Ключ — произвольная шестнадцатеричная строка от 8 до 128 знаков. Владение доменом подтверждает файл: по адресу https://example.ru/<ключ>.txt отдаётся тот же ключ. Других процедур нет.
Что означают коды ответа:
- 200, 202 — принято, адреса встали в очередь;
- 403 — права на домен не подтверждены на стороне приёмника;
- 422 — ключ пока не прочитан с сайта или адрес не с того домена;
- 429 — слишком часто.
Отдельная грабля с ключевым файлом. У нас их какое-то время было два: второй завёлся по ошибке и остался лежать в public/. Скрипт брал первый по алфавиту и слал не тот ключ, который был указан в теле запроса. Ответ приходил осмысленный, заявка не работала. Ключ должен быть один.
Почему Bing отвечает 403 на исправный ключ
Самая дорогая по времени часть истории. Протокол задуман как общий: отправляешь на api.indexnow.org, он раздаёт участникам. На практике общий приёмник пересылает заявку в Bing и возвращает его отказ, если домен там не подтверждён.
Замер сегодня, 29 августа 2026, один и тот же адрес и один и тот же ключ на три приёмника:
yandex.com → 200
www.bing.com → 403
api.indexnow.org → 403
Тело ответа у Bing и у общего приёмника совпадает дословно:
{"errorCode":"UserForbiddedToAccessSite",
"message":"User is unauthorized to access the site.
Please verify the site using the key and try again"}
Отсюда два вывода. Первый: общий приёмник — не независимая инстанция, а прокси, его отказ о протоколе не говорит ничего. Второй, важнее: сообщение «verify the site using the key» вводит в заблуждение. Оно предлагает починить ключ, а ключ исправен: тот же ключ в ту же секунду принимает Яндекс, а файл https://nexforce.ru/<ключ>.txt отдаётся с кодом 200. Дело в неподтверждённом домене на стороне Bing.
Проверка, которая разводит эти два случая за пятнадцать секунд:
for host in yandex.com www.bing.com; do
curl -o /dev/null -w "$host %{http_code}\n" "https://$host/indexnow?url=<адрес>&key=<ключ>"
done
Яндекс 200 и Bing 403 — права в Bing. Оба 403 — смотреть на ключевой файл.
Честная часть: у нас Bing Webmaster подключён 22 августа импортом прав из Search Console, bingbot сайт обходит — 72 обращения в логах, — а IndexNow оттуда по-прежнему 403. Прошло 7 дней, ничего не изменилось. Поэтому наш скрипт шлёт напрямую на приёмник Яндекса, а Bing ждёт отдельной регистрации ключа.
Что считать изменившимся
Отправлять весь сайт при каждой выкладке нельзя — шум, поисковик его игнорирует. Значит, нужен ответ на вопрос «что изменилось с прошлого раза». У нас два способа, оба живут в репозитории.
По содержимому сборки. Скрипт обходит собранные страницы, считает по каждой хеш содержимого и сравнивает с сохранённым состоянием прошлой выкладки. Разошёлся хеш — адрес в отправку. Способ не знает про исходники и ловит любое изменение, включая случайное.
По изменённым файлам. Второй скрипт смотрит git diff с предыдущим коммитом и превращает пути в адреса: content/blog/*.md → /blog/<слаг>/ и так далее. Быстрее, но со слепым пятном, на котором мы обожглись: правка в общем модуле меняет десятки страниц, а в список не попадёт ни одна. Девять новых страниц однажды уехали на боевой, не сообщив о себе никому, — с тех пор такие адреса передаются явно.
Предохранитель. Если после пересборки «изменилось» больше 50% сайта, отправка пропускается. Почти всегда это правка шаблона или сбитое состояние, а не работа над страницами; слать такой пакет вредно. Нужно всё равно — отдельный флаг, осознанно. Первый запуск при пустом состоянии тоже молчит: иначе уедут все страницы разом.
IndexNow не заменяет очередь Вебмастера
Это два разных сигнала, и подменять один другим — ошибка, стоившая нам нескольких недель ожидания.
Первый из них — широковещательное уведомление. Его принимают несколько поисковиков, никакой очерёдности они не обещают и о судьбе конкретного адреса не отчитываются. Ответ 200 означает «получили», а не «поставили в план обхода».
Очередь переобхода в Яндекс.Вебмастере — именная заявка роботу на конкретный адрес. У неё квота 150 адресов в сутки, у каждой заявки есть идентификатор, и по нему видно, забрал робот страницу или нет. Что такое переобход и когда его заказывать — в словаре; остальные разделы Вебмастера, которые обычно пролистывают, разобраны в отдельной статье.
Поэтому после каждой выкладки у нас идут оба шага подряд: сначала IndexNow по изменившимся адресам, потом очередь Вебмастера по тем же. Один шаг дешёвый и без гарантий, второй с квотой и с обратной связью. Квота при этом не жмёт: 150 страниц в сутки на обычной выкладке не выбираются и наполовину — за раз меняются единицы адресов.
Чего IndexNow не делает
Ускоряет обход. Не ускоряет попадание в поиск.
Мы померили это на себе 10 августа: сравнили все страницы сайта с выборкой Вебмастера и искали отличия попавших в поиск от непопавших. Объём текста не объясняет ничего — у страниц вне поиска он местами даже больше. Входящие ссылки не объясняют ничего: у страниц в поиске их медиана 9, у страниц вне поиска — 12, то есть наоборот. Выборку разделил начисто только возраст. Восемь терминов словаря вне поиска оказались ровно теми восемью, что добавлены тем же утром; двадцать восемь, добавленных двумя днями раньше, были в поиске все до одного. Один шаблон, один автор, разница только в двух сутках.
Отсюда правило: судить о новой странице раньше 48 часов нельзя. IndexNow сокращает время до визита робота, а не время до решения о включении в поиск. Ждать позиций на следующее утро после отправки — способ потерять время и переписать нормальный текст.
Порядок для своего сайта
- Придумать ключ — шестнадцатеричная строка, 8–128 знаков. Подойдёт вывод
openssl rand -hex 16. - Положить файл
<ключ>.txtв корень сайта, внутри — тот же ключ. Убедиться, что он отдаётся с кодом 200 по прямой ссылке. - Проверить приёмники руками — одним GET на Яндекс и одним на Bing. Так вы сразу узнаете, где у вас подтверждены права, и не будете потом чинить исправный ключ.
- Слать только изменившееся. Нужен любой способ ответить «что поменялось» — хеши сборки или разбор коммита.
- Поставить предохранитель на массовую отправку, иначе одна правка шаблона однажды выльется в пакет из сотен адресов.
- Добавить второй сигнал — очередь переобхода в Вебмастере по тем же адресам.
- Не мерить результат раньше двух суток.
Первые четыре шага занимают 30 минут и делаются один раз. Дальше — строчка в скрипте выкладки, о которой можно не помнить.