IndexNow возвращает 403 или 422: как проверить ключ

При ошибках IndexNow 403 или 422 сверяйте ключ, его доступный файл и адреса отправленных страниц как один набор. У Яндекса 403 связан с невозможностью загрузить ключ или его несоответствием адресам, а 422 имеет несколько причин. Читайте конкретное сообщение ответа: один код не определяет единственное поле для исправления.

Что ключ подтверждает, а чего не обещает

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

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

Соберите один проверяемый набор

До повтора запроса сохраните endpoint, способ отправки, ключ, расположение ключевого файла и один адрес страницы. Если используется пакет, добавьте его host и список URL. Проверяйте именно фактически сформированные значения: настройка в панели и отправленный запрос могут различаться.

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

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

Как читать ответ endpoint

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

Учебная проверка ошибки расположения

Предположим, настройка указывает на один ключевой файл, а после изменения маршрутов по этому адресу открывается обычная страница сайта. Это вымышленный сценарий. Даже если браузер показывает красивую страницу без ошибки, проверяемое содержимое не совпадает с ожидаемым файлом.

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

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

Что делать с ожидающей проверкой

202 отличается от подтверждённой ошибки параметра. Сначала проверьте известные условия доступа, затем используйте предусмотренную процедуру наблюдения. Не меняйте ключ при каждом таком ответе: вы потеряете возможность понять, что именно исправилось и какой набор проверяется.

Также не рассылайте одинаковые URL непрерывным циклом. В журнале полезны последняя попытка, ответ, внесённое изменение и основание следующего повтора. Факт ожидания не требует создавать поток новых запросов без изменения условий.

Приём запроса не равен индексированию

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

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

Проверка исправления без массовой повторной отправки

1. Сохраните фактические параметры и точный ответ одной неудачной попытки.
2. Проверьте файл ключа по указанному адресу и сравните полученное содержимое.
3. Сверьте host, URL и keyLocation с областью и форматом выбранного способа отправки.
4. Исправьте установленное расхождение, не меняя одновременно все параметры.
5. Выполните ограниченную контрольную отправку в рамках отдельной согласованной проверки.
6. Зафиксируйте приём запроса отдельно от последующего состояния страницы в поиске.

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

Что включить в задачу на аудит

Для технического SEO-аудита подготовьте пример параметров и ответа без лишних данных. При доработке сайта отдельно опишите маршрут ключевого файла и правила формирования URL. Их удобнее проверять как связанные части одной функции.

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