Перенос сайта на новую CMS

Миграция CMS без потери SEO — одна из самых рискованных операций в жизни проекта: при неаккуратной подготовке теряется 30–50% органического трафика на 2–3 месяца, а часть позиций не восстанавливается без отдельной работы по наращиванию ссылок и контенту. При продвижении сайтов через смену движка задача SEO-команды — построить переезд на новую CMS так, чтобы поисковые системы классифицировали его как технический переход внутри одной системы, без сигналов о создании нового сайта. Этот гайд собирает весь цикл от предмиграционного аудита до постмиграционного мониторинга, с акцентом на белорусские проекты под Google и Яндекс.

Когда нужна миграция CMS

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

• Текущая CMS достигла EOL. Magento 1, Joomla 1.5/2.5, Drupal 7, WordPress на PHP 5.x — платформы, для которых прекращены обновления безопасности. EOL (End of Life, конец жизненного цикла) означает, что дальнейшая эксплуатация — риск взлома и потери данных.
• Платформа не справляется с нагрузкой или объёмом каталога. Tilda или WordPress + WooCommerce, разросшийся до 10 000+ SKU с глубокой фильтрацией. Платформа физически не тянет нужный масштаб.
• Бизнес перерос платформу. Лендинг превратился в полноценный магазин, корпоративный сайт — в портал, малый ИМ — в средний с B2B-клиентами. Архитектурные ограничения упираются в потолок.
• Стоимость поддержки выросла непропорционально. Самописная CMS или редкий движок — каждое изменение требует разработчика, нет готовых модулей, поиск специалистов превратился в проблему.
• Скорость и Core Web Vitals не восстанавливаются. Платформа архитектурно тяжёлая, оптимизация даёт ограниченный эффект. Это касается старой Magento на Luma-теме, тяжёлых WordPress-сборок с десятками плагинов, кастомных CMS на устаревших фреймворках.
• Сменилась команда или подрядчик. Новая команда специализируется на другой платформе, поддержка существующего стека для них дорого и неудобно.
• Безопасность. Серия взломов или утечек, отсутствие современных механизмов защиты, низкое качество кодовой базы.
• Стратегические задачи. Запуск маркетплейса, переход на headless-архитектуру, омниканальная розница, интеграции с ERP (Enterprise Resource Planning, системы планирования ресурсов) и CRM (Customer Relationship Management, системы управления отношениями с клиентами), которые требуют принципиально другой архитектуры.

Если ни один из этих триггеров не сработал, миграция чаще даёт больше потерь, чем выгод. Замена работающей CMS «потому что новая платформа выглядит современнее» — типичное провальное решение, после которого трафик восстанавливается 6–9 месяцев.

Главные SEO-риски миграции

Любая миграция CMS — это потенциальная просадка по органике. Реалистичный диапазон для проекта со средней семантикой — потеря 20–30% трафика на первые 4–8 недель, с восстановлением и выходом на новый уровень к 3–4 месяцу. При аккуратной подготовке просадка не превышает 10–15%, при ошибках доходит до 50–70% с долгим восстановлением.

Основные источники потерь

• Битые URL. Старые адреса страниц больше не работают, поисковики отдают 404, ссылочный вес уходит в никуда. Главный фактор просадки.
• Изменение структуры URL. Даже с 301-редиректами часть ссылочного веса теряется, переход требует времени на индексацию новой структуры.
• Потеря мета-тегов. При переносе контента часто слетают индивидуальные Title и Description, заменяясь шаблонными.
• Сломанная микроразметка. Если на старой CMS были Product, Article, Organization JSON-LD, а на новой их забыли реализовать — потеря расширенных сниппетов в выдаче и снижение CTR (Click-Through Rate, кликабельность сниппета).
• Скрытые дубли. При миграции часто возникают зеркала (старый и новый сайт оба доступны), параметры в URL без canonical, дубли через несколько контекстов.
• Изменение скорости. Если новая CMS медленнее старой, Core Web Vitals просаживаются, что напрямую влияет на ранжирование в Google.
• Потеря hreflang. При переезде мультиязычного сайта легко потерять связи между языковыми версиями.
• Изменение sitemap и robots. Поисковик получает противоречивые сигналы: одни URL в sitemap, другие в индексе, третьи закрыты в robots.
• Простой при переключении. Если DNS-переключение проходит с ошибками или серверная конфигурация даёт сбои в первые часы — поисковик фиксирует серию ошибок 5xx.

