Предположим, у компании есть работающий многостраничный сайт, который нужно перенести на новую техническую платформу. Часть страниц получает органический трафик, накоплены внешние ссылки и настроена аналитика.
Опасный сценарий — начать с нового дизайна, а карту старых URL собирать за день до запуска. Безопасный сценарий начинается с инвентаризации текущего актива.
До разработки
Фиксируются все индексируемые URL, их статусы, трафик и роль в структуре. Для каждого адреса заранее определяется судьба: сохранить, перенести на новый эквивалент, объединить или корректно удалить.
До переключения
Готовится карта 301-редиректов, проверяется robots.txt и sitemap, канонические URL, аналитика, формы и критические пользовательские сценарии. Снимается технический baseline, чтобы после запуска сравнивать не по памяти.
В момент релиза
Изменения выполняются контролируемо. После переключения автоматически и вручную проверяются ключевые старые URL, цепочки редиректов, коды ответов, доступность страниц и корректность аналитики.
После релиза
Контролируются ошибки обхода, неожиданные 404, изменения индексируемости и распределение поискового трафика. Если обнаружена системная ошибка, приоритет — восстановить корректный маршрут, а не ждать, что поиск «сам разберётся».
Почему это сценарий, а не кейс
Здесь намеренно нет процентов роста, названия клиента или графиков. Пока у бюро нет разрешённого подтверждённого клиентского кейса по этому процессу, корректнее показывать метод и ограничения открыто.