Смена структуры ЧПУ в WordPress почти всегда оставляет хвост из старых адресов: часть ведёт на 404, часть продолжает жить в поиске, а часть дублируется через архивы, пагинацию и вложенные страницы. Если просто поменять шаблон ссылок и ничего не сделать дальше, поисковик ещё долго будет ходить по старым URL, а пользователи — попадать в тупики.
Ниже — рабочая схема, которая помогает аккуратно закрыть старые адреса после изменения permalink-структуры: сначала находим, какие URL реально сломались, затем ставим редиректы, после этого проверяем, что не осталось цепочек и петлей.
Когда проблема уже видна в логах и Search Console
Обычно сигналов несколько:
- в отчёте о страницах с ошибкой растёт количество
404; - в логах сервера много запросов к старым адресам с прежним форматом ЧПУ;
- в поиске остаются старые URL, хотя на сайте уже новые;
- часть внутренних ссылок всё ещё ведёт на старую структуру, особенно в меню, хлебных крошках и старых записях.
Если у вас была, например, структура /2024/05/%postname%/, а потом вы перешли на /%postname%/, старые адреса не исчезают сами. WordPress не знает, что нужно перенаправить их на новый путь, если вы не добавили правило вручную или через плагин.
Что проверить до изменений
- сохраните текущую структуру постоянных ссылок;
- выгрузите список старых URL из Search Console, аналитики или логов;
- проверьте, нет ли уже настроенных редиректов в
.htaccess, nginx-конфиге или плагине; - убедитесь, что сайт доступен по одному основному домену — с
wwwили без него.
Пошаговое решение: как закрыть старые URL после смены ЧПУ
Самый надёжный вариант — сделать 301-редирект со старой структуры на новую. Если шаблон URL менялся предсказуемо, можно обойтись правилом на уровне сервера. Если структура была сложной или менялась несколько раз, лучше использовать плагин редиректов и отдельно добить проблемные адреса вручную.
Вариант 1. Редирект на уровне .htaccess для Apache
Если старый формат был привязан к дате, а новый — нет, можно перенаправить все URL с датой на новый адрес по slug. Но такой подход подходит только если slug у записи не менялся.
RewriteEngine On
RewriteRule ^[0-9]{4}/[0-9]{2}/([^/]+)/?$ /$1/ [R=301,L]Это пример для случая, когда старый URL выглядел как /2024/05/nazvanie-posta/, а новый — как /nazvanie-posta/. Перед применением проверьте, что на сайте нет страниц, чьи URL случайно совпадут по шаблону.
Вариант 2. Редирект в WordPress через функцию
Если нужен более точный контроль, можно добавить правило в functions.php дочерней темы или в небольшой mu-plugin. Такой способ удобен, когда нужно обработать только конкретный паттерн.
<?php
add_action('template_redirect', function () {
$request_uri = $_SERVER['REQUEST_URI'] ?? '';
if (preg_match('#^/\d{4}/\d{2}/([^/]+)/?$#', $request_uri, $matches)) {
$new_url = home_url('/' . $matches[1] . '/');
wp_redirect($new_url, 301);
exit;
}
});Такой код лучше использовать только после теста на staging. Если на сайте есть страницы с похожими URL, регулярное выражение может захватить лишнее.
Вариант 3. Плагин редиректов для сложной миграции
Если структура менялась не один раз, а список старых адресов большой, удобнее работать через плагин редиректов. Это практичнее, чем пытаться покрыть всё одним правилом. В этом сценарии важно не просто создать перенаправление, а ещё и следить за цепочками: старый URL → промежуточный URL → новый URL — это уже лишняя задержка и лишний риск ошибок.
| Подход | Когда подходит | Минус |
|---|---|---|
| Правило в .htaccess | Один понятный шаблон старых URL | Сложно поддерживать при нескольких форматах |
| Код в WordPress | Нужна точечная логика | Требует аккуратного теста и доступа к коду |
| Плагин редиректов | Много старых адресов и ручных исключений | Нужно следить за производительностью и цепочками |
Как не сломать внутренние ссылки после смены структуры
Редиректы закрывают внешний трафик, но не чинят внутренние ссылки. Если в контенте, меню или виджетах остались старые адреса, пользователь всё равно будет сначала попадать на редирект. Это не критично для единичных случаев, но при массовом накоплении создаёт лишнюю нагрузку.
Проверьте:
- меню в
Внешний вид → Меню; - ссылки в старых записях и страницах;
- хлебные крошки, если они генерируются плагином или темой;
- ссылки в блоках, которые вставлялись вручную в редакторе;
- ссылки в XML-картах сайта и RSS, если они генерируются не WordPress, а SEO-плагином.
Если нужно массово заменить старые ссылки в базе, делайте это через инструмент поиска и замены с поддержкой сериализованных данных. Обычный SQL UPDATE здесь опасен: можно повредить настройки виджетов и блоков.
Проверка результата после внедрения
После настройки редиректов не ограничивайтесь открытием одной страницы в браузере. Нужна проверка по нескольким уровням.
Что именно проверить
- старый URL отдаёт
301, а не302; - новый URL открывается без дополнительного редиректа;
- нет цепочки из двух и более переходов;
- страница не уходит в 404 после редиректа;
- внутренние ссылки уже ведут на новый адрес;
- в Search Console старые URL постепенно уходят из ошибок сканирования.
Проверить код ответа можно так:
curl -I https://example.com/2024/05/nazvanie-posta/В ответе должен быть статус 301 Moved Permanently и заголовок Location с новым адресом. Если видите 302, поисковик может дольше переоценивать переезд. Если видите сразу 200, редирект не сработал.
Частые ошибки и как их исправить
Редирект ведёт на главную вместо нужной страницы
Так бывает, если в правиле не удалось извлечь slug или если новый URL уже не совпадает со старым шаблоном. Исправление простое: для сложных миграций не пытайтесь покрыть всё одной регуляркой, а соберите таблицу соответствий старый URL → новый URL.
Появилась цепочка редиректов
Например, старый адрес сначала уходит на промежуточный формат, а потом на финальный. Это часто случается после нескольких переездов подряд. Уберите промежуточное правило и направляйте старый URL сразу на конечный.
Редирект срабатывает слишком широко
Если правило написано грубо, оно может задеть служебные URL, вложения или страницы таксономий. Перед публикацией проверьте несколько реальных адресов из разных разделов сайта.
Старые URL всё ещё индексируются
Это нормально в переходный период, если редирект настроен правильно. Но если старые адреса продолжают возвращать 200 или 404, поисковик будет держать их в индексе дольше. В таком случае сначала исправьте ответ сервера, а уже потом смотрите на индексацию.
Практические советы по безопасности и производительности
Редиректы — это не только про SEO. Неправильная схема может создать лишнюю нагрузку на сервер, особенно если правила проверяются на каждом запросе в PHP.
- если шаблон простой, лучше решать его на уровне веб-сервера;
- не плодите десятки одинаковых правил в разных местах;
- не ставьте одновременно несколько плагинов редиректов;
- после миграции удалите устаревшие правила, чтобы не держать лишнюю логику в
.htaccessили в коде темы; - сохраняйте резервную копию базы и конфигурации до массовых замен.
Если вам нужно не только убрать дубли, но и регулярно чистить сайт от технического мусора, в экосистеме WPShop есть Clearfy Pro: он помогает с частью SEO- и cleanup-задач, но редиректы после смены ЧПУ всё равно лучше проверять вручную, а не полагаться на автоматизацию вслепую. Подробности: Clearfy Pro.
Если после смены структуры у вас ещё и поменялись правила генерации контента, не забывайте проверить canonical, карту сайта и внутренние ссылки. Редирект сам по себе не исправляет старую разметку и не обновляет адреса в базе.