Если после смены структуры URL, переезда на HTTPS или чистки разделов в индексе остаются старые адреса, проблема обычно не в «плохом SEO», а в неаккуратной схеме редиректов. В WordPress это быстро превращается в цепочки 301 → 301 → 200, дубли с www и без него, а иногда и в петли, когда страница уходит на саму себя.
Ниже — рабочий сценарий: как найти источник старых URL, настроить 301 без лишних переходов и проверить, что поисковики и браузер видят именно один финальный адрес.
Когда редирект действительно нужен, а когда проблема в другом
301 нужен не для каждой «старой ссылки». Если URL продолжает открываться и у него просто изменился канонический адрес, сначала проверьте, не решается ли задача настройкой постоянных ссылок, canonical или внутренними ссылками. Редирект — это уже ответ на ситуацию, когда старый адрес должен навсегда вести на новый.
Типичные сценарии
- сменили структуру постоянных ссылок с
/2024/01/post-name/на/post-name/; - объединили несколько страниц в одну и удалили старые;
- перевели сайт с
httpнаhttpsили сwwwна безwww; - закрыли раздел, но на него остались внешние ссылки и закладки;
- исправили опечатку в slug и хотите сохранить трафик со старого адреса.
Диагностика: где именно ломается маршрут
Перед настройкой редиректа нужно понять, что происходит сейчас. Иначе легко получить две одинаковые проблемы: старый URL редиректит, но новый сам редиректит дальше, либо WordPress и сервер спорят между собой.
Что проверить в первую очередь
- открывается ли старый URL с кодом
404,200или уже редиректит; - нет ли цепочки из нескольких переходов;
- совпадает ли конечный адрес с тем, который должен индексироваться;
- не создаёт ли плагин редиректов конфликт с правилами сервера;
- не дублируется ли страница по разным вариантам URL.
Быстро посмотреть ответ сервера можно через curl:
curl -I https://example.com/staryy-url/Если нужен полный маршрут переходов, используйте:
curl -IL https://example.com/staryy-url/В ответе важно увидеть один финальный 200 OK без лишних промежуточных адресов. Если между ними есть несколько 301, это уже цепочка, которую лучше сократить.
Какой способ выбрать: плагин, код или сервер
Для WordPress есть три нормальных варианта. Выбор зависит от масштаба задачи и того, кто потом будет поддерживать сайт.
| Подход | Когда подходит | Плюсы | Минусы |
|---|---|---|---|
| Плагин редиректов | Нужно быстро закрыть несколько URL без доступа к серверу | Удобно, есть журнал переходов | Лишняя нагрузка, риск конфликтов с кэшем и другими плагинами |
Код в .htaccess или конфиге nginx | Редиректы постоянные и их много | Быстро, без PHP-обработки | Нужен доступ к серверу и аккуратность в синтаксисе |
| PHP-хук в теме или мини-плагине | Нужна логика по условиям, например для старых slug | Гибко, можно версионировать в Git | Нельзя бездумно вешать на каждый запрос |
Если редиректов немного и сайт ведётся через админку, удобнее плагин. Если это миграция или массовая чистка URL, лучше серверный уровень. Для точечных случаев с логикой по шаблону можно использовать PHP.
Пошаговое решение: закрываем старый URL на новый
Вариант 1. Редирект через PHP без плагина
Этот способ полезен, когда нужно закрыть один или несколько старых адресов, а ставить отдельный плагин не хочется. Код лучше вынести в мини-плагин или в functions.php дочерней темы, чтобы не потерять его при обновлении.
add_action('template_redirect', function () {
if (is_admin() || wp_doing_ajax()) {
return;
}
$request_uri = $_SERVER['REQUEST_URI'] ?? '';
$redirects = [
'/staryy-url/' => '/novyy-url/',
'/category/staryy-razdel/' => '/category/novyy-razdel/',
];
foreach ($redirects as $from => $to) {
if (untrailingslashit($request_uri) === untrailingslashit($from)) {
wp_redirect(home_url($to), 301);
exit;
}
}
});Здесь важно не сравнивать только $_SERVER['REQUEST_URI'] «как есть», если на сайте смешаны варианты со слешем и без него. Нормализация через untrailingslashit() снижает шанс промаха.
Вариант 2. Редирект на сервере
Если у вас Apache, правило можно добавить в .htaccess. Это быстрее, чем гонять запрос через PHP.
Redirect 301 /staryy-url/ https://example.com/novyy-url/Для nginx логика обычно задаётся в конфиге сайта. Пример:
location = /staryy-url/ {
return 301 https://example.com/novyy-url/;
}После изменения конфигурации обязательно проверьте, не конфликтует ли правило с уже существующими редиректами на HTTPS, www или слеш в конце URL.
Вариант 3. Если нужно закрыть много старых URL
Когда речь о миграции большого сайта, удобнее вести список редиректов отдельно: в таблице, в конфиге или в плагине с журналом переходов. Это снижает риск забыть старую страницу и помогает быстро найти, какой URL ещё приносит трафик.
- для нескольких десятков адресов — плагин с логированием;
- для сотен и тысяч — серверные правила или отдельный слой маршрутизации;
- для однотипных URL — регулярные выражения, но только если вы уверены в шаблоне.
Как не получить цепочку редиректов
Самая частая ошибка — настраивать редирект на адрес, который уже сам редиректит. Например, /old-page/ ведёт на /new-page, а потом WordPress добавляет слеш и отправляет ещё раз на /new-page/. В итоге браузер делает два перехода вместо одного.
Чтобы этого избежать, сразу указывайте конечный канонический URL. Если сайт использует слеш в конце, редирект должен вести именно на адрес с ним. Если без слеша — наоборот.
Проверка цепочки
Смотрите заголовки ответа:
curl -IL https://example.com/staryy-url/Нормальный результат — один 301 и затем один 200. Если видите несколько 301 подряд, сократите маршрут. Если есть 302, значит где-то используется временный редирект, и это тоже стоит исправить.
Проверка результата после внедрения
После настройки не ограничивайтесь открытием страницы в браузере. Браузер может показывать закэшированный результат, а поисковый робот увидит совсем другое.
Чек-лист проверки
- старый URL отдаёт
301; - новый URL отдаёт
200; - нет цепочки из нескольких переходов;
- внутренние ссылки на сайте уже ведут на новый адрес;
- в
<link rel="canonical">указан финальный URL; - в sitemap нет старого адреса, если он больше не нужен;
- в Search Console старый URL не остаётся как основной для индексации.
Если используете плагин для редиректов, откройте журнал переходов и посмотрите, нет ли запросов на несуществующие старые адреса. Это помогает быстро найти страницы, которые вы забыли закрыть.
Частые ошибки и как их исправить
Редирект настроен на 302 вместо 301
Такое часто случается, если правило добавили через временную настройку или плагин по умолчанию. Для постоянного переноса нужен именно 301. Иначе поисковики могут дольше переобходить старый адрес.
Старый URL ведёт на новый, а новый снова редиректит
Причина обычно в несовпадении слеша, протокола или домена. Проверьте, какой адрес WordPress считает каноническим, и приведите редирект к нему сразу.
Редирект конфликтует с кэшем
Если на сайте стоит page cache или CDN, старый ответ может продолжать отдаваться из кэша. После изменения правил очистите кэш сайта, сервера и CDN, иначе проверка будет показывать старую картину.
Правило написано слишком широко
Регулярка вида «всё, что содержит old, отправить на new» легко ломает другие страницы. Лучше начинать с точного совпадения и только потом расширять шаблон, если это действительно нужно.
Безопасность и производительность: что важно не испортить
Редиректы сами по себе не опасны, но их легко превратить в источник лишней нагрузки. Если у вас много правил, не держите их в functions.php активной темы, особенно если тема может меняться. Для постоянной логики лучше мини-плагин или серверный конфиг.
Ещё один практический момент: не используйте редиректы как замену чистке сайта. Если у вас остались дубли архивов, тегов, авторов или служебных страниц, сначала решите, нужны ли они вообще. Для этого часто помогает аккуратная техническая чистка и управление дублями, например через Clearfy Pro, если он уже используется в вашем стеке.
- не создавайте редирект на редирект;
- не смешивайте правила плагина и сервера без проверки;
- не закрывайте важные URL через
noindex, если они уже должны исчезнуть из индекса навсегда; - не забывайте обновить внутренние ссылки после переноса.
Если после внедрения всё работает, следующий шаг — пройтись по старым адресам из логов, sitemap и Search Console и закрыть оставшиеся хвосты. Тогда редирект перестанет быть точечной заплаткой и станет частью нормальной технической гигиены сайта.