IndexNow — протокол уведомления поисковых систем об изменившихся URL: новых, обновлённых или удалённых страницах. Чтобы пользоваться им надёжно, нужно подтвердить владение сайтом, отбирать реальные изменения, отправлять адреса и разбирать ответы сервера. Полученное уведомление не означает, что страница уже обойдена или включена в поиск. Практический результат настройки — управляемая доставка сведений об изменениях с понятным журналом ошибок.
Когда сайту полезен IndexNow
У интернет-магазина меняются карточки товаров, у издателя выходят материалы, у сервиса обновляются описания услуг. Если команда хочет автоматически сообщать поиску об этих событиях, ей нужен процесс, связанный с публикацией. Ручная отправка адресов после каждого выпуска становится ненадёжной, когда изменения происходят в разных разделах и через несколько систем.
Сначала определите задачу: какие события теряются и кто сейчас отвечает за уведомления. Для небольшого сайта с редкими правками отдельная интеграция может оказаться избыточной. В справке Яндекса об IndexNow указано, что отправлять следует новые, изменённые и удалённые страницы, а не весь архив без изменений; для небольших сайтов упоминается ручной переобход. Поддержка протокола не даёт гарантии индексирования.
Какие события отправлять через IndexNow
Событие должно описывать изменение публичного адреса, а не любое сохранение записи в редакторе. Черновик, предпросмотр и тестовая копия не становятся материалами для поисковой системы только потому, что у них есть ссылка. Определите момент, когда изменение действительно доступно на рабочем сайте.
| Событие | Решение для очереди | Что проверить |
|---|---|---|
| Новая публикация | Добавить публичный URL после выпуска | По адресу открывается нужная версия |
| Содержательная правка | Обновить запись об изменении URL | Изменённый текст уже доступен посетителю |
| Удаление страницы | Передать изменившийся адрес | Сервер отвечает согласно принятому решению об удалении |
| Сохранение черновика | Не включать в публичную очередь | Ссылка предпросмотра не попала в отправку |
| Повторное событие той же версии | Объединить с существующей записью | Не потеряно более позднее изменение |
Правило содержательности зафиксируйте в задании. Например, смена описания услуги и условий заказа — изменение страницы; внутреннее сохранение служебного поля может не менять публичный документ. Не вводите универсальное число изменённых букв: оно плохо отражает смысл правки. Важно, чтобы команда одинаково понимала, какие события запускают отправку.
Сначала выпуск, затем уведомление
Запись в базе ещё не доказывает готовность страницы. Между сохранением и доступностью могут находиться очередь публикации, сборка сайта и обновление кеша. Уведомление, отправленное слишком рано, сообщает о состоянии, которого посетитель пока не видит. Привяжите постановку в очередь к подтверждённому выпуску, а при сбое выпуска оставьте событие на проверку.
Для удалённого URL проверка отличается от проверки новой страницы: не требуйте от него успешного открытия с прежним содержанием. Команда заранее выбирает корректное поведение удалённого адреса и проверяет именно его. Сам запрос IndexNow не удаляет документ с сервера и не заменяет решение о судьбе страницы.
Как подтвердить владение сайтом для IndexNow
В документации протокола IndexNow описано подтверждение через текстовый файл с ключом на соответствующем хосте. Файл в кодировке UTF-8 можно разместить в корне; при другом расположении передают keyLocation, а область допустимых URL зависит от пути файла. Один запрос POST допускает до 10 000 адресов. Это верхний предел пакета, а не целевой размер очереди.
В рабочем задании укажите точный хост, место файла и ответственного за его сохранность. Основной домен и поддомен не следует молча считать одной областью настройки. Проверьте адрес файла снаружи, без входа в административную панель: файл должен быть доступен по тому пути, который использует отправитель, а содержимое должно соответствовать настроенному ключу.
Не помещайте в этот файл пароль администратора, секрет платёжного сервиса или произвольный внутренний токен. Ключ подтверждения создают для данной интеграции. Перед переносом сайта, изменением правил доступа или очисткой корневых файлов проверьте, что механизм подтверждения продолжит работать. Случайно удалённый файл способен нарушить отправку, хотя сами страницы открываются нормально.
Что включить в приёмку подтверждения
- Отправитель обращается к рабочему хосту, а не к тестовой копии.
- Файл открывается по ожидаемому публичному адресу и содержит нужное значение.
- URL отправляемых страниц соответствуют области настройки ключа.
- После смены конфигурации проведена повторная проверка доступности файла.
- В инструкции записано, кто может менять ключ и как обновить отправитель.
Как устроить очередь уведомлений IndexNow
Очередь связывает событие публикации с попыткой доставки. Для каждой записи полезны URL, вид изменения, время появления события, версия публикации, время последней попытки, её ответ и следующее запланированное действие. Названия полей команда выбирает сама; важно, чтобы по ним можно было восстановить историю конкретного изменения.
Объединяйте повторные события одного адреса, но сохраняйте самое позднее состояние. Допустим, редактор исправил страницу, отправка началась, а через минуту вышла ещё одна правка. Ответ на первый запрос относится к уже отправленной версии. Он не должен автоматически стирать новое событие, появившееся во время выполнения запроса.
Как не потерять новую версию
Перед отправкой зафиксируйте номер версии или время события, вошедшего в пакет. После ответа сравните его с актуальной записью. Если за это время появился новый выпуск, завершите старую попытку, но оставьте более свежую запись ожидающей отправки. Это правило работы очереди, предлагаемое для интеграции; оно не является отдельным параметром протокола.
Отдельно задайте восстановление после остановки процесса. Состояние «отправляется» не должно навсегда блокировать URL, если исполнитель завершился до записи результата. Сохраняйте время начала попытки и правило возврата зависших записей на разбор. Интервал выбирают с учётом устройства системы; произвольное короткое значение способно запустить параллельные дубли.
Не удаляйте историю сразу после получения ответа. Для расследования полезно видеть, какой выпуск страницы был связан с уведомлением. При этом ограничьте срок хранения технических подробностей и доступ к журналу. Команде маркетинга обычно достаточно статуса и причины задержки, а разработчику нужны дополнительные сведения о запросе.
Как разбирать ответы IndexNow
Коды ниже приведены по документации протокола. Ответ 200 подтверждает получение отправки, 202 означает, что проверка ключа ещё ожидается. Код 400 указывает на неверный формат, 403 — на проблему ключа, 422 — на несоответствие URL хосту или правилам ключа, 429 — на слишком частые запросы. Ни один из этих ответов не является отчётом о позициях страницы.
Внутренние действия по ответам определите отдельно. При ошибке формата нужно исправлять формирование запроса, а не бесконечно повторять тот же пакет. При проблеме ключа проверьте файл и конфигурацию. При ограничении частоты уменьшите нагрузку и назначьте отложенную попытку. При сетевом сбое сохраните отсутствие подтверждения: не называйте такую попытку ни гарантированно принятой, ни окончательно отклонённой.
Повторные попытки должны иметь предел и владельца. После серии неудач запись переводят на разбор с причиной и временем следующего решения. Иначе автоматизация скрывает проблему: адрес месяцами числится «в работе», а ответственный узнаёт о нём только после жалобы. Уведомление о сбое должно вести к конкретной очереди и понятному действию.
Как измерять работу отправителя
Рассмотрим условный журнал за выпуск. Система получила 120 событий, которые относились к 90 уникальным URL. Повторные события объединили. Ещё 6 адресов исключили как служебные, поэтому к отправке осталось 84 URL. Из них для 60 получено подтверждение получения, а 24 ожидают повторной попытки. Проверка баланса: 60 + 24 = 84.
Доля подтверждённых URL в этой очереди составляет 60 / 84 × 100 ≈ 71,4%. Это показатель доставки уведомлений для выбранного выпуска. Нельзя подписывать его «доля проиндексированных страниц»: в примере состояние поискового индекса вообще не измерялось. Также 120 событий не означают 120 разных страниц, а разница 120 − 90 = 30 описывает избыток событий над числом уникальных адресов.
Рядом с числом ожидающих записей показывайте возраст самой старой и причины задержки. Одинаковый остаток из 24 URL может означать недавний массовый выпуск или давний сбой. Если новые события постоянно вытесняют старые, высокий общий объём отправок маскирует незавершённую работу. Разбивайте очередь по времени появления и ответственному процессу.
Разделите три вида подтверждения
Журнал отправителя показывает доставку уведомления. Серверные наблюдения могут показать последующий запрос страницы роботом. Сведения соответствующей поисковой системы помогают исследовать индексирование. Эти данные отвечают на разные вопросы и относятся к разным моментам времени. Не заменяйте отсутствующий результат одного этапа успешным статусом другого.
Как принять интеграцию перед постоянной работой
Проведите небольшой управляемый выпуск: новая публичная страница, содержательная правка существующей, повторное событие той же версии и изменение во время незавершённой попытки. Отдельно проверьте, что черновики остаются за пределами отправки. Для удаления используйте согласованный тестовый сценарий, чтобы проверка механизма не затронула нужный посетителям материал.
Результат приёмки — не только успешный запрос. Сохраните путь от события до записи в журнале, убедитесь в сохранности новой версии при повторе и назначьте ответственного за ошибки. После обновления модуля повторите ключевые сценарии. Тогда IndexNow остаётся наблюдаемой частью публикации, а не настройкой, о существовании которой вспоминают после поломки.
Вопросы и ответы
Гарантирует ли IndexNow появление страницы в поиске?
Нет. Получение уведомления, обход и индексирование — разные этапы. Успешный ответ отправителю подтверждает только соответствующий этап обмена, а состояние страницы в поиске проверяют отдельно.
Нужно ли регулярно отправлять все старые URL?
Рабочую очередь связывают с реальными изменениями. Повторная отправка неизменившегося архива не заменяет контроль новых публикаций и ошибок доставки. Сначала определите источник событий и правила отбора.
Что делать, если отправка зависла без ответа?
Сохраните попытку без подтверждения и используйте предусмотренное восстановление очереди. Не стирайте запись как успешно завершённую. При повторе учитывайте, не появилась ли более новая версия страницы.
Можно ли установить сразу два отправляющих модуля?
Сначала выясните, кто уже отправляет уведомления и какие события он получает. Независимые механизмы усложняют диагностику и могут дублировать поток. Удобнее иметь одного владельца процесса и согласованный журнал.
Какой отчёт нужен маркетологу после подключения?
Покажите число уникальных изменённых URL, исключения, подтверждённые уведомления, остаток и его возраст. Результаты обхода и индексирования выводите отдельно с источником и датой наблюдения, без обещания роста позиций.
Подрядчики по теме статьи
SEO продвижение — компании в каталоге PROMOmi.
