REST API в WordPress часто оставляют включённым по умолчанию, а потом удивляются лишним запросам, утечке служебных данных в публичной части или конфликтам с плагинами безопасности. Полностью отключать API обычно плохая идея: редактор блоков, админка и часть плагинов на нём завязаны. Практичнее ограничить доступ для гостей и оставить его для авторизованных пользователей.
Ниже — рабочий сценарий: сначала быстро понять, действительно ли REST API нужен в публичной части, потом аккуратно закрыть его для неавторизованных, а затем проверить, что ничего не отвалилось.
Когда REST API лучше ограничить, а не выключать полностью
Если сайт использует Gutenberg, мобильное приложение WordPress, AJAX-запросы некоторых плагинов или фронтенд-формы, полный запрет REST API почти наверняка создаст проблемы. Но если у вас обычный контентный сайт, а в логах видно много обращений к /wp-json/ от ботов и сканеров, ограничение для гостей часто даёт более предсказуемый результат.
Что обычно видно в симптомах
- в логах много запросов к
/wp-json/wp/v2/posts,/wp-json/wp/v2/usersи похожим маршрутам; - плагины безопасности ругаются на доступ к REST API извне;
- в публичной части не нужны JSON-эндпоинты, но админка и редактор должны работать;
- после установки плагина оптимизации появляются ошибки в консоли браузера на страницах редактирования.
Если у вас уже есть проблема с индексацией служебных страниц, это не решается через REST API. Тут речь именно о доступе к API и его ограничении на уровне логики WordPress.
Диагностика: что именно использует REST API на сайте
Перед изменениями проверьте, кто и как обращается к API. Самый простой способ — открыть сайт в браузере, зайти в DevTools и посмотреть вкладку Network на страницах, где есть формы, поиск, фильтры, редактор блоков или виджеты с динамической подгрузкой. Если запросы идут на /wp-json/, значит API используется на фронтенде.
Ещё полезно проверить, не завязаны ли на REST API плагины, которые вы реально используете: кэш, формы, слайдеры, конструкторы, интеграции с CRM. Если сомневаетесь, временно ограничьте доступ только для гостей на тестовой копии сайта, а не на боевом домене.
Быстрая проверка маршрутов
Откройте в браузере:
https://example.com/wp-json/Если сайт публичный, вы увидите JSON с информацией о маршрутах. Это нормально. Вопрос в том, нужен ли такой доступ незалогиненным пользователям именно на вашем проекте.
Пошаговое решение: закрыть REST API для гостей через functions.php или мини-плагин
Самый безопасный вариант — не трогать ядро и не ставить сомнительные плагины, а добавить небольшой код в дочернюю тему или в собственный mu-plugin. Так проще откатить изменения и не потерять их после обновления темы.
Ниже пример, который блокирует REST API для неавторизованных пользователей, но оставляет админку и авторизованные запросы в покое.
<?php
add_filter( 'rest_authentication_errors', 'wpplugin_restrict_rest_api_for_guests' );
function wpplugin_restrict_rest_api_for_guests( $result ) {
if ( ! empty( $result ) ) {
return $result;
}
if ( is_user_logged_in() ) {
return $result;
}
return new WP_Error(
'rest_forbidden',
__( 'REST API доступен только авторизованным пользователям.', 'textdomain' ),
array( 'status' => 401 )
);
}Это жёсткий вариант. Его стоит использовать только если вы уверены, что публичные REST-запросы на сайте не нужны. На практике чаще нужен более мягкий подход: разрешить только конкретные маршруты, а всё остальное закрыть.
Более аккуратный вариант: разрешить только нужные маршруты
Например, если у вас есть фронтенд-форма или плагин, который обращается к собственному маршруту, можно оставить его открытым, а всё остальное ограничить.
<?php
add_filter( 'rest_authentication_errors', 'wpplugin_allow_only_selected_rest_routes' );
function wpplugin_allow_only_selected_rest_routes( $result ) {
if ( ! empty( $result ) || is_user_logged_in() ) {
return $result;
}
$request_uri = isset( $_SERVER['REQUEST_URI'] ) ? wp_unslash( $_SERVER['REQUEST_URI'] ) : '';
$allowed_prefixes = array(
'/wp-json/my-plugin/v1/',
'/wp-json/contact-form-7/v1/',
);
foreach ( $allowed_prefixes as $prefix ) {
if ( strpos( $request_uri, $prefix ) !== false ) {
return $result;
}
}
return new WP_Error(
'rest_forbidden',
__( 'REST API закрыт для гостей.', 'textdomain' ),
array( 'status' => 401 )
);
}Этот вариант требует аккуратности: список маршрутов нужно поддерживать вручную. Если плагин обновился и поменял endpoint, доступ может сломаться.
Сравнение подходов: плагин, код, компромисс
| Подход | Когда подходит | Минусы |
|---|---|---|
| Плагин безопасности | Если нужен быстрый интерфейс и вы не хотите писать код | Может скрывать логику, добавлять лишние проверки и конфликтовать с другими плагинами |
| Код в дочерней теме или mu-plugin | Если нужен точный контроль над доступом | Нужно тестировать маршруты и обновлять исключения вручную |
| Полное отключение REST API | Почти не используется API, сайт простой и статичный | Риск сломать редактор, плагины и фронтенд-интеграции |
Если нужен не только REST API, но и общая чистка WordPress от лишнего технического мусора, иногда удобнее собирать такие настройки в одном месте. Например, Clearfy Pro от WPShop закрывает часть типовых задач по оптимизации и удалению лишних функций, но даже в этом случае логику доступа к REST API лучше проверять отдельно на вашем наборе плагинов: https://wpshop.ru/plugins/clearfy.
Как проверить результат после внедрения
После добавления кода не ограничивайтесь открытием главной страницы. Проверка должна быть практической.
- Откройте
/wp-json/в режиме инкогнито — для гостя должен быть отказ или пустой ответ в зависимости от вашей логики. - Зайдите в админку и откройте редактор записи — он должен работать без ошибок.
- Проверьте формы, поиск, фильтры и виджеты, если они используют AJAX или REST.
- Посмотрите консоль браузера на предмет ошибок
401,403илиrest_forbidden. - Проверьте логи сервера и журнал плагина безопасности, если он установлен.
Если после ограничения API перестал работать блоковый редактор, значит вы слишком жёстко закрыли доступ и нужно искать конкретный маршрут, который использует админка или плагин.
Частые ошибки и как их исправить
1. Код вставили в родительскую тему
После обновления темы изменения пропадут. Для таких правок используйте дочернюю тему или mu-plugins.
2. Закрыли REST API без теста на фронтенде
Некоторые формы и динамические блоки работают через JSON. Если после правки что-то перестало отправляться, ищите запросы к /wp-json/ в DevTools и добавляйте исключения.
3. Путают REST API и XML-RPC
Это разные механизмы. Если вы уже отключали XML-RPC, это не означает, что REST API тоже можно выключить без последствий.
4. Используют готовый сниппет без проверки статуса ответа
Если возвращать неправильный объект или ломать фильтр, можно получить белый экран или странные ошибки в админке. В примерах выше используется штатный WP_Error, а не выдуманные конструкции.
Практические советы по безопасности и производительности
Ограничение REST API само по себе не делает сайт безопасным, но уменьшает поверхность атаки. Это полезно только вместе с нормальной базовой гигиеной: актуальные версии WordPress, плагинов и темы, ограничение прав пользователей, двухфакторная авторизация для админов и контроль логов.
Если цель — снизить нагрузку, не ждите чудес от одного фильтра. Сначала посмотрите, действительно ли REST-запросы создают проблему. Иногда основная нагрузка идёт от кэша, внешних скриптов, медленных запросов к базе или тяжёлых плагинов, а REST API просто попадает под подозрение первым.
Для проектов, где важна техническая чистота, удобно держать такие изменения в одном месте и документировать их рядом с другими правками: что отключено, зачем и как откатить. Это экономит время, когда сайт передаётся другому разработчику или возвращается к поддержке через несколько месяцев.
Если нужен более широкий набор точечных оптимизаций, имеет смысл смотреть на инструменты, которые не навязывают магию, а дают контроль над конкретными функциями WordPress. Но даже тогда проверка после внедрения остаётся обязательной: без неё легко закрыть не то, что нужно, и потом искать причину уже на боевом сайте.