Как настроить IndexNow в WordPress через robots.txt, sitemap и webhook

Если сайт на WordPress регулярно публикует новые страницы, а в индекс они попадают с задержкой, IndexNow может сократить время ожидания. Но сам по себе протокол ничего не гарантирует: важно правильно отдать ключ, не сломать robots.txt, не отправлять мусорные URL и понимать, что именно вы хотите ускорить — новые записи, обновления или удаление страниц.

Ниже — рабочая схема для WordPress: как проверить готовность сайта, как настроить отправку URL, чем отличается ручная отправка от автоматической и где чаще всего всё ломается.

Когда IndexNow действительно полезен

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

Если же сайт обновляется раз в месяц, а новых URL немного, выгода будет скромнее. В таком случае сначала стоит привести в порядок sitemap, canonical, noindex и внутреннюю перелинковку. IndexNow не исправляет проблемы с дублями и не заменяет базовую SEO-гигиену.

Что должно быть в порядке до настройки

• сайт открывается по одному основному домену без лишних редиректов;
• robots.txt не закрывает важные разделы случайно;
• XML-карта сайта отдает только канонические URL;
• на страницах нет массовых 404 и цепочек редиректов;
• вы понимаете, какие URL нужно отправлять в поисковые системы, а какие — нет.

Диагностика: что проверить перед подключением

Перед внедрением IndexNow полезно пройтись по нескольким точкам. Это экономит время: если ключ не находится или sitemap содержит мусор, вы будете искать проблему не там.

Проверка robots.txt и sitemap

Откройте /robots.txt и убедитесь, что он доступен без авторизации и не блокирует важные разделы. Затем проверьте XML-карту сайта: в ней должны быть только страницы, которые вы реально хотите индексировать. Если у вас установлен SEO-плагин, он обычно уже генерирует sitemap, но это не повод не смотреть его вручную.

Минимальный набор проверок:

• https://site.ru/robots.txt отдает 200 OK;
• https://site.ru/sitemap_index.xml или аналогичная карта открывается;
• в sitemap нет страниц с noindex;
• в sitemap нет дублей с параметрами, архивами и служебными URL;
• основной домен совпадает с тем, что указан в настройках WordPress.

Проверка ключа IndexNow

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

Проверьте вручную:

https://site.ru/your-indexnow-key.txt

Ответ должен быть доступен публично, без редиректов и без запрета в robots.txt. Если файл отдается через CDN или кеширующий слой, убедитесь, что он не подменяется и не кэшируется с ошибкой.

Пошаговая настройка IndexNow в WordPress

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

Вариант 1: через плагин

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

После установки проверьте, умеет ли плагин:

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

Если в плагине нет логов, отладка становится неудобной. Тогда лучше либо включить логирование на уровне сервера, либо перейти к собственному коду.

Вариант 2: отправка URL из темы или мини-плагина

Ниже пример, который отправляет URL при публикации или обновлении записи. Это не полноценный плагин, а рабочая заготовка для mu-plugin или собственного плагина.

<?php
add_action('save_post', function ($post_id, $post, $update) {
    if (wp_is_post_revision($post_id) || wp_is_post_autosave($post_id)) {
        return;
    }

    if ($post->post_status !== 'publish') {
        return;
    }

    $url = get_permalink($post_id);
    if (!$url) {
        return;
    }

    $key = 'YOUR_INDEXNOW_KEY';
    $endpoint = 'https://api.indexnow.org/indexnow';

    $body = array(
        'host' => wp_parse_url(home_url(), PHP_URL_HOST),
        'key' => $key,
        'keyLocation' => home_url('/' . $key . '.txt'),
        'urlList' => array($url),
    );

    $response = wp_remote_post($endpoint, array(
        'timeout' => 10,
        'headers' => array('Content-Type' => 'application/json; charset=utf-8'),
        'body' => wp_json_encode($body),
    ));

    if (is_wp_error($response)) {
        error_log('IndexNow error: ' . $response->get_error_message());
        return;
    }

    $code = wp_remote_retrieve_response_code($response);
    if ($code < 200 || $code >= 300) {
        error_log('IndexNow HTTP code: ' . $code);
    }
}, 10, 3);

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

Вариант 3: отправка пачки URL через webhook

