Кейс: переезд магазина на новую платформу — что делали, чтобы не потерять трафик
7 мин чтения9 пунктов чек-листа + 5 шагов плана — готовая основа задачи разработчику.
Кому полезноРуководителю проекта и разработчику
Что станет понятноОсновная работа при переезде — не код, а карта соответствия старых и новых адресов
С чем уйдёте9 пунктов чек-листа + 5 шагов плана — готовая основа задачи разработчику.
Каталог на 6 тысяч страниц, старая платформа не позволяла расти. Разбор по этапам: как готовили карту адресов, что пошло не по плану на второй неделе и почему просадка составила три недели вместо ожидаемых шести.
- Основная работа при переезде — не код, а карта соответствия старых и новых адресов
- Просадка трафика после переезда неизбежна; управляемо только то, насколько она глубокая и долгая
- Выкладывать весь сайт разом опаснее, чем разделами: при ошибке откатывать придётся всё
- Проверку после выкладки должен проходить не тот человек, который выкладывал
- Часть страниц потерялась не из-за техники, а потому что их не было в исходном списке
Контекст и что можно рассказать
Интернет-магазин товаров для дома, каталог около 6 тысяч страниц, органический поиск давал основную долю обращений. Ниша, регион и название компании не раскрываются: проект под соглашением о неразглашении.
Задача звучала так: старая платформа не позволяет создавать страницы под фильтры и управлять адресами, из-за этого продвижение уперлось в потолок. Решение о переезде было принято до нас, наша роль — провести его так, чтобы не потерять накопленные позиции.
Важная оговорка о цифрах: динамику мы приводим в процентах от исходного уровня. Абсолютные значения посещаемости и выручки — коммерческая информация клиента.
Подготовка: три недели до того, как что-то заработало
Самая недооценённая часть переезда происходит до того, как новый сайт вообще показывают людям.
Полный список адресов старого сайта. Выгрузили всё: из карты сайта, из панели вебмастера, из системы аналитики за два года и обходом сайта краулером. Четыре источника дали разные списки, и это нормально: карта сайта содержала не всё, а в аналитике нашлись страницы, о которых никто в компании не помнил.
Отсев мусора. Из объединённого списка примерно пятая часть оказалась техническими дублями: одна и та же карточка с разными параметрами сортировки и фильтрами. Их не нужно переносить один к одному — им место в переадресации на основную страницу.
Карта соответствия. Главный документ переезда: таблица «старый адрес → новый адрес». Заполняли полуавтоматически: категории и карточки сопоставились по артикулу, а вот статьи, страницы услуг и посадочные под рекламу пришлось разбирать руками — их структура на новой платформе изменилась.
Что делать с тем, чему нет замены. Около сотни страниц на новом сайте не имели аналога: разделы, от которых отказались. Здесь два варианта — переадресация на ближайшую по смыслу страницу или честный код «страница удалена». Переадресация всего подряд на главную — распространённая ошибка, поиск воспринимает её как отсутствие страницы и просто исключает адрес.
Сверка содержимого. Выборочно, по 40 страницам разных типов, сравнили: заголовок, описание, текст, характеристики. На новой платформе часть текстов не переносилась автоматически, и без сверки это выяснилось бы уже после запуска.
Выкладка: почему не стали переключать всё разом
Соблазн переключить сайт целиком за одну ночь велик — так короче и понятнее. Мы этого не сделали, и в итоге это оказалось главным решением проекта.
Порядок был такой. Сначала перевели информационные разделы и статьи — примерно 8% трафика. Неделю наблюдали. Затем — три категории каталога из двадцати. Ещё неделю наблюдали. Потом остальной каталог и в последнюю очередь главную страницу.
Что это дало. На первом этапе обнаружились две ошибки, которые на полном переезде стоили бы гораздо дороже: переадресация теряла окончание адреса при переходе с одного написания на другое, и на части страниц не переносился заголовок первого уровня. Обе нашлись на 8% трафика, а не на 100%.
| Этап | Что переносили | Доля трафика | Что нашли |
|---|---|---|---|
| 1-я неделя | статьи и информационные разделы | 8% | обрыв адреса при переадресации |
| 2-я неделя | три категории каталога | 15% | не переносился заголовок H1 |
| 3-я неделя | остальной каталог | 60% | дубли из-за параметров сортировки |
| 4-я неделя | главная и служебные страницы | 17% | без замечаний |
Обратная сторона поэтапной схемы — месяц вместо ночи и необходимость какое-то время поддерживать две системы одновременно. Для проекта, где поиск даёт основную долю обращений, это оправданная плата.
window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
event: 'lead_submit',
form_id: 'audit',
page_path: location.pathname
});Что пошло не по плану
Потерянные страницы, которых не было в списке. На третьей неделе выяснилось, что часть посадочных страниц под рекламу жила вне основной системы — их сделал сторонний подрядчик несколько лет назад. Они не попали ни в карту сайта, ни в выгрузку, и обнаружились только потому, что упал трафик по рекламным кампаниям. Урок: список адресов стоит сверять не только с техническими источниками, но и с отделом маркетинга.
Скорость на новой платформе оказалась хуже. Ожидали улучшения, получили ухудшение: новый шаблон грузил больше кода, а изображения отдавались в исходном размере. Ушла отдельная неделя на оптимизацию уже после переезда. Правильнее было замерить скорость на тестовой площадке под реальной нагрузкой до выкладки.
Обмен с учётной системой сломался на второй день. Цены и остатки перестали обновляться из-за изменившегося формата выгрузки. Сайт двое суток показывал вчерашние цены — для магазина это прямые потери и репутационный риск. После этого добавили простую проверку: если обмен не прошёл дольше трёх часов, приходит уведомление.
Чего не случилось. Массового выпадения страниц из индекса не произошло — карта соответствия сработала. Это и есть основной результат подготовки, хотя внешне выглядит как «ничего не произошло».
Динамика по неделям: как выглядела просадка
За 100% принят средний уровень органического трафика за месяц до начала переезда.
| Неделя | Трафик | Что происходило |
|---|---|---|
| 1 | 98% | перенос статей, поиск ещё не заметил изменений |
| 2 | 91% | переиндексация первых разделов |
| 3 | 76% | перенос основного каталога, пик просадки |
| 4 | 72% | нижняя точка, поиск обходит новые адреса |
| 5 | 84% | возврат категорий в выдачу |
| 6 | 95% | почти исходный уровень |
| 7 | 103% | выше исходного за счёт ускорения и новых фильтров |
Нижняя точка — минус 28% на четвёртой неделе. Это близко к нормальному диапазону для переезда такого объёма: при аккуратной подготовке обычно теряют от 20 до 40%, при неподготовленном переносе просадка бывает вдвое глубже и растягивается на месяцы.
Рост выше исходного уровня на седьмой неделе — заслуга не самого переезда, а того, ради чего он делался: появилась возможность создавать страницы под фильтры, и первые из них начали получать трафик.
Что сделали бы иначе
Начали бы со сверки с маркетингом, а не с техники. Потерянные рекламные страницы обошлись в две недели простоя кампаний. Полчаса разговора с отделом маркетинга в начале проекта закрыли бы этот риск полностью.
Замерили бы скорость до переезда. Тестовая площадка работала на слабом сервере, и её показатели списывали на это. Нужно было проверить новый шаблон под реальной конфигурацией — тогда оптимизация вошла бы в подготовку, а не в аварийные работы после запуска.
Настроили бы контроль обмена заранее. Уведомление о сбое выгрузки появилось после инцидента. Это пятнадцать минут работы, которые нужно делать до, а не после.
Заложили бы больше времени на сверку содержимого. Проверили 40 страниц из шести тысяч — по итогу этого хватило, но выборка была маловата. Разумнее брать по 10–15 страниц каждого типа шаблона, а не общее число.
Главный вывод
Переезд — не техническая задача, а организационная. Код новой платформы пишется предсказуемо, а вот полный список того, что существует на старом сайте, собирается только совместными усилиями разработки, продвижения и маркетинга. Все три проблемы этого проекта возникли на стыках между ними, а не внутри чьей-то зоны.
И вторая мысль, которую стоит проговаривать с руководством до старта: просадка будет. Вопрос не в том, как её избежать, а в том, какой глубины и на сколько недель. Если подрядчик обещает переезд без потерь вообще — он либо не понимает, о чём говорит, либо готовится объяснять падение внешними причинами.
Путь клиента: где эта тема срабатывает
Тема актуальна в момент, когда бизнес перерос текущую платформу, но боится переезда из-за возможной потери позиций и трафика.
Что у клиентаСтарая платформа тормозит рост: не хватает функций, каталог растёт быстрее, чем система успевает обрабатывать.
Что делаемОцениваем масштаб каталога, считаем количество адресов и типов страниц, которые предстоит перенести.
Сигнал, что работаетКлиент понимает порядок объёма работы и примерные сроки, а не только «хочу новый сайт».
Что у клиентаКлиент передаёт доступы к старой системе, статистике и текущей структуре каталога.
Что делаемСтроим карту соответствия старых и новых URL, сверяем со списком реально существующих страниц, а не только с тем, что «должно быть».
Сигнал, что работаетКарта покрывает весь трафикообразующий каталог, расхождений между списком и фактом почти нет.
Что у клиентаМагазин продолжает работать, часть разделов уже переехала, часть — на старой платформе.
Что делаемВыкладываем сайт по частям, проверяем редиректы и индексацию на каждом куске отдельно, привлекаем к проверке другого человека, не того, кто выкладывал.
Сигнал, что работаетПросадка трафика на выложенных разделах предсказуема и укладывается в ожидаемый диапазон.
Что у клиентаКлиент видит графики трафика и хочет понимать, когда всё вернётся к прежним значениям.
Что делаемОтслеживаем динамику по неделям, донастраиваем редиректы под страницы, которых не было в исходном списке.
Сигнал, что работаетТрафик выходит на прежний уровень в срок, близкий к тому, что обсуждали до начала работ.
Стратегия: что делать по шагам
Цель: Перенести каталог на новую платформу так, чтобы просадка трафика была короче и предсказуемей, чем при разовом переключении всего сайта.
Шкала собрана из сроков плана ниже. Это ориентир для последовательности работ.
- Неделя 1-2 Собираем полный список текущих страниц каталога и сверяем его с картой сайта и статистикой посещений — не только с тем, что есть в CMS. Список адресов, которые реально приносят трафик и должны попасть в карту соответствия.
- Неделя 2-3 Строим карту соответствия старых и новых URL, размечаем разделы по приоритету выкладки. Готовая карта редиректов и план очерёдности переноса разделов каталога.
- Неделя 3-4 Выкладываем первый, самый некритичный раздел, проверяем редиректы и индексацию силами другого специалиста. Подтверждённая на практике схема проверки, которую дальше применяем к остальным разделам.
- Неделя 4-6 Поочерёдно выкладываем оставшиеся разделы, фиксируем и донастраиваем адреса, которых не было в исходном списке. Весь каталог переехал, редиректы настроены, расхождения устранены по ходу, а не разом в конце.
- Неделя 6-9 Наблюдаем динамику трафика по неделям, точечно донастраиваем страницы с остаточными проблемами. Трафик возвращается к уровню до переезда, просадка закрыта раньше изначально ожидаемого срока.
Сроки — ориентир для планирования, а не обязательство: скорость зависит от ниши, конкуренции и состояния сайта.
Чек-лист: как готовить переезд каталога без лишней просадки трафика
Помогает не упустить то, что чаще всего решает исход переезда — а не техническую часть, которая обычно проходит спокойнее.
- Соберите список страниц не только из CMS, но и из статистики посещений
- Сверьте карту сайта с тем, что реально существует, а не с тем, что «должно быть»
- Постройте карту соответствия старых и новых адресов до начала выкладки
- Разбейте каталог на разделы и определите очерёдность переноса
- Не выкладывайте весь сайт разом — переносите частями
- Назначьте на проверку выложенного раздела не того, кто его выкладывал
- Заложите в план ожидаемый диапазон просадки трафика, а не точную цифру
- Отслеживайте трафик по неделям, а не только по итогу месяца
- Держите под рукой список страниц, которые не попали в исходную карту, для донастройки редиректов
Самое неприятное открытие в таких проектах — не ошибка в редиректе, а страница, которой вообще не было в исходном списке. Её никто не переносил специально, просто забыли, что она существует, а трафик на неё шёл. Поэтому карту адресов мы всегда сверяем со статистикой, а не только с тем, что видно в административной панели.
Первоисточник: Документация 1С-Битрикс ↗ — справочник по настройке редиректов и структуры каталога
Что в итоге
Переезд каталога на новую платформу — это в первую очередь работа с картой адресов, а не с кодом. Код почти всегда пишется быстрее, чем удаётся собрать полный и точный список страниц, которые реально нужно перенести.
Самая частая ошибка — выкладывать весь сайт разом, надеясь, что проверка после запуска всё покроет. На практике она покрывает то, что искали, а не то, что забыли. Именно пропущенные из исходного списка страницы, а не технические сбои, чаще всего становятся причиной затянувшейся просадки.
С чего начать: Начните с выгрузки полного списка страниц каталога из статистики посещений — это займёт день, но убережёт от главных потерь при переезде.
Вопросы и ответы
Сколько времени занимает переезд сайта?
Для каталога на несколько тысяч страниц — от месяца до полутора вместе с подготовкой. Сама выкладка занимает часы, всё остальное время уходит на сбор списка адресов, карту соответствия и поэтапную проверку.
Можно ли переехать без просадки трафика вообще?
На практике нет. Поисковой системе нужно обойти новые адреса, оценить страницы и пересчитать позиции — это занимает недели. Управлять можно глубиной просадки и сроком восстановления, но не самим фактом.
Что делать со страницами, которых на новом сайте не будет?
Настроить переадресацию на ближайшую по смыслу страницу — раздел, категорию, похожий товар. Если аналога нет совсем, честнее отдать код «страница удалена». Переадресация всего подряд на главную работает хуже, чем её отсутствие.
Нужно ли сохранять старые адреса страниц?
Если структура адресов была логичной — да, это сильно упрощает переезд. Если адреса были техническими и нечитаемыми, менять их стоит, но тогда карта соответствия становится обязательной и делать её нужно вручную.
Как понять, что переезд прошёл успешно?
По трём признакам за 6–8 недель: число страниц в индексе вернулось к прежнему, трафик вышел на исходный уровень, в панели вебмастера нет массовых ошибок обхода. Смотреть на позиции в первые две недели бессмысленно.
Кто должен отвечать за переезд — разработчики или подрядчик по продвижению?
Оба, и это нужно зафиксировать до начала. Разработка отвечает за перенос и работоспособность, продвижение — за карту адресов и контроль индекса. Проекты чаще всего ломаются именно там, где границы ответственности не проговорены.
Стоит ли переезжать в высокий сезон?
Нет. Просадка на месяц в пик спроса стоит дороже, чем ожидание. Оптимальное время — низкий сезон или период, когда есть запас в две-три недели на устранение неожиданностей.
Что делать, если после переезда трафик не вернулся через два месяца?
Проверять по порядку: все ли страницы в индексе, работает ли переадресация без цепочек, сохранились ли тексты и заголовки, не изменились ли адреса повторно. В большинстве случаев причина техническая и находится в первых двух пунктах.
Можно ли откатиться, если что-то пошло не так?
Технически да, если старая система сохранена и не отключена. Но откат — это второй переезд со своей просадкой, поэтому решение принимают только при серьёзных поломках, а не из-за временного падения показателей.
Игорь 12 лет занимается разработкой коммерческих сайтов: интернет-магазины, каталоги с обменом данными, корпоративные сайты и посадочные страницы под рекламу. Работал и на стороне подрядчика, и внутри компании-заказчика, поэтому хорошо понимает обе стороны конфликта «разработчики против маркетинга». В Media Monster руководит отделом разработки и отвечает за то, чтобы сайт создавался под продвижение, а не вопреки ему.
С какими задачами к нему приходят
Самая частая — «сделали редизайн, и просел трафик». Причины почти всегда одни и те же: сменились адреса страниц без переадресации, пропали тексты и заголовки, часть страниц закрылась от индексации при переносе с тестовой площадки. Вторая по частоте — «сайт не даёт добавить нужные страницы»: система управления не позволяет создавать разделы под спрос, и продвижение упирается в потолок платформы.
Отдельная категория — интеграции: наличие и цены должны приезжать из учётной системы, заявки — уходить в CRM, звонки — привязываться к источникам. Здесь основная работа не в коде, а в согласовании: какие данные передаются, как часто и что считать ошибкой обмена.
И, наконец, приходят с брошенными проектами: разработчик пропал, доступов нет, сайт работает, но менять его некому.
Как работает
Начинает не с макета, а со структуры. Пока не понятно, какие страницы нужны и под какой спрос, рисовать дизайн преждевременно: структура определяет и шаблоны, и объём работ, и способ вывода товаров. На проектах, где продвижением занимается другая команда, требует, чтобы карта страниц была согласована до старта вёрстки — иначе через полгода приходится переделывать.
Второй принцип — сдавать по чек-листу. После каждой выкладки проходится список технических проверок на боевом сайте: доступность страниц, файл robots.txt, метатеги, адреса, карта сайта, счётчики. Проверку делает не тот, кто выкладывал.
Третье — доступы принадлежат клиенту. Домен, хостинг, панель управления, репозиторий оформляются на владельца бизнеса с самого начала, а не «когда закончим».
Чего не делает
Не запускает сайт без плана переноса, если у проекта уже есть трафик: сопоставление старых и новых адресов делается до выкладки, а не после падения. Не строит каталог на решениях, которые не позволяют управлять адресами и метатегами страниц. Не берёт проект, где заказчик не готов выделить человека для сбора данных о товарах, — без характеристик и фотографий каталог всё равно не заработает, и срок сорвётся не по вине разработки.
В блоге
Пишет в рубрику «Разработка»: разборы переездов и редизайнов, чек-листы приёмки, интеграции с учётными системами, кейсы проектов. Все клиентские истории публикуются обезличенно — без названий, доменов и регионов.
Портрет автора — иллюстрация, а не фотография.
Материал подготовлен по редакционной политике блога: практика проектов, документация сервисов и проверка перед публикацией.
- Структура каталога, собранная из спроса, а не из выгрузки
- Ускорение загрузки первого экрана
- Интеграция форм с CRM без потери источника
- Редизайн без переноса структуры и адресов
- Тяжёлые изображения и скрипты «на всякий случай»
- Формы без передачи источника заявки
Что делать дальше
₽Посчитать экономикуСходится ли реклама при вашем чеке
?Задать вопросОтветим по вашей ситуации
Опишите задачу в двух словах — специалист ответит в Telegram, обычно в течение рабочего дня. Без презентаций и обязательств.
Написать в Telegram ↗✓Заявка на продвижениеОценить мой сайт
Бесплатно оценим текущее состояние и риски — до того, как вы начнёте что-то менять.
Поставьте оценку — она поможет редакции улучшать следующие разборы.
Обсуждение 17
Спросите, что осталось непонятным — автор материала отвечает в комментариях.
Читайте по теме
Максим Орлов6 мин · 1 июня 2026
Скорость сайта: что реально влияет на конверсию — иллюстрация к разделу «Почему гонка за баллами PageSpeed — дорогая и бесполезная»
Скорость сайта: что реально влияет на конверсию — иллюстрация к разделу «Core Web Vitals простыми словами: LCP, INP, CLS»
Скорость сайта: что реально влияет на конверсию — иллюстрация к разделу «Как мерить: PageSpeed Insights, Метрика и полевые данные»
Скорость сайта: что реально влияет на конверсию — иллюстрация к разделу «Три правки, которые дают 80% результата»
Игорь Волков7 мин · 2 августа 2026
Приёмка сайта у подрядчика: чек-лист, который защитит от типовых проблем — иллюстрация к разделу «Почему приёмка «на глаз» не работает»
Приёмка сайта у подрядчика: чек-лист, который защитит от типовых проблем — иллюстрация к разделу «Почему приёмка «на глаз» не работает»
Приёмка сайта у подрядчика: чек-лист, который защитит от типовых проблем — иллюстрация к разделу «Блок 1. Доступы и права — проверяется первым»
Приёмка сайта у подрядчика: чек-лист, который защитит от типовых проблем — иллюстрация к разделу «Блок 2. Техническая часть — проверяется в браузере»
Игорь Волков6 мин · 25 июля 2026
Сколько стоит разработка сайта и из чего складывается цена — иллюстрация к разделу «Почему за одно и то же называют разные цены»
Сколько стоит разработка сайта и из чего складывается цена — иллюстрация к разделу «Из чего состоит смета: разбор по строкам»
Сколько стоит разработка сайта и из чего складывается цена — иллюстрация к разделу «Из чего состоит смета: разбор по строкам»
Сколько стоит разработка сайта и из чего складывается цена — иллюстрация к разделу «Восемь вопросов, которые делают сметы сравнимыми»
