Переезд на новую CMS без просадки: чек-лист SEO-миграции для бизнеса

Снаружи переезд сайта на новый движок выглядит как технический апгрейд: быстрее админка, удобнее каталог, больше интеграций, меньше ручной рутины. Но для поисковых систем это не «обновление сайта», а часто почти новый объект со сломанной памятью: меняются URL, шаблоны, внутренняя перелинковка, рендеринг, sitemap, canonical, логика фильтров и ответы сервера.

В результате бизнес, который хотел просто сменить CMS, внезапно теряет 60–90% SEO-трафика, а вместе с ним — лиды, выручку и прогноз продаж. Google отдельно рекомендует при переезде с изменением URL использовать серверные постоянные редиректы, тестировать их заранее и мониторить переход индексации со старых URL на новые; Яндекс прямо предупреждает, что CMS сама по себе часто создает дубли, которые могут вытеснить из поиска важные посадочные страницы.

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

Зачем менять CMS и почему разработчики молчат о SEO-рисках

Главные триггеры смены движка

Обычно бизнес решает перенести сайт на другой движок по понятным причинам: накопился технический долг, старая CMS медленная, сложно внедрять интеграции с CRM/ERP, тормозят доработки, есть ограничения по безопасности, не хватает гибкости в eCommerce-процессах. Это нормальный этап взросления продукта.

Проблема в другом: разработчики мыслят сущностями «шаблон», «компонент», «база», «API», а поисковая система — сущностями «URL», «код ответа», «канонический документ», «дубль», «сигнал качества», «страница для обхода». Когда команда обсуждает, как перенести на CMS новый каталог, она почти никогда автоматически не обсуждает, что станет с уже проиндексированными URL, параметрами фильтрации, страницами пагинации и сниппетами.

Что такое SEO-катастрофа при смене CMS

SEO-катастрофа — это не обязательно падение «в ноль» в день релиза. Чаще это каскад:

• часть URL стала отдавать 404;
• часть старых адресов ушла в нерелевантные 301;
• фильтры перестали генерировать ценные НЧ-страницы;
• canonical начал указывать на категории вместо карточек;
• CSR-фронт перестал корректно отдавать содержимое в рендере;
• sitemap.xml автоматически собрал не те страницы;
• robots.txt закрыл нужное или не закрыл мусор.

Google описывает обработку JavaScript-сайтов как цепочку crawl → render → index и прямо указывает, что страницы на JavaScript зависят от отдельной фазы рендеринга; если контент и ссылки появляются только после выполнения JS, а реализация сделана плохо, индексация и обнаружение URL страдают Google for Developers. Для бизнеса это переводится просто: вы можете идеально «запустить» новый сайт для людей и одновременно сломать его для роботов.

Фаза 0. Что необходимо сделать на старой CMS до переноса

Это самая недооцененная часть проекта. Если до старта не зафиксировать текущую SEO-модель, дальше вы будете переносить не актив, а догадки о нём.

Полная инвентаризация

До того как перенос сайта на CMS станет задачей разработчиков, он должен стать задачей аналитиков. На старой CMS нужно собрать:

• полный список существующих URL;
• страницы, реально находящиеся в индексе;
• посадочные с органическим трафиком;
• страницы, дающие лиды и транзакции;
• категории, карточки, статьи, теги, фильтры, пагинацию;
• служебные URL, которые не должны переехать в индекс.

Яндекс отдельно предупреждает: дубли расходуют ресурсы обхода, замедляют индексацию новых страниц и могут привести к тому, что из поиска выпадет важная посадочная. Поэтому инвентаризация — это не «сохранить список страниц», а понять, какие URL являются активом, а какие — балластом.

Бэкап SEO-слоя, а не только базы данных

Типичная ошибка — думать, что резервная копия сайта равна SEO-бэкапу. Это не так. Перед тем как перенести сайт на новую CMS, нужно отдельно сохранить:

• Title, Description, H1;
• canonical;
• robots meta;
• Schema.org / Open Graph;
• тексты и блоки FAQ;
• SEO-тексты категорий;
• хлебные крошки;
• структуру тегирования и ЧПУ;
• шаблоны фильтров;
• текущие sitemap.xml и robots.txt.

Google рекомендует сохранять корректные title, meta description, canonical и статус-коды даже на JavaScript-сайтах; Яндекс требует включать в sitemap канонические URL и отдельно разруливать параметрические дубли.

