Не работает REST API WordPress

Не работает REST API WordPress

Краткий ответ: если не работает REST API WordPress, сначала откройте адрес /wp-json/ и посмотрите, что возвращает сайт: JSON, 404, 403, 500, HTML-страницу, редирект или пустой ответ. Чаще всего проблема связана с постоянными ссылками, .htaccess, Nginx rules, security-плагином, WAF/ModSecurity, кешем, Cloudflare, конфликтом плагинов, HTTPS, CORS, nonce, Authorization header или ошибкой PHP.

REST API нужен не только разработчикам. Через него работают Gutenberg, Site Health, WooCommerce, некоторые формы, личные кабинеты, интеграции, мобильные приложения, CRM, Telegram-уведомления и внешние сервисы. Поэтому поломка REST API может выглядеть по-разному: редактор не сохраняет запись, форма не отправляется, интеграция не получает данные, WooCommerce даёт ошибку, а в Site Health появляется сообщение “The REST API encountered an error”.

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

Причина

REST API WordPress обычно доступен по адресу:

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

Если этот адрес не возвращает нормальный JSON-ответ, значит запрос ломается до WordPress, внутри WordPress или на уровне авторизации. Иногда сам /wp-json/ открывается нормально, но конкретный endpoint, например /wp-json/wp/v2/posts, /wp-json/wp/v2/users или endpoint плагина, возвращает ошибку.

Симптом	Возможная причина	Что проверить
/wp-json/ отдаёт 404	постоянные ссылки, .htaccess, rewrite rules, Nginx	Permalinks, .htaccess, try_files
/wp-json/ отдаёт 403	security-плагин, WAF, IP-блокировка, REST API отключён	логи безопасности, Cloudflare, WAF
/wp-json/ отдаёт 500	PHP Fatal error, конфликт плагина, тема, memory limit	debug.log, error_log, плагины
Возвращается HTML вместо JSON	редирект, кеш, warning/notice, страница ошибки	Network, headers, debug.log
Ошибка 401/403 на защищённом endpoint	нет авторизации, nonce, cookies, Application Passwords	Authorization header, nonce, права пользователя
Site Health пишет REST API error	loopback, cURL, SSL, firewall, HTTP-запрос к самому сайту	Site Health, server logs, SSL, DNS
Gutenberg не сохраняет запись	REST API заблокирован, nonce, WAF, JS-ошибка	Console, Network, wp-json
Интеграция с CRM не работает	auth, CORS, endpoint, webhook, firewall	логи интеграции, headers, API response

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

Диагностика

Начинайте с простого теста: откройте /wp-json/ в браузере. Нормальный ответ должен быть похож на JSON-структуру с routes, namespaces и другой служебной информацией WordPress. Если вместо этого вы видите 404, 403, 500, HTML или редирект, нужно искать слой, который ломает запрос.

1. Проверьте основной endpoint

Откройте:

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

Замените example.com на свой домен. Дальше смотрите результат:

• JSON отображается — базовый REST API работает, нужно проверять конкретный endpoint.
• 404 — проверьте постоянные ссылки, .htaccess или Nginx rules.
• 403 — проверьте security-плагины, WAF, Cloudflare, IP-блокировки.
• 500 — проверьте debug.log и PHP Fatal error.
• HTML вместо JSON — проверьте редиректы, кеш, warning/notice, страницу ошибки.
• Редирект — проверьте http/https, www/non-www, языковые префиксы и плагины редиректов.

2. Проверьте Site Health

В админке WordPress откройте:

Инструменты → Здоровье сайта

Если там есть сообщение про REST API или loopback request, скопируйте точный текст ошибки. Особенно важны HTTP-код, endpoint и сообщение cURL.

• REST API Endpoint;
• REST API Response;
• HTTP-код ответа;
• cURL error;
• timeout;
• SSL error;
• redirect error;
• unexpected result.

3. Проверьте постоянные ссылки

