IndexNow: мгновенная индексация страниц

Классическая схема обхода устроена так: вы что-то поменяли на сайте и ждёте, пока робот сам догадается зайти. Ждать можно от нескольких часов до нескольких недель — в зависимости от того, насколько поисковик считает ваш сайт важным. IndexNow переворачивает эту логику: вместо ожидания вы отправляете поисковой системе HTTP-запрос «вот эти адреса изменились, приходите». Протокол открытый, бесплатный, поддерживается Яндексом и Bing, внедряется за час и не требует ни модерации, ни квот в привычном смысле. При этом вокруг него накопилось столько мифов — от «это ускоряет индексацию в десять раз» до «это вообще не работает», — что разбираться приходится с нуля. В этой статье: как устроен протокол, как правильно поставить ключ, чем отправка отличается от переобхода в Вебмастере, как автоматизировать процесс и на каких ошибках теряют весь эффект. Всё в контексте практической работы по SEO-продвижению сайтов.

Что такое IndexNow и какую проблему он решает

Стандартная модель работы поисковой системы — pull: робот сам решает, какие URL и как часто обходить. Он опирается на историю сайта, частоту обновлений, ссылочные сигналы, данные из sitemap.xml и десяток внутренних эвристик. Владелец сайта в этой схеме — пассивная сторона. Он может подсказать (картой сайта, перелинковкой, lastmod), но не может сказать «зайди сюда сейчас».

IndexNow добавляет к этому push-канал. Вы отправляете простой HTTP-запрос на публичный эндпоинт и передаёте список изменившихся адресов. Поисковик получает сигнал в момент изменения, а не через несколько дней, когда до вашей страницы дойдёт очередь. Протокол был анонсирован Microsoft и Яндексом как открытый стандарт, и его спецификация намеренно сделана примитивной — ни OAuth, ни токенов с истечением срока, ни SDK. Подтверждение владения сайтом реализовано через файл с ключом в корне домена: если вы смогли положить туда файл, значит домен ваш.

Экономический смысл для поисковика очевиден: обходить сайты вслепую дорого. Если владелец сам сообщает, где произошли изменения, робот не тратит запросы на проверку неизменившихся страниц. Это прямая экономия краулингового бюджета — причём обоюдная: и поисковик экономит ресурсы, и ваш сервер получает меньше бессмысленных обращений.

IndexNow не заставляет робота проиндексировать страницу. Он сокращает время между «изменилось» и «робот узнал». Всё, что происходит дальше, — обычный конвейер отбора, где решают качество контента, дубли и приоритеты.

Три сценария, где выигрыш максимален

Протокол даёт разный эффект в зависимости от типа проекта. Больше всего он помогает там, где контент часто меняется и где ценность страницы быстро тает:

• Интернет-магазины с живым ассортиментом. Изменилась цена, появилось наличие, добавилась новая карточка — робот узнаёт об этом в тот же день, а не через две недели. Для e-commerce это напрямую конвертируется в актуальный сниппет и корректные данные о товаре в выдаче. Подробнее о специфике — в материале про SEO для интернет-магазина.
• Новостные разделы и блоги с высокой частотой публикаций. Здесь счёт идёт на часы: материал, попавший в индекс на второй день, теряет большую часть возможного трафика.
• Крупные каталоги с сотнями тысяч URL. На таких проектах полный цикл обхода растягивается на недели. Точечное уведомление позволяет вытащить конкретные изменившиеся страницы из общей очереди, не дожидаясь, пока робот доберётся до них по обычному расписанию.

И обратная сторона: если у вас корпоративный сайт на 40 страниц, которые меняются раз в квартал, IndexNow не изменит вашу жизнь. Он не повредит, настроить его стоит, но ожидать роста позиций от него не нужно — робот и так успевает обходить такой сайт целиком.

Кто реально поддерживает протокол

Это первый вопрос, на котором большинство статей даёт неточный ответ. Разберём честно.

Важнейшая техническая деталь протокола: достаточно отправить уведомление на один эндпоинт. Участники обмениваются полученными списками между собой. То есть отправка на общий адрес api.indexnow.org доставит сигнал и в Яндекс, и в Bing, и в остальные системы-участники. Дублировать один и тот же список по всем адресам не нужно и вредно — вы просто увеличиваете нагрузку и рискуете нарваться на ограничение по частоте.

При этом на практике мы часто настраиваем отправку напрямую на эндпоинт Яндекса для проектов, ориентированных исключительно на рунет: так короче цепочка и проще диагностировать проблемы. Для Google параллельно работают традиционные инструменты — корректный sitemap.xml с честным lastmod и Google Search Console. О различиях в подходах двух систем мы писали в отдельном материале про SEO под Google.

