Как отключить REST API в WordPress без поломки админки и плагинов

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

Когда REST API действительно мешает

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

Типичные симптомы

• в логах много запросов к /wp-json/ от ботов;
• в поиске всплывают технические URL вида /wp-json/wp/v2/posts;
• админка или редактор начинают вести себя странно после «жесткого» отключения;
• плагин на фронтенде перестает подгружать данные через AJAX/REST;
• в консоли браузера появляются ошибки загрузки JSON.

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

Диагностика: кто вообще ходит в REST API

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

На сервере можно быстро посмотреть обращения по логам веб-сервера. Ищите строки с /wp-json/ и оцените, кто именно обращается: бот, пользователь, плагин или ваш же фронтенд.

# Пример для nginx access.log
# Ищем обращения к REST API
grep 'wp-json' /var/log/nginx/access.log | tail -n 50

Если у вас нет доступа к логам, хотя бы проверьте публичные URL вручную в браузере:

https://example.com/wp-json/
https://example.com/wp-json/wp/v2/posts

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

Что лучше: отключить полностью или ограничить доступ

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

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

Пошагово: как ограничить REST API для гостей

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

<?php
add_filter( 'rest_authentication_errors', function( $result ) {
    if ( true === $result || is_wp_error( $result ) ) {
        return $result;
    }

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

    return $result;
} );

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

Если нужно оставить доступ только к отдельным endpoint'ам

Иногда фронтенду нужен только один endpoint, например для формы или поиска. Тогда лучше не рубить всё подряд, а разрешить конкретные маршруты. Пример ниже показывает принцип: вы можете пропускать только нужные пути, а остальное закрывать.

<?php
add_filter( 'rest_authentication_errors', function( $result ) {
    if ( true === $result || is_wp_error( $result ) ) {
        return $result;
    }

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

    if ( strpos( $request_uri, '/wp-json/myplugin/v1/search' ) !== false ) {
        return $result;
    }

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

    return $result;
} );

Этот вариант уже требует аккуратности: проверяйте конкретные пути и не опирайтесь на него как на универсальное решение для всех проектов.

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

После внедрения не ограничивайтесь открытием главной страницы. Проверьте несколько сценариев:

• откройте /wp-json/ в браузере в режиме инкогнито;
• проверьте редактор записей в админке;
• проверьте фронтенд-формы, поиск, фильтры и динамические блоки;
• посмотрите консоль браузера на ошибки загрузки JSON;
• если есть доступ к логам, убедитесь, что публичные обращения к REST API перестали идти или стали получать 401.

Хороший признак — в инкогнито REST API закрыт, а в админке всё работает как раньше. Если после правки Gutenberg начал выдавать ошибки, значит вы ограничили доступ слишком жестко.

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

Отключили REST API через «жесткий» фильтр и сломали редактор

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

Добавили код в родительскую тему

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

Забыли про плагин, который использует REST на фронтенде

Часто проблема проявляется не сразу, а только в отдельном блоке или форме. Если после ограничения API что-то перестало подгружаться, временно отключите фильтр и проверьте, какой плагин делает запросы к /wp-json/.

Проверили только главную страницу

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

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

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

Но не пытайтесь «очистить» сайт до состояния, когда перестают работать базовые сценарии. Любая оптимизация в WordPress должна проверяться на конкретных страницах и в конкретных ролях пользователей. Особенно если у вас есть редакторы, авторы, формы, фильтры и сторонние интеграции.

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

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