Как с помощью ИИ найти и исправить 404 ошибки WordPress REST API

404 в REST API обычно всплывает не на главной странице, а в местах, где сайт уже завязан на редактор, мобильное приложение, интеграции или кастомные блоки. На практике это выглядит так: запрос к /wp-json/ открывается, но конкретный маршрут возвращает 404; или весь API отвечает 404 после переноса сайта, смены домена, установки кеширующего плагина или правки .htaccess.

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

Как выглядит проблема и где её искать

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

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

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

Для диагностики удобно дать ИИ не только текст ошибки, но и конкретные данные: URL маршрута, ответ сервера, фрагмент curl, список активных плагинов, правила редиректов и кусок .htaccess или конфигурации Nginx. Чем точнее входные данные, тем меньше «советов наугад».

Диагностика проблемы с помощью ИИ

Лучше всего работает короткий структурированный запрос. ИИ не должен «лечить WordPress целиком» — ему нужно сопоставить симптом с вероятной причиной.

Проверь причину 404 в REST API WordPress по этим данным:

1) URL маршрута: https://example.com/wp-json/myplugin/v1/items
2) Ответ: 404 Not Found
3) /wp-json/ открывается и возвращает JSON
4) После отключения плагина myplugin маршрут пропадает
5) Сервер: Nginx
6) Сайт перенесён с /blog/ в корень

Нужны:
- вероятная причина
- что проверить в коде плагина
- что проверить в правилах rewrite
- безопасный порядок действий

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

curl -i https://example.com/wp-json/myplugin/v1/items

Для WordPress REST API важно понимать, где именно возникает 404:

• 404 от WordPress — маршрут не зарегистрирован, не совпадает namespace, endpoint отключён условием в коде;
• 404 от веб-сервера — запрос не доходит до WordPress, чаще всего проблема в rewrite-правилах, конфиге Nginx или кеширующем слое;
• 404 только для части пользователей — мешает кеш, CDN, security-плагин или условная логика в теме.

Пошаговое решение: от маршрута к серверу

Ниже порядок, который обычно экономит время. Не начинайте с правки кода, пока не поняли, доходит ли запрос до WordPress.

1. Проверьте регистрацию маршрута

Если endpoint создаётся в плагине или теме, убедитесь, что он регистрируется на хуке rest_api_init. Частая ошибка — код выполняется слишком рано или только в админке.

add_action( 'rest_api_init', function () {
    register_rest_route( 'myplugin/v1', '/items', array(
        'methods'  => 'GET',
        'callback' => 'myplugin_get_items',
        'permission_callback' => '__return_true',
    ) );
} );

function myplugin_get_items( WP_REST_Request $request ) {
    return rest_ensure_response( array(
        'items' => array(),
    ) );
}

Если маршрут пропадает после отключения плагина, это ожидаемо. Но если плагин активен, а маршрут 404, проверьте namespace, путь и наличие permission_callback. В современных версиях WordPress его отсутствие — плохая идея и источник предупреждений.

2. Сравните адрес маршрута и фактический namespace

Очень часто проблема банальна: в коде зарегистрирован myplugin/v1, а фронтенд или внешний сервис стучится в my-plugin/v1. ИИ здесь полезен тем, что быстро сопоставляет строки из кода и URL, если вы покажете оба фрагмента.

Проверьте:

• совпадает ли namespace в register_rest_route() и в запросе;
• не добавлен ли лишний слэш;
• не изменился ли базовый URL после миграции сайта;
• не используется ли старый путь с подкаталогом, который уже удалён.

3. Сбросьте rewrite-правила

Если /wp-json/ открывается, а отдельные маршруты нет, иногда помогает банальный flush правил. Делать это нужно аккуратно: не в каждом запросе, а один раз после изменения структуры ссылок или после переноса сайта.

flush_rewrite_rules();

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

4. Проверьте правила сервера

Если запросы к REST API не доходят до WordPress, ищите проблему в Nginx или .htaccess. Для Apache базовый блок WordPress должен быть целым, без лишних редиректов вокруг index.php. Для Nginx важно, чтобы запросы не перехватывались отдельными location-блоками.

ИИ здесь полезен как ревьюер конфигурации: вы даёте ему фрагмент конфигурации и просите найти, не блокируется ли /wp-json/ или index.php. Но итоговую правку всё равно лучше проверять вручную.