Главное правило миграции — поисковик не должен зафиксировать смену CMS. Идеальная миграция выглядит как технический переезд внутри одной системы: те же URL или их корректные 301-аналоги, те же мета-теги, та же структурированная разметка, тот же hreflang. Со стороны Google и Яндекса проект продолжает работать как раньше.

Предмиграционный аудит

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

Сбор фактической базы

• Полный crawl старого сайта. Screaming Frog, Netpeak Spider или аналог собирает все доступные URL с кодами ответа, Title, Description, H1, canonical, hreflang, мета-robots, размером страницы, скоростью.
• Экспорт из Google Search Console. Список URL с показами и кликами за последний год. По каждому URL фиксируется средняя позиция и CTR.
• Экспорт из Яндекс Вебмастера. Раздел «Страницы в поиске», список приоритетных URL, информация по ИКС (Индекс Качества Сайта Яндекса).
• Список топ-страниц по органике. Из Search Console и Метрики выгружается список 500–1000 страниц, которые формируют 80% трафика. Это критически важные URL — их обязательно сохранить.
• Внутренний ссылочный граф. Какие страницы ссылаются на какие. После миграции структура внутренних ссылок воспроизводится в новой системе.
• Внешний ссылочный профиль. Через Ahrefs, Semrush или Мегаиндекс собирается список входящих ссылок. URL с большим количеством бэклинков обязательно сохраняются или редиректятся 1-к-1.

Аудит контента

• Уникальный текст категорий и товаров. Сколько описаний написано вручную, сколько — копипаст от производителя. Все индивидуальные тексты должны перенестись.
• Блог-контент. Полный список статей с авторами, датами публикации, метаданными.
• Изображения с alt-тегами. Перенос изображений с сохранением исходных имён файлов и alt — отдельная задача миграции.
• Видео и встроенный медиа-контент. Где размещены YouTube-вставки, Vimeo, локальные видео — нужно сохранить эти точки в новой системе.
• Формы и интеграции. Где работают формы захвата, какие CRM/email-сервисы получают данные, какие пиксели и счётчики установлены.

Технический аудит

• SSL-сертификат. Тип, дата истечения, цепочка сертификатов.
• HTTP-заголовки. X-Robots-Tag, Cache-Control, наличие HSTS.
• Текущая sitemap.xml. Структура, количество URL, периодичность обновления.
• Robots.txt. Полный текст текущего файла, что закрыто от индексации.
• Микроразметка Schema.org. Какие типы используются, на каких страницах.
• Hreflang. Связи между языковыми версиями.
• Существующие 301-редиректы. История прошлых миграций, которые тоже нужно учесть.

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

Карта URL и стратегия редиректов

Карта URL — центральный артефакт миграции. Это таблица соответствий «старый URL → новый URL → код редиректа». Без неё миграция превращается в лотерею.

Сценарий 1: URL сохраняются один-в-один

Идеальный случай — структура ЧПУ (человеко-понятных URL) новой CMS совпадает со старой. Например, был /catalog/smartfony/iphone-15/, остался такой же. В этом случае редиректы не нужны, поисковик не зафиксирует миграцию.

Этот сценарий достижим, если новая CMS позволяет полностью настроить структуру URL: WordPress (через настройки постоянных ссылок), MODX (через URL Key и friendly URLs), кастомная разработка. Для коробочных решений с жёсткими шаблонами URL (Bitrix с дефолтными настройками, OpenCart) приходится подстраивать URL под старую схему.

Сценарий 2: 301-редиректы 1-к-1

Старый URL /catalog/category/15-iphone.html → новый /smartfony/iphone-15/. Для каждого старого URL прописывается прямой редирект на новый адрес. Карта составляется в Excel или CSV: первая колонка — старый URL, вторая — новый, третья — код ответа (301), четвёртая — комментарий.

