301 редирект разделов работает как серверное перенаправление. Он переводит адреса целой рубрики каталога на актуальные и передаёт им накопленные сигналы. Нужен он, когда каталог перестраивают, статьи переносят в другое место или проект уезжает на обновлённую CMS. В нашей практике потери трафика при редизайне чаще связаны не с дизайном и текстами, а с забытыми адресами прошлого дерева. Разбираем, как собрать список адресов раздела, записать групповое правило для всей ветки, проверить глубокие уровни и что обновить после запуска.
Когда при смене структуры сайта нужен 301 редирект раздела
Постоянное перенаправление ставят тогда, когда прежний адрес больше не должен существовать, а его содержимое живёт по актуальному URL. В справке Яндекс Вебмастера, посвящённой смене структуры и дизайна сайта, названы три повода поменять адреса: перестройка дерева, внедрение человекопонятных адресов (ЧПУ) и обновление либо замена CMS. Раздел отличается от одиночного документа масштабом, и это меняет способ работы.
Просто опубликовать текст по актуальному адресу недостаточно. Без склейки индексирующий робот воспринимает материал по двум URL как два разных, и они индексируются и ранжируются независимо. Серверный 301 снимает развилку, потому что робот индексирует конечный адрес и удаляет из поиска устаревшие.
Сценарии: переименование, объединение и перенос раздела
Мы делим такие задачи на три типа, и от типа зависит вид правила. При переименовании поменялся только один сегмент в адресе, например /katalog/obuv/ стал /catalog/shoes/. При объединении две рубрики схлопываются в одну, и часть карточек получает другого родителя. При переносе ветка уезжает в иное место дерева или на поддомен, а вложенные сегменты сохраняются.
В интернет-магазине эту работу называют иначе. 301 редирект категорий означает тот же групповой перенос, когда меняется адрес категории, а карточки товаров переселяются вместе с ней. Даже если переезжает одна ветка каталога, 301 редирект категории пишут тем же групповым шаблоном, что и для раздела.
Когда постоянный 301 обязателен:
- каталог перестроили, и категории получили другие уровни вложенности или слаги;
- проект перевели на ЧПУ, и вместо index.php?id=12 появились читаемые пути;
- блог переехал из /news/ в /blog/ с сохранением дат и слагов;
- сменили CMS, и свежая система строит адреса по своим порядкам;
- раздел вынесли на поддомен или вернули в основной домен.
Порядок работ в этих сценариях одинаков. Сначала собираем полный список адресов, затем проектируем дерево и только потом садимся за конфигурацию. Обратная очерёдность даёт пропуски, которые находятся через месяц по откликам 404. Тем, кто дерево только проектирует, пригодится наш разбор о том, что такое структура сайта.
Почему именно 301, а не 302 или canonical
Код 301 сообщает поисковой системе, что переезд постоянный: старые адреса уходят из индекса, а сигналы закрепляются за новыми. При временном 302 в индексе остаётся старый адрес, поэтому код, поставленный «на время тестирования» редизайна, после запуска обязательно меняют на 301. Canonical решает другую задачу: оба адреса продолжают открываться, а робот воспринимает указание как рекомендацию. Подробнее об этом в статьях что такое 302 редирект и canonical или 301 редирект.
Механика одинакова и для одиночного адреса, и для рубрики целиком. 301 редирект на другую страницу сайта отличается от группового только числом адресов, которые попадают под шаблон. Если тематика сохранилась, а конкретных документов на другом месте нет, справка Яндекса рекомендует вести такие адреса на вершину соответствующей рубрики или в близкую по смыслу. Если тематика поменялась, они должны отдавать 404, и после переобхода поиск их потеряет.
Подготовка: список адресов раздела и карта редиректов
Адрес ценного материала лучше сохранить, чем переносить: в переходный период позиции колеблются. Поэтому перед сменой адресов мы оцениваем раздел по трём осям: позиции, трафик и входящие внешние ссылки. Самые ценные адреса оставляем нетронутыми, а для остальных подбираем близкие соответствия – тот же товар, ту же категорию, тот же тип материала.
Адреса собирают из sitemap.xml до переезда, журнала access.log, выгрузки краулера и панелей вебмастеров: каждый источник по отдельности неполон. Карта соответствий состоит из четырёх колонок: адрес до переноса, адрес после, тип и комментарий. Для важных URL мы пишем точечные соответствия, ветка, переехавшая целиком, получает одно групповое правило. Как составлять такую таблицу построчно, разобрано в материале про карту редиректов со старых страниц на новые.
Как настроить 301 редирект раздела в .htaccess
Правила для раздела пишут в корневой .htaccess, и они действуют на рубрику целиком, включая вложенные уровни. Перед правкой сохраните резервную копию файла: ошибка в синтаксисе кладёт сайт с кодом 500. Где лежит файл и как устроены директивы, разобрано в статье 301 редирект в .htaccess. Массовый 301 редирект тем и удобен, что заменяет сотню записей одной: перечислять позиции каталога поимённо бессмысленно.
Если старая и новая ветка различаются только префиксом, хватает директивы Redirect 301 /katalog/obuv https://site.ru/catalog/shoes: она уведёт и сам каталог, и всё, что под ним. Как только нужно перестроить порядок сегментов, объединить рубрики или учесть условие, берут RewriteRule.
Перенос всего раздела с сохранением вложенных путей
Групповая запись умещается в одну строчку. Маска ловит старый префикс, забирает хвост адреса в группу (.*), а подстановка вставляет этот хвост после актуального:
RewriteEngine On
RewriteRule ^katalog/obuv/(.*)$ https://site.ru/catalog/shoes/$1 [R=301,L]
Адрес /katalog/obuv/krossovki/nike-air/ превращается в /catalog/shoes/krossovki/nike-air/, вложенность сохраняется на любую глубину. Так 301 редирект с раздела на новый адрес закрывает всю ветку одной строкой. Флаг R=301 обязателен: без кода сервер вернёт временный 302.
Если вложенность на новом месте другая, в выражении выделяют несколько групп и подставляют их в правильной очерёдности. Для блога, где /news/2024/kak-vybrat/ должен стать /blog/kak-vybrat/2024/, маска ^news/(\d{4})/(.*)$ захватывает год в $1 и слаг в $2. Такие записи мы проверяем на живых адресах: промах в номере группы уводит читателя не туда.
Объединение рубрик и порядок правил
При объединении 301 редирект с разделами-донорами ведут на одну общую рубрику. Две ветки, кеды и кроссовки, сводятся в одну записью RewriteRule ^katalog/(kedy|krossovki)/(.*)$ https://site.ru/catalog/sneakers/$2 [R=301,L]. Если однотипных соответствий нет и их сотни, записи в .htaccess заменяют внешней картой RewriteMap, но объявляют её в конфигурации виртуального хоста, поэтому без доступа к конфигу остаются шаблоны и точечные исключения.
Очерёдность записей важнее их количества. Директивы обрабатываются сверху вниз, флаг L останавливает обработку на первом совпадении, поэтому частные правила ставят выше общих. Иначе широкий шаблон перехватит и те URL, для которых десятью строками ниже написано исключение.
Редирект раздела в Nginx и через CMS
В Nginx групповой перенос описывают блоком location с префиксом и rewrite с группой захвата, а после правки конфигурацию перечитывают; тот же порядок действует при переезде всего домена, и этот случай мы разобрали в материале про перенос с домена на домен. Плагины CMS удобны для единичных адресов, но массовый перенос раздела надёжнее делать на стороне сервера: правило отрабатывает до запуска CMS, и слоёв перенаправлений не становится два.
Как проверить редирект раздела после внедрения
Проверка идёт по всему собранному списку, а не по вершине ветки: ошибки обычно прячутся на глубоких уровнях – в карточках, фильтрах, пагинации. Список прогоняют краулером, и у каждого старого адреса должен быть код 301 и один переход до страницы, которая отвечает 200 и отдаёт контент. Неожиданные адреса, которых нет ни в одном списке, ищут в access.log. Браузер надолго запоминает ответ 301, поэтому вручную адреса открывают в режиме инкогнито.
Способы и сервисы проверки мы разобрали в статье как проверить 301 редирект, а поиск лишних переходов – в материале про цепочки редиректов.
Что сделать после запуска редиректов раздела
Рабочая конфигурация закрывает половину переезда. Вторая половина в том, чтобы проект перестал ссылаться на устаревшие пути: пока внутренние ссылки ведут туда, каждый клик читателя проходит лишний переход, а робот тратит краулинговый бюджет на адреса, которых нет.
Что обновляем после переноса раздела:
- внутренние ссылки в меню, хлебных крошках и текстах переводим на актуальные адреса напрямую;
- sitemap.xml пересобираем только с действующими URL;
- в robots.txt проверяем, что переехавший раздел открыт для индексации;
- у целевых документов снимаем noindex и канонические указания на посторонний адрес;
- в Яндекс Вебмастере отправляем на переобход и свежие адреса, и прежние с перенаправлением, а обновлённый файл Sitemap загружаем повторно;
- на вкладке «Внешние ссылки» смотрим, кто ссылается на устаревшие URL, и просим владельцев площадок поправить адрес.
Дальше идёт наблюдение. Всплеск 404 в логах означает, что часть URL в список не попала, а провал трафика при чистых ответах сервера говорит о неверных целях.
Частые ошибки при редиректе раздела
Большинство промахов при групповом переносе связаны с самим шаблоном и его местом в файле:
- всю рубрику перенаправили на главную, и поисковые системы расценивают это как soft 404, поэтому позиции теряются;
- неэкранированная точка в регулярном выражении заставляет шаблон ловить лишние адреса;
- общий шаблон стоит выше частных, поэтому исключения не срабатывают.
Отдельно стоит конфликт сигналов: 301 ведёт на адрес со слешем, а canonical по месту прибытия указывает на адрес без слеша. После миграции мы сверяем canonical, sitemap и внутренние ссылки. Остальные ошибки и их диагностику мы собрали в материале про проблемы с 301 редиректом.
