IndexNow против sitemap.xml: что реально ускоряет индексацию в 2026

Статья:

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

Sitemap.xml — pull-модель, которую поисковик обходит по своему графику

Sitemap лежит на сервере, поисковик сам приходит за ним. Проверить, когда Google последний раз его читал: Search Console → Индексирование → Файлы Sitemaps — там есть колонка «Последнее сканирование». Если дата старше 3–4 дней при активной публикации — это уже сигнал, что карта не в приоритете у краулера. Подробнее о том, как правильно собрать и проверить sitemap, можно почитать в статье Sitemap.xml в 2026: как составить, проверить и не слить crawl budget .

Практика, а не теория:

• Если sitemap перегенерируется раз в сутки по крону, а вы публикуете статьи весь день — новые URL физически не попадают в карту до следующей сборки. Решение: генерировать sitemap инкрементально при каждой публикации, а не по расписанию.
• lastmod должен реально меняться при правке контента, а не быть датой сборки сайта. Если у всех URL в sitemap одна и та же дата — Google это быстро считывает как некачественный сигнал и перестаёт доверять lastmod конкретно у вас.
• Больше 50 000 URL или 50 МБ в одном файле — обязательно sitemap index с несколькими файлами, иначе часть карты просто не обработается.

IndexNow — push, но не для Google

Механика простая: вы публикуете страницу и сразу дёргаете эндпоинт.

curl -X POST "https://api.indexnow.org/indexnow" \
  -H "Content-Type: application/json" \
  -d '{
    "host": "example.ru",
    "key": "ваш_ключ",
    "keyLocation": "https://example.ru/ваш_ключ.txt",
    "urlList": ["https://example.ru/novaya-statя"]
  }'

Ответ 200 или 202 значит только «принято», не «проиндексировано». Ключевой файл ваш_ключ.txt должен лежать в корне и содержать сам ключ строкой — без этого запрос отклонят с 403.

Кто реально слушает IndexNow в 2026: Bing, Яндекс, Naver, Seznam.cz, Yep. DuckDuckGo собственного приёма не имеет — его выдача строится на индексе Bing, поэтому пинг доходит туда только косвенно. Google протокол не поддерживает — ни в каком виде, это официальная позиция, а не временное ограничение. Подробнее о причинах отсутствия поддержки читайте в статье Почему Google не поддерживает IndexNow и как это обходить . Если видите в блогах советы «отправляйте в Google через IndexNow» — это или устаревшая статья, или подмена понятий с Google Indexing API (который работает только для двух типов разметки: JobPosting и BroadcastEvent, для обычных статей бесполезен).

Частая ошибка на практике: слать один и тот же URL повторно при каждой мелкой правке (опечатка, замена картинки). Bing и Яндекс видят это как шум и начинают игнорировать источник — есть смысл группировать правки и слать пачкой раз в час, а не при каждом сохранении в CMS.

Сценарий: страница висит в «Обнаружено, но не проиндексировано»

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

1. Открываете Search Console → Проверка URL (или Ctrl+ клик по значку лупы вверху) → вставляете адрес → смотрите блок отчёта о покрытии.
2. Видите статус Discovered — currently not indexed. Это значит: краулер видел ссылку на URL (из внутренней перелинковки, sitemap или внешнего сигнала), но не считает страницу достаточно приоритетной, чтобы тратить на неё краулинговый бюджет прямо сейчас.
3. Если статус держится больше 2–3 недель — это НЕ вопрос терпения, обычно один из трёх факторов:
   • Слабая внутренняя перелинковка — на страницу не ведёт ни одна ссылка с уже проиндексированных, авторитетных разделов сайта.
   • Тонкий контент — Google просканировал шаблон страницы, увидел мало уникального текста относительно похожих URL, и отложил.
   • Общий низкий crawl budget домена — актуально для молодых сайтов и сайтов с историей технических проблем.
4. Что делать: добавить 2–3 ссылки с трастовых страниц раздела, убедиться что canonical указывает сам на себя (не на другую версию URL), и нажать «Запросить индексирование» в том же интерфейсе проверки URL — но помните лимит: около 10–12 ручных запросов в сутки на аккаунт, дальше форма молчит до завтра.

Если статья не единичная, а пачка из 50–200 URL после публикации серии материалов или миграции — вручную по одной в GSC не набегаешься из-за суточной квоты. Здесь разумно прогнать список массовой проверкой индексации через Rush Analytics — сервис за один прогон показывает, какие URL из списка реально в индексе, какие нет, и на каких страницах менять приоритеты перелинковки.

Что делать, если Google конкретно не подхватывает — а IndexNow ему не поможет

Раз официального push-канала для Google нет, а нужно ускорить попадание в индекс страниц или свежих обратных ссылок — используют сторонние индексаторы, которые не полагаются на протокол IndexNow, а гоняют URL через свою инфраструктуру (переходы, пинги, краулинг‑сети), повышая шанс визита бота Google без нарушения самого протокола. Для страниц и бэклинков в такой ситуации решает индексатор SpeedyIndex — задача ставится списком URL, сервис не обещает мгновенного результата, но заметно сокращает время ожидания по сравнению с пассивным ожиданием обхода sitemap.

Sitemap и IndexNow — рабочая цепочка на живом проекте

1. Публикация или правка страницы в CMS.
2. CMS инкрементально обновляет sitemap.xml, честно меняет lastmod у изменённого URL.
3. Скрипт или плагин сразу отправляет URL на api.indexnow.org.
4. Bing и Яндекс получают push‑сигнал — обычно визит бота в течение часов, иногда быстрее.
5. Google узнаёт о странице через обычный обход sitemap либо через внутреннюю ссылку с уже проиндексированной страницы — здесь push‑канала нет физически.

Если объём публикаций большой (новостник, каталог, листинги с частой сменой цен/наличия) и нужно регулярно контролировать, что реально долетело до индекса по обеим веткам — не ловить статусы вручную по одному URL, а держать список под пачечной проверкой в Rush Analytics: там же удобно сравнивать динамику индексации до и после смены sitemap‑стратегии.

Таблица: когда что использовать

Чего не делать

• Не отправлять весь сайт через IndexNow одним списком. Это не массовая переиндексация, а канал для точечных изменений — для полного пересбора приоритет у sitemap.
• Не слать один URL по многу раз в день. Источник быстро теряет доверие у Bing и Яндекса.
• Не отправлять закрытые URL. noindex или блокировка в robots.txt плюс уведомление об этом же URL — конфликт сигналов, который поисковик фиксирует.
• Не считать, что IndexNow снимает вопрос с Google. Для Google работает только связка sitemap + внутренние ссылки + осторожная ручная отправка + (в узких случаях) Indexing API для двух типов разметки.

Связанные термины

• robots.txt — управляет обходом, не индексацией напрямую.
• canonical URL — какой адрес страницы Google считает основным при дублях.
• Crawl budget — лимит ресурсов краулера на домен; IndexNow экономит его на стороне поисковика, который его поддерживает.
• Google Indexing API — отдельный канал только для Google и только для JobPosting/BroadcastEvent, для обычных статей неприменим.