Как найти и удалить старые редиректы 301 в WordPress без поломки SEO

Автор: Виктор Никитин | Опубликовано: 08.09.2026

Со временем на WordPress-сайте накапливаются редиректы, которые уже не нужны: старые правила из .htaccess, записи в плагине редиректов, автоматические перенаправления после смены URL-структуры, а иногда и цепочки из двух-трёх переходов подряд. Сайт при этом может работать «нормально», но поисковым роботам и пользователям приходится делать лишние запросы, а часть правил начинает конфликтовать между собой.

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

Когда старые редиректы уже мешают

Проблема обычно проявляется не одной ошибкой, а набором мелких симптомов. Самые частые:

страница открывается не сразу, а через 2–3 перехода;
в логах сервера много запросов к URL, которых уже нет в контенте;
в плагине редиректов десятки правил на старые адреса, которые давно не используются;
после смены структуры ссылок часть правил дублирует друг друга;
в Google Search Console всплывают URL с перенаправлением, хотя они не должны индексироваться.

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

Диагностика: что именно нужно найти

Перед чисткой полезно разделить редиректы на три группы:

нужные — ведут со старого URL на актуальный;
дублирующие — повторяют уже существующее правило;
устаревшие — ведут на страницы, которых больше нет, или на адреса, которые уже перенаправляются другим правилом.

Проверять лучше не только админку, но и фактическое поведение URL. Для этого удобно использовать curl и смотреть заголовки ответа:

curl -I https://example.com/staryy-url/

В ответе важно увидеть:

код 301 или 302;
заголовок Location;
нет ли цепочки из нескольких переходов.

Если URL сначала ведёт на один адрес, а потом ещё раз перенаправляется, это уже повод искать лишнее правило.

Как быстро увидеть цепочку редиректов

Для проверки цепочки удобно использовать:

curl -IL https://example.com/staryy-url/

Флаг -L заставляет curl идти по перенаправлениям, а -I показывает только заголовки. Если в выводе видно несколько строк HTTP/1.1 301 подряд, значит редиректов больше одного.

Ещё один практичный способ — открыть URL в браузере с включённой вкладкой Network в DevTools. Это полезно, когда редирект зависит от протокола, слеша в конце или версии домена с www.

Пошаговое решение: как убрать лишнее и не сломать сайт

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

1. Сначала найдите источник редиректа

В WordPress редиректы обычно живут в одном из мест:

.htaccess или конфиг Nginx;
плагин редиректов;
кастомный код в теме или mu-plugin;
SEO-плагин, если он управляет перенаправлениями;
настройки хостинга или панели управления.

Если редирект задаётся в нескольких местах одновременно, удалять нужно только дублирующий слой. Например, правило уже есть в серверной конфигурации, а в плагине осталось старое копирование — тогда плагинное правило можно убрать, но серверное оставить.

2. Проверьте, не используется ли URL в реальном трафике

Перед удалением полезно посмотреть статистику переходов и логи веб-сервера. Если на старый адрес всё ещё приходят запросы из поиска или внешних ссылок, удалять правило рано. В таком случае лучше оставить 301 и только убрать цепочку, если она есть.

Если трафика нет, а редирект ведёт на уже существующий актуальный адрес, правило можно удалить после теста на staging-копии.

3. Уберите дублирующие правила

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

Пример аккуратного правила в .htaccess для одного старого адреса:

Redirect 301 /old-page/ https://example.com/new-page/

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

4. Уберите цепочки редиректов

Типичный случай: /old-page/ ведёт на /intermediate-page/, а та уже на /new-page/. Для SEO и скорости лучше, чтобы старый адрес сразу вел на конечный URL.

Вместо цепочки:

/old-page/  ->  /intermediate-page/  ->  /new-page/

нужно оставить прямой переход:

/old-page/  ->  /new-page/

Это особенно важно после миграций, смены структуры постоянных ссылок и переноса разделов.

5. Удаляйте только то, что можно воспроизвести

Если правило непонятно, не стирайте его сразу. Сначала попробуйте найти исходный URL в базе данных, в старых записях или в sitemap-архиве. Иногда редирект нужен для страницы, которая уже не существует в меню, но всё ещё получает переходы из внешних источников.

Если правило не удаётся связать с реальным адресом и оно не участвует в цепочке, его можно пометить как кандидат на удаление и проверить через 404-лог или Search Console.

Пример проверки и удаления через код

Если редиректы заданы в кастомном коде, их лучше хранить в одном месте и документировать. Например, можно добавить собственный массив правил в mu-plugin и затем удалять устаревшие записи централизованно.

<?php
/**
 * Plugin Name: Redirect Rules
 */

add_action('template_redirect', function () {
    $path = wp_parse_url($_SERVER['REQUEST_URI'], PHP_URL_PATH);

    $rules = [
        '/old-page/' => '/new-page/',
        '/old-category/' => '/category/news/',
    ];

    if (isset($rules[$path])) {
        wp_redirect(home_url($rules[$path]), 301);
        exit;
    }
});

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

Если редиректы уже управляются плагином, сначала экспортируйте список правил, а потом удаляйте только те, у которых нет входящего трафика и нет зависимости от других URL.

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

Подход	Когда подходит	Плюс	Минус
Плагин редиректов	Когда правил много и ими управляет контент-редактор	Удобно искать и отключать записи	Легко накопить дубли и цепочки
Код в теме / mu-plugin	Когда редиректов немного и нужна прозрачность	Понятно, где лежит логика	Требует аккуратного деплоя
.htaccess / Nginx	Когда нужен быстрый и предсказуемый ответ сервера	Минимальная нагрузка	Сложнее сопровождать без дисциплины

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

Как проверить, что очистка сработала

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

старый URL отдаёт только один 301 и сразу ведёт на конечный адрес;
новый URL открывается без перенаправления;
нет редирект-цепочки при переходе с http на https и с www на без www;
в sitemap остались только актуальные адреса;
в Search Console не растёт число URL с перенаправлением.

Для быстрой проверки можно снова использовать:

curl -IL https://example.com/old-page/

Если вывод показывает один переход и конечный адрес отвечает 200 OK, базовая проверка пройдена.

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

Удалили редирект, который ещё нужен для внешних ссылок

Такое часто случается после чистки «по ощущениям». Исправление простое: вернуть 301 на старый адрес и проверить, есть ли на него входящий трафик из аналитики или Search Console. Если да, правило лучше оставить.

Оставили одинаковое правило в двух местах

Например, редирект есть и в плагине, и в .htaccess. Тогда поведение становится непредсказуемым, особенно если правила отличаются конечным URL. Нужно оставить только один источник истины.

Сломали редирект с www на без www

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

Удалили цепочку, но забыли обновить внутренние ссылки

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

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

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

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

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

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