Как закрыть WP REST API от индексации и лишнего доступа в WordPress

WP REST API в WordPress нужен для редактора, приложений, интеграций и части плагинов. Но на живом сайте часто всплывает другая задача: убрать из индекса служебные JSON-эндпоинты, ограничить доступ к части маршрутов и при этом не сломать блоки, админку и внешние сервисы.

Полностью отключать REST API обычно плохая идея. Гораздо безопаснее сначала понять, какие именно маршруты доступны публично, какие из них реально используются, а затем точечно закрыть лишнее.

Когда проблема действительно есть

Сценарий обычно выглядит так: в поиске появляются URL вида /wp-json/ или отдельные маршруты плагинов, в логах видно много запросов к REST API, а некоторые security-плагины начинают резать и нужные вызовы тоже. Если сайт работает на Gutenberg, то грубое отключение API быстро ломает редактор и часть фронтенд-функций.

Что проверить до изменений

• Открывается ли /wp-json/ в браузере без ошибок.
• Использует ли сайт редактор блоков, мобильное приложение или внешнюю интеграцию.
• Есть ли в индексе страницы вида /wp-json/wp/v2/posts или похожие служебные URL.
• Не завязаны ли на REST API формы, поиск, фильтры или кастомные виджеты.

Если вы не уверены, сначала посмотрите, какие маршруты реально доступны. Это проще, чем гадать по симптомам.

add_action('rest_api_init', function () {
    $routes = rest_get_server()->get_routes();

    if (defined('WP_DEBUG') && WP_DEBUG) {
        error_log('REST routes count: ' . count($routes));
    }
});

Этот код не решает проблему сам по себе, но помогает понять масштаб: на сайте может быть не только ядро WordPress, но и маршруты от SEO-плагина, формы, кэша, темы и сторонних интеграций.

Как закрыть лишнее без поломки сайта

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

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

add_filter('rest_endpoints', function ($endpoints) {
    if (is_user_logged_in()) {
        return $endpoints;
    }

    $blocked = array(
        '/wp/v2/users',
        '/wp/v2/comments',
    );

    foreach ($blocked as $route) {
        if (isset($endpoints[$route])) {
            unset($endpoints[$route]);
        }
    }

    return $endpoints;
});

Такой вариант полезен, если вам не нужно публично показывать список пользователей или комментарии через API. Но если у вас есть фронтенд-компоненты, которые читают комментарии через REST, этот код надо доработать.

Ограничение доступа по правам, а не по факту запроса

Если задача не в индексации, а именно в защите данных, лучше проверять права через permission_callback в собственных маршрутах. Это правильнее, чем пытаться «запретить всё» на уровне сервера.

add_action('rest_api_init', function () {
    register_rest_route('myplugin/v1', '/report', array(
        'methods'  => 'GET',
        'callback' => 'myplugin_get_report',
        'permission_callback' => function () {
            return current_user_can('manage_options');
        },
    ));
});

function myplugin_get_report(WP_REST_Request $request) {
    return rest_ensure_response(array(
        'status' => 'ok',
    ));
}

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

Что делать с индексацией wp-json

Служебные REST-URL обычно не должны попадать в поиск. Но закрывать их через robots.txt недостаточно, если URL уже известен поисковику. Надежнее сочетать несколько уровней: не генерировать лишние ссылки, не отдавать их в sitemap, а при необходимости добавлять заголовки или правила индексации на уровне SEO-плагина.

Если на сайте есть SEO-плагин, проверьте, не включил ли он автоматическую индексацию служебных страниц. Иногда проблема возникает не в WordPress, а в том, что в карту сайта или внутренние ссылки попадают технические эндпоинты.

Если нужен более широкий контроль дублей и служебных страниц, иногда удобнее использовать связку SEO-настроек и чистки сайта. В таких задачах помогает, например, Clearfy Pro: https://wpshop.ru/plugins/clearfy?utm_source=wpdebug.ru&utm_medium=article&utm_campaign=kak-zakryt-wp-json-ot-indeksacii-i-lishnego-dostupa-v-wordpress. Но даже с плагином важно понимать, какие именно маршруты вы закрываете.

Пошаговая проверка после внедрения

После правок не ограничивайтесь тем, что сайт «открылся без ошибок». Проверьте REST API в нескольких режимах.

1. Откройте /wp-json/ в браузере в режиме гостя.
2. Проверьте, доступны ли нужные маршруты для авторизованного пользователя.
3. Зайдите в редактор блоков и убедитесь, что он сохраняет записи без ошибок.
4. Проверьте фронтенд-формы, фильтры и виджеты, если они используют AJAX через REST.
5. Посмотрите логи браузера и консоль на предмет 401, 403 и 404.

Если у вас есть доступ к WP-CLI, можно быстро проверить, не сломалась ли базовая загрузка сайта после изменений:

wp option get siteurl
wp option get home

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

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

Отключили REST API целиком

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

Скрыли маршруты, не проверив фронтенд

Некоторые темы и плагины используют REST API незаметно для администратора. После отключения на сайте могут перестать работать поиск, фильтры, автодополнение или комментарии. Поэтому сначала смотрите сетевые запросы в браузере, а уже потом режьте маршруты.

Путают индексацию и доступ

Закрыть URL от поисковиков и запретить доступ к данным — это разные задачи. robots.txt не защищает данные, а фильтр маршрутов не всегда решает вопрос индексации. Нужна комбинация мер.

Ломают собственные маршруты плагина

Если у вас есть кастомный endpoint, не используйте общие правила, которые удаляют все маршруты подряд. Для своих маршрутов лучше задавать явный permission_callback и тестировать доступ для гостя, редактора и администратора отдельно.

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

Не делайте REST API «невидимым» без причины. Чем агрессивнее фильтрация, тем выше риск сломать обновления редактора и интеграции. Для безопасности важнее убрать лишние публичные маршруты, ограничить чувствительные ответы и следить за правами доступа.

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

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

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