Фиксация точки «A»

До миграции надо зафиксировать:

• видимость по кластерам запросов;
• органический трафик;
• лиды / транзакции из SEO;
• CR по ключевым типам страниц;
• выручку из органики;
• топовые URL по трафику и по деньгам.

Именно здесь полезно показать бизнесу формулу риска:
Убыток от просадки=Органический трафик/мес×Конверсия×Средний чек×Процент падения×Время восстановления

Если сайт получает 50 000 SEO-сеансов в месяц, конвертирует 1,8%, средний чек — 18 000 ₽, падение составило 70%, а восстановление заняло 3 месяца, убыток легко уходит в миллионы рублей. И это без учета пожизненной ценности клиента и влияния на отдел продаж.

Если вы не знаете, как перенести старый сайт на новый движок, команда Калинин Студио может до старта проекта проверить структуру текущего сайта, выявить страницы-активы и заранее показать зоны риска миграции.

Фаза 1. Проектирование структуры и правила переезда на новую CMS

Вот здесь решается, будет ли переезд сайта на новый движок управляемым или превратится в дорогой эксперимент.

Сохранение URL-структуры vs тотальный 301-редирект

Идеальный сценарий — сохранить старые URL без изменений. Если это невозможно, нужна строгая матрица переадресации, а не «массовый редирект на похожие разделы». Google рекомендует постоянные серверные редиректы 301/308, избегать цепочек и по возможности вести сразу в конечный URL.

Правило простое:

• старая категория → новая эквивалентная категория;
• старая карточка → новая карточка того же товара;
• старая статья → новая статья;
• удаленная страница без замены → 410/404 по ситуации, а не редирект на главную.

Редирект «всё на главную» — это почти всегда потеря релевантности и веса.

Генерация Redirect Map

Профессиональный перенос на CMS невозможен без Redirect Map. Это таблица соответствий, где для каждого старого URL определён новый адрес, тип редиректа и логика обработки исключений.

Минимум, что должно быть в матрице:

Особенно опасна потеря фильтров. Если при миграции каталога обнулить GET-параметры и SEO-страницы фасетов, бизнес за один релиз может потерять сотни НЧ-посадочных, которые раньше стабильно приносили лиды.

Синхронизация логики тегирования и ЧПУ

Когда компания хочет ответить на вопрос «как правильно перенести сайт?», она часто думает о дизайне и каталоге, но забывает о логике генерации URL новой CMS:

• будет ли конечный слэш;
• останутся ли старые транслитерации;
• как CMS генерирует URL категорий и карточек;
• изменятся ли суффиксы .html, /catalog/, /product/;
• как формируются страницы тегов;
• как обрабатываются дубликаты с UTM и сервисными параметрами.

Яндекс указывает, что каноникал — это рекомендация, а не приказ: если контент заметно отличается, робот может проигнорировать canonical; кроме того, для параметрических URL стоит отдельно использовать Clean-param или другие меры. Это особенно критично, если вы решили перенести сайт на другой движок и одновременно изменить ЧПУ.

Перед тем как сменить CMS, закажите в Калинин Студио проектирование матрицы редиректов, структуры URL и правил каноникализации. Это дешевле, чем восстанавливать трафик после релиза +7 (999) 770-30-18.

Фаза 2. Тестирование на Dev/Staging-сервере до переноса домена

Защита тестового контура от индексации

Staging должен быть закрыт не только robots.txt. Яндекс прямо пишет, что страницы, закрытые robots.txt, всё равно могут участвовать в поиске, а для удаления из поиска нужны noindex или корректная недоступность для робота. Поэтому безопасный вариант для staging-environment — Basic Auth плюс проверка мета-тегов и заголовков.

Google отдельно отмечает, что страницы за логином должны отдавать осмысленные HTTP-коды, например 401, а не маскироваться под обычные 200.

Сквозная проверка кодов ответа, canonical, hreflang и Schema.org

Перед тем как перенести на CMS продуктив, нужно прогнать технический аудит staging:

• все шаблонные страницы отдают 200 OK;
• старые URL на тестовом контуре корректно маппятся в новую структуру;
• 301 не создают цепочек;
• отсутствуют ложные soft 404;
• canonical стоят на самих себе или на целевых канонических URL;
• hreflang непротиворечив;
• микроразметка не потерялась при смене шаблонов.

