Как исправить 404 на страницах сайта после смены URL в WordPress

Ситуация типовая: сайт открывается, админка доступна, а часть страниц, записей или архивов внезапно отдаёт 404 после смены домена, переезда на HTTPS, переноса WordPress в подпапку или правки адресов в настройках. В таких случаях проблема часто не в контенте, а в правилах перезаписи, кэше, структуре постоянных ссылок или несоответствии адресов сайта и фактического расположения файлов.

Сначала проверьте, что именно сломалось

404 после переезда бывает разной. Иногда не открываются только ЧПУ-страницы, а /wp-admin/ и /wp-login.php работают нормально. Иногда ломаются только архивы рубрик, а главная и отдельные записи открываются. Это важно: от типа ошибки зависит, где искать причину.

Быстрая диагностика

• Откройте /wp-admin/options-permalink.php и проверьте текущую структуру постоянных ссылок.
• Сравните значения home и siteurl в таблице wp_options или через wp option get.
• Проверьте, существует ли файл .htaccess в корне сайта и не перезаписывает ли его сервер или плагин кэша.
• Если сайт на Nginx, проверьте блок try_files и правила для WordPress.
• Очистите серверный и плагинный кэш, если он есть.

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

Почему после смены URL появляются 404

Чаще всего причина одна из четырёх:

• не обновились правила перезаписи после переноса;
• в home и siteurl остались старые адреса;
• сервер смотрит не в ту папку, где лежит index.php WordPress;
• кэш отдаёт старые ответы или старые редиректы.

Если WordPress перенесли в подпапку, а домен остался прежним, особенно часто ломаются вложенные страницы. Если меняли HTTP на HTTPS, иногда проблема маскируется настройками плагина кэша или CDN.

Пошаговое решение без лишних изменений

1. Обновите структуру постоянных ссылок

Самый безопасный шаг — просто сохранить настройки постоянных ссылок заново. Это заставляет WordPress пересобрать правила маршрутизации.

/* Вручную через админку: Настройки → Постоянные ссылки → Сохранить изменения */

Если доступа к админке нет, можно сделать это через WP-CLI:

wp rewrite flush --hard

Команда пересоздаст правила перезаписи. Используйте её после того, как убедились, что адреса сайта уже корректны.

2. Проверьте адреса сайта

Если home и siteurl указывают на старый домен или старый протокол, WordPress может строить ссылки и редиректы неправильно. Проверить значения можно так:

wp option get home
wp option get siteurl

Если нужно исправить адреса, делайте это аккуратно и только после бэкапа:

wp option update home 'https://example.com'
wp option update siteurl 'https://example.com'

Когда WordPress установлен в подпапке, siteurl обычно указывает на папку установки, а home — на публичный адрес сайта. Эти значения не всегда должны совпадать.

3. Сбросьте правила перезаписи программно, если нужно

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

<?php
add_action( 'init', function () {
    if ( get_option( 'my_flush_rewrite_rules_done' ) ) {
        return;
    }

    flush_rewrite_rules( false );
    update_option( 'my_flush_rewrite_rules_done', 1 );
} );

После первого успешного запуска этот код нужно убрать или оставить только в виде одноразовой миграции. Постоянный вызов flush_rewrite_rules() на фронтенде сильно бьёт по производительности.

4. Проверьте .htaccess или конфигурацию Nginx

Для Apache в корне сайта должен быть стандартный блок WordPress. Если его нет или он повреждён, ЧПУ-страницы будут отдавать 404.

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

Для Nginx логика обычно строится вокруг try_files. Базовый вариант выглядит так:

location / {
    try_files $uri $uri/ /index.php?$args;
}

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

Когда проблема не в WordPress, а в кэше

После смены URL кэш часто продолжает хранить старые правила, старые canonical-адреса или даже старые 404. Это касается плагинов кэша, серверного кэша, CDN и браузера.

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

Проверка результата после внедрения

После исправлений не ограничивайтесь открытием главной страницы. Проверьте несколько типов URL:

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

Удобно проверить ответ сервера через curl:

curl -I https://example.com/sample-post/
curl -I https://example.com/category/news/

В ответе должен быть не 404, а нормальный код вроде 200 или ожидаемый редирект на новый адрес. Если редирект есть, но он ведёт на старый URL, снова проверьте home, siteurl и правила редиректов в плагинах.

Частые ошибки и как их исправить

Сохранили постоянные ссылки, но 404 остались

Значит, проблема не только в правилах WordPress. Смотрите .htaccess, конфигурацию Nginx и кэш. Иногда файл правил вообще не записывается из-за прав на каталог.

Изменили адрес сайта в базе, но админка стала вести на старый домен

Проверьте, нет ли жёстко заданных значений в wp-config.php через WP_HOME и WP_SITEURL. Если они заданы, значения из базы могут игнорироваться.

404 только на части страниц

Так бывает, если сломаны правила для конкретного типа записей: кастомного post type, таксономии или страницы автора. Тогда нужно смотреть регистрацию типа записи и параметр rewrite, а не только общие настройки ссылок.

После HTTPS появились старые адреса и 404

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

Если 404 связаны с кастомным кодом темы или плагина

Когда сайт использует собственные типы записей, ошибка может быть в регистрации маршрутов. Например, если в register_post_type() указан неверный rewrite или забыта поддержка has_archive, архивы и отдельные страницы будут открываться нестабильно.

<?php
add_action( 'init', function () {
    register_post_type( 'docs', [
        'label'       => 'Документация',
        'public'      => true,
        'has_archive' => true,
        'rewrite'     => [ 'slug' => 'docs' ],
        'supports'    => [ 'title', 'editor' ],
    ] );
} );

После изменения таких параметров всегда нужно обновлять правила перезаписи. Иначе WordPress продолжит использовать старые маршруты.

Практические советы по безопасности и производительности

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

Если вы часто меняете структуру URL на проекте, полезно иметь отдельный сценарий миграции: сначала обновить home и siteurl, затем выполнить wp rewrite flush --hard, потом очистить кэш и только после этого проверять страницы. Такой порядок снижает шанс поймать ложные 404 из-за старых данных.

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

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