Назад
Карта редиректов при миграции на Битрикс: типовые риски

Карта редиректов при миграции на Битрикс: типовые риски

Как подготовить карту редиректов при переезде на Битрикс и не потерять трафик из-за 404, дублей и цепочек переходов.

Миграция сайта на 1С-Битрикс похожа на переезд офиса: мебель можно перевезти быстро, но если забыть повесить таблички на старом адресе, клиенты будут стоять у закрытой двери. В SEO роль таких табличек играет карта редиректов — таблица, где каждому старому URL сопоставлен новый адрес.

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

Google в своей документации по переезду сайта прямо советует подготовить список старых URL и сопоставить их с новыми адресами, а для постоянного переезда применять 301 или 308. У Яндекса смысл тот же: старые страницы должны вести на аналогичные новые страницы, которые нужны в поиске. Подробности есть в справке Google Search Central и рекомендациях Яндекса по смене структуры сайта.

Что такое карта редиректов — без канцелярита

Карта редиректов — это не «табличка для галочки». Это рабочий документ для SEO-специалиста, разработчика, контент-менеджера и владельца проекта. В нём фиксируются старый адрес, новый адрес, тип перехода, статус страницы, комментарий и иногда приоритет.

Например, старая карточка товара была по адресу /catalog/divany/model-123/, а после переезда на Битрикс стала /catalog/sofas/model-123/. Если редиректа нет, пользователь увидит 404. Поисковый робот тоже. Один раз — не беда. Сотни раз — уже тревожный звонок.

В нормальной карте не должно быть гадания на кофейной гуще. Старый URL либо ведёт на максимально близкую новую страницу, либо честно получает 404/410, если аналога нет и страница больше не нужна. Массовый редирект всех пропавших страниц на главную выглядит удобно, но для SEO часто пахнет дымом: поисковик видит не релевантный ответ, а попытку спрятать мусор под ковёр.

Почему Битрикс добавляет свои острые углы?

1С-Битрикс сам по себе не враг SEO. Но у него есть своя логика адресов, ЧПУ, инфоблоков, разделов, фильтров и обработки 404. В старых проектах часто участвует файл urlrewrite.php, а в новых версиях Bitrix Framework есть роутинг. В официальной документации Битрикса указано, что раньше для маршрутизации применялся urlrewrite.php, а сейчас доступен механизм роутинга; также описана обработка адресов через UrlRewrite и роутинг Bitrix Framework.

В чём же дело? Редирект может быть настроен на уровне сервера, в .htaccess, в nginx-конфиге, в обработчике Битрикса, в модуле из Marketplace или даже в кастомном PHP-коде. Если эти уровни спорят друг с другом, начинается маленький цирк: один адрес кидает на второй, второй — на третий, третий возвращает на первый. Робот не смеётся.

Поэтому перед релизом нужно понимать, где именно живут правила. Не «где-то программисты поставили», а конкретно: сервер, CMS, модуль, код шаблона, обработчик 404. И да, это тот редкий случай, когда занудство окупается.

Риск №1: старые URL собрали не полностью

Самая частая беда — карта сделана только по страницам из меню. А где товары, теги, новости за 2018 год, страницы пагинации, старые акции, PDF, адреса с параметрами, URL из внешних ссылок? Они тоже живут в памяти поиска и пользователей.

Источники для сбора стоит брать разные:

  • выгрузка из старой CMS;
  • XML-карты сайта;
  • данные Google Search Console и Яндекс Вебмастера;
  • логи сервера;
  • краулер вроде Screaming Frog, Sitebulb или аналога;
  • список страниц с трафиком из веб-аналитики;
  • внешние ссылки из SEO-сервисов.

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

Риск №2: редирект ведёт «примерно туда»

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

Если старая карточка товара вела на конкретный товар, новый адрес тоже должен вести на этот товар или на максимально близкий аналог. Если товар снят с продажи, можно вести на категорию или замену — но только когда это полезно человеку. Редирект ради редиректа не лечит проблему, он её маскирует.

