Яндекс И Bing

Как сообщить Яндексу и Bing о новой странице через IndexNow

Как настроить IndexNow технически: ключ, curl-запрос, коды ответов, чек-лист перед отправкой и что делать, если страница не индексируется 1-2 недели.

Как сообщить Яндексу и Bing о новой странице через IndexNow
Содержание

IndexNow — протокол, по которому сайт сам сообщает поисковику: «здесь новая страница» или «эта страница обновилась». Технически это один HTTP‑запрос с адресом страницы и ключом подтверждения на общую точку входа api.indexnow.org — сигнал оттуда автоматически расходится Яндексу и Bing, стучаться в каждый поисковик отдельно не нужно. Google эту схему не поддерживает — почему именно и что делать вместо неё, разбирал в статье Почему Google не поддерживает IndexNow и как это обходить . Подробнее о самом протоколе читайте в статье Что такое IndexNow и как им пользоваться .

Сразу разведём два действия: «сообщить о странице» и «проиндексировать её» — не одно и то же. IndexNow передаёт сигнал «загляните сюда», но включать страницу в выдачу или нет — решает алгоритм. Пустую страницу, закрытую в robots.txt, или почти дословный дубль соседнего материала протокол не спасёт: он просто быстрее донесёт до робота содержимое, включая все проблемы. Чем механизм принципиально отличается от sitemap.xml — в статье Чем IndexNow отличается от sitemap.xml .

Как настроить технически: ключ, файл, запрос

Шаг 1. Сгенерируйте ключ — подойдёт любая строка из 8–128 latin‑символов и цифр (можно взять готовый UUID и убрать дефисы).

Шаг 2. Создайте файл <ваш-ключ>.txt в корне домена, например https://site.ru/a1b2c3d4e5f6.txt. Внутри — тот же ключ, без пробелов и переносов строки. Так поисковик проверяет, что запрос действительно от владельца домена, а не от постороннего.

Шаг 3. Отправьте запрос. Для одной страницы — GET вида:

https://api.indexnow.org/indexnow?url=https://site.ru/novaya-stranitsa/&key=a1b2c3d4e5f6

Для пакета из нескольких адресов (до 10 000 URL за один запрос) — POST с JSON‑телом:

curl -X POST https://api.indexnow.org/indexnow \
  -H "Content-Type: application/json" \
  -d '{
    "host": "site.ru",
    "key": "a1b2c3d4e5f6",
    "keyLocation": "https://site.ru/a1b2c3d4e5f6.txt",
    "urlList": [
      "https://site.ru/novaya-stranitsa/",
      "https://site.ru/obnovlennaya-stranitsa/"
    ]
  }'

Что означает ответ сервера:

  • 200 OK / 202 Accepted — запрос принят, сигнал ушёл в очередь обработки;
  • 400 Bad Request — сломан формат JSON или URL;
  • 403 Forbidden — ключ не совпадает с содержимым файла keyLocation, или файл недоступен;
  • 422 Unprocessable Entity — URL не принадлежит указанному host, либо ключ выпущен для другого домена;
  • 429 Too Many Requests — отправляете слишком часто, снизьте частоту.

Если пишете на своём движке — это 5 строк кода после публикации статьи. Если сайт на WordPress — часть SEO‑плагинов (Yoast SEO, RankMath) уже умеет пинговать IndexNow автоматически при сохранении записи и сама кладёт ключ в корень. Ручная отправка через панель Яндекс.Вебмастера или Bing Webmaster Tools имеет смысл только для разовых случаев — 3–5 страниц, когда лень писать скрипт; подробнее о том, как это сделать, в статье Как сообщить Яндексу о новой странице через Вебмастер и IndexNow ; для регулярной публикации выгоднее автоматизация.

Когда отправлять, а когда — нет

СитуацияОтправлять?Почему
Новая статья, прошла вычитку, доступна без ошибокДа, сразу после публикацииСигнал актуален, странице есть что показать
Правка существующей страницы (обновили цифры, добавили блок)ДаРобот сам это заметит не скоро — быстрее подсказать
Черновик или технический раздел (корзина, фильтр с пустой выдачей)НетТратите сигнал на страницу, которую и индексировать не нужно
Массовая партия из 500+ почти одинаковых страниц (теговые архивы, дубли фильтров)Нет, сначала сократить дублиIndexNow не отличает мусор от контента — вы просто ускорите индексацию мусора
GoogleНетПротокол не поддерживается, нужен отдельный маршрут (sitemap + Search Console + перелинковка)

Чек‑лист перед отправкой

Прогоните каждую страницу по пяти пунктам, прежде чем слать запрос:

  1. Страница открывается 200‑м кодом без лишних редиректов. Проверка за 5 секунд: curl -IL https://site.ru/stranitsa/ — если видите 301/302 на другой адрес, отправляйте финальный URL, а не промежуточный.
  2. Не закрыта в robots.txt и в meta‑теге robots. Смотрите исходный код (Ctrl+U) на <meta name="robots" content="noindex"> — если есть, IndexNow бессмысленен, пока тег не убран.
  3. Заголовок и description не шаблонные. Не «Страница 3 — Каталог», а осмысленный текст под конкретную страницу.
  4. На страницу ведёт хотя бы одна внутренняя ссылка с уже проиндексированного материала — страница‑сирота без входящих ссылок индексируется хуже даже после пинга.
  5. Адрес есть в sitemap.xml и не противоречит по смыслу похожим URL по соседству.

