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

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

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

Когда проблема точно связана со сменой структуры URL

Если после изменения /%postname%/ на другой формат или после правки базы ссылок начали сыпаться 404, сначала проверьте не только сами записи, но и архивы, вложения, пагинацию и старые ссылки из меню. В WordPress 404 после смены структуры часто появляются в таких случаях:

• изменили настройки в Настройки → Постоянные ссылки, но не обновили правила перезаписи;
• старые URL остались в индексе поисковиков;
• в теме или плагине есть жёстко прописанные ссылки на старый формат;
• сервер не обрабатывает .htaccess или правила nginx;
• кэш продолжает отдавать старые адреса после миграции.

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

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

Диагностика: где именно ломается маршрут

Перед исправлением полезно понять, на каком уровне возникает 404. Это экономит время и помогает не лечить симптомы.

1. Проверьте, открывается ли запись по новому адресу из админки.
2. Сравните ответ сервера для старого и нового URL через curl или DevTools.
3. Посмотрите, не отдаются ли старые страницы из кэша плагина или CDN.
4. Проверьте, не менялся ли тип записи: иногда 404 появляется не из-за permalink, а из-за register_post_type() с другим rewrite.

Быстрый тест через консоль:

curl -I https://example.com/old-post-url/

Если в ответе видите HTTP/1.1 404 Not Found, а не 301 или 200, редирект не настроен. Если приходит 200, но в браузере всё равно 404, значит мешает кэш или конфликт на уровне темы/плагина.

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

1. Сохраните старую структуру как карту редиректов

Если URL менялись массово, не пытайтесь исправлять всё вручную через отдельные записи. Сначала составьте список старых адресов, которые реально получают трафик или есть в индексе. Подойдут логи сервера, Search Console и выгрузка из старого sitemap, если он сохранился.

2. Настройте 301-редирект со старого формата на новый

Для единичных случаев можно использовать плагин редиректов, но если структура изменилась системно, лучше сделать правило на уровне сервера. Для Apache это обычно .htaccess, для nginx — конфигурация виртуального хоста.

Пример для Apache, если старый формат был с датой в URL, а новый стал без неё:

RewriteEngine On
RewriteRule ^([0-9]{4})/([0-9]{2})/(.+?)/?$ /$3/ [R=301,L]

Это пример, а не универсальное правило. Перед применением проверьте, что ваш старый формат действительно совпадает с шаблоном. Иначе можно сломать другие разделы сайта.

3. Если нужно точечно закрыть старые адреса, используйте PHP-редирект

Когда у вас небольшое количество проблемных URL, можно добавить редирект в functions.php дочерней темы или в небольшой mu-plugin. Это удобнее, чем тащить отдельный плагин ради пары адресов.

add_action('template_redirect', function () {
    $old_paths = array(
        '/2019/05/old-post/',
        '/2020/01/another-article/'
    );

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

    if (in_array($request_uri, $old_paths, true)) {
        wp_redirect(home_url('/new-post-url/'), 301);
        exit;
    }
});

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

4. Обновите правила перезаписи WordPress

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

Если сайт на nginx, убедитесь, что конфигурация содержит стандартную обработку try_files для WordPress. Без неё новые URL могут не доходить до PHP.

Сравнение подходов: плагин, код, сервер

Как проверить, что 404 действительно исчезли

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

• старый URL отдаёт 301, а не 302;
• новый URL открывается с 200 OK;
• нет цепочки из нескольких редиректов подряд;
• внутренние ссылки на сайте уже ведут на новый адрес;
• в Search Console старые URL постепенно уходят из отчёта об ошибках.

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

curl -I -L https://example.com/old-post-url/

Если после -L финальный ответ — 200 OK на новом адресе, редирект работает. Если цепочка длинная, стоит сократить её до одного шага.

Частые ошибки и почему они появляются

Редирект на главную вместо нужной записи

Такое часто случается, когда правило слишком общее и не учитывает структуру старого URL. В результате все старые адреса улетают на главную, а не на соответствующий контент. Для поисковика это слабый сигнал, а для пользователя — плохой опыт.

Использование 302 вместо 301

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

Конфликт с кэшем

После настройки редиректов старый адрес может ещё какое-то время открываться из кэша страницы, CDN или браузера. Очистите кэш плагина, серверный кэш и, если используется, кэш на стороне CDN. Иначе вы будете тестировать уже не WordPress, а старую копию ответа.

Правило написано слишком широко

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

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

Если редиректов много, не держите их в теме. При смене темы вы потеряете правила и снова получите 404. Для долгоживущих правил лучше использовать серверную конфигурацию или mu-plugin. Это и безопаснее, и проще для сопровождения.

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

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

Что делать, если 404 остались только у части записей

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

• старые записи с предсказуемым шаблоном;
• ручные переносы с изменённым slug;
• материалы, которые были удалены без замены;
• URL, которые должны отдавать 410, а не редиректиться.

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

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