Миграция сайта без потерь: правильная настройка 301-редиректов

301 редирект не работает: где ломается переезд и уходит трафик

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

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

Разрозненные правила — главный источник обрывов. Часть редиректов прописана в конфигурации сервера, часть — на уровне приложения, часть заведена вручную; при слиянии они конфликтуют, а разделы и адреса с параметрами остаются без правил. Отдельно ломается склейка адресов: версии с www и без, разные протоколы и завершающий слэш должны сходиться к одному каноническому виду, иначе дубли делят между собой вес.

Есть и молчаливые сбои: сервер отдаёт код успеха на странице-заглушке «ничего не найдено». Отчёты Search Console по карте перенаправлений, цепочкам и внутренним ссылкам показывают такие места до того, как они съедят позиции. Разбираем, как это закрывается — от инвентаризации адресов до единой точки правил и контроля после запуска.

Что даёт корректная настройка: результат в цифрах и сроках

Корректно построенная карта 301-редиректов даёт измеримый эффект сразу на входе: 98-99% переходов по старым адресам попадают на целевую страницу с первого шага, а не на промежуточный ответ. Пользователь видит нужный контент, а не заглушку, и не теряет секунды на лишний круг запросов — для разделов с высоким трафиком это заметная доля удержания.

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

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

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

Способы перенаправления: когда какой режим уместен

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

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

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

Порядок миграции: от инвентаризации адресов до проверки

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

1. Аудит адресов. Собираем полную карту входов: логи веб-сервера за несколько месяцев, карта сайта, отчёты о индексации, внешние ссылки. В неё попадают адреса с параметрами, хвостовым слешем и в разном регистре — именно они чаще всего остаются без пары.
2. Проектируем схему перенаправлений. Каждый старый адрес получает ровно один целевой, без цепочек и промежуточных звеньев: несколько переходов подряд съедают вес и время ответа. Для страниц без аналога ставим честный код «удалено» вместо отправки на главную.
3. Собираем тестовый контур. Копия структуры и правил на отдельном стенде: прогоняем карту адресов скриптом и сверяем коды ответов, заголовки и итоговые точки назначения.
4. Настраиваем перенаправления. На уровне веб-сервера или балансировщика, а не в разметке страницы — так правило срабатывает до отдачи контента и не зависит от движка.
5. Проверка охвата. Сверяем список из аудита с реальными ответами: считаем долю адресов, отдающих корректный код, и убеждаемся, что новых цепочек не появилось.
6. Переключение и наблюдение. После запуска отслеживаем коды ответов на бывших адресах и динамику входов по ним; расхождения закрываем точечно.
7. План отката. Конфигурация правил версионируется рядом с проектом: если структура принята неудачно, возврат к прежней схеме занимает минуты, без ручной правки боевого окружения.

Карта перенаправлений, журналы и регламенты обновления

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

• Карта перенаправлений — таблица «старый адрес → целевой → тип перехода → ответственный», включая схлопнутые цепочки, где несколько ссылок ведут на одну страницу за один переход.
• Документация по миграции — что и почему перенесли, какие адреса оставили намеренно, какие разделы закрыли и куда теперь ведут их посетители.
• Журнал изменений адресов — дата, автор, причина правки и прежнее правило: по нему видно, когда появилось задвоение и что именно откатывать.
• Регламент обновления — где заводятся новые правила, в каком порядке они применяются и как проверяются до публикации на рабочем контуре.
• Инструкция для поддержки — сценарии на типовые случаи: переименовали раздел, склеили каталог, удалили страницу без замены.
• Конфигурации правил — файлы веб-сервера и настройки на уровне приложения с комментариями, чтобы правку внёс инженер, не участвовавший в переносе.
• Набор проверок — обход карты адресов, который ловит «страница не найдена» и лишние цепочки раньше, чем их увидят посетители и поисковые роботы.

Всё это лежит рядом с проектом, а не в переписке. Новому инженеру не приходится восстанавливать логику переходов по косвенным признакам.

Миграция интернет-магазина: трафик и позиции до и после

Каталог на 1С-Битрикс жил в плоской структуре: 12 тысяч адресов, разделы в один уровень, часть карточек — по служебным путям фильтров. Переходы из поиска приносили больше половины заказов, поэтому смена структуры разделов означала риск разом потерять видимость и выручку.

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

Как настраивали переходы

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

Что получилось

Первую неделю после переключения доля переходов из поиска просела на 12% — ожидаемая реакция на смену адресов. К третьей неделе видимость восстановилась до 95% от прежней, через два месяца — до 104%: новая структура разделов добавила охвата за счёт более точных запросов. Ошибки 404 остались на 0,4% от всех обращений вместо 6% в первые дни — их сняли точечными правилами по логам.

Чем отличается 301 редирект от временного перенаправления?

301 — постоянный перенос: поисковая система заменяет старый адрес на новый в индексе и переносит на него накопленные сигналы. Временное перенаправление (302 и 307) говорит обратное — адрес вернётся, поэтому исходный URL остаётся основным, а новый ранжируется как отдельная страница. Отсюда и разница: при 301 вес страницы переезжает, при временном — остаётся на месте.

На практике выбор диктует сценарий. Склейка дублей — со слэшем и без, с www и без, старый и новый шаблон — всегда через 301: все версии сходятся на один канонический адрес, и сигналы не размазываются между копиями. Временный режим уместен для тестовых лендингов, геопереключений и технических работ: Google продолжает отдавать показы исходному адресу, а после снятия редиректа откатывать ничего не нужно.

Повторный переезд — отдельный риск. Цепочка 301 → 301 → 301 размывает сигналы: робот проходит несколько переходов, и часть веса теряется по дороге. Поэтому при втором переносе редирект ставим сразу на финальный адрес, а внутренние ссылки, карту сайта и канонические адреса обновляем тем же релизом — чтобы цепочек и петель не оставалось вовсе.

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

Технические сомнения: вопросы о перенаправлениях и склейке

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

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

Сайт уже переехал, но часть адресов отдаёт ошибку — что делать?

Сначала источник: ошибки ответа сервера на нужных адресах обычно означают, что правило не сработало, перекрыто другим или указывает на промежуточный адрес. Дальше — повторная миграция только проблемного сегмента: сверяем журнал обращений с картой адресов, схлопываем цепочки вида A→B→C в прямое A→C и уводим на финальную страницу.

Как убедиться, что новые адреса проиндексировались?

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

Мы снова меняем структуру — правила придётся переписывать?

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

Обсудим вашу миграцию: что прислать для оценки и плана

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

• Выгрузка текущих адресов: карта сайта, лог сервера за один-два месяца, таблица адресов с частотой обращений.
• Структура нового сайта: перечень разделов и адресов, чтобы сопоставить старые и новые один к одному и не оставить «висящих» страниц.
• Действующие правила: редиректы на уровне веб-сервера и обратного прокси, robots.txt, канонические адреса, настройки пагинации и параметров в ссылках.
• Особые случаи: языковые версии, закрытые разделы, документы и файлы, адреса с завершающим слэшем и в верхнем регистре.
• Доступы: тестовый контур, панель хостинга, репозиторий с конфигурацией — проверим коды ответов и цепочки редиректов до переключения, а не после.
• Даты: желаемое окно переключения и периоды, когда боевой сайт трогать нельзя.

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