Редизайн сайта обычно начинается с обсуждения цветов и сетки, а заканчивается — потерей страниц, которые годами приводили целевой трафик. Пока команда спорит о шрифтах, на старом сайте меняются адреса разделов, услуги объединяются, фильтры удаляются, контент переезжает в новую структуру. Если решение о судьбе каждого старого URL принимают уже после публикации, поисковая система получает сотни сигналов сразу: страницы исчезли, ссылки ведут в никуда, заголовки поменялись.
Восстановление после такой миграции занимает дольше, чем сама подготовка. Хорошая новость: потерю трафика можно предотвратить, и сохранять каждый адрес не обязательно. Ненужные, дублирующие и технические страницы вполне можно закрыть — если для них заранее выбран сценарий.
Три вопроса рабочей миграции
Перед стартом работ стоит честно ответить на три вопроса:
- Какие URL существовали до запуска?
- Куда должен попасть пользователь с каждого важного адреса?
- Как команда подтвердит, что поисковый робот увидел новую версию?
Если хотя бы на один вопрос нет ответа — рано открывать макеты.
Инвентаризация до дизайна
Список адресов собирают из нескольких источников: технического обхода сайта, XML-карты, панели поискового сервиса, веб-аналитики, рекламных посадочных страниц и выгрузки из CMS. Один источник картину не покроет. Старая страница может давно исчезнуть из меню, но продолжать получать переходы по внешней ссылке или из сохранённой выдачи.
Для каждого URL в рабочей таблице фиксируют код ответа, заголовок, назначение страницы, органический трафик, внешние ссылки и решение по судьбе адреса. Полезно назначить владельца решения: маркетолог определяет, нужна ли тема в новой структуре, редактор переносит материал, разработчик настраивает правило, SEO-специалист проверяет результат. Тогда строка «разобраться позже» не доживает до ночи релиза.
Отдельно стоит отделить ценные страницы от технического шума. В любом перечне найдутся параметры фильтров, служебная пагинация, результаты внутреннего поиска и старые дубли. Их нельзя автоматически направлять на главную: такое перенаправление не объясняет ни пользователю, ни роботу, где оказался нужный материал. Для значимой страницы ищут ближайшую новую, для окончательно удалённой оставляют честный код 404 или 410 и убирают внутренние ссылки.
Карта соответствий вместо списка догадок
Карта редиректов строится как соответствие «старый URL — новый URL — тип решения». Для переезда нужен серверный постоянный редирект. Переход через JavaScript, метаобновление или промежуточную страницу в браузере сработает, но усложнит диагностику и съест обходы робота.
Сценарии бывают разные. Страница услуги обычно переезжает на её новый адрес. Несколько почти одинаковых старых страниц могут слиться в один канонический материал, если новая страница действительно отвечает на их запрос. Адреса с параметрами лучше закрывать правилом, а не вручную перечислять бесконечные комбинации. В таблице стоит сразу отметить исключения: языковые версии, документы, личный кабинет, файлы и страницы, для которых редирект запрещён.
После настройки правило проверяют и как посетитель, и как робот: старый адрес должен сразу давать один переход на конечную страницу. Цепочка «старый URL → временная страница → новый URL» увеличивает время загрузки и маскирует ошибки. Внутренние ссылки, canonical, hreflang, sitemap и ссылки в шаблонах должны вести сразу на новые адреса.
Контрольная точка перед релизом
Редизайн меняет не только URL. У страницы могут смениться заголовок, текст, блоки ссылок, микроразметка, robots-правила и код ответа. Для ключевых разделов заранее сохраняют исходные title, description, H1, текстовые блоки, изображения, canonical и данные о видимости. Это не копирование старого сайта: контрольная копия нужна, чтобы отличить плановое изменение от случайной потери.
Тестовую среду до релиза закрывают от индексации и проверяют, что она не канонизируется на себя из продакшена. После релиза запрет снимают только там, где страница должна участвовать в поиске. Классическая ошибка — оставить на новом сайте заголовок X-Robots-Tag или robots.txt от стенда и заметить это спустя недели.
Контроль после публикации
В день запуска проверяют выборку приоритетных URL вручную и автоматизированным обходом: коды ответа, конечные адреса, canonical, title, H1, robots, sitemap и ссылки на медиа. Редирект сработал — ещё не значит, что новая страница доступна для обхода и не объявлена дублем.
Дальше в течение недель смотрят отчёты об индексировании, ошибки сканирования, число исключённых URL, переходы на 404 и динамику поисковых посадочных. Просадку нельзя объяснять одной цифрой трафика: сезонность, рекламные кампании и изменение спроса идут параллельно. В журнал релиза записывают дату переключения и существенные изменения структуры — это потом экономит часы споров.
Ошибки, которые ломают миграцию
Четыре самых частых сценария провала:
- Карта редиректов появляется после запуска. Когда таблицу собирают по обращениям пользователей, часть старых адресов уже выпала из обхода.
- Все удалённые страницы ведут на главную. Главная редко заменяет конкретную услугу, инструкцию или документ.
- Редирект настроен только для варианта без параметров. Переходы из рекламы, рассылок и внешних ссылок почти всегда содержат параметры.
- Проверяют только главную и меню. Ошибки прячутся в карточках, файлах, старых посадочных и вложенных разделах.
Итог
SEO-миграция начинается до макетов и завершается не в момент публикации. Инвентаризация, карта соответствий, тестовые выборки и журнал контроля дают команде способ увидеть ошибку по конкретному URL, а не спорить о суммарном графике трафика.
Top comments (0)