А знаете что? Хорошая карта редиректов иногда выглядит неаккуратно: где-то страница к странице, где-то страница к разделу, где-то 404. Но именно такая «живая» карта ближе к реальности.

Риск №3: цепочки и петли

Цепочка — это когда старый URL ведёт не сразу на финальную страницу, а через несколько прыжков: /old//new-old//new/. Петля ещё хуже: адреса гоняют пользователя по кругу.

Google отмечает, что после переезда робот должен посетить старые и новые URL, а нагрузка на новый сайт может временно вырасти. Лишние прыжки в этот момент только мешают. Лучше сразу вести старый адрес на финальный новый URL, без промежуточных остановок и «потом поправим».

Для Битрикса это особенно важно из-за типовых нормализаций: http на https, www на без www, index.php на папку, слеш в конце, нижний регистр, параметры сортировки. Если каждое правило живёт отдельно и срабатывает по очереди, цепочки растут как сорняки после дождя.

Риск №4: 302 вместо 301

Для постоянного переезда страниц Google рекомендует постоянные редиректы, например 301 или 308. В интерфейсах, модулях и самописных обработчиках иногда случайно ставят 302 — временный переход. Пользователь разницы почти не заметит, а поисковик может дольше держать старый адрес в выдаче.

Проверка простая: прогнать карту редиректов краулером и посмотреть фактический HTTP-код. Не тот, который «должен быть», а тот, который сервер возвращает сейчас. Разница между планом и реальностью бывает бодрящей.

Риск №5: дубли после переезда

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

Тут редиректы работают вместе с canonical, robots, sitemap и внутренними ссылками. Важно, чтобы меню, хлебные крошки, карточки товаров и XML-карта ссылались уже на новые чистые URL. Иначе получится странно: сервер говорит «иди туда», а сайт внутри упорно зовёт обратно.

Риск №6: забыли про 404 и снятые страницы

Не каждой старой странице нужен новый дом. Если новость устарела, товар исчез навсегда, а раздел больше не имеет смысла, корректная 404 иногда честнее редиректа. В Битриксе нужно отдельно проверить, что страница 404 отдаёт именно код 404, а не красивую HTML-страницу со статусом 200. Такое встречается чаще, чем хотелось бы.

Официальная справка Битрикса по обработке адресов упоминает подключение /bitrix/modules/main/include/urlrewrite.php в 404.php при определённой серверной настройке. Это тонкий момент: визуально всё может выглядеть нормально, но код ответа окажется неверным. А поиску важен именно ответ сервера.

Как проверить карту перед запуском

Перед релизом устройте карте редиректов небольшой экзамен. Не «открыли десять страниц руками», а полноценную проверку.

  • Все старые URL из таблицы отдают 301 или 308 там, где запланирован постоянный переход.
  • Финальная страница отвечает 200 и открывается без авторизации.
  • Нет цепочек длиннее одного перехода.
  • Нет петель.
  • Редирект ведёт на релевантную страницу, а не на главную по умолчанию.
  • Sitemap содержит новые URL, а не старые.
  • Внутренние ссылки уже обновлены.
  • Страницы 404 реально отдают код 404.

После запуска проверка не заканчивается. Первые недели стоит смотреть отчёты об индексации, ошибки сканирования, логи и страницы входа из органики. Миграция — не кнопка, а процесс. Да, звучит скучно. Зато трафик любит скучную дисциплину.

Итог: карта редиректов — это страховка, а не формальность

При миграции на Битрикс карта редиректов защищает не только SEO-позиции. Она защищает путь клиента: из поиска, из старой закладки, из письма, из внешней статьи. Человек нажал — и попал туда, куда ожидал. Вот и вся магия.

Главное — собрать полный список старых URL, назначить точные новые адреса, настроить постоянные редиректы, проверить коды ответа и не забыть о Битрикс-специфике: ЧПУ, urlrewrite.php, 404, фильтры, зеркала, index.php. Тогда переезд пройдёт не без шума, конечно, но без пожара. А это уже хороший результат.