Прогонять пункты 1–2 по всему списку новых URL вручную долго, если публикаций больше 10–20 в неделю. Для массового тех‑аудита удобнее набор инструментов вроде Арсенкин: загружаете список адресов, получаете статусы, редиректы и robots‑ограничения одним отчётом, а не открываете каждую страницу поштучно.

Что смотреть после отправки

Частая ошибка — проверять результат через 5 минут и что‑то менять на странице, не дождавшись реакции. Так делать не стоит: осмысленную проверку лучше проводить через 3–7 дней. Смотрите три вещи: открывается ли адрес по прямой ссылке из поиска, не выбрал ли поисковик для показа другую похожую страницу вашего же сайта, и нет ли по этому URL ошибок в панели вебмастера.

Если публикуете пачками (20–50 URL в неделю), проверять индексацию каждого вручную в поиске — потерянное время. Для массовой сверки статуса по списку удобен Rush Analytics: загружаете весь список отправленных URL и получаете отчёт, какие уже в индексе, какие нет и сколько дней прошло с публикации — так видно проблемные адреса, а не гадаете по одному.

Если адрес так и не появился в поиске через 1–2 недели, разбираться нужно не с IndexNow, а с причиной. Пройдитесь по типичным виновникам:

  • слабый или тонкий текст (меньше 1000–1500 знаков осмысленного контента);
  • отсутствие внутренних ссылок на страницу;
  • дубли похожего контента на сайте;
  • случайный запрет в robots.txt или meta‑теге;
  • низкое доверие поисковика к сайту в целом — если сайт молодой или на нём есть спам‑сигналы, даже здоровые страницы индексируются медленнее. Проверить общий траст домена можно через Checktrust — если показатель низкий, работа над доверием важнее, чем повторные пинги.

IndexNow передаёт сигнал быстрее, но не подменяет собой ни редактуру, ни работу над структурой сайта.

По темеIndexNow и AI-поиск: что доказано, а что миф в 2026 году→

Когда одного IndexNow мало

Бывает так: страница технически идеальна по чек‑листу, сигнал отправлен, отчёт показывает «принято», а в индексе её всё равно нет неделями — обычно дело в доверии к домену, а не в самом протоколе. В таких случаях, а также для страниц, которые всё равно не видны Google (куда IndexNow не достаёт), параллельно имеет смысл использовать индексатор вроде SpeedyIndex — он прогоняет URL через собственные механизмы обхода, включая посылку в Google, и подходит как второй канал, а не замена IndexNow.

Пример из практики

Выпустили статью «Почему похожие страницы плохо индексируются». Порядок действий:

  1. Проверили страницу глазами обычного читателя: заголовок понятен без пояснений, есть таблица с признаками проблемы, есть ссылка из соседнего материала про качество сайта, обложка не выглядит случайной заглушкой.
  2. Убедились, что адрес попал в sitemap.xml (curl https://site.ru/sitemap.xml | grep stranitsa).
  3. Отправили через IndexNow одним запросом на Яндекс и Bing.
  4. Записали дату отправки в таблицу наблюдений — без этого через неделю легко забыть, что и когда проверяли.
  5. Через 5 дней вернулись: адрес появился в поиске по прямому запросу, ошибок в панели вебмастера нет — на этом кейс закрыт.

Если бы на шаге 5 адреса не оказалось — следующий шаг не «отправить IndexNow ещё раз», а перепроверка чек‑листа: дубли, внутренние ссылки, тонкий контент.

Частые ошибки

  • Отправлять черновики и страницы, которые сами пока не готовы показать постороннему — трата сигнала и лишний шум.
  • Использовать протокол как замену внутренней перелинковке и структуре сайта — он ускоряет обнаружение, а не чинит архитектуру.
  • Делать выводы «работает или нет» через 10 минут после отправки — индексация так быстро не происходит ни у одного поисковика.
  • Смешивать IndexNow с продвижением в Google. Для Google маршрут другой: sitemap, внутренние ссылки, Search Console и качество материала.
  • Отправлять один и тот же URL по нескольку раз без изменений в надежде «продавить» индексацию — повторная отправка без реального обновления страницы сигнала не усиливает.

Короткий вывод

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

Для нового сайта разумнее отправлять не всё подряд, а только то, что действительно готово, и вести хотя бы простую таблицу дат отправки. Если через 1–2 недели результата всё ещё нет, возвращайтесь не к самому протоколу, а к качеству материала, внутренним ссылкам, дублям и трасту домена. Тогда IndexNow становится рабочей частью системы индексации, а не кнопкой, в которую хочется верить как в решение всех проблем.

По теме2index.ninja: обзор сервиса и проверка результата→ По темеРотация ключа IndexNow без потери push-сигналов→