WordPress: записи выдают 404 после смены постоянных ссылок

#Почему появляется 404

Главная страница открывается, а записи и страницы дают «404 Not Found». Причина в правилах перезаписи URL: WordPress ожидает, что веб-сервер будет передавать все несуществующие пути в index.php. Если правила в .htaccess отсутствуют, mod_rewrite отключён, в Apache запрещено AllowOverride, или в nginx нет директивы try_files, сервер ищет физический файл и сообщает, что страницы нет. Проблема часто возникает после переноса сайта, смены хостинга или сброса настроек ссылок.

#Причины

#Порядок

1. Сохраните настройки постоянных ссылок в WordPressВойдите в /wp-admin/ → «Настройки → Постоянные ссылки», перепишите выбранную структуру и нажмите «Сохранить изменения», даже если шаблон не меняли. Откройте одну проблемную запись и главную страницу в приватной вкладке. Если записи начали открываться, ошибка была связана с правилами маршрутизации; не меняйте адреса записей по одной.
2. Проверьте правила .htaccess на Apache и try_files на NginxОпределите веб-сервер: в панели хостинга откройте сведения о сайте или обратитесь к администратору. Для Apache проверьте, что в корне WordPress есть .htaccess с правилами именно WordPress и что их применение разрешено соответствующим AllowOverride; для Nginx .htaccess не используется, нужна корректная директива try_files. Сохраните существующие правила прежде чем заменять.
3. Проверьте mod_rewrite и AllowOverride в ApacheНа Apache администратор проверяет apachectl -M | grep rewrite и применяемый <Directory> для WordPress; при отсутствии модуля/разрешения согласует включение. Для Nginx проверьте sudo nginx -T и соответствие root и try_files $uri $uri/ /index.php?$args; логике сайта. Не копируйте этот пример в конфигурацию, где используется нестандартный фронт-контроллер.
4. Сверьте адреса и пути установки WordPressЕсли WordPress установлен в подкаталог или за обратным прокси, сверьте «Настройки → Общие» (Адрес WordPress и Адрес сайта) с фактическим путём и HTTPS. Изменение этих адресов может лишить входа в админку, поэтому сделайте копию базы и wp-config.php и подготовьте способ возврата.
5. Проверьте конфликтующие плагины и правила перенаправленияПроверьте, не перехватывают ли URL плагины перенаправлений, безопасности, кеширования и правила CDN. На стенде по одному отключайте недавно изменённые плагины, записывая эффект. Не отключайте защиту действующего сайта без плана доступа; сначала сравните журналы с точным адресом 404.
6. Проверьте состояние и адрес конкретной записиЕсли 404 выдаёт только одна запись, откройте её в редакторе и убедитесь, что она опубликована, а адрес не конфликтует со страницей или таксономией. Проверьте статус в «Записи → Все записи» и сохраните ссылку, не меняя массово slug других материалов.
7. Проверьте конфигурацию веб-сервера и откройте несколько страницПосле правки конфигурации веб-сервера выполните проверку синтаксиса (nginx -t или apachectl configtest) и перезагрузите конфигурацию, затем проверьте главную, пару старых и новых ЧПУ и служебную страницу /wp-admin/. Если проблема остаётся, сохраните HTTP-код, URL, журнал и конфигурацию маршрутизации.
8. Убедитесь, что отсутствующая страница возвращает HTTP 404Убедитесь, что WordPress выдаёт собственную страницу 404 для действительно несуществующего URL, а не ответ 200 на всё подряд. Это полезно и для безопасности, и для индексирования; избегайте правил, которые автоматически направляют на главную любой ошибочный адрес.
9. Команды для отдельных ситуацийВыберите только подходящий вариант. Это не одна последовательность: часть команд диагностирует проблему, а часть меняет настройки или данные.
   Выберите подходящий вариант — это не команды для последовательного выполнения

   Вариант 1Стандартные правила WordPress для Apache

   ТекстКомандаКопировать всёВыделить

   Стандартные правила WordPress для Apache

   # 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

   Вариант 2Правило nginx для WordPress в блоке server

   NginxКомандаКопировать всёВыделить

   Правило nginx для WordPress в блоке server

   location / {

   try_files $uri $uri/ /index.php?$args;

   }

   Вариант 3Включить mod_rewrite в Apache и проверить конфигурацию (Debian/Ubuntu)

   Linux · Терминал (Bash)КомандаНужен sudoКопировать всёВыделить

   Включить mod_rewrite в Apache и проверить конфигурацию (Debian/Ubuntu)

   sudo a2enmod rewrite

   sudo apache2ctl configtest

   sudo systemctl reload apache2

   Вариант 4WP-CLI запускать из каталога конкретного WordPress под его системным пользователем после резервной копии; б…

   Linux · Терминал (Bash)КомандаКопировать всёВыделить

   WP-CLI запускать из каталога конкретного WordPress под его системным пользователем после резервной копии; без --hard, чтобы не переписывать .htaccess без нужды.

   wp rewrite flush

   wp rewrite list --format=table | head -20

   wp option get siteurl

   wp option get home

   Вариант 5Диагностика доступа к .htaccess без безусловной смены прав

   Linux · Терминал (Bash)КомандаКопировать всёВыделить

   Диагностика доступа к .htaccess без безусловной смены прав

   ls -l .htaccess

   # Не изменяйте права .htaccess без подтверждённого отказа доступа.

   # Уточните владельца, группу и действующие ACL.

#Особенности мультисайта и подкаталога

Если WordPress установлен в подкаталог (/blog/), в .htaccess значение RewriteBase и последнее правило должны содержать этот путь: RewriteBase /blog/ и RewriteRule . /blog/index.php [L]. Для мультисайта правила другие: скопируйте блок из «Сеть → Настройка сети». Если используется кеширующий плагин, после смены ссылок очистите его кеш, иначе посетители будут видеть старые 404.