Мы видели много историй, когда после переезда на новую CMS трафик из поиска падал вдвое, а восстанавливался месяцами. Причём новый сайт был лучше старого: быстрее, удобнее, красивее. Проблема была не в новом движке, а в том, как прошёл переезд. Потерялись страницы, сменились адреса, исчезли мета-теги, а поисковые системы восприняли всё это как появление нового, незнакомого сайта.
Перенос сайта на новую платформу — это не копирование файлов, а проект со своей методологией. Расскажем, как мы его проводим и на что обращаем внимание на каждом этапе.
Когда переезд действительно нужен
Сначала стоит убедиться, что переезд оправдан. Типичные причины, по которым к нам приходят с такой задачей:
- текущая CMS больше не поддерживается разработчиками и не получает обновлений безопасности;
- платформа не позволяет реализовать нужную функциональность или делает это слишком дорого;
- сайт сделан на конструкторе, который ограничивает SEO, скорость или интеграции;
- самописный движок, разработчик которого недоступен, а код никто не может поддерживать;
- стоимость лицензии и поддержки текущей системы перестала быть оправданной.
Иногда при ближайшем рассмотрении оказывается, что проблемы решаются доработкой без смены платформы. Поэтому мы начинаем с анализа текущего сайта и честно говорим, если переезд не нужен.
Что можно потерять при переезде
Полезно заранее понимать, что именно находится под угрозой:
- Позиции и трафик из поиска. Поисковые системы ранжируют конкретные страницы по конкретным адресам. Сменился адрес без перенаправления — страница для поисковика исчезла.
- Контент. Тексты, изображения, файлы, которые не были перенесены или перенеслись с ошибками.
- Данные. Пользователи, заказы, история покупок, отзывы, подписчики.
- Функциональность. Мелкие функции, о которых все забыли, но которыми пользуются клиенты: калькулятор, сравнение товаров, фильтр.
- Интеграции. Обмен с CRM, учётной системой, платёжными сервисами, службами доставки.
- Аналитика. Счётчики, цели, история данных.
Каждый из этих пунктов требует отдельной работы. Пропустить можно любой.
Этап 1. Инвентаризация старого сайта
Прежде чем строить новое, нужно точно знать, что есть сейчас. Мы делаем полный слепок старого сайта.
Все URL
Сканируем сайт специальным краулером, выгружаем адреса из sitemap, из панелей вебмастеров и из систем аналитики. Каждый источник показывает свою часть картины: краулер найдёт то, на что есть ссылки, аналитика покажет страницы, на которые приходит трафик, панели вебмастеров — то, что проиндексировано. Объединяем всё в одну таблицу.
SEO-данные по каждой странице
Title, description, заголовки H1, канонические адреса, микроразметка. Отдельно фиксируем, какие страницы приносят больше всего трафика и по каким запросам они ранжируются. Это наши приоритеты — их потеря будет самой болезненной.
Функциональность
Проходим по сайту как пользователь и записываем всё, что он может сделать: все формы, фильтры, калькуляторы, личный кабинет, поиск. Опрашиваем сотрудников заказчика: чем они пользуются в админке, какие отчёты выгружают.
Внешние ссылки
Какие страницы сайта имеют ссылки с других ресурсов. Эти ссылки — ценный актив для продвижения, и их нельзя терять.
Этап 2. Карта соответствия адресов
Это ключевой документ всего переезда. Таблица, где для каждого старого URL указан новый.
Идеальный вариант — сохранить адреса без изменений. Если структура URL на новой платформе может быть настроена так же, как на старой, — это лучший путь, потому что для поисковых систем ничего не меняется. Но часто это невозможно или нежелательно: старые адреса бывают вида /index.php?id=123&cat=5, и переезд — хороший повод сделать их понятными.
Если адреса меняются, для каждого старого URL определяем новый:
- страница переносится — указываем её новый адрес;
- страница объединяется с другой — указываем адрес той, куда объединили;
- страница удаляется — указываем наиболее релевантную замену, например родительский раздел.
Важно: не перенаправлять всё подряд на главную. Поисковые системы воспринимают такие массовые перенаправления как ошибку, и ценность старых страниц теряется. Каждая страница должна вести на максимально близкую по смыслу.
Для больших сайтов с тысячами товаров карта составляется не вручную, а по правилам: например, все карточки товаров переходят по шаблону с сохранением артикула в адресе. Правила проверяем на выборке.
Этап 3. Перенос контента и данных
Способ переноса зависит от объёма. Десять страниц проще перенести вручную. Тысячи товаров с характеристиками, ценами и фотографиями — только скриптом.
Мы пишем скрипты миграции, которые выгружают данные из старой базы, преобразуют их в структуру новой платформы и загружают. Что важно учесть:
- Изображения и файлы. Переносятся вместе с привязками к товарам и страницам. Ссылки на изображения внутри текстов переписываются на новые пути.
- Внутренние ссылки в контенте. Если в текстах статей есть ссылки на другие страницы сайта, они должны указывать на новые адреса, а не идти через перенаправление.
- Пользователи и пароли. Пароли хранятся в зашифрованном виде, и алгоритмы у разных CMS отличаются. Нужно либо реализовать поддержку старого алгоритма, либо предложить пользователям сменить пароль при первом входе.
- Заказы и история. Для магазинов — перенос истории заказов, чтобы клиенты видели её в личном кабинете, а менеджеры — в админке.
- SEO-поля. Title, description, H1 переносятся для каждой страницы. Это легко забыть, и тогда новый движок сгенерирует их автоматически — обычно хуже, чем было.
Миграцию прогоняем несколько раз на тестовом стенде, каждый раз проверяя результат и исправляя ошибки скрипта.
Этап 4. Тестирование до запуска
Новый сайт полностью собран на тестовом сервере, закрытом от индексации. Теперь проверяем всё:
- Перенаправления. Прогоняем весь список старых URL и убеждаемся, что каждый ведёт на правильную новую страницу с кодом 301 и без цепочек из нескольких перенаправлений.
- Контент. Выборочно сравниваем страницы старого и нового сайта. Особенно внимательно — самые трафиковые.
- SEO-элементы. Мета-теги, заголовки, канонические адреса, микроразметка, robots.txt, sitemap.
- Функциональность. Все формы, корзина, оформление заказа, оплата, личный кабинет, поиск, фильтры — по списку из инвентаризации.
- Интеграции. Тестовые заявки и заказы доходят в CRM и учётную систему.
- Аналитика. Счётчики установлены, цели срабатывают.
- Скорость и адаптивность. Новый сайт должен быть не медленнее старого.
Этап 5. Запуск и первые недели
Запуск планируем на время минимальной активности и не перед выходными, чтобы команда была на связи, если что-то пойдёт не так. Порядок такой:
- финальная синхронизация данных, накопившихся на старом сайте с момента последней миграции;
- переключение домена на новый сайт;
- снятие запрета индексации — частая и очень обидная ошибка, когда сайт запускают с закрытым от поисковиков robots.txt;
- повторная проверка перенаправлений уже на рабочем домене;
- отправка нового sitemap в панели вебмастеров.
Дальше — мониторинг. В первые недели ежедневно смотрим на ошибки сканирования в панелях вебмастеров, на страницы с кодом 404 в логах, на динамику трафика и позиций. Небольшое временное колебание позиций после переезда — нормально, поисковым системам нужно время на переиндексацию. Но если какая-то группа страниц резко просела, это сигнал искать проблему.
Старый сайт не удаляем ещё как минимум месяц — его копия может понадобиться для сверки. Перенаправления оставляем навсегда или, по крайней мере, на очень долгий срок. Сопровождение переезда и последующую оптимизацию удобно проводить вместе со специалистами по SEO-продвижению.
Вывод
Перенос сайта на новый движок без потерь возможен, но требует методичной работы. Полная инвентаризация старого сайта, точная карта соответствия адресов, аккуратная миграция контента и данных с сохранением SEO-полей, тщательное тестирование на закрытом стенде и внимательный мониторинг после запуска — вот из чего складывается успешный переезд. Экономия на любом из этих этапов почти всегда оборачивается потерей трафика, восстановление которого обходится дороже. Если вы планируете смену платформы, начните с аудита текущего сайта — он станет основой для всего проекта.