Если у вас редакция публикует материалы пачками, удобнее собирать URL и отправлять их одним запросом. Это снижает количество обращений к API и уменьшает шанс упереться в лимиты или сетевые сбои.

<?php
function my_send_indexnow_urls(array $urls) {
    $urls = array_values(array_filter(array_unique($urls)));
    if (empty($urls)) {
        return false;
    }

    $body = array(
        'host' => wp_parse_url(home_url(), PHP_URL_HOST),
        'key' => 'YOUR_INDEXNOW_KEY',
        'keyLocation' => home_url('/YOUR_INDEXNOW_KEY.txt'),
        'urlList' => $urls,
    );

    $response = wp_remote_post('https://api.indexnow.org/indexnow', array(
        'timeout' => 10,
        'headers' => array('Content-Type' => 'application/json; charset=utf-8'),
        'body' => wp_json_encode($body),
    ));

    return !is_wp_error($response) && wp_remote_retrieve_response_code($response) >= 200 && wp_remote_retrieve_response_code($response) < 300;
}

Такой подход удобен, если вы хотите запускать отправку по cron после импорта, массового редактирования или публикации серии материалов.

Как проверить, что IndexNow сработал

Проверка нужна не только после установки, но и после каждого изменения логики отправки. Иначе легко получить ситуацию, когда код выполняется, а URL уходит с неверным host или ключом.

1. Откройте ключевой файл по прямой ссылке и убедитесь, что он доступен.
2. Проверьте ответ API: для успешной отправки обычно приходит 2xx-статус.
3. Посмотрите серверные логи или error_log, если отправка идет из кода.
4. Проверьте, что в sitemap и на странице указан один и тот же канонический URL.
5. После публикации обновите страницу и убедитесь, что отправляется именно финальный permalink, а не черновой адрес.

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

Сравнение подходов: плагин, код или гибрид

Частые ошибки и как их исправить

Ключовый файл лежит не в корне

Это самая банальная причина отказа. Если файл доступен по вложенному пути, но не по корню сайта, проверка провалится. Решение простое: разместить файл в корне и проверить URL без редиректов.

Отправляется неканонический URL

Часто в код попадает ссылка с UTM-параметрами, временный адрес предпросмотра или URL с другим протоколом. Отправлять нужно только финальный канонический адрес, который реально должен индексироваться.

Сайт закрыт редиректами или смешанными доменами

Если WordPress живет на одном домене, а фронт отдает другой, IndexNow может получить host, который не совпадает с ключом или sitemap. Проверьте home_url(), site_url(), настройки CDN и правила редиректов.

Плагин шлет слишком много запросов

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

Кеш мешает проверке

Иногда ключевой файл или robots.txt отдаются через агрессивный кеш, и после обновления вы видите старую версию. Очистите кеш на уровне плагина, сервера и CDN, затем перепроверьте URL напрямую.

Практические советы по безопасности и производительности

Не храните ключ в открытом месте, если у вас есть риск утечки репозитория. Для мини-плагина допустимо вынести ключ в константу в wp-config.php или хотя бы в отдельный конфиг, который не попадает в публичный git.

Если отправка идет на каждом save_post, добавьте защиту от дублей и автосохранений. Иначе редактор будет генерировать лишние запросы при каждом черновике.

Для больших сайтов полезно:

• отправлять только опубликованные канонические URL;
• не слать архивы, теги и служебные страницы без необходимости;
• логировать только ошибки, а не каждый успешный запрос;
• проверять, что cron или webhook не создают очередь из повторов;
• после массового импорта делать одну пакетную отправку, а не сотни одиночных.

Если вам нужно параллельно чистить сайт от дублей, служебных страниц и лишних SEO-артефактов, удобнее сначала привести структуру к норме, а уже потом включать автоматическую отправку URL. В таких задачах часто помогает связка с Clearfy Pro, если вам нужен практичный набор инструментов для технической чистки и SEO-настроек.

Что делать после запуска

После включения IndexNow не оставляйте настройку без наблюдения. Первую неделю проверьте несколько публикаций вручную: новая запись, обновление старой записи, удаление страницы. Смотрите не только на код ответа API, но и на то, совпадает ли отправленный URL с каноническим адресом в WordPress.

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