Ошибка 404 в WordPress: почему страницы пропали и как вернуть постоянные ссылки

Если главная страница сайта открывается, а записи и обычные страницы внезапно отдают 404, проблема почти всегда связана не с контентом, а с маршрутизацией URL. WordPress не может правильно сопоставить адрес страницы с записью в базе, либо веб-сервер не передаёт запрос в систему перезаписи ссылок. В такой ситуации удалять записи, переустанавливать WordPress или сразу менять тему не нужно: сначала стоит проверить, где именно ломается цепочка — в настройках постоянных ссылок, файле .htaccess, конфигурации сервера или после недавних изменений на сайте.

Как выглядит именно эта проблема

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

Ещё один полезный признак — адреса с параметрами, например ?p=123, могут открываться, а человекочитаемые ссылки вида /category/post-name/ — нет. Это почти всегда указывает на сбой перезаписи ссылок, а не на потерю данных.

Что чаще всего ломается в такой ситуации

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

Наиболее вероятные причины

• не обновились правила постоянных ссылок после изменения структуры URL;
• повреждён или перезаписан .htaccess на Apache/LiteSpeed;
• на Nginx не настроена передача «красивых» ссылок в WordPress;
• плагин или тема изменили правила перезаписи и создали конфликт;
• после миграции сайта не совпадают домен, путь установки или настройки сервера;
• для произвольного типа записи не зарегистрированы rewrite rules или изменился его slug;
• редко — проблема в кэше, но обычно кэш лишь маскирует основную причину, а не создаёт её.

С чего начать диагностику без риска

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

1. Сохраните текущие настройки и проверьте, не меняли ли структуру ссылок

Если ошибка появилась сразу после изменения постоянных ссылок, переноса сайта, установки SEO-плагина или обновления темы, это уже хороший ориентир. В админке откройте Настройки → Постоянные ссылки и посмотрите, какая структура выбрана. Иногда проблема возникает после переключения с простой структуры на «Название записи» или после ручного редактирования базы/конфига.

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

2. Пересохраните постоянные ссылки

Это самый частый и самый безопасный шаг. Он не меняет контент и часто исправляет ситуацию, если правила rewrite не были обновлены после изменений в теме, плагинах или структуре URL.

Что делать:

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

Если после этого всё заработало, значит проблема была именно в несинхронизированных правилах перезаписи. Если 404 остались, идём дальше.

3. Проверьте, не сломан ли .htaccess

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

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

Стандартный блок для WordPress на Apache выглядит так:

<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 и последней строке должен соответствовать реальному расположению сайта.

4. Уточните, какой у вас веб-сервер

Если сайт работает на Nginx, файл .htaccess не используется вообще. В этом случае 404 на страницах обычно означает, что в конфигурации Nginx не настроено перенаправление запросов в WordPress. Это уже не проблема WordPress как такового, а вопрос серверной конфигурации.

Для Nginx нужен корректный блок, который передаёт запросы в index.php. Если после переноса сайта на новый хостинг главная открывается, а внутренние страницы — нет, очень часто причина именно здесь. На shared-хостинге это обычно решает поддержка. На VPS или выделенном сервере нужно править конфиг сайта и затем перезагружать Nginx.

Как отличить проблему WordPress от проблемы сервера

Есть простой практический ориентир. Если при открытии обычной записи WordPress показывает свою 404-страницу, а главная и админка работают, значит PHP и база, скорее всего, живы, а сбой связан с маршрутизацией. Если же вместо страницы WordPress вы видите 404 от самого веб-сервера, без оформления темы и без типичного шаблона сайта, проблема может быть на уровне Nginx/Apache или правил виртуального хоста.

Проверить это можно по заголовкам и виду страницы, но без глубокого анализа логов иногда трудно отличить одно от другого. Если у вас есть доступ к error log, ищите записи в момент открытия проблемного URL. Для Apache и Nginx это обычно самый быстрый путь понять, доходит ли запрос до WordPress.

Если ошибка появилась после плагина, темы или миграции

После обновления темы, установки SEO-плагина, переноса сайта на другой домен или изменения структуры URL конфликт тоже возможен. Но отключать всё подряд не лучший первый шаг. Сначала нужно понять, что именно изменилось.

Проверка конфликта без лишнего риска

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

Если staging нет, действуйте точечно:

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

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

Что проверить после миграции сайта

После переноса сайта 404 на внутренних страницах часто связаны с тем, что:

• WordPress установлен в другой папке, чем раньше;
• в siteurl и home остались старые адреса;
• на новом сервере не включён mod_rewrite или не работает нужный блок Nginx;
• в корне сайта лежит старый .htaccess, который не соответствует новой конфигурации.

Если домен менялся, проверьте настройки адреса сайта в Настройки → Общие. Но не путайте это с проблемой 404: неверный siteurl обычно ломает вход в админку, загрузку ресурсов или редиректы, а не только внутренние страницы. Хотя при переносе оба симптома могут идти вместе.

Когда нужно смотреть базу данных и логи

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

Проверьте, не повреждены ли правила перезаписи

WordPress хранит rewrite rules в базе данных. Обычно они пересоздаются автоматически, но после нестандартной миграции или сбоя кэша объектных данных правила могут не обновиться как надо. В таком случае помогает повторное сохранение структуры ссылок, а иногда — временное отключение плагинов, которые регистрируют свои типы записей или таксономии.

Если у вас есть WP-CLI, можно проверить и обновить правила через командную строку, но это уже уместно только при уверенном доступе к серверу. На shared-хостинге проще и безопаснее сделать это через админку.

Проверьте логи веб-сервера

Логи полезны, когда 404 не объясняется настройками WordPress. В error log ищите сообщения о недоступном файле, ошибках rewrite, неверном пути к index.php или запрете доступа. Если в логах видно, что запрос вообще не доходит до PHP, значит проблема на уровне веб-сервера или его конфигурации. Если PHP отрабатывает, но WordPress всё равно отдаёт 404, значит нужно смотреть правила маршрутизации, тип записи или конфликт плагина.

Как безопасно восстановить работу постоянных ссылок

Если коротко, порядок действий такой:

1. Сделайте резервную копию .htaccess и, если возможно, базы данных.
2. Пересохраните постоянные ссылки в админке.
3. Проверьте, не изменился ли веб-сервер и не нужен ли отдельный блок для Nginx.
4. Сравните текущий .htaccess со стандартным шаблоном WordPress.
5. Точечно отключите плагины, которые влияют на URL, и проверьте результат после каждого шага.
6. После исправления откройте несколько старых и новых URL, чтобы убедиться, что 404 исчезла не только на одной странице.

Если сайт работает на Apache/LiteSpeed, а .htaccess постоянно перезаписывается, проверьте, не делает ли это плагин кэша, безопасности или редиректов. Если на Nginx всё зависит от конфигурации хоста, без доступа к серверу вы можете только подтвердить симптом, но не исправить его полностью — тогда разумнее обратиться в поддержку хостинга.

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

После исправления откройте:

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

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

Если после всех шагов главная открывается, а внутренние страницы по-прежнему недоступны, не стоит бесконечно повторять одни и те же действия. В этот момент нужны логи веб-сервера, информация о типе хостинга и точные примеры URL, которые не работают. По этим данным уже можно понять, где именно рвётся цепочка: в WordPress, в rewrite rules, в .htaccess или в конфигурации Nginx/Apache.