REST API часто ломается вместе с красивыми URL. Если сайт на Apache, проблема может быть в .htaccess. Если сайт на Nginx, проблема может быть в try_files.

В админке откройте:

Настройки → Постоянные ссылки → Сохранить изменения

После сохранения снова откройте /wp-json/. Если проблема ушла, причина была в rewrite rules.

4. Проверьте Console и Network

Если REST API ломается не в браузере напрямую, а в редакторе, форме, WooCommerce или личном кабинете, откройте DevTools:

• Console — JavaScript-ошибки;
• Network — запросы к /wp-json/;
• Status — 200, 301, 401, 403, 404, 500;
• Response — что реально вернул сервер;
• Headers — Authorization, cookies, nonce, content-type;
• Timing — нет ли timeout.

5. Проверьте плагины безопасности

Security-плагины часто блокируют REST API полностью или частично. Иногда они разрешают публичный /wp-json/, но блокируют endpoint для пользователей, заказов, форм, WooCommerce или кастомных плагинов.

Проверьте:

• не отключён ли REST API полностью;
• не заблокирован ли /wp-json/;
• не заблокированы ли неавторизованные запросы;
• не заблокирован ли IP клиента или сервиса;
• не включена ли защита XML-RPC/REST API вместе;
• не блокируется ли User-Agent внешнего сервиса;
• нет ли события в firewall logs.

6. Проверьте кеш и оптимизацию

REST API не должен отдавать старый кешированный HTML вместо JSON. Но агрессивный page cache, CDN, минификация, firewall rules или неправильные исключения могут ломать запросы.

