Главная › Новости

Смена CMS без гаданий: контрольная карта для технической и SEO-команды

Опубликовано: 26.05.2026

Переезд на другую систему управления контентом редко бывает спонтанным решением. Обычно к этому моменту накоплен ворох проблем: старая платформа тормозит, разработчики ушли, расширения больше не обновляются, а бизнес хочет функционал, который просто невозможно реализовать в текущих рамках. Но как бы ни хотелось поскорее закрыть эту страницу, сам процесс миграции — не та вещь, которую стоит делать на интуиции.

Ниже — практическая карта действий, которая помогает не упустить критические моменты. Она не привязана к конкретным платформам и работает независимо от того, переезжают ли на готовую SaaS-систему или разворачивают собственное решение.

Что сделать до написания строки кода

Самая частая ошибка — начать техническую миграцию, не разобравшись с тем, что именно нужно перенести. Звучит очевидно, но на практике часто оказывается, что nobody knows: контент-менеджеры уверены, что всё в порядке, SEO-специалист свалился в проект месяц назад, а разработчики смотрели на базу данных два года назад.

На этом этапе нужно зафиксировать три вещи:

• Полный список URL — не только тех, что в карте сайта, но и тех, что индексируются реально. Выгрузка из Google Search Console и другие панели вебмастерова покажет страницы, которых уже нет в навигации, но поисковик о них помнит.
• Структуру мета-данных — title, description, canonical, hreflang. Если на старой CMS они генерировались по какому-то шаблону, этот шаблон нужно задокументировать.
• Микроразметку — что реализовано, какие типы schema.org используются, есть ли ошибки валидации прямо сейчас. Часто оказывается, что разметка кривая, но поисковик к ней привык — и исправление «по правилам» вызывает просадку.

Отдельно стоит выгрузить логи сервера за последний месяц. Они покажут реальную частоту обхода ботов и те страницы, которые поисковики запрашивают, но получают 404 даже сейчас. Это скрытые проблемы, которые при переезде только усугубятся.

URL-структура и редиректы — фундамент миграции

Первый вопрос, который нужно решить: меняются ли URL. Если нет — задача сильно упрощается, но это редкий случай. Чаще всего новая CMS формирует адреса иначе: где-то появляются лишние категории, где-то меняется транслитерация, где-то добавляются числовые идентификаторы.

Если URL меняются, единственный надёжный путь — составить таблицу соответствия «старый адрес — новый адрес» для каждой страницы. Не правилами, не регулярными выражениями, а построчно. Да, это скучно. Да, на десяти тысячах страниц это занимает время. Но любая автоматизация на этом этапе — это ставка на то, что логика старой и новой системы совпадает. Обычно они не совпадают.

Типичные ловушки при настройке редиректов:

• Цепочки из нескольких 301-й редиректов вместо одного прямого.
• Редирект на страницу с другим смыслом («купить ноутбук» → «каталог электроники»).
• Отсутствие редиректов для URL с параметрами (UTM-метки, сортировки, фильтры).
• Слабые страницы, которые лучше редиректить в 410 (Gone), чем тащить на новый сайт.

Каждый из этих пунктов способен съесть часть переданного веса или создать бесконечные циклы, которые боты не любят.

Технические проверки нового сайта

Когда контент перенесён, а редиректы настроены, начинается этап, который часто недооценивают — собственно тестирование нового сайта. Причём тестировать нужно не «открывается ли главная», а конкретные параметры, влияющие на индексацию.

Скорость и рендеринг

Новая CMS может заметно изменить техническую реализацию сайта. Может измениться порядок загрузки ресурсов, появиться дополнительные скрипты аналитики, по-другому работать кэширование. Нужно сравнить Core Web Vitals старого и нового сайта не в лабораторных условиях, а по реальным данным из CrUX — если старый сайт уже там присутствует.

Отдельная история — серверный рендеринг. Если старый сайт отдавал готовый HTML, а новый полагается на клиентский JavaScript, нужно убедиться, что поисковый бот видит контент. Проверка через URL Inspection Tool в Google Search Console и «Проверку ответа сервера» в Вебмастере обязательна до любого запуска. Перед переносом полезен трекер позиций Google, но его отчёт нужно сохранить вместе со списком URL, запросов и датой измерения.

Индексируемость

Нужно проверить, что:

• Файл robots.txt корректен и не блокирует нужные разделы.
• Карта сайта генерируется с правильными URL и актуальными датами.
• Мета-теги robots отсутствуют там, где не должны быть, и присутствуют там, где нужны.
• Нет случайных noindex на страницах пагинации, фильтров или карточек товаров.

Последний пункт — классика: разработчик ставит noindex на тестовые страницы, забывает убрать перед релизом, и через неделю половина каталога выпадает из индекса.

Контент: не только тексты

При миграции легко потерять неочевидные элементы контента. Тексты обычно переносят — они в базе данных, их видно. А вот что часто пропадает:

• Альтернативные тексты изображений — при массовом импорте медиафайлов они часто сбрасываются.
• Внутренние ссылки — в текстах могут быть абсолютные URL со старым доменом или относительные пути, которые на новой CMS разрешаются иначе.
• Файлы — PDF, DOCX, изображения, которые прикреплены к страницам или лежат в скрытых разделах.
• Пользовательский контент — комментарии, отзывы, вопросы. Иногда бизнес решает «не переносить комментарии, начнём с чистого листа». Это решение, но оно должно быть осознанным, а не случайным.

Хорошая практика — сделать выборочную проверку: взять 20–30 случайных страниц старого сайта и сравнить их с новыми поэлементно. Не по скриншоту, а по исходному коду.

Пост-запуск: первые недели решают всё

День запуска — это начало периода контроля. Дальше нужно регулярно проверять несколько ключевых показателей:

Если проблемы обнаружились, реакция должна быть быстрой. Поисковики прощают ошибки при переезде, но только если они исправляются. Редирект, который не работал неделю — это потерянный вес. Редирект, который починили за день — это незначительный сбой.

Динамика после смены CMS зависит от масштаба изменений и частоты обхода. При устойчивом падении следует проверить редиректы, индексируемость, canonical, внутренние ссылки, производительность и фактические изменения контента.

Документирование как часть процесса

Последний элемент, о котором редко вспоминают заранее, — фиксация всех решений. Почему именно такие URL? Почему эти страницы решили не переносить? Почему выбрали 301 вместо 410 для определённой группы? Через полгода никто не вспомнит контекст, а если придётся разбирать просадку, отсутствие истории решений превратит диагностику в гадание на кофейной гуще.

Простая таблица с датой, решением и обоснованием — это не бюрократия, а страховка. Особенно в командных проектах, где к моменту пост-запускного анализа может уже не быть половины участников миграции.

Смена CMS — управляемый риск. Контрольная карта не исключает колебаний, но делает диагностику последовательной и помогает быстрее локализовать подтверждённую проблему.