Смена структуры постоянных ссылок в WordPress почти всегда тянет за собой хвост из 404. На практике проблема всплывает не только на старых записях: ломаются категории, вложенные страницы, архивы авторов, а иногда и произвольные типы записей. Если сайт уже индексировался, поисковики продолжают ходить по старым URL, а пользователи ловят пустые страницы из закладок и внешних ссылок.
Ниже — рабочий сценарий: как быстро понять, что именно сломалось, как настроить редиректы без лишних костылей и как проверить, что после правки WordPress действительно перестал отдавать 404.
Что именно ломается после смены permalink-структуры
В WordPress 404 после изменения постоянных ссылок обычно появляются по одной из трех причин:
- новая структура URL не совпадает с правилами перезаписи, и часть маршрутов не резолвится;
- старые адреса не перенаправлены на новые, поэтому внешние ссылки и поисковый трафик упираются в 404;
- кэш, CDN или серверный редирект конфликтуют с правилами WordPress и отдают не тот ответ.
Если меняли только шаблон ссылки для записей, а 404 появились и на страницах, и на рубриках, сначала проверьте, не слетели ли правила перезаписи. После миграции, смены темы или установки плагина для ЧПУ это встречается чаще, чем кажется.
Диагностика: где искать источник ошибки
Начинать лучше не с редактирования .htaccess, а с проверки фактического ответа сервера. Важно понять, кто именно отдает 404: WordPress, веб-сервер или кэш.
Проверка URL в браузере и через curl
Возьмите один старый адрес и один новый. Если старый должен редиректиться, а вместо этого сразу возвращает 404, посмотрите заголовки ответа:
curl -I https://example.com/staryy-url/В нормальном сценарии вы увидите 301 или 302 с заголовком Location. Если сразу приходит 404, редиректа нет. Если приходит 200, но страница визуально пустая или не та, проблема уже не в permalink-структуре, а в маршрутизации или кэше.
Проверка правил перезаписи в админке
Откройте Настройки → Постоянные ссылки и просто сохраните форму без изменений. Это принудительно пересобирает rewrite rules. После этого проверьте проблемный URL еще раз. Если 404 исчезли, значит правила были устаревшими. Если нет — идем дальше.
Когда виноват серверный кэш
Если на хостинге включен Nginx FastCGI cache, Varnish или CDN, старый 404 может быть закэширован. В таком случае WordPress уже исправлен, но посетитель все равно видит старую ошибку. Очистка только кэша плагина не поможет — нужно сбросить и серверный, и CDN-кэш.
Пошаговое решение без лишнего риска
Самый безопасный путь — сначала восстановить корректную маршрутизацию, потом закрыть старые адреса редиректами, и только после этого чистить кэш и проверять индексацию.
Шаг 1. Сбросьте правила перезаписи
Если доступен WP-CLI, это самый быстрый способ:
wp rewrite flush --hardКоманда пересобирает правила и записывает их в базу. После этого проверьте несколько старых и новых адресов. Если WP-CLI недоступен, сохраните постоянные ссылки через админку.
Шаг 2. Настройте редиректы со старых URL на новые
Если структура URL изменилась, поисковым системам и пользователям нужен понятный переход. Для точечных случаев удобнее всего делать редиректы на уровне сервера или через плагин редиректов. Если логика простая и предсказуемая, можно добавить правило в .htaccess для Apache:
RewriteEngine On
RewriteRule ^old-section/(.*)$ /new-section/$1 [R=301,L]Для Nginx аналогичная логика задается в конфиге сервера, а не в WordPress. Если вы не уверены в синтаксисе, лучше не править конфиг вручную на проде: одна ошибка может положить весь сайт.
Шаг 3. Если нужен редирект только для отдельных записей, используйте PHP
Когда URL поменялись не массово, а только у нескольких материалов, можно добавить редирект в functions.php дочерней темы или в небольшой mu-plugin:
<?php
add_action('template_redirect', function () {
if (is_page('old-page-slug')) {
wp_redirect(home_url('/new-page-slug/'), 301);
exit;
}
});Такой вариант подходит для единичных случаев. Если редиректов десятки, код в теме быстро станет неуправляемым. Тогда лучше использовать отдельный плагин или правила на сервере.
Шаг 4. Очистите все уровни кэша
После правок очистите:
- кэш WordPress-плагина;
- серверный кэш, если он есть;
- CDN-кэш;
- кэш браузера для проверки вручную.
Если этого не сделать, вы будете проверять уже исправленный сайт по старому ответу из кэша и искать несуществующую проблему.
Какой способ выбрать: плагин, сервер или код
| Подход | Когда подходит | Плюсы | Минусы |
|---|---|---|---|
| Плагин редиректов | Много старых URL, нужна админка и журнал переходов | Удобно править без кода | Дополнительная нагрузка и зависимость от плагина |
| Server-level redirect | Постоянные шаблонные перенаправления | Быстро и надежно | Нужен доступ к конфигу сервера |
| PHP-код | Несколько точечных страниц | Гибко и без лишних плагинов | Нужно поддерживать код вручную |
Если сайт небольшой, а редиректов немного, код или серверное правило обычно практичнее. Если же вы переносили большой архив, удобнее использовать плагин с логированием 404 и массовым управлением редиректами.
Проверка результата после внедрения
Не ограничивайтесь открытием одной страницы в браузере. Проверка должна подтвердить три вещи: старый URL редиректится, новый URL открывается с 200, а в логах нет новых 404 по тем же адресам.
Минимальный чек-лист
- старый адрес отвечает
301и ведет на новый URL; - новый адрес отдает
200; - в консоли браузера нет цепочки из нескольких редиректов подряд;
- в отчете поисковой системы старые URL постепенно заменяются новыми;
- страницы не выпадают из sitemap.xml из-за неправильных канонических адресов.
Для быстрой проверки можно снова использовать curl -I. Если редирект настроен верно, цепочка должна быть короткой и предсказуемой. Длинные цепочки вида http → https → www → новый путь лучше сокращать до одного шага.
Частые ошибки и как их исправить
Редирект ведет на главную вместо нужной страницы
Так бывает, если правило слишком общее и матчится на все URL подряд. Проверьте порядок правил: более конкретные должны идти выше общих. В плагинах редиректов это тоже важно.
После сохранения постоянных ссылок 404 не исчезли
Частая причина — конфликт с кэшем или неправильный файл .htaccess. На Apache убедитесь, что WordPress-блок не поврежден и сервер вообще читает этот файл. На Nginx проблема обычно не в WordPress, а в конфиге сайта.
Редирект работает в браузере, но не работает для бота
Проверьте, не отдает ли CDN отдельные правила для роботов или не кэшируется ли 404 слишком агрессивно. Иногда бот видит старый ответ дольше, чем обычный пользователь.
Сломались вложенные страницы и архивы
Это часто случается после изменения структуры с базой рубрик или страниц. Например, если раньше был URL вида /blog/post-name/, а потом базу убрали, нужно отдельно проверить вложенные маршруты и таксономии.
Безопасность и производительность: что не стоит делать
Не держите десятки редиректов в functions.php активной темы. При смене темы вы потеряете всю логику. Лучше вынести такие правила в mu-plugin или отдельный плагин, если они должны жить долго.
Не ставьте несколько SEO-плагинов или плагинов редиректов одновременно без необходимости. Дублирование логики часто приводит к цепочкам редиректов и конфликтам. Если нужен инструмент для чистки дублей, служебных URL и технических хвостов, уместно посмотреть в сторону Clearfy Pro, но только если вы реально используете его функции, а не ставите ради одной задачи.
И еще один практический момент: после массовой смены URL не удаляйте старые страницы сразу. Сначала убедитесь, что редиректы работают, поисковый трафик стабилизировался, а в логах нет новых 404. Иначе можно потерять и переходы, и накопленные сигналы.
Когда проблема не в permalink-структуре
Иногда 404 появляются после смены темы, обновления плагина или переноса сайта, но причина совсем другая. Если у вас ломаются только отдельные шаблоны, а сами записи открываются, проверьте:
- не изменились ли slug у записей или рубрик;
- не добавил ли плагин свои rewrite rules;
- не отключен ли нужный post type;
- не переписал ли сервер правила маршрутизации поверх WordPress.
В таких случаях полезно временно отключить сторонние плагины и проверить сайт на стандартной теме. Это быстрее, чем искать ошибку в коде наугад.