Это особенно важно для JavaScript-проектов и headless-архитектур. Google использует рендеринг для понимания JS-страниц и рекомендует использовать History API, корректные ссылки, каноникализацию и статус-коды.

Контроль производительности и рендеринга

В 2026 году разговор о миграции без Core Web Vitals выглядит устаревшим. Google определяет CWV как набор метрик реального пользовательского опыта и рекомендует держать LCP до 2,5 сек, INP менее 200 мс, CLS менее 0,1.

На практике это означает:

• нельзя переносить сайт на «современный» фронт, который красив в демо, но тяжел в production;
• нельзя без проверки уводить проект в CSR, если SSR/SSG давали более предсказуемую индексируемость;
• нельзя увеличивать JS-бандлы, блокирующие рендер;
• нельзя ломать стабильность интерфейса в карточке, корзине и checkout.

Для eCommerce это уже не только SEO, но и конверсия. Исследования по электронной коммерции показывают, что характеристики сайта и пользовательского опыта напрямую связаны с конверсионной результативностью, а ухудшение производительности влияет на продажи и поведение пользователей.

Фаза 3. День «Д»: переключение DNS, бесшовный перенос и софт-старт

Технический регламент переключения

В день релиза важен не героизм, а дисциплина:

• заморозить контентные изменения на старом сайте;
• проверить актуальность Redirect Map;
• убедиться, что robots.txt и sitemap боевые, а не тестовые;
• перепроверить canonical на ключевых шаблонах;
• выполнить DNS cutover;
• сделать выборочную проверку топ-URL;
• контролировать серверные логи и ошибки первые 72 часа.

Google советует тестировать редиректы заранее, мониторить пользовательский и краулерный трафик на старом и новом сайте, а также отправлять карты сайта со старыми и новыми URL, чтобы отслеживать переход индексации.

Что перепроверить в Яндекс.Вебмастере и Google Search Console

Сразу после запуска:

• отправить актуальный sitemap.xml;
• проверить доступность robots.txt;
• выборочно прогнать ключевые URL через инспекцию;
• убедиться, что старые URL уходят в правильные 301;
• отследить ошибки обхода;
• проверить, не полезли ли в индекс staging-домены, дубль-страницы, сортировки и внутренний поиск.

Яндекс рекомендует использовать sitemap только с каноническими страницами и отдельно диагностировать дубли в Webmaster.

Мониторинг после миграции: как понять, что перенос прошел успешно

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

• ежедневно растут 404 и soft 404;
• в индекс массово попадают дубли;
• sitemap содержит неканонические адреса;
• часть шаблонов отдает пустой HTML до рендера;
• обрушился трафик именно на коммерческие разделы;
• просела конверсия из-за изменений корзины, checkout, доверительных блоков.

В контексте качества Google полезно помнить: системы ранжирования стремятся поощрять helpful content, сильный page experience и сигналы доверия; в E-E-A-T наиболее важен. Если после миграции вы упростили контент, убрали признаки экспертизы, скрыли контактные и коммерческие элементы, сломали отзывы, доставку, FAQ и карточки автора — это тоже часть проблемы, а не только «техническое SEO».

Ориентир хорошей миграции — когда:

• индекс постепенно переезжает со старых URL на новые;
• топовые страницы сохраняют релевантность;
• краулинг не уходит в мусор;
• трафик стабилизируется без системного падения конверсии;
• команда понимает, какие отклонения допустимы, а какие требуют немедленного отката или фикса.

Заключение

Смена CMS — это не задача формата «поднять новый шаблон и перелить базу». Это операция по переносу цифрового актива, который поисковые системы годами учились понимать и оценивать. Любое изменение URL-логики, шаблонов, рендеринга, тегов, карты сайта, параметров фильтрации и коммерческих элементов меняет то, как этот актив видят Яндекс и Google.

Поэтому вопрос для бизнеса должен звучать не «можем ли мы перенести сайт на другой движок?», а «как сделать это без потери накопленного поискового капитала?». Правильный ответ — только через регламент: инвентаризация, проектирование, staging-аудит, Redirect Map, тестирование, контролируемый релиз и пост-мониторинг.

Если вы планируете перенос сайта на CMS, команда Калинин Студио подключается до старта разработки: фиксирует точку A, проектирует структуру, собирает Redirect Map, проверяет staging, сопровождает день релиза и мониторит восстановление после запуска. Это не «дополнительная услуга», а страховка выручки в момент, когда цена ошибки максимальна.

Часто задаваемые вопросы