Миграция сайта на другую CMS без потери позиций: план переезда
Миграция сайта на другую CMS — это не «поставить новый движок и скопировать тексты». Для поисковика сайт на новой платформе выглядит как новый набор страниц: другой HTML, другие адреса, другая скорость ответа сервера. Если не объяснить роботу, что новая страница — продолжение старой, он заново оценивает её с нуля, и позиции, набранные годами, уходят за пару недель. Ниже — план переезда, по которому смена CMS проходит с временной просадкой в пределах нормы, а не с потерей половины трафика.
Статья про смену движка. Если вы меняете только сервер — это другая задача, о ней в материале про хостинг и переезд между провайдерами. Смену доменного имени разбираем отдельно в статье что такое домен; здесь её касаемся только там, где она совпадает со сменой CMS.
Когда миграция на другую CMS оправдана, а когда нет
Переезд на другой движок стоит денег и несёт риск для SEO, поэтому решение принимают по бизнес-причинам, а не «потому что Битрикс/WordPress лучше». Типичные оправданные поводы:
- Платформа упёрлась в потолок. Нужны фильтры каталога с посадочными страницами, личный кабинет, сложные цены, B2B-логика, а текущая CMS или конструктор этого не позволяют либо каждая доработка — костыль.
- Движок заброшен. Самописная система без документации, CMS без обновлений безопасности, модули, под которые больше никто не пишет. Каждая доработка дорожает, а уязвимости копятся.
- Нужны интеграции. Обмен с 1С, CRM, маркетплейсами, складом, которые на старой платформе либо не реализуются, либо работают нестабильно.
- Стоимость владения. Поддержку старого решения может вести один исполнитель на рынке, и бизнес от него зависит.
Плохие поводы: «трафик падает — наверное, виноват движок». Просадка позиций почти всегда связана с контентом, структурой, дублями или техническими ошибками, которые переедут вместе с сайтом. Сначала аудит, потом решение. Если сомневаетесь, что выбрать — доработку, редизайн или новый сайт, — это разобрано в статье как обновить устаревший сайт.
План переезда: этапы, риски и как их снизить
Последовательность одинакова независимо от направления — перенос сайта на Битрикс, с Joomla на WordPress, с конструктора на полноценную CMS или с самописного движка на фреймворк. Меняется только объём работ на каждом шаге.
| Этап | Главный риск | Как снизить |
|---|---|---|
| 1. Аудит текущего сайта | Не знаете, что именно переносить и что приносит трафик | Полный краулинг, выгрузка страниц с трафиком из Метрики за 12–24 месяца, снимок позиций, список внешних ссылок |
| 2. Карта URL | Страницы без пары на новом сайте → 404 | Таблица «старый URL → новый URL» по каждой странице, включая старые редиректы |
| 3. Перенос контента и данных | Потеря текстов, мета, товаров, заказов, пользователей | Скрипты импорта, сверка количества записей до и после, выборочная ручная проверка |
| 4. Дизайн и шаблон | Пропадают SEO-блоки, H1, хлебные крошки, микроразметка | Список обязательных элементов для каждого типа страниц в ТЗ |
| 5. Функционал и интеграции | Не работают формы, оплата, обмен с 1С | Сценарии тестирования на каждую функцию, тестовые платежи |
| 6. Тестовый стенд | Стенд попадает в индекс как дубль | Закрыть паролем (HTTP-авторизация), а не только robots.txt |
| 7. 301-редиректы | Цепочки, 302 вместо 301, массовый редирект на главную | Прогон всего списка старых URL краулером до запуска |
| 8. Запуск | Noindex и Disallow со стенда уезжают на прод | Чек-лист запуска, переключение в окно низкой нагрузки, бэкап старой версии |
| 9. Мониторинг | Ошибки замечают через месяц по падению заявок | Ежедневный контроль Вебмастера, Search Console, 404 в логах и целей Метрики первые 2–4 недели |
Аудит и карта URL — фундамент всей миграции
Первое, что делается до выбора шаблона и написания кода, — инвентаризация. Краулером (Screaming Frog, SiteAnalyzer или аналог) собирают все URL сайта с кодами ответа, title, description, H1, canonical. К этому добавляют три источника, которые краулер не видит:
- Страницы входа из поиска в Яндекс Метрике за 1–2 года — сюда попадают и те, на которые нет внутренних ссылок, но есть трафик.
- Страницы, на которые ведут внешние ссылки (Вебмастер → «Ссылки», Search Console → «Ссылки»).
- Действующие редиректы старого сайта — в .htaccess, конфиге nginx или модуле CMS. Их часто забывают, и адреса, которые когда-то уже переезжали, после смены CMS начинают отдавать 404.
Итог — таблица соответствия: старый адрес, новый адрес, тип страницы, трафик, наличие ссылок. Лучший вариант — сохранить URL один-к-одному: если новая CMS позволяет настроить ЧПУ по старым шаблонам, редиректы вообще не нужны. Там, где это невозможно (например, у конструкторов и WordPress разная логика адресов), каждый старый адрес ведёт 301-редиректом на максимально близкую по смыслу новую страницу.
Перенос контента и данных: товары, пользователи, заказы, SEO-мета
Для корпоративного сайта перенос — это тексты, изображения и мета-теги. Для интернет-магазина и портала данных намного больше, и именно здесь прячется основная трудоёмкость.
Контент и SEO-мета
Title, description, H1, тексты категорий, alt изображений переносятся постранично, а не «шаблоном по умолчанию». Если на старом сайте мета заполнены вручную на сотнях страниц, а на новом генерируются по шаблону, релевантность проседает сразу. Изображения переносят с сохранением или редиректом адресов, если они собирают трафик из поиска по картинкам.
Товары и каталог
Структура каталога, свойства, торговые предложения (цвета, размеры), цены, остатки, связанные товары. У разных CMS разные модели данных: в Битриксе инфоблоки и торговые предложения, в WooCommerce — вариативные товары и атрибуты, в OpenCart — опции. Перенос почти всегда требует скрипта-конвертера, а не штатного импорта CSV. После импорта сверяют количество товаров, разделов и свойств по обеим базам.
Заказы и история
Историю заказов переносят, если клиенты видят её в личном кабинете или она нужна для программы лояльности. Если учёт ведётся в 1С или CRM, иногда достаточно перенести только клиентов, а архив оставить в выгрузке.
Пользователи и пароли: нюанс с хэшами
Пароли в базе хранятся не открытым текстом, а в виде хэшей, и у каждой CMS свой формат. WordPress исторически использует phpass, а с версии 6.8 — bcrypt; Joomla — bcrypt; старые версии OpenCart — многократный SHA-1 с солью; у 1С-Битрикс собственная схема с солью. Перенести пароли «как есть» и ждать, что новая CMS их примет, нельзя. Рабочих варианта два:
- Ленивая миграция. Старые хэши импортируют в отдельное поле, на новом сайте пишут проверку по старому алгоритму. При первом успешном входе пароль перехэшируется в родной формат новой CMS. Пользователь ничего не замечает.
- Сброс паролей. Аккаунты переносят без паролей, всем рассылается письмо со ссылкой на установку нового. Проще технически, но часть клиентов потеряется — особенно в магазине с редкими покупками.
Дизайн, шаблон и функционал на новой CMS
Миграцию часто совмещают с редизайном. Это нормально, но каждое изменение шаблона — ещё один фактор, влияющий на ранжирование. Для каждого типа страниц (главная, категория, карточка товара, статья, контакты) в ТЗ фиксируют обязательные SEO-элементы: H1, текстовый блок, хлебные крошки, перелинковка, микроразметка Schema.org (Product, BreadcrumbList, Organization, FAQPage), canonical, пагинация.
Отдельно проверяют скорость. Новый движок с тяжёлым шаблоном и десятком плагинов легко оказывается медленнее старого самописного сайта. Ориентир — Core Web Vitals на мобильных (LCP, INP, CLS) и время ответа сервера не хуже, чем до переезда.
Интеграции: 1С, оплата, CRM
- 1С. Обмен по CommerceML поддерживают Битрикс (штатно), WordPress/WooCommerce и OpenCart (через модули). Но настройки сопоставления — какие свойства, склады и типы цен выгружаются — придётся собирать заново. Первую полную выгрузку делают на стенде, а не на проде. Подробно про связку учёта и сайта — на странице интеграции 1С и CRM.
- Оплата. Модуль ЮKassa, CloudPayments или Робокассы ставится под новую CMS, а в личном кабинете эквайринга меняются адреса уведомлений (callback/webhook). Проверяют не только оплату, но и возвраты и отправку чеков по 54-ФЗ.
- Формы и аналитика. Отправка заявок в CRM и на почту, счётчик Метрики, цели, электронная коммерция, коллтрекинг. Цели в Метрике привязаны к адресам и идентификаторам элементов — после смены шаблона они молча перестают срабатывать.
Тестовый стенд и 301-редиректы по карте
Новый сайт собирают на отдельном поддомене или сервере. Его закрывают HTTP-авторизацией: запрет в robots.txt не гарантирует, что страницы не попадут в индекс, если на стенд где-то появится ссылка. На стенде проходят все сценарии: регистрация, вход по старому паролю, корзина, оплата, формы, поиск, фильтры.
Затем по таблице соответствия настраивают редиректы. Правила:
- Только 301 (постоянный), не 302. При временном редиректе поисковики считают старый адрес основным и могут оставить в выдаче его, а не новую страницу.
- Один шаг: старый URL сразу ведёт на финальный новый. Цепочки вида «старый → промежуточный → новый» переписывают, включая редиректы прошлых переездов.
- Один-к-одному: страница товара — на тот же товар, категория — на ту же категорию. Если аналога нет — на ближайший раздел, а не на главную.
- Для удалённых без замены страниц, на которые нет ни трафика, ни ссылок, допустим код 404 или 410.
Перед запуском весь список старых адресов прогоняют краулером в режиме списка: каждый должен отдать 301 и привести на страницу с кодом 200. Всё, что даёт 404, цепочку или редирект на главную, — дорабатывается до запуска.
Запуск и мониторинг в Вебмастере и Search Console
Переключение планируют на начало рабочей недели и вне сезона продаж: не в пятницу вечером и не в декабре для магазина новогодних товаров. Порядок запуска:
- Полный бэкап старого сайта — файлы и база — с возможностью быстро откатиться.
- Финальная синхронизация данных: заказы и регистрации, появившиеся на старом сайте за время разработки.
- Выкладка новой версии, снятие HTTP-авторизации, проверка robots.txt, мета robots и заголовка X-Robots-Tag.
- Включение редиректов, генерация sitemap.xml и отправка её в Вебмастер и Search Console.
- Проверка счётчиков, целей, форм, оплаты и обмена с 1С на живом сайте.
Первые 2–4 недели сайт смотрят ежедневно: число страниц в поиске, ошибки сканирования, всплески 404 в логах сервера, позиции по «точке ноль», конверсии в Метрике. Временная просадка на несколько недель — нормальная часть процесса, пока роботы обходят сайт и склеивают старые адреса с новыми. Тревожный сигнал — страницы массово выпадают из индекса или трафик не начинает восстанавливаться через 3–4 недели. Итоговую оценку результата делают не раньше чем через 3 месяца.
Сроки и стоимость миграции сайта на другую CMS
Цена зависит от объёма данных, а не от числа страниц как таковых. Лендинг на 10 экранов переезжает быстро. Магазин на 20 000 товаров с торговыми предложениями, личными кабинетами и обменом с 1С — это проект на недели или месяцы, сопоставимый по трудоёмкости с частью новой разработки.
| Задача | Ориентир по цене | Что влияет |
|---|---|---|
| Перенос на другой хостинг без смены движка | от 5 000 ₽; с базой и интеграциями — от 15 000 ₽ | Объём, почта, SSL, DNS |
| Смена домена с 301-редиректами | от 10 000 ₽ | Число URL, склейка, настройка Вебмастера |
| Миграция на другую CMS | от 35 000 ₽, считается по аудиту | Объём каталога и данных, пользователи, интеграции, редизайн |
Цены — ориентиры для простых случаев; итоговая сумма зависит от объёма данных, количества интеграций и того, совмещается ли переезд с редизайном и новым функционалом. Её фиксируют после аудита. Состав работ и порядок расчёта — на странице услуги перенос сайта без потери позиций.
По срокам основную часть времени занимают подготовка карты URL, конвертация данных и тестирование, а не сама выкладка. Если подрядчик оценивает переезд магазина с 1С в «пару дней», скорее всего, в оценку не вошли редиректы, пользователи и проверка интеграций.
Типичные ошибки при переносе сайта на другую CMS
- Массовый 301 на главную. Все старые адреса ведут на главную страницу. Google прямо предупреждает, что такие редиректы могут расцениваться как soft 404, Яндекс советует их избегать — позиции по запросам на внутренние страницы теряются.
- Потеря страниц. Карту строят только по текущему меню и sitemap, забывая про страницы фильтров, теги, старые статьи и адреса из прошлых редиректов, на которые идут ссылки и трафик.
- Noindex на проде. Мета robots noindex, Disallow: / в robots.txt или X-Robots-Tag со стенда уезжают на рабочий сайт. Через неделю страницы начинают выпадать из поиска.
- Мета по шаблону вместо ручных. Вручную прописанные title и description заменяются автогенерацией, тексты категорий теряются при импорте.
- Дубли адресов. Новая CMS отдаёт одну страницу по нескольким URL: со слешем и без, с index.php, с параметрами сортировки. Без canonical и редиректов на основное зеркало появляются дубли.
- Сломанная аналитика. Цели не срабатывают, и падение заявок принимают за падение трафика — или наоборот.
- Переезд одновременно со сменой домена и полной переделкой структуры. Чем больше изменений за раз, тем сложнее понять причину просадки. Если есть выбор, домен меняют отдельным этапом.
Чек-лист миграции сайта
- Зафиксирована бизнес-причина переезда и выбрана целевая CMS под задачи, а не «по моде».
- Собран полный список URL: краулинг, страницы входа из Метрики, внешние ссылки, старые редиректы.
- Сняты позиции, трафик и конверсии — «точка ноль».
- Составлена таблица «старый URL → новый URL», где возможно, адреса сохранены один-к-одному.
- Перенесены тексты, title, description, H1, alt, микроразметка; количество товаров и записей сверено.
- Выбрана схема переноса паролей — ленивая миграция хэшей или сброс.
- Интеграции (1С, оплата, CRM, формы) проверены на стенде, callback-адреса обновлены.
- Стенд закрыт паролем, скорость не хуже старой версии.
- Все старые URL проверены краулером: 301 → 200, без цепочек и редиректов на главную.
- На проде нет noindex и Disallow, sitemap.xml отправлен в Вебмастер и Search Console.
- Счётчики и цели работают, бэкап старого сайта сохранён.
- Назначен ответственный за ежедневный мониторинг первые 2–4 недели.
Итог
Миграция сайта на другую CMS — управляемый проект, если относиться к нему как к SEO-задаче с первого дня, а не как к копированию файлов. Основные деньги и время уходят на подготовку: аудит, карту URL, конвертацию данных и тест. Сама выкладка занимает часы. Экономить стоит на чём угодно, кроме карты редиректов и проверки стенда: именно там теряются позиции, которые потом возвращают месяцами.