Как отключить REST API для гостей в WordPress и не сломать редактор и плагины

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

Ниже — рабочая схема: сначала быстро понять, кто именно ходит в REST API, затем ограничить его для неавторизованных пользователей, после чего проверить, что редактор и плагины не сломались.

Когда это вообще нужно

Ограничение REST API имеет смысл, если в логах или в панели мониторинга видно много запросов к /wp-json/ от ботов, а сайт не использует публичные API-маршруты для фронтенда. Это типичный сценарий для корпоративных сайтов, блогов и лендингов, где WordPress нужен как CMS, а не как публичный API-сервер.

Но если у вас есть:

• Gutenberg-редактор в админке;
• плагины форм, поиска, фильтров или кеша, которые используют REST;
• мобильное приложение или внешний сервис, который читает контент через API;
• кастомные блоки, подгружающие данные асинхронно;

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

Диагностика: что именно использует REST API

Перед изменениями проверьте, есть ли на сайте реальные обращения к REST API не только из админки. Самый простой способ — открыть главную страницу и поискать в исходном коде или в DevTools запросы к /wp-json/. Если сайт активно использует блоки, часть запросов будет идти из редактора и фронтенда.

Что смотреть в первую очередь

• сетевые запросы в браузере к /wp-json/;
• ошибки в консоли после входа в админку;
• логи плагинов форм и кеша;
• страницы, где подгружается контент без перезагрузки.

Если нужно быстро проверить доступность API снаружи, можно сделать обычный запрос:

curl -I https://example.com/wp-json/

Для гостя на живом сайте вы обычно увидите ответ 200 или 401/403 в зависимости от настроек и плагинов. Важно не сам код ответа, а то, не ломает ли ограничение нужные сценарии.

Пошаговое решение: ограничить REST API для неавторизованных

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

<?php
add_filter( 'rest_authentication_errors', function( $result ) {
    // Если уже есть ошибка аутентификации, не вмешиваемся.
    if ( ! empty( $result ) ) {
        return $result;
    }

    // Авторизованным пользователям REST API оставляем.
    if ( is_user_logged_in() ) {
        return $result;
    }

    // Разрешаем служебные запросы, если они нужны вашему сайту.
    $uri = isset( $_SERVER['REQUEST_URI'] ) ? wp_unslash( $_SERVER['REQUEST_URI'] ) : '';

    if ( strpos( $uri, '/wp-json/' ) === false ) {
        return $result;
    }

    return new WP_Error(
        'rest_forbidden',
        __( 'REST API доступен только авторизованным пользователям.', 'textdomain' ),
        array( 'status' => 401 )
    );
} );

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

Вариант через MU-плагин

Создайте файл wp-content/mu-plugins/disable-rest-for-guests.php. Если папки mu-plugins нет, создайте её вручную.

<?php
/**
 * Plugin Name: Disable REST API for Guests
 */

add_filter( 'rest_authentication_errors', function( $result ) {
    if ( ! empty( $result ) || is_user_logged_in() ) {
        return $result;
    }

    return new WP_Error(
        'rest_forbidden',
        __( 'REST API доступен только авторизованным пользователям.', 'textdomain' ),
        array( 'status' => 401 )
    );
} );

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

Если нужен более мягкий вариант: блокировать только часть маршрутов

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

Для этого в фильтре можно проверять маршрут и разрешать только нужные пути. Пример ниже — шаблон, который надо адаптировать под свой сайт:

<?php
add_filter( 'rest_authentication_errors', function( $result ) {
    if ( ! empty( $result ) || is_user_logged_in() ) {
        return $result;
    }

    $request_uri = isset( $_SERVER['REQUEST_URI'] ) ? wp_unslash( $_SERVER['REQUEST_URI'] ) : '';

    // Разрешаем только чтение публичных записей.
    $allowed = array(
        '/wp-json/wp/v2/posts',
        '/wp-json/wp/v2/pages',
    );

    foreach ( $allowed as $path ) {
        if ( strpos( $request_uri, $path ) !== false ) {
            return $result;
        }
    }

    return new WP_Error( 'rest_forbidden', 'REST API закрыт для гостей.', array( 'status' => 401 ) );
} );

Такой подход полезен, если сайт использует фронтенд-подгрузку контента, но вы хотите убрать лишние маршруты, которые не должны быть доступны извне.

Сравнение подходов

Подход	Что делает	Плюсы	Минусы
Плагин для ограничения REST	Блокирует API по заданным правилам	Быстро, без кода	Нужно проверять, не режет ли нужные маршруты
MU-плагин с фильтром	Точечно ограничивает гостей	Контроль, предсказуемость, не зависит от темы	Нужен доступ к файлам
Полное отключение API	Режет всё	Просто	Часто ломает редактор и интеграции

Если нужен не только REST, но и общая чистка сайта от лишних технических сущностей, иногда удобнее делать это набором точечных настроек. Например, в Clearfy Pro есть инструменты для удаления части служебного мусора и SEO-дублей, но ограничение REST API всё равно лучше держать отдельным кодом, если вам важна точность.

Проверка результата после внедрения

После изменения откройте сайт в режиме гостя и проверьте три сценария:

• главная и внутренние страницы открываются без ошибок;
• админка и редактор доступны после входа;
• в консоли браузера нет массовых ошибок к /wp-json/.

Дальше проверьте ответ API напрямую:

curl -I https://example.com/wp-json/

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

Для более точной проверки откройте редактор записи и посмотрите вкладку Network. Если там есть запросы к /wp-json/wp/v2/ и они проходят успешно, значит вы не сломали базовый сценарий работы WordPress.

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

Сломали редактор блоков

Это обычно происходит, когда REST API закрывают вообще для всех, включая авторизованных пользователей. Решение простое: не режьте запросы без проверки is_user_logged_in() и не блокируйте админку по одному только URI.

Плагин форм перестал отправлять данные

Некоторые формы и AJAX-сценарии используют REST-маршруты для отправки или валидации. Если после ограничения что-то перестало работать, проверьте документацию плагина и добавьте исключение для его маршрута.

Появились ложные 401 в логах

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

Добавили код в functions.php и потеряли контроль

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

Безопасность и производительность: что ещё учесть

Ограничение REST API не заменяет нормальную защиту сайта. Если цель — снизить шум от ботов, параллельно проверьте:

• актуальность ядра, темы и плагинов;
• наличие кеша страниц и объектного кеша, если он нужен;
• ограничение лишних публичных эндпоинтов в плагинах;
• логи ошибок PHP, чтобы не пропустить поломку после изменения.

Если у вас много публичного контента и REST API нужен частично, не пытайтесь «выиграть безопасность» ценой поломки сайта. В WordPress лучше работают точечные ограничения: закрыть лишнее, оставить нужное и проверить каждый сценарий руками.

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