Краулер не телепат. Пока поисковая система сама не заметит новую страницу или изменение старой, товар в каталоге может подешеветь, распродаться и исчезнуть со склада. Без подсказок робот узнаёт об этом через дни, а то и недели, потому что не обходит каждый адрес часто. Протокол IndexNow снимает паузу: сайт сам отправляет короткий сигнал о каждом изменении, а принявшие его поисковики ставят адрес в приоритетную очередь обхода. Механизм бесплатный, открытый и давно поддержан Яндексом и Bing, но вокруг него хватает заблуждений - от веры в мгновенную индексацию до страхов про штрафы. Ниже разобрано, как протокол устроен, где он приносит ощутимую пользу и как подключить его к сайту за один вечер.
Как работает протокол IndexNow и какие поисковики принимают уведомления
IndexNow появился в октябре 2021 года как совместная разработка Microsoft Bing и Яндекса, позже к протоколу присоединились Naver, Seznam и Yep, а уведомления принимает и краулер Amazon. Протокол открыт и распространяется по лицензии Creative Commons, поэтому любой поисковик может встроить его поддержку.
За время жизни вокруг протокола выросла инфраструктура. Глобальный endpoint принимает уведомления от любого сайта, у крупных поисковиков есть собственные адреса приёма, а файл ключа стал стандартом де-факто: ни регистраций, ни API-токенов, ни кабинетов - только текстовый файл в корне домена.
Логика простая. Вместо ожидания визита робота сайт отправляет обычный HTTP-запрос с адресом изменённой страницы. Дальше работает главная особенность протокола: уведомление, отправленное в один endpoint, автоматически передаётся всем участвующим поисковым системам. Отдельно "звонить" Яндексу, потом Bing, потом Seznam не нужно. Google в протоколе не участвует, и это принципиальный момент: для него остаётся классическая механика sitemap и Search Console.
Заявленная цель протокола - эффективность обеих сторон. Поисковик не тратит обход на страницы, где ничего не произошло, и быстрее находит реальные изменения. Владелец сайта не ждёт неделями переобхода важной карточки товара. Для Bing свежесть индекса имеет и прямое денежное измерение: их индекс лежит в основе AI-ответов, и устаревшая цена в таком ответе хуже, чем её отсутствие.
Масштаб стоит оценивать трезво. На большинстве русскоязычных сайтов основной поток поиска приносит Яндекс, и его участие делает интеграцию осмысленной уже само по себе. Bing добавляет англоязычный трафик и индекс, на котором строятся AI-сервисы Microsoft. Seznam закрывает чешский рынок, Naver - корейский. Если аудитория сайта не пересекается с этими системами, выгода ограничится запасом свежести контента.
Ключ подтверждения владения сайтом и коды ответов сервера протокола
Протоколу нужно убедиться, что уведомления отправляет владелец сайта, а не случайный желающий. Для этого служит ключ: строка от восьми до ста двадцати восьми символов из латинских букв, цифр и дефиса. Ключ кладут в корень сайта текстовым файлом с именем вида {ключ}.txt, и файл должен содержать ровно этот ключ без лишних символов. Поисковик при первом уведомлении скачивает файл и сверяет содержимое.
Сервер протокола отвечает стандартными кодами HTTP, и каждый код говорит о своей ситуации:
- код 200 подтверждает, что адрес принят и обработан;
- код 202 означает, что адрес получен, но ключ ещё проходит проверку;
- код 400 сигнализирует о сломанном формате запроса или неверном URL;
- код 403 приходит, когда ключ не найден или содержимое файла с ним не совпадает;
- код 422 возвращается, если адреса не принадлежат хосту из запроса;
- код 429 означает слишком частые отправки и подозрение на спам.
Первый вызов по свежему ключу обычно возвращает 202, это нормальная реакция, а не ошибка: после проверки файл начинает возвращаться со статусом 200. Адреса в запросе кодируют по стандарту RFC-3986, иначе парсер может отбросить часть URL. За один POST-запрос отправляют до десяти тысяч адресов, свыше протокол отвечает кодом 422.
У ключа есть расширенная схема: файл можно положить не в корень, а в конкретный каталог и указать его адрес параметром keyLocation. Тогда ключ действует только на адреса внутри этого каталога - удобно для крупных проектов, где разные разделы обслуживают разные команды. Ключ можно и сменить: достаточно положить новый файл, и поисковики при следующем уведомлении проверят его заново.
Реальная польза для страниц с частыми изменениями цен и остатков
Выгода концентрируется там, где контент живёт быстро. Интернет-магазин меняет цены и остатки несколько раз в день, маркетплейс публикует тысячи объявлений, доска объявлений удаляет закрытые лоты, новостной сайт правит заголовки и обновляет материалы. Каждая из этих ситуаций - законный повод для уведомления: протокол ждёт сигналы о добавленных, изменённых и удалённых страницах.
Удаление - отдельная сильная сторона. По протоколу стоит отправлять адреса, которые стали отдавать код 404 или 410, и страницы с редиректами 301 и 302: поисковик быстрее выкинет мёртвый адрес из выдачи и перенесёт сигналы на новое место. Для магазина с сотнями снимаемых с продажи позиций это ускоряет чистку индекса заметнее, чем любое ожидание.
Отдельный регламент существует для пользовательского контента - отзывов, комментариев, форумных веток. Чтобы не стрелять очередями по каждому новому отзыву, протокол советует отсылать уведомления порциями: каждый отзыв в первой двадцатке, затем каждый пятый до сотни и каждый десятый до тысячи. Между повторными сигналами по одному адресу выдерживают паузу не меньше пяти минут. Отправки идут в счёт общего краулингового бюджета, поэтому бессмысленный пинг по мелким правкам только сжигает ресурс.
Автоматизация должна отделять значимые правки от косметических. Скрипт, который отправляет адрес при каждом сохранении черновика, бесполезен и вреден: правка опечатки в описании и смена цены - события разного веса. Практичная схема - сравнивать контрольные поля (цена, остаток, заголовок, статус) и уведомлять только при реальном изменении. СМИ и блогам этого достаточно: черновики и технические правки в сигнал не попадают.
Показательный пример - доска объявлений. Новый лот появляется вечером и за ночь собирает просмотры из поиска, а лот после продажи должен исчезнуть из выдачи немедленно, иначе покупатель кликает по мёртвому адресу и теряет доверие к площадке. Обе задачи закрываются парой строк в обработчике публикации и снятия с продажи: адрес ушёл в IndexNow, и поисковики узнали об изменении в течение секунд.
Подключение к WordPress и другим CMS через готовые плагины
Прежде чем писать код, стоит проверить свой стек. Нативную поддержку или готовые модули имеют WordPress, Shopify, Wix, GoDaddy, Duda, XenForo, Milestone, Joomla, Drupal, Bitrix24, PrestaShop, MODX, Shopware, OpenCart, Typo3 и Umbraco. Сайты за Cloudflare получают интеграцию из коробки - достаточно включить отправку уведомлений в панели управления.
В экосистеме WordPress выбор зависит от SEO-плагина. Rank Math содержит модуль IndexNow прямо в бесплатной версии - он включается в разделе модулей и дальше работает сам: публикация, обновление или удаление записи автоматически порождают уведомление. Yoast SEO поддерживает протокол в версии Premium, уведомления уходят без ручных действий. AIOSEO предлагает аналогичную функцию в платных тарифах. Для самостоятельной установки в каталоге плагинов лежат и отдельные бесплатные решения, включая плагин от команды Bing Webmaster, появившийся в январе 2022 года.
Для Bitrix24, OpenCart и PrestaShop поддержка обычно ставится модулем из маркетплейса соответствующей платформы. Общий алгоритм везде одинаков: установить расширение, сгенерировать ключ, убедиться, что файл ключа доступен по прямому адресу, и наблюдать первые отправки в логе плагина.
Если ни плагина, ни модуля нет, протокол остаётся доступным любому сайту, потому что сводится к одному HTTP-запросу - редкий случай, когда отсутствие готового решения не означает неделю разработки. На shared-хостинге отправку вешают на хуки CMS или на cron-скрипт, который раз в несколько минут забирает изменённые адреса из таблицы очереди. Важно лишь не забыть про файл ключа: без него первый же запрос вернёт 403, и интеграция замрёт на этапе проверки.
Ручная отправка уведомлений через curl и скрипт на PHP
На самописном сайте вся интеграция занимает один файл. Сначала генерируют ключ и создают файл:
openssl rand -hex 32
echo -n "a1b2c3d4e5f6478890abcdef12345678" > /var/www/example.com/public/a1b2c3d4e5f6478890abcdef12345678.txtОдиночный адрес отправляют GET-запросом, адрес кодируется по стандарту:
curl "https://api.indexnow.org/indexnow?url=https%3A%2F%2Fexample.com%2Fcatalog%2Fproduct-42&key=a1b2c3d4e5f6478890abcdef12345678"Пачку адресов отправляют POST-запросом с JSON-телом:
curl -X POST "https://api.indexnow.org/indexnow" \
-H "Content-Type: application/json; charset=utf-8" \
-d '{"host": "example.com",
"key": "a1b2c3d4e5f6478890abcdef12345678",
"urlList": ["https://example.com/catalog/product-42",
"https://example.com/catalog/product-43"]}'В WordPress отправку вешают на хук сохранения записи:
add_action('save_post', function ($post_id) {
if (wp_is_post_revision($post_id) || get_post_status($post_id) !== 'publish') {
return;
}
$url = get_permalink($post_id);
$key = 'a1b2c3d4e5f6478890abcdef12345678';
wp_remote_post('https://api.indexnow.org/indexnow', [
'timeout' => 5,
'headers' => ['Content-Type' => 'application/json; charset=utf-8'],
'body' => wp_json_encode([
'host' => parse_url(home_url(), PHP_URL_HOST),
'key' => $key,
'urlList' => [$url]
])
]);
});В лог отправки стоит писать время, адрес, код ответа и число повторов: такой минимум позволяет увидеть, когда ключ перестал проходить проверку или когда сервер начал отвечать 429. Запросы к протоколу отправляют в один endpoint, глобальный или конкретного поисковика, дублировать по всем не нужно - рассылка участникам происходит на стороне протокола.
Отдельный сценарий - массовые обновления каталога. При пересчёте цен по десяткам тысяч карточек адреса не отправляют по одному, а складывают в очередь и гонят пачками по нескольку тысяч за запрос: так соблюдается регламент протокола, и нагрузка на собственный сервер остаётся предсказуемой.
Ограничения протокола и ожидания, которые IndexNow не оправдывает
Первое и главное: уведомление не гарантирует индексацию. Поисковик принимает сигнал, а дальше сам решает, обходить ли адрес, по своей квоте, расписанию и оценке качества. Одна и та же страница может быстро появиться в Яндексе и надолго зависнуть вне Bing - у каждого движка свои критерии.
Второе: протокол не влияет на ранжирование. Он ускоряет знакомство поисковика с изменением, но позиции страницы определяются содержимым и ссылками. Покупать "ускорение индексации" как SEO-услугу имеет смысл только в связке с реальными улучшениями контента.
Третье: у протокола есть границы применения. Поддомен считается отдельным хостом со своим ключом. Языковые версии отправляют по отдельности, с корректными canonical и hreflang. Ретроспективно заливать весь сайт бессмысленно - протокол создан для изменений после подключения, а для полного списка адресов существует sitemap с честным lastmod. Полная выгрузка оправдана один раз, например после переезда сайта.
Четвёртое ограничение психологическое: протокол не заменяет работу с индексацией в целом. Если сайт закрыт от обхода, страдает от дублей или отдаёт медленные ответы, уведомления лишь быстрее доставят робота к проблемной странице. IndexNow усиливает здоровую индексацию, а не лечит больную.
Проверить эффект можно без специальных утилит: в Яндекс Вебмастере работает история обхода с датами визитов робота по конкретным адресам, в Bing Webmaster Tools видна статистика отправленных уведомлений. Если после отправки адрес действительно посещается быстрее, интеграция делает свою работу. Итог получается скромным, но честным: IndexNow - не волшебная кнопка, а надёжный экспресс-канал для свежих изменений, который отлаживается за вечер и дальше просто работает.