Карта редиректов: влияние на SEO, риски и практические рекомендации

Карта редиректов нужна тогда, когда известные пользователям и поисковым системам адреса меняются: при новой структуре каталога, переходе на другую CMS, объединении страниц, смене домена или масштабном редизайне. На практике это не один «механизм перенаправления», а рабочее соответствие старый URL → новый URL, из которого уже создаются правила 301 или 308.

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

Карта редиректов — это спецификация, а не набор случайных 301

Минимальная карта действительно может состоять из двух колонок:

Старый URL	Новый URL
/blog/seo-audit/	/articles/seo-audit/
/services/seo-old/	/services/seo/

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

Старый URL	Новый URL	Действие	Приоритет	Проверка
/blog/seo-audit/	/articles/seo-audit/	301	высокий	verified
/old-service/	/services/new-service/	301	высокий	verified
/expired-event/	—	404/410	низкий	verified

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

Как карта редиректов влияет на обход, индексирование и SEO

Постоянный серверный редирект сообщает поисковой системе, что ресурс перемещён. Google рассматривает постоянные перенаправления, включая 301 и 308, как сильный сигнал в пользу канонизации URL назначения. Яндекс также относит 301 и 308 к постоянным, а 302, 303 и 307 — к временным перенаправлениям.

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

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

Цепочки тоже не должны становиться нормой:

/old/ → /old-v2/ → /category/new/ → /articles/new/

Технически робот способен пройти несколько переходов, но цель нормальной карты — сразу описывать конечный маршрут:

/old/ → /articles/new/

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

Сначала соберите старые URL, а не открывайте таблицу вручную

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

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

• полного краула действующего сайта;
• XML Sitemap;
• посадочных страниц из поисковой аналитики;
• веб-аналитики;
• серверных логов;
• известных URL с внешними ссылками;
• старых выгрузок CMS и предыдущих карт миграций.

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

Именно на этом этапе стоит отметить приоритет. Страница с поисковым трафиком, внешними ссылками или коммерческой ценностью должна проверяться вручную, даже если основная масса однотипных URL сопоставляется по шаблону.

Как выбирать новый URL: релевантность важнее удобства настройки

Для каждой строки карты стоит сначала определить смысл страницы, а уже затем искать похожий адрес.

Содержимое осталось тем же, изменился только путь. Старый URL направляется непосредственно на новый вариант этой же страницы.

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

Страница удалена, но существует полноценная тематическая замена. Возможен редирект на неё, если пользователь получает ожидаемое продолжение, а не просто страницу уровнем выше.

Релевантной замены нет. Не нужно создавать фиктивную связь только ради кода 301. Для окончательно удалённого ресурса корректный 404 или 410 может точнее описывать ситуацию, чем перенаправление на нерелевантную страницу.

Отдельный случай — временное перемещение. Если исходный URL должен снова стать основным, постоянный редирект не соответствует задаче. Именно для временных сценариев существуют 302 и 307.

Из карты нужно получить прямые серверные правила

Для постоянной смены обычной веб-страницы наиболее понятным вариантом остаётся серверный 301. Например, точечное правило Nginx может выглядеть так:

location = /old-page/ {
    return 301 https://example.com/new-page/;
}

Для Apache с mod_alias:

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

Эти примеры показывают принцип, а не универсальный конфиг для любого сервера. Перед массовым внедрением нужно учитывать уже существующие rewrite-правила, обработку параметров, завершающего слеша, HTTP/HTTPS, www, прокси и CDN.

Особенно важно не генерировать новое правило поверх старой цепочки. Если /a/ уже ведёт на /b/, а после миграции /b/ переносится на /c/, лучше по возможности обновить исходное правило:

плохо:   /a/ → /b/ → /c/
лучше:   /a/ → /c/
          /b/ → /c/

Как проверить карту редиректов на работающем сайте

После внедрения нельзя ограничиваться фразой разработчика «редиректы настроены». Проверять нужно фактический HTTP-маршрут.

Для одного URL достаточно посмотреть заголовки:

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

В ответе для постоянного переноса ожидается код 301 или 308 и корректный Location.

Для просмотра всей цепочки:

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

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

старый URL
301 Moved Permanently
Location: https://example.com/new-page/

новый URL
200 OK

Но код конечной страницы — только первый уровень контроля. Нужно дополнительно убедиться, что новая страница не закрыта noindex, доступна роботам, содержит корректный self-referencing canonical и присутствует во внутренних ссылках уже под новым адресом.

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

• исходный URL;
• первый HTTP-код;
• Location;
• количество переходов;
• конечный URL;
• конечный HTTP-код.

Затем фактическую выгрузку можно сравнить с картой. Именно здесь обнаруживаются опечатки, неожиданные 302, циклы, переходы через промежуточные адреса и назначения, которые возвращают 404.

Практический сценарий: раздел /blog/ переносится в /articles/

Допустим, WordPress-сайт меняет структуру материалов. Раньше статьи находились в /blog/, после обновления таксономии должны открываться в /articles/.

Плохой подход — написать одно широкое правило и считать миграцию законченной. До этого нужно проверить, действительно ли каждый старый материал сохранился и имеет однозначную новую страницу.

Исходная карта может выглядеть так:

/blog/seo-audit/          → /articles/seo-audit/
/blog/redirects/          → /articles/redirects/
/blog/old-seo-checklist/  → /articles/seo-checklist/
/blog/event-2021/         → нет релевантной замены

Первые три адреса можно перевести постоянными редиректами непосредственно на новые страницы. Четвёртый требует отдельного решения: если событие удалено и актуального эквивалента нет, отправлять его на /articles/ только потому, что это новый раздел, необязательно и часто бессмысленно.

После запуска проверяется уже не таблица, а сервер:

/blog/seo-audit/
→ 301
→ /articles/seo-audit/
→ 200

Затем на новой версии сайта нужно заменить внутренние ссылки на /articles/seo-audit/. Иначе пользователи и роботы будут постоянно ходить через редирект даже внутри нового сайта.

Если изменение URL является частью более крупной технической переработки, карту редиректов разумно рассматривать вместе с краулингом, индексированием, canonical, Sitemap и внутренними ссылками. Такой контур обычно входит в комплексное SEO-продвижение сайта, когда требуется не просто установить 301, а проконтролировать последствия изменений для поисковой видимости.

Ошибки, которые чаще всего ломают хорошую карту

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

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

Постоянный перенос сделан временным редиректом. Если URL изменён окончательно, 302 не отражает реальный характер изменения. Для постоянного переноса Google рекомендует серверные постоянные редиректы, например 301 или 308; Яндекс также классифицирует 301/308 как постоянные.

Цель редиректа сама недоступна. Схема 301 → 404 не решает проблему. Аналогично нужно искать 301 → 500, циклы и маршруты на закрытые от индексирования страницы.

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

Sitemap и canonical противоречат миграции. Новый URL не должен одновременно получать сигналы, что канонической является старая страница. После запуска технические сигналы должны быть согласованы с новой структурой.

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

После запуска проверка не заканчивается

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

При переносе домена Google рекомендует использовать инструмент изменения адреса Search Console после настройки редиректов. Для обычного изменения путей внутри того же домена этот инструмент не нужен. В Яндекс Вебмастере при смене домена используется инструмент переезда сайта.

Одновременно стоит контролировать:

• ошибки обхода и индексирования;
• появление новых URL в поиске;
• обращения роботов к старым адресам;
• неожиданные 404 и 5xx в серверных логах;
• новые страницы, которые не были учтены исходной картой;
• внутренние ссылки на старые URL.

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

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