Если после обновления сайта, смены темы или переноса часть страниц и записей WordPress открывается с ошибкой 404, проблема чаще всего не в самих материалах, а в правилах постоянных ссылок, структуре URL или настройках сервера. В таких случаях контент обычно на месте, но WordPress не может правильно сопоставить адрес страницы с записью в базе данных.
Ниже разберём, как быстро определить причину 404 и что делать в первую очередь, чтобы вернуть доступ к нужным страницам без лишних правок в коде.
С чего начать диагностику
Сначала проверьте, действительно ли проблема касается только отдельных страниц и записей. Если 404 появляется на всём сайте, включая главную, архивы и даже служебные страницы, причина может быть в более общей поломке: неверном .htaccess, отключённых правилах перезаписи, проблеме на уровне веб-сервера или конфликте с плагином.
Если же главная страница открывается, а отдельные записи и страницы — нет, в большинстве случаев виноваты постоянные ссылки. Это самый частый сценарий после переноса сайта, смены темы или ручного изменения настроек.
Полезно сразу проверить три вещи:
- открывается ли запись по старому адресу и по новому;
- не менялась ли структура постоянных ссылок в Настройки → Постоянные ссылки;
- не было ли переноса на другой домен, поддомен или в подпапку.
Самое частое решение: сбросить правила постоянных ссылок
Если WordPress перестал находить записи и страницы, начните с пересохранения настроек постоянных ссылок. Это безопасное действие: оно не меняет содержимое сайта, а только заново записывает правила маршрутизации URL.
Откройте Настройки → Постоянные ссылки и просто нажмите кнопку Сохранить изменения, не меняя саму структуру, если она уже выбрана правильно. После этого WordPress пересоздаст правила и часто сразу убирает 404 на страницах и записях.
Если сайт работает на Apache, WordPress обычно использует файл .htaccess. При сохранении постоянных ссылок он должен содержать стандартные правила WordPress. Если файл недоступен для записи, обновление настроек может не помочь, и тогда правила придётся проверить вручную.
Для стандартной установки WordPress на Apache в .htaccess обычно должны быть такие правила:
<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>Если WordPress установлен не в корне домена, а в подпапке, путь в RewriteBase и последнем правиле будет отличаться. Это важно: чужой пример из интернета нельзя вставлять без проверки пути установки.
Проверьте, не сломалась ли структура URL после переноса или смены темы
После переноса сайта иногда меняется не только домен, но и путь установки. Например, сайт мог переехать из тестовой папки в корень, а старые ссылки остались в базе или в меню. В этом случае 404 появляется не из-за WordPress как такового, а потому что запрос идёт по адресу, которого больше нет.
Проверьте:
- совпадает ли домен в Настройки → Общие с фактическим адресом сайта;
- не остались ли в контенте абсолютные ссылки на старый домен или старую папку;
- не изменилась ли структура постоянных ссылок, например с
/%postname%/на другую схему.
Если менялся домен, сначала убедитесь, что в базе данных обновлены адреса сайта. В WordPress это обычно касается значений home и siteurl. Их можно проверить в админке или через базу данных, если доступ к панели уже ограничен. Неверные значения здесь часто приводят к странным 404, редиректам и циклам переходов.
Когда виноват сервер, а не WordPress
Если пересохранение постоянных ссылок не помогло, а 404 сохраняется только на красивых URL, проблема может быть на стороне веб-сервера. Это особенно вероятно, если сайт перенесли на другой хостинг или изменили тип сервера.
Apache и mod_rewrite
Для Apache важно, чтобы был включён модуль mod_rewrite и разрешена обработка .htaccess. Если хостинг отключил переопределение правил или файл .htaccess игнорируется, WordPress не сможет обрабатывать человеко-понятные ссылки.
Признак такой проблемы: сайт открывается только по прямому адресу вида ?p=123, а страницы с красивыми URL дают 404.
Nginx
На Nginx правила WordPress настраиваются не через .htaccess, а в конфигурации сайта. Если после переноса на Nginx страницы и записи начали отдавать 404, нужно проверить, есть ли в конфиге правило передачи запроса в index.php. Без него Nginx будет искать физический файл и папку, которых не существует.
Если вы не управляете сервером напрямую, этот шаг обычно выполняет хостинг-поддержка. Важно описать им симптом точно: главная страница открывается, а отдельные записи и страницы WordPress возвращают 404 после переноса или смены структуры ссылок.
Проверьте конфликт плагинов и темы
Иногда 404 появляется после установки или обновления плагина, который вмешивается в маршрутизацию URL: создаёт свои типы записей, меняет правила перезаписи или добавляет дополнительные шаблоны. Смена темы тоже может повлиять на адреса, если тема регистрирует собственные типы записей, таксономии или шаблоны архивов.
Чтобы быстро проверить конфликт, временно отключите все плагины, кроме тех, без которых сайт не работает технически. Затем снова откройте проблемную страницу. Если 404 исчезла, включайте плагины по одному, пока не найдёте источник конфликта.
Если отключение плагинов не помогло, временно переключитесь на стандартную тему WordPress, например Twenty Twenty-Four. Если страницы начали открываться, значит проблема связана с текущей темой или её функциями.
Этот способ безопасен для контента, но на рабочем сайте может изменить внешний вид. Лучше делать проверку в спокойное время или на копии сайта.
Если 404 только у части страниц
Бывает, что не открываются не все записи, а только отдельные страницы. Тогда причина часто локальная:
- страница была удалена или перемещена в корзину;
- изменился её ярлык, а старый адрес нигде не перенаправляется;
- запись привязана к таксономии или шаблону, который больше не существует;
- в URL есть кириллица, спецсимволы или лишние символы после ручного редактирования ссылки.
Откройте проблемную запись в админке и проверьте её постоянную ссылку. Если ярлык изменился, старый адрес перестанет работать сам по себе. В таком случае нужно либо вернуть прежний URL, либо настроить редирект со старого адреса на новый.
Если страница была удалена случайно, восстановите её из корзины. Для записей и страниц WordPress это самый быстрый способ вернуть прежний адрес, если контент ещё не очищен окончательно.
Как проверить, что ошибка исправлена
После каждого изменения откройте проблемный URL в обычном окне браузера, а не только из админки. Лучше проверить страницу в режиме инкогнито или после очистки кэша браузера, чтобы не увидеть старую версию ответа.
Если на сайте используется кэш-плагин, очистите его кэш после правок. Иначе можно получить ложное впечатление, что 404 осталась, хотя сервер уже отдаёт правильный ответ, а браузер или кэш-плагин показывает старую страницу.
Проверка считается успешной, если:
- страница открывается по нужному адресу без 404;
- адрес в строке браузера совпадает с ожидаемым;
- внутренние ссылки на сайте ведут на рабочие URL;
- после обновления страницы ошибка не возвращается.
Что делать, если ничего не помогло
Если пересохранение постоянных ссылок, проверка .htaccess, смена темы и отключение плагинов не дали результата, проблема, скорее всего, глубже: в конфигурации сервера, правах доступа, повреждённой базе данных или нестандартной структуре сайта после миграции.
В таком случае имеет смысл проверить:
- доступность файла
.htaccessдля записи на Apache; - правильность значений
homeиsiteurlв базе данных; - логи веб-сервера, если есть доступ к ним;
- не использует ли сайт кастомные правила перезаписи для произвольных типов записей.
Если сайт рабочий и ошибка затрагивает важные страницы, безопаснее сначала сделать резервную копию, а потом уже менять серверные настройки или править базу. Это особенно важно после переноса: одна неверная правка может добавить к 404 ещё и редирект-цикл или поломку входа в админку.
В большинстве случаев ошибка 404 на страницах и записях WordPress устраняется именно на уровне постоянных ссылок и правил перезаписи. Начинайте с пересохранения настроек, затем проверяйте сервер, тему и плагины. Такой порядок экономит время и не заставляет лезть в код раньше, чем это действительно нужно.