Для масштабных миграций (десятки тысяч URL) карта строится через регулярные выражения: /catalog/(\d+)-(.+)\.html$ → /$2/. Это сокращает количество правил в десятки раз.

Сценарий 3: 301 на ближайшую сущность. Когда страница на новой системе не имеет точного аналога — редирект на ближайшую категорию, ближайший товар или раздел. Например, снятый с продажи товар → его категория. Эта стратегия применяется для устаревшего контента, который не имеет смысла переносить, но имеет ссылочный вес.

301 vs 302 vs 410

Где прописываются редиректы

• На уровне сервера. Apache .htaccess с правилами RewriteRule или Nginx-конфиг с rewrite-блоками. Самый производительный вариант для больших карт.
• На уровне CMS. Yoast Redirection для WordPress, модуль Redirects для PrestaShop, Redirector для MODX. Удобно для маленьких карт и оперативных правок.
• На уровне CDN. Cloudflare Page Rules, Workers — для проектов, где статика и редиректы идут через CDN.

Перенос контента

Контент — основной актив, который должен переехать без потерь. Разные типы контента переносятся разными способами.

Товары и каталог

• Экспорт в CSV или XML. Большинство CMS поддерживают экспорт каталога во внешний формат. Минимальные поля для экспорта: ID, название, описание, цена, наличие, артикул, категория, изображения, мета-теги, URL.
• Маппинг полей. Поля старой CMS сопоставляются с полями новой. Не всегда соответствие 1-к-1: например, «Бренд» в старой системе может быть отдельным полем, а в новой — атрибутом.
• Импорт через нативные инструменты новой CMS. WooCommerce — Product CSV Import, Bitrix — модуль импорта, Magento — Data Migration Tool, PrestaShop — встроенный импорт через CSV.
• Валидация после импорта. Контрольная выборка из 50–100 товаров проверяется вручную: название, описание, цена, изображения, атрибуты, мета-теги.

Категории и страницы

• Структура категорий воспроизводится в новой системе с теми же названиями.
• Описания категорий переносятся в полном объёме, включая HTML-разметку.
• Изображения категорий загружаются с сохранением исходных имён файлов.
• SEO-настройки каждой категории (Title, Description, H1, canonical) переносятся индивидуально.

Блог и статьи

• Каждая статья переносится отдельно с сохранением даты публикации (важно для микроразметки Article).
• Сохраняется автор статьи, если на старом сайте была авторская атрибуция.
• Изображения внутри статей переносятся с правильными путями.
• Внутренние ссылки внутри статей пересобираются под новые URL.
• URL статей фиксируются в карте редиректов даже при сохранении структуры — это страховка.

Изображения и медиа

• Все файлы переносятся в новую систему с сохранением исходных имён и alt-тегов.
• Если на новой CMS другая структура папок медиафайлов — все ссылки на изображения внутри текстов обновляются.
• Изображения, потерявшие связь с контентом (например, картинки внутри удалённых блог-постов), удаляются перед миграцией.
• Видеовставки YouTube/Vimeo проверяются на сохранность плеера — иногда визуальные редакторы новой CMS ломают эмбед.

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

Базовый набор технических настроек, которые активируются на новой CMS до запуска.

• HTTPS на всём сайте. SSL-сертификат установлен, принудительный редирект с HTTP на HTTPS, HSTS-заголовок настроен.
• Главное зеркало. Один основной домен (с www или без), остальные варианты редиректятся 301.
• Canonical-теги. На каждой странице — canonical на собственный URL или на основной вариант при наличии параметров.
• Sitemap.xml. Корректная карта всех индексируемых страниц, обновляется автоматически. Адрес прописан в robots.txt.
• Robots.txt. Технические разделы закрыты, рабочий контент открыт. Содержит ссылку на sitemap.
• Мета-теги по каждой странице. Title и Description заполнены индивидуально, шаблонных подстановок не остаётся.
• Структура заголовков. Один H1 на страницу, H2/H3 размечены последовательно.
• Внутренняя перелинковка. Хлебные крошки, меню, связи между категориями и товарами.
• Mobile-friendly. Сайт корректно отображается на мобильных, проходит Mobile-Friendly Test.
• Core Web Vitals. Метрики LCP (отрисовка крупнейшего контента), INP (отклик на пользовательское взаимодействие), CLS (кумулятивный сдвиг макета) измерены и оптимизированы.
• HTTP/2 и Brotli. Современный протокол передачи и сжатие включены на веб-сервере.
• CDN для статики. Cloudflare, BunnyCDN или аналог снижает TTFB (Time to First Byte, время до первого байта) и нагрузку на источник.
• OPcache на уровне PHP. Базовая серверная оптимизация.
• Защита от индексации staging. Тестовый поддомен закрыт через HTTP Basic Auth или мета-robots noindex.