Как устроен протокол: ключ, файл, эндпоинт

Ключ

Ключ — произвольная строка длиной от 8 до 128 символов. Допустимы латинские буквы в любом регистре, цифры и дефис. Никакой криптографии за ним не стоит: это просто общий секрет, доказывающий, что отправитель имеет доступ к файловой системе сайта. Практика — брать UUID без дефисов или 32-символьную hex-строку; читаемых слов лучше избегать, чтобы ключ нельзя было подобрать перебором.

Файл с ключом

Файл называется {ключ}.txt и содержит ровно тот же ключ обычным текстом. То есть если ключ — a1b2c3d4e5f60718293a4b5c6d7e8f90, то по адресу https://site.ru/a1b2c3d4e5f60718293a4b5c6d7e8f90.txt должна открываться страница с этим же значением внутри. Требования к файлу:

• Код ответа 200, без редиректов на пути.
• Тип содержимого text/plain. HTML-обёртка от CMS или JSON недопустимы — некоторые движки любят отдавать «красивую» страницу вместо простого текста.
• Содержимое — только ключ. Ни BOM, ни лишних строк, ни комментариев.
• Доступность по тому же протоколу и хосту, что и отправляемые URL. Для https-сайта — обязательно https. О том, почему протокол вообще должен быть один, — в статье про переход на HTTPS.
• Файл не должен быть закрыт в robots.txt. Это редкая, но убийственная ошибка на сайтах с агрессивным Disallow для корневых txt-файлов.

Область действия ключа

По умолчанию файл кладётся в корень, и тогда ключ авторизует любые URL этого хоста. Спецификация допускает разместить файл в подкаталоге и передать его адрес в параметре keyLocation — но тогда ключ действителен только для URL внутри этого каталога. Это удобно, когда разными разделами сайта управляют разные команды: каждой выдаётся свой ключ со своей зоной ответственности, и разработчики одного раздела не могут случайно отправить уведомления по всему домену.

Отдельно про поддомены: каждый хост — отдельная сущность. Файл ключа на site.ru не авторизует URL на shop.site.ru. Если у вас региональная сетка поддоменов, ключевой файл нужно раскатать на каждый из них. То же касается пары «с www» и «без www» — формально это разные хосты, и хотя один из них обычно редиректит на другой, файл лучше сделать доступным на обоих. Логика выбора структуры разбиралась в материале про поддомены или подпапки.

Пошаговое внедрение

Два способа отправки: GET и POST

Протокол предусматривает две формы запроса. Выбор между ними определяется тем, сколько URL вы отправляете за раз.

GET — один URL

Простейший вариант: обычная ссылка вида https://api.indexnow.org/indexnow?url=https%3A%2F%2Fsite.ru%2Fpage%2F&key=ВАШ_КЛЮЧ. Отправляемый адрес обязан быть URL-энкодирован, иначе параметры «поедут» на первом же амперсанде или кириллическом символе. Такой формат удобен для отладки, для точечных отправок и для встраивания в простые CMS-хуки.

POST — до 10 000 URL за раз

Для пакетной отправки используется POST с JSON-телом и заголовком Content-Type: application/json; charset=utf-8. Структура тела:

Все URL в одном POST-запросе обязаны принадлежать хосту, указанному в поле host. Если вы управляете сетью поддоменов, каждому нужен свой запрос со своим host и своим ключом. Лимит в 10 000 адресов на запрос щедрый, но не воспринимайте его как приглашение отправлять по 10 000 URL ежедневно — об этом ниже, в разделе про подводные камни.

Коды ответа: читаем то, что вернул сервер

Интеграция, которая не проверяет коды ответа, — это интеграция, которая рано или поздно молча перестанет работать. Разбор возможных ответов:

Про 429 стоит сказать отдельно. Формальных публичных лимитов частоты протокол не декларирует, но защита от злоупотреблений на стороне поисковика есть, и она реагирует не только на число запросов в секунду, но и на осмысленность отправок. Разумная схема для большинства проектов: агрегировать изменения и отправлять пакетом раз в 5–15 минут, а не дёргать API на каждое сохранение записи. При получении 429 — не повторять запрос немедленно, а откладывать с удвоением интервала.

IndexNow против переобхода в Вебмастере: в чём разница