• исключите /wp-json/* из кеша;
• исключите ?rest_route=* из кеша;
• очистите page cache;
• очистите object cache;
• очистите Cloudflare/CDN;
• отключите минификацию JS для теста;
• проверьте, не кешируется ли ответ API.

Решение

Исправление зависит от того, какой ответ возвращает REST API. Нельзя лечить 404, 403 и 500 одинаково. Сначала определите HTTP-код и источник проблемы, потом применяйте точечное решение.

1. Если /wp-json/ возвращает 404

Сначала пересохраните постоянные ссылки. Затем проверьте .htaccess или Nginx config.

• Настройки → Постоянные ссылки → Сохранить изменения;
• проверить стандартный .htaccess;
• проверить, включён ли Apache mod_rewrite;
• для Nginx проверить try_files;
• очистить кеш;
• проверить, нет ли плагина, который меняет REST URL.

Если 404 возникает не только у REST API, а вообще на всех внутренних страницах, проверьте статью WordPress показывает ошибку 404 на всех страницах.

2. Если REST API возвращает 403

403 означает, что доступ запрещён. Чаще всего виноват security-плагин, WAF, ModSecurity, Cloudflare, блокировка IP или кастомное правило, которое отключает REST API.

• проверьте firewall logs;
• временно отключите security-плагин на staging-копии;
• проверьте Cloudflare WAF events;
• проверьте .htaccess на запреты;
• проверьте server error_log;
• проверьте IP внешнего сервиса;
• попросите хостинг проверить ModSecurity.

3. Если REST API возвращает 500

Ошибка 500 почти всегда требует проверки логов. В браузере вы можете видеть только общий ответ, но в debug.log часто будет конкретный файл, строка и плагин.

• включите debug.log;
• проверьте PHP Fatal error;
• отключите последний обновлённый плагин;
• временно переключитесь на стандартную тему;
• проверьте PHP memory_limit;
• проверьте версию PHP;
• проверьте error_log хостинга.

4. Если ошибка только у защищённых endpoint

Если публичный /wp-json/ работает, но endpoint для публикации, пользователей, заказов или настроек возвращает 401/403, проблема часто в авторизации.

Проверьте:

• передаётся ли Authorization header;
• используется ли HTTPS;
• правильный ли Application Password;
• есть ли у пользователя нужные права;
• корректный ли nonce;
• не блокирует ли сервер Authorization header;
• не конфликтует ли JWT/OAuth/Basic Auth плагин.

5. Если REST API ломается в Gutenberg

Если редактор блоков не сохраняет запись, не загружает категории, не показывает preview или пишет “Updating failed”, проверьте запросы в Network.

• найдите запрос к /wp-json/;
• проверьте HTTP-код;
• проверьте nonce;
• очистите кеш;
• отключите security-плагин для теста;
• проверьте, нет ли JS-ошибок;
• проверьте, не выводит ли PHP warning перед JSON.

6. Если REST API нужен для интеграции

Для CRM, мобильного приложения, Telegram, headless frontend или внешней публикации важно не только открыть /wp-json/, но и правильно настроить endpoint, метод, авторизацию, права и формат ответа.

Если стандартного функционала недостаточно, лучше делать отдельный endpoint через кастомный плагин. Для таких задач полезно понимать, когда нужен кастомный WordPress-плагин.

Код

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

Проверить REST API через curl

Куда выполнять: терминал или SSH.

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

Проверить тело ответа:

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

Проверить REST endpoint записей

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

Проверить REST API через WP-CLI

Куда выполнять: SSH в корне сайта.

wp rewrite flush
wp option get permalink_structure

Стандартный .htaccess для WordPress

Куда вставлять: файл .htaccess в корне сайта. Перед заменой сохраните старый файл.

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Nginx правило для WordPress REST API

Куда вставлять: server block Nginx внутри location /. После изменения нужно проверить конфигурацию.

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

Проверка конфигурации:

nginx -t

Перезагрузка Nginx:

systemctl reload nginx

Передать Authorization header на Apache/FastCGI

Если REST API авторизация через Application Passwords или Basic Auth не работает, иногда сервер не передаёт Authorization header в PHP.

Куда вставлять: .htaccess, выше стандартного блока WordPress или внутри подходящей секции, если хостинг это поддерживает.

SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1

На некоторых конфигурациях также используют:

RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

Проверить, не отключён ли REST API через код

Куда искать: functions.php дочерней темы, mu-plugins, кастомные плагины.

add_filter('rest_authentication_errors', function ($result) {
    return new WP_Error('rest_disabled', 'REST API disabled.', array('status' => 403));
});

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

Пример корректной регистрации своего REST endpoint

Куда вставлять: отдельный мини-плагин или кастомный плагин, не в файлы ядра WordPress.

add_action('rest_api_init', function () {
    register_rest_route('sc/v1', '/ping', array(
        'methods'  => 'GET',
        'callback' => function () {
            return rest_ensure_response(array(
                'success' => true,
                'message' => 'REST API works',
            ));
        },
        'permission_callback' => '__return_true',
    ));
});

После добавления endpoint можно проверить:

https://example.com/wp-json/sc/v1/ping

Результат

После правильного исправления REST API должен возвращать JSON, а не 403, 404, 500, HTML, редирект или пустой ответ.

Хороший результат:

• /wp-json/ открывается и возвращает JSON;
• Site Health не показывает ошибку REST API;
• Gutenberg сохраняет записи;
• формы и AJAX-запросы работают;
• WooCommerce не ломается на checkout из-за блокировки API;
• внешняя интеграция получает ожидаемый ответ;
• Authorization header передаётся корректно;
• security-плагин не блокирует нормальные запросы;
• кеш не подменяет JSON-ответ;
• debug.log не содержит REST-related fatal errors.

Дополнительные способы

Проверить CORS

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

Проверить mixed content

Если сайт работает на HTTPS, а API вызывается по HTTP, браузер может блокировать запрос. Проверьте, чтобы сайт, WordPress Address, Site Address и API-запросы использовали одну HTTPS-схему.

Проверить редиректы

REST API может ломаться из-за цепочек 301/302: http → https, без www → www, языковой префикс, trailing slash, редиректы плагинов. Внешние сервисы не всегда корректно проходят такие цепочки.

Проверить PHP warnings перед JSON

Даже один PHP warning, notice или лишний пробел перед JSON может испортить ответ. В браузере это может выглядеть как “invalid JSON response” или ошибка парсинга.

Проверить loopback requests

Site Health может одновременно показывать ошибку REST API и loopback request. Это бывает, когда WordPress не может сделать HTTP-запрос к самому себе из-за DNS, SSL, firewall, basic auth, WAF или хостинга.

Проверить кастомные endpoint

Если не работает только endpoint вашего плагина, проверьте namespace, route, methods, callback, permission_callback, args и return. Callback должен возвращать корректный ответ, а не echo/print.

Частые ошибки

Отключать REST API полностью

Это может сломать Gutenberg, Site Health, WooCommerce, формы, интеграции, личные кабинеты и внешние приложения. Если нужно ограничить доступ, лучше делать точечные правила.

Проверять только /wp-json/

Базовый endpoint может работать, но конкретный endpoint плагина или защищённый route может возвращать 401, 403 или 500.

Игнорировать headers

Для авторизации важны Authorization header, cookies, nonce, content-type и HTTPS. Без проверки headers можно искать проблему не там.

Кешировать REST API как обычную страницу

REST API должен отдавать актуальный JSON. Если кеш отдаёт HTML или старый ответ, редактор и интеграции могут работать неправильно.

Путать CORS с поломкой API

Если запрос из браузера заблокирован CORS, API может быть рабочим. Нужно отдельно проверить ответ через curl или Postman.

Не проверять security-плагины

Многие блокировки REST API идут не от WordPress, а от firewall, WAF, Cloudflare или security-плагина.

Возвращать echo вместо rest_ensure_response

В кастомных endpoint лучше возвращать данные через rest_ensure_response(), WP_REST_Response или WP_Error, а не печатать JSON вручную.

Диагностика проблем

Проблема: /wp-json/ показывает 404

Возможная причина: постоянные ссылки, .htaccess, Apache rewrite, Nginx try_files.

Что делать: пересохранить permalinks, восстановить .htaccess, проверить mod_rewrite или Nginx config.

Проблема: /wp-json/ показывает 403

Возможная причина: REST API заблокирован security-плагином, WAF, Cloudflare, .htaccess или кастомным кодом.

Что делать: проверить firewall logs, .htaccess, security-плагины, rest_authentication_errors и IP-блокировки.

Проблема: /wp-json/ показывает 500

Возможная причина: PHP Fatal error, конфликт плагинов, тема, memory limit, несовместимость PHP.

Что делать: включить debug.log, проверить error_log, отключить проблемный плагин, переключить тему для теста.

Проблема: Gutenberg пишет “Updating failed”

Возможная причина: REST API заблокирован, nonce неверный, WAF блокирует запрос, кеш отдаёт неправильный ответ или есть JS-ошибка.

Что делать: открыть DevTools → Network, найти запрос к /wp-json/, проверить статус, response и headers.

Проблема: Application Passwords не работают

Возможная причина: неверный пароль приложения, нет HTTPS, сервер не передаёт Authorization header, пользователь не имеет прав.

Что делать: проверить Basic Auth, HTTPS, Authorization header, права пользователя и настройки сервера.

Проблема: внешний сервис получает HTML вместо JSON

Возможная причина: кеш, редирект, страница защиты, Cloudflare challenge, warning/notice или неправильный URL endpoint.

Что делать: проверить curl, headers, кеш, Cloudflare, debug.log и точный endpoint.

Проблема: REST API работает для гостя, но не для администратора

Возможная причина: cookies, nonce, роль пользователя, security-плагин или ошибка в context=edit.

Что делать: проверить авторизацию, nonce, права пользователя, endpoint с context=view и context=edit.

Проблема: не работает только кастомный endpoint

Возможная причина: ошибка register_rest_route, namespace, permission_callback, callback, метод запроса или return.

Что делать: проверить rest_api_init, route, methods, callback, permission_callback и debug.log.

Краткие AI-friendly ответы

Почему не работает REST API WordPress?

Чаще всего из-за постоянных ссылок, .htaccess, Nginx rules, security-плагина, WAF, кеша, Cloudflare, ошибки PHP, неправильной авторизации, nonce, HTTPS, CORS или Authorization header.

Как проверить REST API WordPress?

Откройте https://example.com/wp-json/. Если возвращается JSON, базовый REST API работает. Если 404, 403 или 500 — нужно проверять rewrite rules, блокировки, сервер и debug.log.

Что делать, если /wp-json/ отдаёт 404?

Пересохраните постоянные ссылки, проверьте .htaccess на Apache или try_files на Nginx, очистите кеш и проверьте, не конфликтуют ли плагины.

Что делать, если /wp-json/ отдаёт 403?

Проверьте security-плагины, WAF, ModSecurity, Cloudflare, .htaccess, IP-блокировки и кастомный код, который может отключать REST API.

FAQ

Что такое REST API WordPress?

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

Почему Site Health пишет, что REST API не работает?

WordPress делает тестовый запрос к своему REST endpoint. Если запрос возвращает ошибку, timeout, 403, 404, 500, редирект или неожиданный ответ, Site Health показывает предупреждение.

Можно ли отключить REST API?

Технически можно, но обычно это плохая идея. Полное отключение может сломать редактор Gutenberg, Site Health, WooCommerce, формы, личные кабинеты и интеграции.

Почему REST API возвращает 401?

Обычно нет авторизации или у пользователя нет прав. Проверьте cookies, nonce, Application Passwords, Authorization header, HTTPS и capability пользователя.

Почему REST API возвращает 403?

Доступ запрещён security-плагином, WAF, Cloudflare, .htaccess, IP-блокировкой, ролью пользователя или кастомным кодом в rest_authentication_errors.

Почему REST API возвращает 404?

Чаще всего сломаны постоянные ссылки, .htaccess, rewrite rules или Nginx try_files. Также возможен неправильный namespace или route у кастомного endpoint.

Почему REST API возвращает HTML вместо JSON?

Возможен редирект, кеш, страница защиты, PHP warning перед JSON, Cloudflare challenge, страница ошибки или неправильный URL endpoint.

Как проверить, виноват ли плагин?

Проверьте debug.log, временно отключите подозрительный плагин на staging-копии, откройте /wp-json/ снова и посмотрите Network. Часто виноваты security, cache, optimization или custom endpoint плагины.

Почему REST API ломает редактор Gutenberg?

Gutenberg использует REST API для сохранения и загрузки данных. Если API заблокирован, отдаёт неправильный JSON или не проходит nonce, редактор может писать “Updating failed”.

Когда обращаться к специалисту?

Если REST API нужен для заявок, CRM, WooCommerce, личного кабинета, внешнего сервиса или кастомного плагина, лучше не отключать защиту наугад. Нужна диагностика endpoint, headers, логов, авторизации и серверных правил.

Вывод

Если не работает REST API WordPress, сначала нужно понять, какой ответ возвращает /wp-json/: JSON, 404, 403, 500, HTML, редирект или timeout. От этого зависит правильное решение.

Чаще всего проблема находится в постоянных ссылках, .htaccess, Nginx rules, security-плагине, WAF, кешировании, Cloudflare, PHP-ошибке, авторизации, nonce, HTTPS, CORS или Authorization header.

Самый безопасный порядок: backup, проверка /wp-json/, Site Health, Network, debug.log, permalinks, .htaccess/Nginx, security-плагинов, кеша и авторизации. Так можно восстановить REST API без лишнего риска для редактора, форм, WooCommerce и интеграций.