Как исправить 404 на wp-json в WordPress: диагностика REST API и настройка сервера

Автор: Наталья Ковалева | Опубликовано: 15.08.2026

Если в браузере или в логах вы видите 404 на /wp-json/, проблема обычно не в самом REST API, а в маршрутизации: сломанные правила пермалинков, неверная конфигурация Nginx/Apache, конфликтующий плагин или тема, которая вмешалась в rest_url() и связанные фильтры. Для сайта это быстро превращается в цепочку ошибок: не работают блоки редактора, формы, мобильные приложения, интеграции и часть админских запросов.

Ниже разберём, как локализовать источник 404, что проверить в WordPress и на сервере, и как убедиться, что REST API снова отвечает корректно.

Когда 404 на wp-json — это действительно проблема WordPress

Сначала стоит понять, где именно ломается маршрут. Если https://example.com/wp-json/ открывается, но отдельный endpoint даёт 404, это одна история. Если не открывается вообще, чаще всего проблема на уровне rewrite-правил или веб-сервера. Если 404 появляется только в админке или только на фронтенде, ищите конфликт плагина, темы или кэша.

Быстрая диагностика

Откройте /wp-json/ в браузере в режиме инкогнито.
Проверьте Settings → Permalinks и сохраните настройки без изменений.
Посмотрите, не отдаёт ли сервер 404 до загрузки WordPress.
Временно отключите плагины, которые меняют URL, безопасность, кэш или редиректы.
Проверьте, не блокирует ли WAF или mod_security запросы к /wp-json/.

Если у вас есть доступ к логам веб-сервера, это самый быстрый способ понять, доходит ли запрос до WordPress. Для Nginx и Apache ошибка маршрутизации выглядит по-разному, но смысл один: запрос не попадает в index.php.

Что проверить в WordPress в первую очередь

WordPress строит REST-маршруты через rewrite-правила. Если они устарели или повреждены, /wp-json/ может начать отдавать 404 даже при рабочем ядре. Самый безопасный шаг — сбросить правила пермалинков. Это не меняет структуру контента, а только пересобирает маршрутизацию.

// Можно временно добавить в mu-plugin или functions.php темы для проверки маршрутов.
add_action('init', function () {
    if (is_admin() && current_user_can('manage_options') && isset($_GET['flush_rewrite'])) {
        flush_rewrite_rules();
        wp_die('Rewrite rules flushed');
    }
});

Такой код нужен только как временный диагностический инструмент. После проверки его надо удалить. В продакшене не стоит вызывать flush_rewrite_rules() на каждом запросе: это лишняя нагрузка и риск для производительности.

Проверка через WP-CLI

Если есть доступ к консоли, удобнее проверить и пересобрать правила через WP-CLI:

wp rewrite flush --hard

После этого снова откройте /wp-json/. Если маршрут ожил, причина была в rewrite-правилах или в том, что плагин/тема не давали WordPress корректно их собрать.

Настройка Nginx и Apache: где чаще всего ломается маршрут

Когда REST API даёт 404 только на сервере, а WordPress внутри вроде бы настроен правильно, смотрите конфигурацию веб-сервера. Для Nginx критично, чтобы запросы не упирались в статическую обработку и уходили в index.php.

Пример для Nginx

location / {
    try_files $uri $uri/ /index.php?$args;
}

Если у вас кастомный конфиг, проверьте, что нет более специфичного блока location, который перехватывает /wp-json/ и отдаёт 404 раньше WordPress. Частая ошибка — отдельные правила для кэша, API или защитных путей, которые случайно задевают REST.

Что важно в Apache

Для Apache обычно нужен рабочий .htaccess с правилами WordPress. Если файл повреждён или mod_rewrite отключён, REST-маршруты тоже начинают сыпаться. Проверьте, что в корне сайта есть стандартный блок WordPress и что сервер разрешает чтение .htaccess.

Подход	Когда помогает	Компромисс
Сброс пермалинков	Сломаны rewrite-правила в WordPress	Не решает серверные 404
Проверка Nginx/Apache	404 приходит до WordPress	Нужен доступ к конфигам
Отключение конфликтных плагинов	REST ломает плагин безопасности/кэша	Нужно тестировать по одному

Плагины и тема: как найти конфликт без лишней паники

Если /wp-json/ перестал работать после обновления, не начинайте с переустановки ядра. Сначала проверьте плагины, которые меняют URL, скрывают wp-json, включают жёсткую защиту или переписывают заголовки. Отдельно смотрите плагины кэша и безопасности: они нередко режут REST-запросы по своим правилам.

Удобный способ локализации — временно отключить все плагины, кроме обязательных, и переключиться на стандартную тему. Если REST API ожил, включайте всё обратно по одному. Так вы найдёте конкретный конфликт, а не будете гадать по симптомам.

Минимальная проверка через код

add_action('rest_api_init', function () {
    register_rest_route('wpdetect/v1', '/ping', [
        'methods'  => 'GET',
        'callback' => function () {
            return rest_ensure_response(['ok' => true]);
        },
        'permission_callback' => '__return_true',
    ]);
});

Если собственный маршрут /wp-json/wpdetect/v1/ping тоже даёт 404, проблема почти наверняка не в конкретном endpoint, а в общей маршрутизации REST API.

Пошаговое решение, если wp-json отдаёт 404

Проверьте /wp-json/ напрямую в браузере и в curl.
Сохраните настройки пермалинков в админке.
Сбросьте rewrite-правила через WP-CLI или временный диагностический код.
Проверьте Nginx/Apache на наличие корректного try_files или .htaccess.
Отключите плагины безопасности, кэша и редиректов.
Переключитесь на стандартную тему и повторите тест.
Проверьте логи сервера и PHP error log на связанные ошибки.

Если после этих шагов REST API заработал, включайте плагины по одному и повторяйте тест. Обычно виновник находится быстро: либо кэш, либо security-плагин, либо кастомный код в теме.

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

Не ограничивайтесь открытием главной страницы. Проверьте именно REST-маршруты и ответ сервера.

Откройте /wp-json/ и убедитесь, что возвращается JSON, а не 404.
Проверьте собственный тестовый маршрут, если вы его добавляли.
В админке откройте редактор записей и убедитесь, что блоки и автосохранение работают.
Если сайт использует внешние интеграции, проверьте их запросы в логах.

Для быстрой проверки из консоли можно использовать:

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

В норме вы должны увидеть не 404, а ответ сервера с корректным статусом. Если там редирект, это тоже повод проверить правила безопасности и кэширования.

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

Скрыли wp-json через security-плагин

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

Сломали маршрутизацию на уровне сервера

Если index.php не участвует в обработке запроса, WordPress не получит шанс отдать JSON. Исправляется конфигом Nginx/Apache, а не настройками в админке.

Кэш отдает старый 404

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

Кастомный код вмешался в REST

Проверьте темы и mu-plugins на фильтры вроде rest_url, rest_authentication_errors и на код, который меняет rewrite-правила. Ошибка часто сидит в небольшом фрагменте, добавленном «на время» и забытом в продакшене.

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

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

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

Самый надёжный порядок работы здесь простой: сначала доказать, где возникает 404, потом исправить конкретный слой — WordPress, сервер или плагин. Тогда проблема не возвращается после следующего обновления.