Это главный источник путаницы. У Яндекса есть инструмент «Переобход страниц» в Яндекс.Вебмастере, есть API Вебмастера с той же функцией, и есть поддержка IndexNow. Все три канала делают формально похожую вещь — просят робота зайти на URL, — но живут по разным правилам.

Практический вывод: это не конкуренты, а слои одной системы. Sitemap — фундамент, который обязан быть корректным всегда. IndexNow — постоянный автоматический поток уведомлений об изменениях. Переобход в Вебмастере — ручной инструмент для единичных срочных случаев, и его суточную квоту разумно беречь именно для них, а не расходовать на рутину. Если у вас настроены все три канала и вы всё равно жалуетесь на медленную индексацию, проблема не в каналах доставки, а в самом сайте — разбор причин мы собрали в статье про индексацию сайта в Яндексе.

Отдельно про Google: у него есть Indexing API, но он официально предназначен только для страниц с разметкой вакансий и трансляций. Использовать его как универсальный ускоритель индексации нельзя — это прямое нарушение условий использования. Для Google остаётся классика: чистая структура, быстрая отдача сервера, честный lastmod и внутренние ссылки на новые страницы с часто обходимых узлов.

Что отправлять, а что не отправлять

Список отправляемых URL — не «все страницы сайта», а «страницы, которые действительно изменились и должны быть в индексе». Эта дисциплина определяет, будет ли поисковик доверять вашим уведомлениям.

Отдельная дисциплина — неканонические адреса. Если страница доступна по нескольким URL, отправлять нужно только канонический вариант. Уведомление о неканоническом адресе не приведёт к его индексации, но добавит вам мусора в статистике, а роботу — бессмысленных обходов. Механику разбирали в статье про canonical и дубли страниц.

Автоматизация: как это делают на реальных проектах

Архитектура интеграции

Правильная интеграция — это не «дёрнуть API из обработчика сохранения», а небольшой конвейер. Схема, которую мы разворачиваем на проектах:

1. Событие. CMS фиксирует изменение сущности и кладёт URL в очередь с меткой времени и типом изменения. Никаких сетевых вызовов в этот момент.
2. Фильтрация. Перед отправкой URL проходит проверки: страница публична, отдаёт 200, не закрыта в robots.txt, не имеет noindex, канонический адрес совпадает с самим собой.
3. Дедупликация. Если один и тот же URL менялся пять раз за десять минут, в отправку уходит один экземпляр. Дедуп по URL в окне 10–15 минут снимает основную массу дублей.
4. Троттлинг. Ограничение на число уведомлений в сутки по домену. Разумный потолок задаётся исходя из реальной частоты изменений: если сайт объективно меняет 300 страниц в день, отправка 5 000 — это сигнал о баге, а не о продуктивности.
5. Пакетирование. Накопленные URL уходят одним POST-запросом раз в несколько минут. Это и экономнее, и безопаснее с точки зрения лимитов.
6. Повторы. При ошибках 5xx и таймаутах — повтор с экспоненциальной задержкой. При 400 и 422 повторять бессмысленно: это ошибка в данных, её нужно чинить, а не ретраить.
7. Журнал. Каждая отправка пишется в таблицу: URL, время, код ответа, номер попытки. Этот журнал — основа для последующего анализа эффективности.

Готовые решения по платформам

Писать интеграцию с нуля нужно далеко не всегда — для популярных CMS протокол уже поддерживается на уровне плагинов и модулей.

• WordPress. Поддержка встроена в основные SEO-плагины, есть и отдельный плагин от Bing. Настройка сводится к генерации ключа в интерфейсе — файл создаётся автоматически. Проверьте только, что он реально отдаётся с диска, а не генерируется на лету и не ломается при включении кэширующего плагина. Общие настройки движка — в материале про SEO на WordPress.
• 1С-Битрикс. В маркетплейсе есть готовые модули, но на нагруженных магазинах мы чаще пишем собственный обработчик на событиях изменения элементов инфоблоков — так контролируется фильтрация и пакетирование. Специфика платформы разобрана в статье про SEO на 1С-Битрикс.
• MODX, OpenCart и прочие движки. Обычно проще всего повесить отправку на системное событие сохранения ресурса или товара плюс отдельный крон-скрипт, вычитывающий изменения за период из базы.
• Уровень CDN. У части провайдеров есть механизм, который сам отправляет IndexNow-сигналы, определяя изменения на уровне кэша. Включается одним переключателем, но контроля над тем, что именно отправляется, у вас почти нет. Для сайтов без своей интеграции это лучше, чем ничего; для крупных проектов предпочтительнее собственный конвейер.
• Самописные и headless-проекты. Отправка встраивается в CI/CD или в вебхук CMS. Здесь как раз проще всего сделать всё правильно: очередь, фильтры, батчи, логи.