Перенос структурированных данных

Микроразметка Schema.org — отдельная задача миграции, часто упускаемая командами разработки. На старом сайте могла работать рабочая разметка Product, Article, Organization, BreadcrumbList — если на новой системе её нет, поисковая выдача теряет расширенные сниппеты.

Минимальный набор для переноса

• Organization или LocalBusiness. На главной — название, логотип, контакты, sameAs со ссылками на соцсети, contactPoint.
• WebSite + SearchAction. На главной — поддержка Sitelinks Searchbox в выдаче.
• BreadcrumbList. На всех страницах кроме главной — цепочка категорий.
• Product + Offer. Для интернет-магазина — на каждой карточке товара. Включает name, image, description, sku, brand, price, priceCurrency, availability, priceValidUntil, condition.
• AggregateRating + Review. Если на товарах есть отзывы — переносится рейтинг и количество отзывов.
• Article. На блог-постах и новостях — headline, datePublished, dateModified, author, image.
• FAQPage. На страницах с FAQ — структура вопросов и ответов.

Способы реализации

Микроразметка встраивается в шаблоны новой CMS одним из способов:

• Через специализированные плагины и модули. Yoast SEO Schema, RankMath, Schema Pro для WordPress; Mageworx SEO Suite для Magento; SchemaProMODX для MODX; PrestaSEO для PrestaShop.
• Через встроенные средства темы. Hummingbird для PrestaShop, Hyvä для Magento, Astra для WordPress — выводят базовый Schema.org без дополнительных модулей.
• Через прямое редактирование шаблонов. JSON-LD вставляется в шаблон страницы вручную, переменные подставляются через теги CMS.

После реализации каждая ключевая страница проверяется через Google Rich Results Test и Schema Markup Validator. Для Яндекса дополнительно — валидатор микроразметки в Вебмастере.

Мультиязычность при переезде

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

Главные точки контроля

• Структура URL по языкам. Сохраняется тот же подход, что был на старом сайте: подпапки (/ru/, /en/), поддомены (ru.example.by) или отдельные домены. Смешивать варианты во время миграции — критическая ошибка.
• Hreflang-теги. На каждой странице — полный набор тегов с указанием на все языковые версии и x-default. Проверяется через crawl новой системы.
• Связи между переводами. Каждая страница знает свои переводы. Если в новой CMS это реализовано через ID — связи восстанавливаются после импорта.
• Канонические URL внутри языковой версии. Canonical русской страницы указывает на русскую, не на английскую.
• Sitemap по языкам. Отдельный sitemap на каждый язык или единый sitemap с указанием языковых версий через hreflang.

Запуск: staging и переключение

Финальная стадия миграции — запуск нового сайта на основном домене. От качества подготовки зависит, потеряет проект 5% или 30% трафика в первые недели.

Финальная проверка на staging

Перед переключением весь сайт проверяется на тестовом поддомене (stage.example.by) с закрытым доступом для поисковиков. Чек-лист проверки:

• Полный crawl staging — все страницы доступны, отдают 200, имеют корректные мета-теги.
• Sitemap генерируется и содержит правильные URL (после смены домена).
• Robots.txt не содержит закрытий рабочего контента.
• Микроразметка Schema.org валидна на ключевых страницах.
• Hreflang корректен на всех языковых версиях.
• Скорость сопоставима со старым сайтом или выше, Core Web Vitals в зелёной зоне.
• Формы захвата работают, данные приходят в CRM/email.
• Счётчики аналитики (Google Analytics, Яндекс Метрика) установлены и собирают данные.
• Карта 301-редиректов протестирована: 20–30 случайных старых URL отдают редирект на правильные новые.
• Тестовые покупки и оформление заказов проходят корректно.

День переключения

Переключение лучше планировать на ночь рабочего дня или раннее утро в будний день — минимум активного трафика, есть запас времени на устранение проблем до пика. Воскресная ночь — оптимальное окно для большинства проектов.

Порядок действий в день переключения:

1. Финальная синхронизация контента staging → production (свежие заказы, последние правки).
2. Снять с staging закрытие от индексации.
3. Переключить DNS на новый сервер. TTL DNS-записей за 24–48 часов до переключения снижается до 300 секунд для быстрого распространения.
4. Проверить доступность сайта по основному домену с разных провайдеров и регионов.
5. Активировать карту 301-редиректов на уровне веб-сервера.
6. Отправить новую sitemap.xml в Google Search Console и Яндекс Вебмастер.
7. Запросить переобход ключевых страниц через Search Console (URL Inspection → Request Indexing).
8. Активировать IndexNow для Яндекса и Bing (если поддерживается на новой CMS).

Первые 24 часа после переключения

• Каждые 2–3 часа проверять Search Console и Вебмастер на новые ошибки 5xx и 4xx.
• Мониторить серверные логи на массовые 404 — индикатор пропущенных редиректов.
• Контролировать счётчики аналитики — нет ли резкой просадки трафика, что может означать проблему с DNS или счётчиком.
• Тестировать ключевые сценарии: оформление заказа, регистрация, формы захвата.

Постмиграционный мониторинг

После запуска начинается период активного мониторинга, который занимает 4–8 недель. В это время поисковики переиндексируют сайт, обрабатывают редиректы, перестраивают индекс структуры. Любая ошибка в этот период проявляется как просадка трафика. При продвижении сайтов после миграции этот этап критичен — пропуск ошибки на первой неделе оборачивается потерями на месяцы.

Первая неделя

• Ежедневная проверка Search Console: индексация, ошибки crawl, сообщения о санкциях.
• Ежедневная проверка Яндекс Вебмастера: индексация, ошибки, изменения ИКС.
• Краулинг сайта целиком через Screaming Frog: новые битые ссылки, неработающие редиректы.
• Проверка позиций по топ-200 запросам — фиксация baseline до миграции, отслеживание движения.
• Логи сервера: массовые 404, замедление ответа, всплески 5xx.

Вторая-четвёртая неделя

• Динамика индексации: количество страниц в Google и Яндексе должно расти, приближаясь к старым показателям.
• Постепенное восстановление трафика — на 60–70% от прежнего уровня к концу четвёртой недели.
• Корректировка проблемных редиректов: если какой-то старый URL отдаёт 404 — дописывается редирект.
• Доработка мета-тегов на страницах с просевшими позициями.
• Поведенческие метрики в Метрике и GA4 — сравнение с историческими значениями.

Пятая-восьмая неделя

• Выход на стабильные показатели: 80–95% от прежнего трафика для аккуратной миграции.
• Долговременные точечные правки: страницы с просевшими позициями анализируются индивидуально.
• Анализ новых возможностей: что улучшилось на новой CMS (скорость, новые типы микроразметки, удобство редактирования).
• Начало роста выше старого уровня — если новая CMS архитектурно лучше, рост заметен с 2–3 месяца после миграции.

Особенности миграции сайтов в Беларуси

Раскрутка сайтов в РБ после миграции имеет несколько локальных особенностей, которые проверяются дополнительно к стандартному чек-листу. SEO-продвижение в Беларуси чувствительнее к работе с Яндекс Вебмастером, чем в других регионах.

