IndexNow: какие адреса отправлять после изменения сайта

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

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

Что именно вы отдаёте поисковику, когда правите страницу

Представьте условный магазин на 4 800 адресов: в понедельник редактор поправил цену и наличие у 37 карточек, дизайнер переверстал раздел доставки, а разработчик поменял шаблон, от которого зависят ещё 900 страниц. Нужно решить, какие адреса уходят уведомлением, в каком порядке и что считать результатом. Сцена условная, но именно из таких будней состоит работа с IndexNow.

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

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

Три состояния адреса, которые нельзя смешивать

У любого URL в момент отправки есть три независимых состояния, и путаница между ними — источник большинства ошибок. Первое — техническое: страница отвечает 200, отдаёт нужный HTML, не редиректит. Второе — содержательное: на ней уже та версия текста, цены или структуры, ради которой затевалась правка. Третье — каноническое: адрес, который вы отправляете, совпадает с тем, что страница объявляет каноническим, и не является дублем.

Уведомление осмысленно только когда все три состояния сходятся. Классическая ошибка — отправить URL сразу после деплоя, когда CDN ещё раздаёт старый кэш, а база уже отдаёт новые данные. Формально страница жива, но поисковик придёт и увидит промежуточное состояние. Второй распространённый случай — отправка адреса с параметрами (?utm_source=..., ?page=2), который канонизируется на чистый URL: вы просите переобойти то, что сами объявили неглавным.

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

Ключ, хост и область доверия

IndexNow работает на доверии к ключу: вы размещаете файл с ключом на хосте и подтверждаете, что имеете право говорить от имени этого хоста. Отсюда несколько практических следствий, которые всплывают не сразу.

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

Отдельная тонкость — кто владеет ключом внутри компании. Если ключ лежит в личном кабинете подрядчика, при смене подрядчика вы теряете не только доступ, но и историю того, что и когда отправлялось. Ключ — это инфраструктурный актив, а не деталь реализации.

Что происходит после HTTP-ответа

Самый дорогой в обслуживании миф звучит так: «сервер ответил 200 — значит, страница в поиске». Ответ 200 означает ровно одно: уведомление принято к рассмотрению. Дальше адрес проходит валидацию, попадает в очередь обхода, и только потом поисковая система решает, обновлять ли индекс. Между этими шагами могут быть часы и дни, и на каждом шаге адрес может отвалиться.

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

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

Уведомление — не замена карте сайта

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

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

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

Уведомление об изменённом URL: запись об изменении

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

Ключевое здесь — поле version. Без него невозможно отличить «мы отправили актуальную версию» от «мы отправили что-то, а потом ещё трижды правили страницу». Версия привязывается к моменту, когда контент стал доступен снаружи, а не к моменту сохранения в редакторе.

Второй важный элемент — batch_id. Пачки нужны, чтобы можно было остановить, повторить или разобрать конкретную отправку, не трогая остальные. И третье — verified_at, которое заполняется только внешней проверкой. Пока это поле пустое, запись не считается закрытой, сколько бы зелёных ответов ни пришло.

Два эпизода: как это ломается на практике

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

Разбор занимает полдня, потому что нет ни версий, ни разделения по типам изменений. Правильная схема для такого случая: скрипт не отправляет уведомления напрямую, а создаёт записи со статусом draft; отдельный шаг проверяет доступность и канонизацию и переводит их в ready; отправка идёт пачками с ограничением частоты; ответы пишутся в response_code; снятые с продажи товары получают change_type: removed и обрабатываются отдельно от ценовых правок. Разница в трудозатратах — не в пользу «отправить всё сразу».

Эпизод второй: правка отменена. Условная компания по прокату оборудования готовит обновление раздела условий. Текст выкладывают, уведомление уходит, а через час юрист просит откатить формулировку до завтрашнего согласования. Страница возвращается к прежней версии. Что делать с уже отправленным уведомлением?

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

Где начинается коммерческая часть

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

Уведомление об изменённом URL: исключения и проверка условий

Любой регламент упирается в случаи, где «отправить изменённый адрес» перестаёт быть очевидным. Разберём самые частые.

