Как исправить ошибку 404 на страницах WordPress

Если отдельные записи, страницы или целые разделы WordPress внезапно начали отдавать 404, проблема обычно не в самом контенте, а в правилах маршрутизации: сбились постоянные ссылки, вмешался редирект, плагин изменил адреса, либо сервер перестал отдавать нужные rewrite-правила. Хорошая новость в том, что в большинстве случаев это чинится без переезда сайта и без правки базы вручную.

Ниже — практичный порядок проверки. Он помогает быстро понять, где именно ломается адрес: в настройках WordPress, в плагинах, на уровне сервера или в конкретной записи.

Сначала проверьте, что именно даёт 404

404 на WordPress бывает разным по причине, хотя внешне выглядит одинаково. Иногда не открывается одна страница, иногда весь раздел записей, иногда только старые URL после изменения структуры ссылок. От этого зависит, с чего начинать.

• Одна запись или страница — чаще всего проблема в удалённом/изменённом slug, конфликте редиректа или в том, что URL ведёт на несуществующий адрес.
• Все записи или все страницы — чаще ломаются постоянные ссылки или правила перезаписи на сервере.
• Только часть URL — нередко виноват плагин редиректов, кэш или настройка ЧПУ.

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

Самый частый фикс: пересохранить постоянные ссылки

Это первое действие, которое стоит сделать почти всегда. WordPress хранит правила формирования URL, и после миграции, смены темы, обновления плагинов или ручных правок они иногда перестают совпадать с реальными правилами на сервере.

Что сделать:

1. Откройте Настройки → Постоянные ссылки.
2. Ничего не меняя, нажмите Сохранить изменения.
3. Проверьте проблемную страницу ещё раз.

После этого WordPress заново записывает правила маршрутизации. Если 404 исчезла, значит проблема была именно в перегенерации rewrite-правил. Это безопасный шаг: он не меняет контент и не удаляет записи.

Если сайт работает на Apache, WordPress обычно опирается на файл .htaccess. Если он повреждён или недоступен для записи, пересохранение постоянных ссылок может не помочь. На Nginx логика другая: там правила должны быть корректно прописаны в конфигурации сервера, а не в .htaccess.

Проверьте, не сломались ли редиректы

Когда страница раньше открывалась по одному адресу, а потом начала отдавать 404, часто виноват редирект. Это особенно заметно после смены структуры ссылок, переезда с другого домена или установки SEO-плагина.

Проверьте три типичных сценария:

• Редирект ведёт в никуда — старый URL перенаправляет на несуществующую страницу.
• Цепочка редиректов — адрес проходит через несколько переходов и в конце упирается в 404.
• Конфликт правил — один плагин отправляет на новый адрес, другой тут же возвращает на старый или меняет конечный URL.

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

Особенно внимательно проверьте:

• редиректы с HTTP на HTTPS;
• редиректы с www на без www или наоборот;
• правила после смены структуры постоянных ссылок;
• автоматические редиректы из SEO-плагинов и плагинов безопасности.

Исключите конфликт плагинов

Если 404 появилась после установки или обновления плагина, не стоит сразу искать проблему в теме или сервере. Чаще всего конфликтуют плагины, которые вмешиваются в URL: SEO, редиректы, кэширование, мультиязычность, фильтры ЧПУ, защита от спама и некоторые конструкторы.

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

Порядок проверки обычно такой:

1. Отключите плагины редиректов и SEO-расширения.
2. Проверьте кэш-плагины, если они меняют правила доставки страниц.
3. Посмотрите плагины мультиязычности и фильтрации URL.
4. Если не помогло, временно отключите все плагины и проверьте снова.

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

Как безопасно тестировать плагины на живом сайте

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

Проверьте саму запись или страницу

Иногда 404 возникает не из-за настроек сайта, а потому что у записи изменился адрес. В WordPress URL записи зависит от slug — части адреса после домена. Если slug был отредактирован, старый адрес перестаёт работать.

Что проверить в админке:

• существует ли запись или страница в нужном статусе;
• не переведена ли она в черновик, корзину или приватный режим;
• не изменился ли slug;
• не вложена ли страница в другой родительский раздел, из-за чего адрес стал длиннее.

Для записей и страниц с иерархией это особенно важно. Например, страница могла быть перенесена под другой родительский раздел, и старый URL больше не совпадает с новым. В таком случае 404 на старом адресе — нормальное поведение, если редирект не настроен.

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

Когда проблема на стороне сервера

Если пересохранение постоянных ссылок не помогло, а плагины отключены, смотрите на серверные правила. Здесь уже важны тип хостинга и веб-сервер.

Для Apache проверьте, что:

• в корне сайта есть корректный .htaccess;
• файл доступен для записи WordPress;
• на сервере включён модуль mod_rewrite;
• директива AllowOverride не запрещает чтение правил из .htaccess.

Для Nginx правила WordPress должны быть прописаны в конфигурации сайта. Если там нет корректной обработки красивых ссылок, WordPress будет отдавать 404 даже при правильных настройках в админке.

Если вы не управляете сервером напрямую, передайте хостингу конкретный симптом: «после пересохранения постоянных ссылок отдельные страницы WordPress отдают 404». Это быстрее, чем писать просто «не открывается сайт», потому что проблема может быть только в rewrite-правилах.

Как проверить, что ошибка действительно исправлена

После каждого изменения проверяйте не только одну страницу, но и несколько типов URL:

• проблемную запись или страницу;
• одну обычную страницу без вложенности;
• раздел архива записей, если он есть;
• старый адрес, если вы настраивали редирект.

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

Хороший признак — после пересохранения постоянных ссылок и отключения конфликтующих плагинов все нужные адреса открываются стабильно, а старые URL, если вы их меняли, корректно ведут на новые страницы через 301-редирект.

Что делать, если 404 возвращается снова

Если ошибка появляется периодически, причина обычно не в одной настройке, а в процессе, который снова и снова переписывает URL. Такое бывает после автообновлений плагинов, при синхронизации с кэшем, при импорте контента или после работы SEO-расширений.

В этом случае полезно зафиксировать:

• после какого действия 404 появилась снова;
• какой именно URL ломается;
• какой плагин был обновлён или настроен перед этим;
• меняется ли поведение после очистки кэша.

Если проблема повторяется после очистки кэша, проверьте, не создаёт ли плагин кэширования старую версию маршрутов. Если 404 появляется после редактирования записи, посмотрите, не меняется ли slug автоматически. Если после обновления SEO-плагина — проверьте его правила редиректов и работу с постоянными ссылками.

В большинстве случаев порядок такой: пересохранить постоянные ссылки, отключить конфликтующий плагин, проверить редиректы, затем уже смотреть сервер. Такой подход экономит время и не заставляет менять то, что и так работает.