IndexNow: как ускорить передачу новых и изменённых URL поисковикам

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

Это сокращает промежуток между изменением на сайте и моментом, когда поисковик узнаёт о нём. Особенно заметна такая разница на проектах, где URL меняются постоянно: в интернет-магазинах, новостных ресурсах, каталогах, базах знаний и крупных контентных сайтах.

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

На таких проектах IndexNow полезен как один из элементов общего процесса: при SEO-услугах для крупных и часто обновляемых сайтов его имеет смысл контролировать вместе с Sitemap, внутренними ссылками, доступностью URL и фактическим состоянием страниц в индексе.

IndexNow передаёт сигнал, а не команду на индексацию

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

IndexNow добавляет ещё один маршрут: сайт сам отправляет уведомление сразу после события.

Логика выглядит так:

публикация или изменение → URL → IndexNow → поисковая система → решение об обходе → решение об индексации

Поэтому говорить, что IndexNow «индексирует страницу», технически неточно. Протокол лишь устраняет часть задержки на этапе обнаружения изменений.

Через него имеет смысл передавать:

• новый опубликованный URL;
• существующую страницу после существенного изменения;
• удалённый URL;
• страницу, для которой изменился редирект или другое значимое состояние.

Периодически отправлять всю базу URL без изменений не нужно.

Как один сигнал попадает в несколько поисковых систем

IndexNow создавался как общий протокол. Участвующие в нём поисковые системы могут обмениваться полученными URL, поэтому интеграцию не обязательно строить как набор отдельных API для каждого поисковика.

На практике для русскоязычного сайта особенно важен Яндекс, а для международных проектов — также Bing и другие участники экосистемы IndexNow.

У Яндекса есть собственный endpoint https://yandex.com/indexnow, а универсальные реализации могут работать через https://api.indexnow.org/indexnow.

Для обычных страниц сайта IndexNow при этом не стоит рассматривать как способ отправки URL в Google. У Google остаются собственные механизмы обнаружения и повторного обхода: внутренние ссылки, Sitemap и инструменты Search Console. Google Indexing API — отдельный механизм и официально предназначен для ограниченных типов страниц, в частности JobPosting и BroadcastEvent внутри VideoObject.

Получается, что IndexNow дополняет стандартную техническую SEO-инфраструктуру, а не заменяет её.

Ключ подтверждает право отправлять URL

Перед приёмом уведомлений поисковой системе нужно убедиться, что сторонний сайт не отправляет изменения от имени чужого домена. Для этого используется ключ IndexNow.

Это строка длиной от 8 до 128 допустимых символов. Файл с ключом обычно размещают в корне сайта:

https://example.com/YOUR_INDEXNOW_KEY.txt

Содержимое файла:

YOUR_INDEXNOW_KEY

Размещение в корне проще всего: ключ распространяется на URL соответствующего хоста, а конфигурацию легче проверять и поддерживать.

При работе с Яндексом для поддоменов следует использовать отдельные ключи. Это особенно важно на инфраструктуре вида:

www.example.com
shop.example.com
docs.example.com

Если ключ лежит не в корне, в запросе можно передать keyLocation, но тогда область действия ключа зависит от каталога его размещения. Без практической необходимости усложнять эту схему обычно нет смысла.

Как выглядит отправка нескольких URL через API

Для автоматизации удобнее отправлять изменения пакетами через POST. Например:

curl -i -X POST "https://api.indexnow.org/indexnow" \
  -H "Content-Type: application/json; charset=utf-8" \
  --data '{
    "host": "example.com",
    "key": "YOUR_INDEXNOW_KEY",
    "keyLocation": "https://example.com/YOUR_INDEXNOW_KEY.txt",
    "urlList": [
      "https://example.com/new-page/",
      "https://example.com/updated-page/"
    ]
  }'

В одном таком запросе протокол позволяет передать до 10 000 URL.

Но этот предел не следует воспринимать как рекомендацию собирать пакет из 10 000 адресов при каждом запуске. Правильная модель — передавать только те документы, с которыми действительно произошло событие.

На WordPress это удобно привязать к публикации, обновлению и удалению записи. Для готовых решений существуют плагины, которые самостоятельно создают ключ и отправляют изменившиеся permalink в фоне. Для проекта с собственной логикой публикации тот же процесс можно реализовать непосредственно в коде CMS.

Практический сценарий: обновление большого каталога

