Устранение 404 после смены структуры постоянных ссылок в WordPress

Смена структуры постоянных ссылок в WordPress почти всегда оставляет хвост из 404: старые URL уже где-то проиндексированы, лежат в закладках, приходят из внешних ссылок или внутренней перелинковки. Если просто поменять настройки в Настройки → Постоянные ссылки и ничего не сделать дальше, сайт быстро начинает терять трафик и накапливать ошибки в Search Console.

Ниже — практический сценарий: как диагностировать проблему, где именно ломаются URL, как настроить редиректы и как проверить, что всё действительно работает, а не только «открывается в браузере».

Как понять, что 404 связаны именно со сменой permalink-структуры

Сначала нужно отделить старые адреса от случайных ошибок. После смены структуры обычно ломаются:

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

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

Проверьте несколько старых URL из логов сервера, Search Console или аналитики. Если ошибка повторяется на типовых шаблонах, например /2023/05/nazvanie-posta/ вместо нового /nazvanie-posta/, значит нужен не точечный фикс, а правило перенаправления.

Полезно посмотреть и серверные логи. Если у вас есть доступ к nginx/apache access log, ищите запросы с кодом 404 и одинаковыми старыми паттернами. Это быстрее, чем вручную щёлкать десятки ссылок.

Пошаговое решение: от проверки настроек до редиректов

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

1. Сохраните текущую структуру и сбросьте правила

После изменения структуры зайдите в Настройки → Постоянные ссылки и нажмите «Сохранить изменения» ещё раз. Это обновляет rewrite rules. Если сайт на кэше или с агрессивной оптимизацией, очистите кэш страницы и объектный кэш, если он есть.

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

wp rewrite flush --hard

Команда полезна после миграций и правок в functions.php, но не стоит запускать её на каждом запросе или в cron без необходимости.

2. Настройте редирект со старого шаблона URL

Если структура была, например, /%year%/%monthnum%/%postname%/, а стала просто /%postname%/, можно сделать редирект на уровне сервера или через плагин. Для точечных правил безопаснее сервер, для массовых и разнородных сценариев — плагин редиректов.

Пример для functions.php или мини-плагина: редирект старых URL записей с датой на новый slug. Это не универсальное решение для всех сайтов, но для типового случая работает предсказуемо.

add_action('template_redirect', function () {
    if (is_admin() || wp_doing_ajax()) {
        return;
    }

    $request_uri = $_SERVER['REQUEST_URI'] ?? '';

    if (preg_match('#^/\d{4}/\d{2}/([^/]+)/?$#', $request_uri, $matches)) {
        $slug = sanitize_title($matches[1]);
        $post = get_page_by_path($slug, OBJECT, 'post');

        if ($post) {
            wp_redirect(get_permalink($post), 301);
            exit;
        }
    }
});

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

3. Проверьте внутренние ссылки

Даже идеальный 301 не спасёт от лишней нагрузки, если в контенте остались старые ссылки. Ищите старые шаблоны в базе, меню, виджетах и блоках. Для этого удобно использовать поиск по базе через WP-CLI или инструмент миграции/поиска-замены, если он у вас уже есть в рабочем процессе.

Пример безопасной проверки через WP-CLI: сначала ищем старый фрагмент, потом меняем только после бэкапа.

wp search-replace '/2023/05/' '/' --dry-run

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

Что выбрать: плагин, серверный редирект или код

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

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

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

После настройки редиректов важно не ограничиваться ручным открытием пары страниц. Проверка должна показать три вещи: старый URL отдаёт 301, новый URL открывается с 200, а цепочек редиректов нет.

Проверка через curl

Самый быстрый способ — посмотреть заголовки ответа:

curl -I https://example.com/2023/05/nazvanie-posta/
curl -I https://example.com/nazvanie-posta/

В первом случае ожидается 301 и заголовок Location на новый адрес. Во втором — 200. Если старый URL сначала ведёт на другой старый URL, а потом уже на новый, это цепочка редиректов. Её лучше убрать.

Проверка в Search Console и логах

После переобхода страниц в Search Console смотрите, уменьшается ли число ошибок «Страница не найдена». Полезно также проверить серверные логи: если старые URL продолжают массово запрашиваться, значит где-то остались ссылки или поисковик ещё не переиндексировал изменения.

Отдельно проверьте:

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

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

Редирект сделан на главную вместо релевантной страницы

Это частая ошибка после массовой смены структуры. Главная страница не заменяет старую запись и выглядит как soft 404 для поисковика. Исправление простое: ведите старый URL на максимально близкий новый адрес, а не на корень сайта.

Правило редиректа ловит лишние URL

Слишком широкая регулярка может начать перенаправлять не только старые записи, но и реальные страницы, файлы или служебные маршруты. Если видите странные срабатывания, сузьте шаблон и проверьте исключения для /wp-json/, медиафайлов и страниц админки.

Кэш мешает увидеть результат

Если вы проверяете редирект в браузере, а он «не работает», сначала очистите кэш плагина, CDN и браузера. Иногда старый ответ 404 или 200 продолжает отдаваться из кэша, хотя правило уже исправлено.

Не обновили внутренние ссылки

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

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

Если редиректов много, не складывайте всю логику в functions.php активной темы. При смене темы вы потеряете правила. Лучше вынести их в небольшой mu-plugin или отдельный мини-плагин, который не зависит от дизайна.

Не ставьте несколько плагинов редиректов одновременно. Они могут конфликтовать, создавать цепочки и усложнять диагностику. Один инструмент для управления правилами обычно достаточно.

Для сайта с большим количеством старых URL полезно:

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

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