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

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

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

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

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

Типичные признаки:

• старые ссылки на записи открываются с 404, хотя запись опубликована;
• в логах много запросов к URL с прежним префиксом, например /2024/05/slug/ вместо /slug/;
• внутренние ссылки в старых статьях ведут на несуществующий формат;
• поисковик продолжает показывать старые адреса в выдаче.

Что проверить в первую очередь

Не начинайте с массовых редиректов наугад. Сначала убедитесь, что проблема именно в структуре ссылок, а не в другом:

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

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

Если сайт небольшой, можно обойтись логами веб-сервера и отчётом Search Console. На проектах побольше удобнее собрать список из нескольких источников: старые sitemap-файлы, экспорт из аналитики, логи 404 и внутренний поиск по базе контента.

Практичный минимум:

1. Откройте отчёт 404 в Search Console и выгрузите примеры URL.
2. Проверьте access log за последние дни: ищите ответы 404 по старым шаблонам ссылок.
3. Сравните старую и новую структуру permalink, чтобы понять, можно ли сделать редирект правилом, а не вручную.

Если у вас есть доступ к консоли сервера, быстро отфильтровать 404 можно так:

grep ' 404 ' /var/log/nginx/access.log | tail -n 50

Для Apache путь к логам может отличаться, но логика та же: вам нужны именно URL, которые стабильно дают 404, а не единичные случайные запросы ботов.

Пошаговое решение: как закрыть старые адреса без поломки новых

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

Подход	Когда использовать	Плюсы	Минусы
Плагин редиректов	Нужно быстро закрыть десятки URL	Удобно править, не нужен доступ к серверу	Дополнительная нагрузка и зависимость от плагина
Правило в сервере	Старый URL имеет стабильный шаблон	Быстро и без PHP-обработки	Нужно аккуратно тестировать регулярные выражения
Код в теме или mu-plugin	Нужна точечная логика под конкретный кейс	Гибкость, контроль в репозитории	Требует разработки и поддержки

Вариант 1: массовый редирект через шаблон

Если старая структура была предсказуемой, например /YYYY/MM/post-name/, а новая стала просто /post-name/, можно сделать правило на уровне сервера. Для Nginx это обычно выглядит так:

rewrite ^/([0-9]{4})/([0-9]{2})/(.+)/?$ /$3/ permanent;

Это сработает только если $3 действительно соответствует новому slug записи. Перед выкладкой проверьте на тестовом стенде: неправильное регулярное выражение легко отправит часть URL не туда.

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

Вариант 2: точечные редиректы для конкретных страниц

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

Пример через template_redirect в mu-plugin:

<?php
/**
 * Plugin Name: Old URL Redirects
 */
add_action('template_redirect', function () {
    $path = trim(parse_url($_SERVER['REQUEST_URI'], PHP_URL_PATH), '/');

    $map = [
        '2024/05/my-old-post' => 'my-new-post',
        'blog/old-about-page'  => 'about',
    ];

    if (isset($map[$path])) {
        wp_redirect(home_url('/' . $map[$path] . '/'), 301);
        exit;
    }
});

Такой вариант хорош тем, что его легко ревизировать. Но если редиректов много, список нужно хранить отдельно и не превращать в хаос внутри темы.

Вариант 3: плагин редиректов, если нужен быстрый интерфейс

Если у вас нет доступа к серверу или нужно, чтобы редиректы мог редактировать контент-менеджер, используйте плагин класса Redirection. Он не решает проблему сам по себе, но помогает быстро закрыть старые URL и отслеживать 404.

Важно: не ставьте несколько плагинов редиректов одновременно. Иначе можно получить цепочки 301 → 301 → 404 или конфликт правил.

Как не сломать SEO при смене структуры ссылок

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

Проверьте ещё три вещи:

• внутренние ссылки в контенте обновлены на новый формат;
• в XML sitemap попали только актуальные URL;
• canonical у страницы указывает на новый адрес, а не на старый.

Если у вас стоит плагин для SEO, после смены permalink-структуры полезно пересобрать sitemap и очистить кеш. Иначе поисковик может какое-то время получать смешанный набор старых и новых адресов.

Проверка результата: как убедиться, что 404 закрыты

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

1. Откройте старый URL и убедитесь, что он отдаёт 301, а не 302 или 404.
2. Проверьте, что конечный адрес отвечает 200.
3. Сделайте повторную выборку в Search Console через несколько дней и посмотрите, уменьшается ли число ошибок.
4. Проверьте, не появились ли новые 404 из-за внутренних ссылок в старых записях.

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

curl -I https://example.com/2024/05/my-old-post

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

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

Редирект ведёт на главную

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

Сделали 302 вместо 301

Временный редирект не подходит для постоянной смены структуры ссылок. Если оставить 302, поисковик может дольше держать старый адрес в индексе. Проверьте настройки плагина или код редиректа.

Редиректов слишком много и они конфликтуют

Часто это происходит, когда часть правил лежит в плагине, часть — в .htaccess, а ещё что-то добавлено в тему. В итоге один URL проходит через несколько обработчиков. Решение: оставить один источник истины и удалить дублирующиеся правила.

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

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

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

Редиректы — это не только SEO, но и лишняя нагрузка, если их сделать неаккуратно. Несколько правил, которые реально помогают:

• не ставьте тяжёлые PHP-обработчики на каждый запрос, если шаблон можно решить на уровне сервера;
• не храните огромные массивы редиректов прямо в теме — лучше вынести в mu-plugin или отдельный файл конфигурации;
• после массовых изменений очистите кеш страниц, объектный кеш и CDN;
• если редиректы редактируют несколько человек, ограничьте доступ к их настройке и ведите список изменений.

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

Короткий чек-лист перед публикацией изменений

• Старые URL собраны из логов, Search Console или старого sitemap.
• Для каждого шаблона есть понятное правило редиректа.
• Редирект ведёт сразу на конечную страницу с кодом 301.
• Внутренние ссылки обновлены.
• Кеш сайта и CDN очищены.
• Проверка через curl -I или браузер показывает правильный статус.
• В Search Console нет всплеска новых 404 по тем же URL.

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