Сайт на WordPress внезапно открывает только главную страницу, а на записях, товарах и рубриках вылезает 404 - притом что в коде и в базе всё цело. Это классическая ситуация: WordPress выдаёт 404 на всех страницах после переезда на другой хостинг, обновления PHP, смены темы или банального сбоя при сохранении настроек. Ошибка пугает своей тотальностью, но чинится в девяти случаях из десяти за 10-15 минут - без переустановки движка и без восстановления из бэкапа. Разбираю причины и последовательность действий, которую использую сам на клиентских проектах.
Почему WordPress выдаёт 404 на всех страницах
Ошибка 404 на всех внутренних страницах почти всегда означает, что сервер не понимает, как передать «красивый» URL (/blog/moya-statya/) в index.php. Пока WordPress работает через свой обработчик маршрутов (rewrite rules), всё нормально; как только эта цепочка рвётся, сервер честно ищет файл по такому пути, не находит его и отдаёт стандартную 404 от Apache или Nginx, а не от шаблона темы.
Три причины встречаются чаще всего:
- слетели или не создались правила в .htaccess (Apache) - типично после переноса на новый хостинг или ручной правки файла;
- в конфиге Nginx нет блока try_files, который отдаёт все запросы в index.php;
- сломались постоянные ссылки в базе (таблица wp_options, поле rewrite_rules) - из-за конфликта плагинов, ручного вмешательства в БД или отката к старому дампу.
Отдельно встречается ситуация с интернет-магазинами на WooCommerce: после миграции слетевшие permalinks ломают не только каталог, но и эндпоинт для приёма колбэков от эквайринга. У меня был кейс, когда после переезда сайта на новый хостинг перестали приходить уведомления об оплате от Т‑Банка именно потому, что URL вебхука отдавал 404 - никто не связывал это с настройками ссылок, пока не проверили постоянные ссылки в первую очередь.
Проверяю настройки постоянных ссылок в WordPress
Первым делом захожу в консоль администратора: Настройки → Постоянные ссылки. Ничего не меняю в самих полях - просто нажимаю «Сохранить изменения». WordPress пересоздаёт правила rewrite и, если сервер настроен корректно, заново прописывает .htaccess.
Если админка сама открывается без проблем (то есть 404 только на публичной части) - в большинстве случаев этого шага достаточно. Если после сохранения ничего не изменилось, значит дело не в базе, а в том, что сервер вообще не выполняет rewrite-правила - переходим к файлу .htaccess или конфигу Nginx.
Если 404 отдаёт и сама админка (wp-admin), permalinks через интерфейс не поправить - тогда сразу переходим к ручной правке .htaccess либо смотрим на уровень веб-сервера.
Восстанавливаю правила в .htaccess вручную
На Apache-хостинге (большинство виртуальных хостингов вроде Timeweb, Beget, Reg.ru) файл .htaccess лежит в корне сайта, рядом с wp-config.php. Причины, по которым он пропадает или ломается: чистая установка через FTP без переноса скрытых файлов, ограничение прав 644/755 хостером, ручная правка с опечаткой.
Открываю файл через FTP или файловый менеджер хостинга и проверяю, что там стандартный блок WordPress:
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
Если файла нет вообще - создаю его руками с этим содержимым и выставляю права 644. Если файл есть, но блока WordPress нет или он оборван - вставляю блок целиком, ничего не подставляя вместо RewriteBase (обычно это /, если сайт не висит в подпапке).
Стоит убедиться, что в конфиге Apache включён AllowOverride All для директории сайта - иначе хостинг игнорирует .htaccess целиком, сколько бы правил там ни было. На большинстве виртуальных хостингов это уже настроено, но на своём VPS с Apache это частая причина, почему правки в .htaccess просто не работают.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Если сайт работает на Nginx - правлю конфиг веб-сервера
Nginx не читает .htaccess - это специфика Apache. Если WordPress переехал на VPS с Nginx (или связку Nginx + PHP-FPM) без готовой панели, а раньше сайт жил на обычном виртуальном хостинге, 404 на всех страницах почти гарантированы: правила из .htaccess туда просто не перенеслись, потому что Nginx их не читает в принципе.
Нужный блок в конфиге сайта (обычно /etc/nginx/sites-available/имя-сайта или в панели вроде ISPmanager/aaPanel через визуальный редактор):
location / {
try_files $uri $uri/ /index.php?$args;
}
location ~ .php$ {
include fastcgi_params;
fastcgi_pass unix:/var/run/php/php8.1-fpm.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}
Путь до сокета php-fpm (fastcgi_pass) зависит от версии PHP и дистрибутива - смотрю его в выводе systemctl status php8.1-fpm или в файле пула /etc/php/8.1/fpm/pool.d/www.conf. После правки обязательно проверяю синтаксис командой nginx -t и перезапускаю сервис systemctl reload nginx - без reload новый конфиг не подхватится, и 404 никуда не денется.
Ищу конфликт плагинов и тем, которые ломают маршрутизацию
Если permalinks пересохранены, .htaccess и Nginx-конфиг в порядке, а 404 всё равно на месте - дело в коде. Плагины, которые регистрируют собственные rewrite-правила (WooCommerce, кастомные типы записей, SEO-плагины, кеширующие плагины вроде WP Rocket или LiteSpeed Cache), иногда конфликтуют между собой или ломаются при обновлении.
Порядок действий:
- через FTP переименовываю папку /wp-content/plugins в plugins_old - WordPress автоматически отключит все плагины разом;
- проверяю, ушла ли 404;
- если да - возвращаю исходное имя папки и включаю плагины по одному через админку, каждый раз проверяя фронт;
- если 404 держится и без плагинов - переключаюсь на тему по умолчанию (Twenty Twenty-Four) через wp-config.php или напрямую в базе (таблица wp_options, поля template и stylesheet).
Отдельно смотрю в functions.php активной темы: если там руками добавлены add_rewrite_rule() или add_rewrite_endpoint(), ошибка в них ломает всю карту маршрутов сайта целиком, а не только новый URL.
Если ничего не помогло - глубокая диагностика
Когда предыдущие шаги не дали результата, смотрю глубже:
| Что проверяю | Где смотреть | На что обращаю внимание |
|---|---|---|
| Логи веб-сервера | /var/log/nginx/error.log или error_log хостинга | Реальная причина 404 - файл не найден, ошибка rewrite, проблема с правами |
| Таблица wp_options | phpMyAdmin, поле rewrite_rules | Пустое значение или явно битый сериализованный массив |
| Кеш страниц | WP Rocket, LiteSpeed Cache, кеш на уровне хостинга | Старая закешированная 404-страница отдаётся вместо актуальной |
| Мультисайт (Multisite) | wp-config.php, константа MULTISITE | Для сети сайтов нужны отдельные правила .htaccess |
Если сайт стоит в подпапке (например, example.ru/shop/), проверяю, что RewriteBase в .htaccess указывает именно на /shop/, а не на / - это частая причина, когда 404 вылезает только у части URL после переноса магазина в подкаталог.
Если после переезда на новый хостинг всплыли сразу несколько проблем разом - 404, битые ссылки на изображения, неработающие вебхуки - обычно проще заказать перенос и настройку сайта под ключ, чем чинить последствия самостоятельного FTP-переноса по частям: миграция базы и медиатеки WordPress - отдельная история со своими подводными камнями (сериализованные пути в базе, права на файлы, версии PHP). Такую миграцию и последующую настройку можно заказать через услуги по разработке и сопровождению сайтов.
Чтобы сайт работал без сбоев
Техподдержка
от 15 000 ₽/мес
Подробнее →Частые вопросы
Почему 404 появилась сразу после переезда на новый хостинг?
Потому что .htaccess либо не скопировался целиком (это скрытый файл, некоторые FTP-клиенты его не показывают по умолчанию), либо новый хостинг работает на Nginx, а старый - на Apache, и правила из .htaccess там просто не действуют. Проверяю тип веб-сервера у нового хостера и создаю нужный конфиг под конкретную связку.
Помогает ли переустановка WordPress при 404 на всех страницах?
Почти никогда, потому что ошибка не в ядре движка, а в связке сервер плюс правила маршрутизации плюс база. Переустановка ядра ничего не поправит, если .htaccess не создан заново или конфиг Nginx не содержит try_files. Ядро WordPress можно смело оставить как есть.
Может ли CDN или кеширующий сервис быть причиной 404 на всех страницах?
Такое встречается, если CDN или прокси перед сайтом кеширует старую версию страницы или отдаёт закешированную 404 вместо актуальной. В этом случае сначала чиню правила на сервере, а затем сбрасываю кеш на стороне CDN и жду обновления.
Что делать, если 404 появляется только на страницах товаров WooCommerce, а остальные работают?
Обычно это конфликт кастомных типов записей WooCommerce с правилами rewrite - помогает пересохранение постоянных ссылок (Настройки → Постоянные ссылки → Сохранить) после каждого обновления самого WooCommerce или темы магазина. Если не помогло, проверяю в базе таблицу wp_options на предмет корректного значения woocommerce_permalinks.