Каноникал указывает на другой адрес. Вы правите страницу-дубль, но она канонизируется на основной URL. Отправлять нужно основной адрес, потому что именно он представляет контент в индексе. Если же правка меняет сам каноникал — например, вы объединяете две страницы, — это уже структурное изменение, и его нужно проводить через отдельную проверку, а не через общий поток уведомлений.

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

Ключ недоступен. Как только проверка ключа падает, очередь должна останавливаться, а не копиться. Иначе после восстановления вы отправите накопленное разом и получите 429 на всю пачку. Лучше потерять несколько часов, чем всю очередь.

Изменение отменено. Описано в эпизоде выше: откат — это новое изменение с новой версией, а не повод «забыть» про предыдущее уведомление.

Ответ 202 и ожидание валидации. Принято — не значит обработано. Запись остаётся в статусе accepted до внешнего подтверждения. Не переводите её в verified по факту кода ответа.

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

Уведомление об изменённом URL на экране сотрудника

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

Разумное разделение такое. Система сама определяет канонический адрес, проверяет доступность, группирует правки в пачки и следит за частотой. Человек подтверждает содержательную сторону: та ли это версия, нужно ли вообще уведомлять об этом изменении, не является ли правка временной. Статусы в интерфейсе стоит называть по-человечески: «ждёт публикации», «готово к отправке», «отправлено», «подтверждено переобходом». Слово «принято» без пояснения сбивает с толку — люди читают его как «готово».

Отдельно нужен экран для разбора исключений: адреса, которые не прошли проверку, с причиной. Без него исключения тонут в общем списке, и через неделю никто не помнит, почему конкретная страница так и не ушла. И нужен журнал пачек — чтобы на вопрос «а мы отправляли эту страницу?» был ответ с датой, версией и кодом ответа, а не воспоминания.

Как проверить, что контур работает

Проверка не должна сводиться к «посмотрели, вроде зелёное». Нужны тесты, которые воспроизводят именно те сбои, из-за которых всё ломается. Ниже — набор проверок, которые стоит прогнать до того, как пускать поток в бой.

Эти тесты полезны ещё и тем, что заставляют явно договориться о терминах внутри команды. Что считается «готово»? Кто закрывает запись? Что делать, если подтверждение не пришло за сутки? Ответы на эти вопросы важнее, чем конкретная реализация.

Практикум: разбираем условную пачку из 240 адресов

Возьмём условный сайт сервисной компании с 240 адресами в пачке за день. Из них: 150 — обновление цен в прайсе, 40 — новые статьи блога, 30 — правки в разделе «О компании», 15 — товары, снятые с продажи, 5 — страницы, у которых сменился канонический адрес после объединения разделов.

Наивный подход — отправить все 240 одной пачкой. Разберём, почему это плохо, по шагам.

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

Дальше — порядок и частота. Нет смысла отправлять 240 адресов в одну секунду: получите 429 и потеряете всю пачку. Разумнее разбить на несколько подпачек с интервалом и следить за кодами ответа. Если пошёл 429 — останавливаемся, ждём, разбираемся, а не повторяем.

И наконец — закрытие. Записи по ценам и статьям уходят в accepted, а затем проверяются внешне. Пять структурных изменений закрываются только после того, как новая каноникализация видна снаружи. Снятые товары — после того, как отдают корректный код. Пока verified_at пуст, пачка не считается завершённой, даже если все ответы были 200.

Такой разбор занимает меньше времени, чем кажется, и почти всегда выявляет одну-две проблемы, которые иначе всплыли бы через неделю в виде «а почему у нас старая цена в поиске».

Что стоит зафиксировать в регламенте

Регламент не должен быть длинным. Достаточно нескольких правил, которые все понимают одинаково. Отправка привязана к проверенной публичной версии, а не к сохранению. Канонический адрес определяется системой, а не человеком. Ключ — инфраструктурный актив с ответственным. Ответ 200/202 — это «принято», а не «готово». Повтор пачки без нового изменения — исключение, а не норма. Исключения разбираются на отдельном экране, а не в переписке.

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

Финальная проверка перед следующей пачкой

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

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

Смежный вопрос разобран отдельно: Индексация сайта в Яндексе: проверка и исправления.