5. Отключите конфликтующие фильтры и security-слой

Иногда 404 создаёт не сам REST API, а плагин безопасности или кастомный фильтр, который режет запросы по шаблону. Особенно это заметно, если endpoint работает в админке, но ломается для внешних запросов.

Проверьте, нет ли в коде фильтров на:

• rest_authentication_errors;
• rest_pre_dispatch;
• parse_request;
• template_redirect.

Если в проекте есть собственные ограничения, они должны возвращать понятную ошибку, а не маскировать всё под 404. Иначе диагностика превращается в угадывание.

Как использовать ИИ для точечной проверки кода

Самый полезный сценарий — дать ИИ не весь проект, а конкретный кусок, где регистрируется маршрут. Тогда он может подсветить несоответствия: неправильный хук, условие, которое не выполняется, или callback, который возвращает не тот тип данных.

add_action( 'init', function () {
    register_rest_route( 'myplugin/v1', '/items', array(
        'methods'  => 'GET',
        'callback' => 'myplugin_get_items',
    ) );
} );

В этом примере проблема в том, что маршрут регистрируется на init, а не на rest_api_init. WordPress может не увидеть endpoint в нужный момент. ИИ обычно ловит такие вещи быстро, если попросить его не просто «проверить код», а найти именно причины 404 в REST API.

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

После правки нужно проверить не только сам endpoint, но и сценарий, ради которого он существует. Иначе можно случайно починить URL и сломать формат ответа.

• откройте /wp-json/ и убедитесь, что JSON отдается без ошибки;
• проверьте конкретный маршрут через браузер или curl -i;
• сравните HTTP-статус до и после правки;
• проверьте ответ в редакторе блоков, если маршрут используется там;
• посмотрите error log и access log на повторяющиеся 404;
• если есть кеш, очистите его и повторите запрос.

Полезно проверить и заголовки ответа. Если маршрут доступен, но отдаёт старый кешированный 404, вы увидите это по Age, X-Cache или похожим заголовкам от CDN/прокси.

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

Маршрут зарегистрирован не там

Код висит на init или выполняется только в админке. Исправление — перенести регистрацию на rest_api_init и убрать лишние условия, если endpoint нужен на фронтенде.

Неправильный namespace

В коде один префикс, в запросе другой. Это особенно часто случается после рефакторинга плагина. Исправление — привести к одному имени и проверить все места, где URL собирается вручную.

Сервер отдаёт 404 раньше WordPress

Значит, проблема не в PHP-коде. Ищите rewrite-правила, конфликтующие location-блоки, защитные правила хостинга или CDN. ИИ здесь помогает быстро разобрать конфиг, но править нужно осторожно и по одному изменению за раз.

Кеш держит старую ошибку

После исправления маршрут всё ещё выглядит сломанным только для части пользователей. Причина часто в полном page cache или edge cache. Очистите кеш на всех уровнях и проверьте запрос с параметром, который не кэшируется, если это допустимо в вашем сценарии.

Фильтр безопасности маскирует блокировку под 404

Некоторые плагины безопасности специально возвращают 404 вместо 403. Это усложняет диагностику. Если такой слой есть, временно отключите его на тестовом стенде и проверьте, исчезает ли ошибка.

Сравнение подходов: плагин, код или серверная правка

Если нужен более широкий аудит технических ошибок сайта, иногда удобнее подключить инструменты, которые помогают искать дубли, мусор и SEO-проблемы на уровне WordPress. Например, Clearfy Pro у WPShop можно использовать как вспомогательный слой для технической чистки и устранения части типовых дублей, но в случае REST API 404 он не заменяет разбор маршрутов и конфигурации сервера: https://wpshop.ru/plugins/clearfy.

Как не сломать сайт при исправлении

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

• сначала снимите текущий ответ curl -i;
• внесите одну правку;
• снова проверьте тот же маршрут;
• посмотрите логи;
• только потом переходите к следующему шагу.

Если ИИ предлагает «универсальное» решение вроде отключения всех плагинов, не принимайте его бездумно. Для боевого сайта это слишком грубо. Лучше сузить круг: один endpoint, один плагин, один слой кеша, один серверный блок.

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