Представим интернет-магазин с 80 000 товарных URL. За день появились 120 новых карточек, у 600 товаров изменились цены или наличие, а 40 карточек были окончательно удалены.

Без событийной отправки поисковой системе остаётся самостоятельно обнаруживать эти изменения при очередных обходах.

С IndexNow сайт формирует очередь только из изменившихся адресов: новые и обновлённые страницы отправляются как актуальные URL, удалённые — после того как сервер уже возвращает корректный 404 или 410.

Одновременно XML Sitemap продолжает описывать актуальный состав индексируемых страниц сайта.

В этой схеме у инструментов разные задачи:

Механизм	Что сообщает
IndexNow	Конкретный URL только что изменился
Sitemap	Какие индексируемые URL входят в структуру сайта
Внутренние ссылки	Как страницы связаны между собой
HTTP-код, canonical, robots	Как обрабатывать конкретный документ

Если после отправки URL страница остаётся неиндексируемой из-за noindex, неправильного canonical или серверной ошибки, IndexNow это не исправит. Он лишь быстрее передаст поисковику сведения о существующем состоянии страницы.

Проверка должна идти дальше ответа API

Первый уровень проверки — HTTP-код ответа.

200 OK означает, что набор URL принят. При использовании нового ключа можно сначала получить 202 Accepted: поисковая система получила запрос, но ещё проверяет ключ.

Ошибки 4xx уже указывают на проблему реализации. Среди типовых причин — недоступный или неверный ключ, URL другого хоста, неправильный keyLocation, некорректное тело запроса или слишком интенсивная отправка.

Но даже 200 OK — только техническое подтверждение доставки.

Дальше нужно проверить, что происходит с самим URL. В Bing Webmaster Tools для IndexNow доступны сведения об отправленных, просканированных и индексированных адресах. В Яндекс Вебмастере можно проверять состояние страниц и видеть IndexNow среди источников, через которые поисковая система получила информацию о URL.

То есть корректный контроль выглядит не как:

API вернул 200 → задача закрыта

а как:

URL отправлен → сигнал принят → страница доступна роботу → выполнен обход → проверено состояние в поиске

Где IndexNow действительно полезен

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

Это может быть наличие товара, цена, новый материал, актуализированная справочная статья, удалённая карточка, новостная публикация или другой URL, для которого задержка обнаружения нежелательна.

Для небольшого сайта из нескольких редко меняющихся страниц выгода будет скромнее. Яндекс прямо предлагает для таких случаев использовать и обычный инструмент переобхода страниц в Вебмастере.

Не следует и противопоставлять IndexNow Sitemap. Карта сайта отвечает за охват URL, а IndexNow — за своевременный сигнал об отдельном изменении. Для крупного сайта нормальная схема использует оба механизма.

Ошибки, которые сводят пользу IndexNow к нулю

Самая частая ошибка — оценивать работу по самому факту отправки. Сервер вернул 200, и кажется, что URL уже «проиндексирован». На самом деле подтверждена только доставка уведомления.

Вторая проблема — отправка каждого URL при любом техническом сохранении записи. Если редактор несколько раз подряд поправил пробел, метаполе или служебное значение, нет необходимости создавать поток одинаковых уведомлений. Яндекс отдельно не рекомендует слишком часто отправлять один и тот же адрес и при необходимости советует выдерживать паузу.

Третья ошибка — пытаться IndexNow компенсировать проблемы страницы. Протокол не исправляет:

• блокировку обхода;
• noindex;
• конфликтующий canonical;
• ошибочный HTTP-ответ;
• слабое или дублирующееся содержимое;
• неправильную внутреннюю структуру сайта.

Наконец, не стоит превращать IndexNow в инструмент искусственного «SEO-ускорения». Сам факт использования протокола не является доказанной причиной роста позиций. Его измеримый технический результат гораздо конкретнее: поисковая система раньше получает информацию о том, что URL изменился.

Рабочая модель для сайта

Для большинства проектов достаточно простой архитектуры: сохранять полноценный Sitemap, обеспечить нормальную внутреннюю перелинковку, автоматически отправлять через IndexNow только реально изменившиеся URL и отдельно контролировать индексирование в инструментах поисковых систем.

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

Дальнейшая индексация и ранжирование уже зависят не от количества повторных отправок, а от состояния самого URL и решений конкретной поисковой системы.