• Яндекс Вебмастер. При смене CMS Яндекс воспринимает миграцию строже, чем Google. Активная работа с Вебмастером в первые 4 недели обязательна: переотправка sitemap, запрос переобхода ключевых страниц, контроль раздела «Страницы в поиске».
• Регион в Вебмастере. При миграции часто слетают региональные настройки. Регион выставляется заново на конкретный город (Минск, Гомель, Могилёв, Витебск, Гродно, Брест) или на всю Беларусь, в зависимости от географии бизнеса.
• ИКС. По нашим наблюдениям, Индекс Качества Сайта Яндекса временно проседает на 5–15 пунктов после миграции, восстанавливается через 4–8 недель. Это нормальное поведение, не повод паниковать.
• ЕРИП-оплата. При миграции ИМ интеграция с ЕРИП-системой проверяется отдельно — некорректная настройка приводит к потере части заказов.
• Прайс-агрегаторы. Onliner-каталог и katalog.by получают данные через YML-фид. При смене CMS адрес фида меняется — нужно обновить настройки в каталогах вручную.
• Доставка через локальные службы. Интеграции с Европочтой, Белпочтой, СДЭК Беларусь проверяются отдельно: API-ключи, токены, обработчики статусов.
• Карточка в Яндекс Бизнесе. После миграции проверяется привязка карточки к новой версии сайта, обновляется адрес сайта в профиле.
• Санкционные ограничения. При выборе целевой CMS учитываются ограничения: Adobe Commerce и Shopify приостановили операции в РБ с 2022 года, новые лицензии и регистрации недоступны.

Типичные ошибки при миграции

Список повторяющихся проблем, которые встречаются при миграциях CMS — обычно одни и те же ошибки повторяются от проекта к проекту.

• Запуск без карты редиректов. Старые URL отдают 404, ссылочный вес теряется. Главная и наиболее болезненная ошибка.
• Карта редиректов только на топ-страницы. Покрыты главная, категории и топ-100 товаров — а ещё 5000 второстепенных страниц возвращают 404.
• 302 вместо 301. Временный редирект не передаёт ссылочный вес. Используется только 301.
• Цепочки редиректов. Старый URL → промежуточный → ещё промежуточный → финальный. Каждый шаг теряет часть веса, поисковик может прекратить следование по цепочке. Решение — прямые редиректы старый → финальный.
• Дубли через зеркала. Старый сайт остаётся доступен под IP или на тестовом поддомене, индексируется параллельно с новым.
• Sitemap не обновлён. В sitemap.xml остались старые URL, новые туда не попали.
• Robots.txt с staging-настройками. На production-сайте остался Disallow: /, который закрывает весь сайт от индексации. Происходит при копировании staging-окружения без проверки.
• Не перенесена микроразметка. На старом сайте было Schema.org Product, на новом — только базовая Open Graph. Расширенные сниппеты исчезают из выдачи.
• Сломанный hreflang. При миграции мультиязычного сайта связи между языковыми версиями не воспроизведены.
• Изменение URL без необходимости. Команда решает «заодно» переименовать категории и поменять структуру URL — даже при наличии 301-редиректов это удваивает SEO-потери.
• Потеря даты публикации статей. При импорте блога даты сбрасываются на день миграции. Решение — отдельная проверка datePublished в JSON-LD.
• Запуск в высокий сезон. Миграция ИМ перед Чёрной пятницей или в декабре. Любая просадка в пик сезона стоит дорого, миграция планируется в низкий сезон.
• Отсутствие резервной копии старого сайта. При критической ошибке нет возможности откатиться. Полный бэкап старой версии хранится минимум 6 месяцев после миграции.
• Игнорирование Яндекс Вебмастера. Команда работает только с Search Console, игнорирует Яндекс. Для проектов под Яндекс это критическая ошибка — потери на Яндексе могут быть сильнее, чем на Google.
• Слишком короткий период мониторинга. Через 2 недели проект «отпускается», ошибки и просадки замечаются поздно. Минимум 8 недель активного контроля.

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

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

Сколько занимает миграция сайта на новую CMS?

Полный цикл — от старта аудита до выхода на стабильную работу новой системы — занимает от 2 до 6 месяцев в зависимости от размера проекта. Подготовка и разработка — 1,5–4 месяца, тестирование на staging — 2–4 недели, переключение и постмиграционный мониторинг — 8 недель. Для крупного интернет-магазина с 10 000+ SKU цикл доходит до 6–9 месяцев.