Для проектов с генерацией страниц по шаблонам — а это типичная история programmatic SEO — интеграция с IndexNow практически обязательна: без неё робот месяцами добирается до вновь сгенерированных разделов. Общие подходы к обвязке SEO-процессов скриптами описаны в статье про автоматизацию SEO через API.

Подводные камни и как их обходить

Собрали проблемы, которые встречаются на аудитах чаще всего, вместе с причинами и решениями.

Отдельно предупредим о безопасности: ключ лежит в открытом доступе в корне сайта, и это нормально по замыслу протокола — но именно поэтому им может воспользоваться кто угодно, кто его нашёл. Практических рисков немного: чужой отправитель сможет только уведомить поисковик о ваших же URL. Тем не менее, если вы видите в логах странную активность или подозреваете злоупотребление, ключ меняется за минуту: генерируете новый, кладёте новый файл, обновляете конфиг, старый файл удаляете.

Как измерить эффект и не обмануть себя

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

Три корректные метрики

Задержка «отправка → первый обход». Основная метрика. Берёте журнал отправок, берёте логи сервера с обращениями верифицированных роботов, соединяете по URL, считаете медиану разницы во времени. Сравниваете с медианой до внедрения по тем же типам страниц. Именно эта цифра показывает, работает механизм или нет.

Доля отправленных URL, обойдённых за 24 и 72 часа. Дополняет медиану: медиана может выглядеть хорошо, а хвост — плохо. Если 30% отправленных адресов робот не посетил и за трое суток, значит фильтрация отправляемых URL требует пересмотра либо у сайта общая проблема с доверием.

Задержка «публикация → появление в индексе». Конечная метрика для контента. Снимается по проверке индексации выборки новых URL. Она медленнее и шумнее, но именно её понимает бизнес.

Чего не надо делать: измерять эффект по общему росту числа страниц в индексе. Этот показатель меняется по десятку причин, и приписать его IndexNow нельзя. Точно так же бессмысленно сравнивать «до и после» на разных периодах с разной интенсивностью публикаций — сравнивайте сопоставимые окна и однотипные страницы. Общая логика построения измеримых метрик описана в статье про KPI в SEO.

IndexNow в типичных сценариях из практики

Миграция сайта

Единственный случай, когда массовая отправка большого списка URL оправдана. При смене структуры или переезде на новый домен старые адреса начинают отдавать 301, и чем быстрее робот это увидит, тем быстрее перенесутся сигналы. Схема: после переключения отправляем пакетами старые URL (чтобы робот увидел редиректы) и новые URL (чтобы он их обошёл), растягивая отправку на несколько дней, а не вываливая всё за час. Полный чек-лист переезда — в материале про миграцию сайта без потери трафика.

Массовое обновление цен

Типичная ситуация в e-commerce: ночная выгрузка изменила цены на 15 000 карточках. Отправлять все 15 000 не нужно — отфильтруйте те, где изменение существенное (например, цена изменилась более чем на несколько процентов или изменилось наличие), и отправьте их. Косметические изменения на копейку смысла не имеют, а объём отправок раздувают кратно.

Исправление технической ошибки

Починили шаблон, из-за которого группа страниц отдавала пустой контент или неправильный title. После деплоя отправляем затронутые URL — это заметно ускоряет переиндексацию по сравнению с ожиданием естественного обхода. Здесь IndexNow работает лучше всего: изменение реальное, значимое и затрагивает конкретный ограниченный список адресов.

Восстановление после просадки

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

Запуск нового сайта

На старте у проекта нет ни истории обхода, ни ссылок, и робот приходит редко. Уведомления помогают быстрее обнаружить первые страницы, но чуда не сделают: молодой домен всё равно проходит период накопления доверия. Разумная схема — отправить основные посадочные и разделы каталога, а дальше подключить обычный поток уведомлений о новых материалах.

Чек-лист внедрения и приоритеты

Сводная таблица работ: что делать, в каком порядке и сколько это реально занимает.

Итого базовое внедрение с нормальной архитектурой — от одного до трёх рабочих дней разработчика в зависимости от платформы. Это одна из самых дешёвых технических доработок в SEO по соотношению «затраты — потенциальный эффект», особенно на проектах с частыми изменениями контента. Примеры технических перестроек, которые мы делали на клиентских проектах, есть в портфолио, а состав и стоимость работ — на странице цен на SEO-продвижение.

Частые вопросы