Ошибка 404 после обновления плагина WordPress - одна из самых частых заявок, с которыми ко мне обращаются: вчера сайт работал, сегодня обновили пару плагинов через панель, и половина страниц или все товары в WooCommerce стали отдавать «страница не найдена». Причина почти всегда в правилах ЧПУ (rewrite rules), которые WordPress хранит в базе и не всегда пересобирает сам после изменений, внесённых плагином. Ниже - порядок действий, который использую на практике: от самого быстрого способа до разбора конкретных случаев с WooCommerce и Nginx.
Почему после обновления плагина сайт выдаёт 404 на страницах
WordPress строит адреса страниц, товаров и записей по правилам, которые генерируют сами плагины через регистрацию типов записей и таксономий. Эти правила пересчитываются и кладутся в опцию базы данных при активации плагина или сохранении настроек постоянных ссылок, а не при каждом обновлении. Если новая версия плагина меняет базовый слаг, добавляет новый тип записи или переименовывает существующий, старые правила остаются в кеше, и WordPress не находит соответствие для новых адресов.
В моей практике чаще всего к этому приводят:
- обновления WooCommerce и плагинов оплаты, которые трогают настройки страниц товаров и корзины;
- плагины с собственными типами записей - каталоги, портфолио, календари событий;
- SEO-плагины, которые управляют редиректами и постоянными ссылками;
- многоязычные плагины, перестраивающие слаги под каждый язык;
- конструкторы страниц, которые после обновления пересобирают шаблоны и меняют внутренние маршруты.
Отдельная история - сервер. Обновление плагина иногда переписывает файл .htaccess (обычно это делают плагины безопасности или SEO-модули с функцией управления редиректами), и блок правил WordPress из файла пропадает целиком.
Сбрасываю правила ЧПУ - первый и часто единственный шаг
Перед тем как искать конфликт плагинов, я просто пересобираю правила заново. Самый быстрый способ - зайти в Настройки, открыть Постоянные ссылки и нажать «Сохранить изменения», ничего не меняя. WordPress пересчитает список правил и запишет его заново.
Если есть доступ по SSH и установлен WP-CLI, делаю то же самое из терминала:
wp rewrite flush --hardФлаг --hard дополнительно пытается перезаписать .htaccess на Apache, чего обычное сохранение из админки иногда не делает, если у WordPress нет прав на запись в файл. Проверить, какие правила реально загружены после сброса, можно так:
wp rewrite list --format=tableЕсли в выводе нет правила для нужного типа записи (например, для товаров WooCommerce), значит плагин просто не зарегистрировал маршрут заново, и дело не только в кеше - нужно смотреть логи на предмет ошибок при инициализации плагина.
Проверяю .htaccess и конфигурацию сервера
На Apache стандартный блок в .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Если блока нет вообще или он обрезан - пересохранение постоянных ссылок в админке обычно восстанавливает его само, но если сервер не даёт WordPress права на запись в файл, придётся вставить блок руками через FTP или файловый менеджер хостинга.
На Nginx история другая: .htaccess там не читается вообще, и сброс ЧПУ через админку меняет только запись в базе данных, а не конфиг сервера. Для WordPress на Nginx маршрутизация задаётся директивой в конфиге сайта:
location / {
try_files $uri $uri/ /index.php?$args;
}Если эта директива на месте, обычного сброса ЧПУ достаточно для любых новых маршрутов, которые регистрирует плагин через стандартный API WordPress. Отдельный location-блок под конкретный плагин требуется редко - в основном когда плагин добавляет собственный REST-эндпоинт со специфичной обработкой заголовков, и тогда без правки конфига и перезапуска Nginx 404 не уйдёт, сколько ни сохраняй настройки в админке.
| Способ сброса ЧПУ | Когда использую | Что нужно для доступа |
|---|---|---|
| Пересохранение в Настройки - Постоянные ссылки | Первая попытка при любом 404 после обновления плагина | Доступ в админку WordPress |
| wp rewrite flush - hard в WP-CLI | Когда админка недоступна из-за конфликта плагинов или белого экрана | SSH-доступ и установленный WP-CLI |
| Ручная правка .htaccess или конфига Nginx | Файл перезаписан плагином или отсутствует нужный блок правил | Доступ к файлам сервера или панели хостинга |
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Кеш и CDN тоже отдают старую 404-страницу
После сброса правил страница иногда всё равно показывает «не найдено» - и дело не в WordPress, а в кеше поверх него. Разделяю проверку на три уровня:
- кеш плагина ускорения (WP Rocket, WP Super Cache, LiteSpeed Cache и подобные) - у них своя очистка в настройках, обычно кнопка «Очистить кеш» в верхней панели админки;
- объектный кеш на Redis или Memcached - в нём может застрять сериализованный массив правил или закешированные результаты запросов WooCommerce к товарам;
- кеш на уровне CDN (например, Cloudflare) - он хранит HTTP-ответы, включая 404, со своим сроком жизни, и без ручной очистки в панели CDN отдаёт старый ответ, даже когда на сервере всё уже починено.
Объектный кеш через WP-CLI сбрасывается отдельной командой:
wp cache flushПроверять результат лучше не в обычной вкладке браузера, а в приватном окне или через curl - браузер тоже может закешировать 404-ответ по заголовкам Cache-Control, и тогда будет казаться, что ничего не помогло, хотя на сервере всё уже исправлено.
Частый случай: WooCommerce меняет структуру ссылок на товары
Отдельно разбираю сценарий, с которым сталкивался не раз: обновление WooCommerce вместе с плагином платёжного шлюза (например, эквайринга через Т‑Банк) иногда сопровождается сбросом базового слага товаров к значению по умолчанию. Настройки постоянных ссылок товаров лежат не внутри WooCommerce, а в стандартном разделе WordPress: «The permalink settings for WooCommerce are located alongside the standard WordPress settings. To access them, go to Settings > Permalinks in your WordPress dashboard», а сами варианты базы - в блоке «Product permalinks» на той же странице. Ссылки на карточки товаров, которые уже разошлись по рекламным кампаниям и в переписке с клиентами, начинают вести на 404.
Что проверяю по порядку:
- захожу в Настройки, Постоянные ссылки, нахожу блок «Product permalinks» и сверяю базовый слаг с тем, что было до обновления;
- если слаг сбился - возвращаю прежнее значение и сохраняю, это заодно пересобирает правила ЧПУ;
- если слаг поменяли осознанно и старые ссылки больше не нужны в прежнем виде - настраиваю редиректы со старых адресов на новые, чтобы не терять переходы из рекламы и поисковой выдачи;
- если сайт использует персистентный объектный кеш - дополнительно сбрасываю его командой выше, потому что WooCommerce кеширует результаты запросов к товарам отдельно от общего кеша правил.
Если ничего не помогло: ищу конфликт и делаю откат плагина
Когда сброс ЧПУ и очистка кеша не убрали 404, смотрю логи сервера на предмет фатальных ошибок в момент генерации правил - иногда плагин падает до того, как успевает зарегистрировать нужный тип записи, и тогда его маршруты просто отсутствуют в системе. Если в логе тихо, отключаю все плагины и включаю по одному, проверяя проблемную страницу после каждого - на сайт с полусотней плагинов такая проверка занимает час-полтора, но однозначно показывает виновника.
Найдя проблемный плагин, откатываю его на предыдущую версию. Если у плагина в каталоге WordPress есть история версий, в карточке плагина на странице «Плагины» есть расширенный просмотр с возможностью отката. Через WP-CLI это делается установкой конкретной версии поверх текущей:
wp plugin install <slug> --version=X.Y.Z --forceПеред откатом обязательно снимаю бэкап базы и файлов - если проблема была не только в правилах ЧПУ, но и в структуре данных, откат версии плагина без резервной копии может создать больше проблем, чем решить. Если разбираться с конфликтом плагинов самостоятельно нет времени или сайт коммерческий и простой стоит денег, обращаюсь к отдельной разработке и поддержке сайта на WordPress - там же чиню и подобные конфликты после обновлений.
WordPress регулярно обновляется, поэтому перед внедрением я сверяюсь с актуальной документацией.
Частые вопросы
На Nginx сброс ЧПУ через админку вообще работает?
Частично. Сохранение постоянных ссылок в админке обновляет только запись правил в базе данных WordPress, а сам Nginx её не видит - он работает через директиву try_files в конфиге сайта. Если эта директива стоит правильно и передаёт все запросы в index.php, обновлённой записи в базе достаточно и новые страницы открываются. Если же плагину нужен отдельный location-блок под свой эндпоинт, без правки конфига Nginx и его перезапуска 404 останется.
Почему 404 появляется только на части страниц, а остальные открываются?
Это нормально и обычно означает, что сломались правила только для конкретного типа записи или таксономии, которую регистрирует проблемный плагин - товары, события, элементы портфолио. Обычные страницы и записи WordPress используют базовые правила ядра и от плагина не зависят, поэтому продолжают открываться как ни в чём не бывало.
Нужно ли чистить кеш браузера, чтобы проверить, помог ли сброс?
Лучше не полагаться на обычную вкладку браузера - он может закешировать 404-ответ по заголовкам Cache-Control и показывать старую картину даже после того, как на сервере всё исправлено. Проверяю в приватном окне или через curl, чтобы исключить локальный кеш и увидеть реальный ответ сервера.
Как понять, какой именно плагин вызвал 404 после обновления?
Сначала смотрю время последнего обновления плагинов на странице «Плагины» и сопоставляю его со временем появления ошибки. Если совпадений несколько, отключаю все плагины и включаю по очереди, проверяя проблемную страницу после каждого включения - способ медленный, но даёт точный ответ без гаданий.