Сколько трафика теряется при миграции CMS?

При аккуратной подготовке — 10–15% на первые 2–4 недели с полным восстановлением к 2–3 месяцу. При типичной миграции с несколькими упущенными деталями — 20–30% на 4–8 недель. При серьёзных ошибках (нет карты редиректов, потеряна микроразметка, дубли через зеркала) — 50–70% с восстановлением 6–9 месяцев. Профессиональная миграция стоит дороже, но окупается уже за счёт сохранённого трафика.

Можно ли провести миграцию самостоятельно без агентства?

Технически — да, при наличии разработчика с опытом нужной CMS и SEO-специалиста в команде. На практике самостоятельная миграция чаще даёт серьёзные потери: команда не имеет опыта именно миграций, упускает технические детали, недооценивает важность постмиграционного мониторинга. Для маленьких сайтов (до 100 страниц) самостоятельный переезд оправдан, для среднего и крупного проекта — экономия на агентстве почти всегда оборачивается потерями в выручке.

Что важнее при миграции — сохранить URL или улучшить структуру?

Сначала сохранить URL, потом улучшать структуру отдельным проектом. Миграция CMS — техническая операция, в которой меняется только движок. Параллельная реорганизация URL удваивает SEO-риски: при каждом изменении часть ссылочного веса теряется, даже при наличии 301-редиректов. Если структура URL действительно требует переработки — это делается через 3–6 месяцев после стабилизации миграции, как отдельный проект.

Как защитить SEO-продвижение в Беларуси на этапе миграции?

Несколько обязательных шагов. Первый — активная работа с Яндекс Вебмастером в первые 4 недели: ежедневная проверка раздела «Страницы в поиске», переотправка sitemap, запрос переобхода ключевых страниц через IndexNow. Второй — повторная настройка региона на конкретный город по убыванию населения (Минск, Гомель, Могилёв, Витебск, Гродно, Брест) или на всю Беларусь. Третий — обновление YML-фидов в Onliner-каталоге и katalog.by на новые URL. Четвёртый — проверка интеграций с ЕРИП и локальными службами доставки. Пятый — мониторинг ИКС, который временно проседает на 5–15 пунктов и восстанавливается через 4–8 недель.

Что делать со старыми ссылками с внешних сайтов?

Ничего отдельного — 301-редирект со старого URL на новый передаёт ссылочный вес автоматически. Главное — чтобы каждый URL с входящими ссылками был включён в карту редиректов. Перед миграцией через Ahrefs, Semrush или Мегаиндекс собирается список топ-500 URL с самыми сильными входящими ссылками — они получают приоритет в карте редиректов. Связываться с владельцами внешних ресурсов с просьбой обновить ссылки не нужно: при корректных 301 это не даёт заметного эффекта.

Можно ли мигрировать с устаревшей CMS на современную через промежуточный этап?

Иногда — да. Пример: миграция со старой кастомной CMS на современный движок проходит в два шага. Первый — экспорт данных в промежуточный универсальный формат (CSV, XML) и приведение к чистой структуре. Второй — импорт в целевую CMS через её нативные средства. Между этапами проект может временно работать на статической HTML-копии, если простой неприемлем. Двухэтапные миграции дольше, но безопаснее для проектов с кривой исходной CMS.

Что делать, если после миграции трафик не восстановился через 3 месяца?

Сначала — детальный аудит того, что произошло. Через Search Console и Вебмастер ищутся конкретные страницы с просевшими позициями. По каждой проверяется: есть ли 301-редирект со старого URL, корректны ли мета-теги, индексируется ли страница, нет ли дублей, есть ли микроразметка. Часто проблема локализуется на 50–100 страницах с одинаковым типом ошибки (например, потеря Product Schema на всех товарных карточках), и исправление точечной проблемы возвращает значительную часть трафика. При раскрутке сайтов после неудачной миграции иногда требуется частичная переработка структуры или массовая правка контента.