Почему смена CMS физически ломает SEO
Смена CMS — это не «поменяли движок, контент остался». Со стороны пользователя это выглядит так: те же страницы, те же тексты, возможно даже похожий дизайн. Но со стороны поискового робота и уже накопленного SEO‑ресурса меняется почти всё одновременно, и каждое изменение по отдельности — это риск потерять часть накопленных позиций.
Проще всего увидеть это, если выписать, что именно хранит CMS как SEO‑сигнал: структуру URL, шаблон заголовков H1–H6, разметку метаданных (title, description, canonical, hreflang, OpenGraph, Schema.org), внутреннюю перелинковку, пагинацию, sitemap.xml, robots.txt, правила обработки дубликатов, генерацию микроразметки, шаблоны 404 и, наконец, скорость и стабильность рендера. Любое из этих полей в новой CMS по умолчанию устроено иначе — и если не настроить миграцию поэлементно, часть накопленного SEO‑веса просто рассыпается.
Поисковые системы при этом ведут себя предсказуемо: Googlebot и Яндекс‑бот идут по ссылкам и sitemap, видят массовые 404, дубликаты, изменённые title и пропавшие метатеги — и постепенно пересчитывают рейтинг страниц вниз. Восстановление после такой «тихой поломки» сложнее и дольше, чем сама миграция: бот перестаёт доверять сайту и снижает частоту обхода, что откладывает переиндексацию новых URL ещё на несколько недель.[1]
Главная ошибка — воспринимать миграцию как релиз сайта
Разработчик, который не думает о SEO, видит миграцию как «запустили новую версию — всё работает — задача закрыта». Для поисковой системы это момент максимальной неопределённости: она одновременно обнаруживает новые URL, пропавшие URL, изменившиеся метатеги, изменившийся robots.txt, новую структуру перелинковки, возможно новый IP и новую скорость загрузки. Если все эти сигналы не согласованы и не объяснены через 301‑редиректы, sitemap и Search Console — бот перестраховывается и снижает рейтинг сомнительных страниц.
Четыре фазы правильной миграции — от аудита до стабилизации
SEO‑миграцию полезно рассматривать как четырёхфазный проект с чёткими входами и выходами у каждой фазы. Это не формальность — именно разделение на фазы с отдельной приёмкой снижает риск «чего‑то недоделали» на запуске. Большая часть катастрофических миграций — это пропуск одной из фаз «ради сроков».
Четыре фазы SEO‑миграции и их ключевые артефакты
Аудит и инвентаризация
Полный краулинг старого сайта (Screaming Frog / Sitebulb / Netpeak), выгрузка топ‑страниц из GSC и Яндекс.Вебмастер, экспорт бэклинков, inventory URL, метатегов, заголовков, микроразметки, sitemap и robots. Артефакт — единая таблица «URL → метаданные → трафик → бэклинки».
Маппинг URL и проектирование
Маппинг один к одному со старых URL на новые — в том числе фасетная навигация, теги, категории, пагинация. Решения по canonical, hreflang, robots. Проект структуры метаданных новой CMS, шаблоны title/description, структура микроразметки Schema.org. Артефакт — маппинг‑таблица + SEO‑ТЗ для разработки.
Staging и приёмка
Сборка на staging, краулинг staging, сравнение «старый vs новый» по каждому URL из inventory. Проверка 301‑редиректов, title/description, H1, canonical, hreflang, sitemap, микроразметки, скорости, мобильной версии. Артефакт — отчёт приёмки и список блокирующих дефектов (zero tolerance).
Запуск и стабилизация
Переключение DNS/конфига, немедленный краулинг прода, отправка новой sitemap в GSC и Вебмастер, использование Change of Address, мониторинг логов, позиций, Core Web Vitals. Еженедельные отчёты первые 2 месяца, точечные правки. Артефакт — отчёт стабилизации и закрытие проекта.
Главное, что нужно понимать про эту схему: фазы нельзя параллелить и нельзя ускорять за счёт пропуска этапов. Маппинг, который не опирается на полный краулинг, будет с дырами. Staging без сравнения «старый vs новый» не ловит тонкие регрессии (например, пропавший canonical или подменённый hreflang). Запуск без постзапускового мониторинга — это эффективно «выложили новую версию и надеемся, что ничего не сломается». Экономия недели на одной из фаз оборачивается месяцами восстановления трафика после запуска.
Шесть технических рисков, о которых забывают чаще всего
Из десятков пост‑мортем провальных миграций видно, что большинство катастроф складывается не из одной большой ошибки, а из нескольких мелких одновременных пропусков. Ниже — шесть рисков, которые регулярно «ускользают» даже у опытных команд и требуют явной галочки в чеклисте.
Пропущенные 301‑редиректы
критичноИзменённые метаданные
критичноРазошедшаяся структура URL
критичноНеправильный robots.txt и sitemap
критичноПросевшая скорость и Core Web Vitals
критичноПотеря сигналов бэклинков
критичноСравнение: «миграция на коленке» и миграция по методологии
Ниже — сведённое сравнение двух типовых проектов смены CMS: один идёт по «сценарию разработчика», второй — по полноценной SEO‑методологии. Объём работ и стоимость второго варианта выше, но именно он позволяет пройти миграцию без заметной просадки трафика и заявок.
| Параметр | Миграция «на коленке» | Миграция по методологии |
|---|---|---|
| Аудит до старта | нет или поверхностный | полный краулинг + inventory URL, метатегов, бэклинков |
| Маппинг URL | «основные страницы перекинем руками» | каждый URL из inventory → новый, включая фильтры и пагинацию |
| 301‑редиректы | только главные разделы, без «хвостов» | полное покрытие, прямые редиректы без цепочек[6] |
| Staging и приёмка | «открыли — вроде работает» | краулинг staging, сравнение со старым по ~50 метрикам |
| Title / description | сгенерированы из шаблона новой CMS | перенесены один‑к‑одному, где были уникальные |
| Микроразметка | «добавим после запуска» | Article / Product / Organization / Breadcrumb — в шаблонах до запуска |
| robots.txt на старте | часто с Disallow, унаследованным со staging | финальный robots согласован, проверен в staging, пересобран на проде |
| sitemap.xml | старая sitemap висит неделями, новая не отправлена | новая sitemap сгенерирована, отправлена в GSC и Вебмастер в первые 24 часа[2] |
| Скорость и Core Web Vitals | проверяется «когда клиенты начнут жаловаться» | измерена до запуска, целевые LCP/INP/CLS закреплены как KPI |
| Мониторинг после запуска | нет или раз в месяц | ежедневные логи + еженедельные SEO‑отчёты первые 60–90 дней |
| Change of Address | «а зачем, домен же тот же» | используется при смене домена, нотификация в GSC и Вебмастер |
| Типовая просадка трафика | −30…−70% на 2–6 месяцев | 0…−10% на 2–6 недель с быстрым восстановлением |
Важный нюанс: первый вариант стоит «дешевле» в момент заказа — клиент платит только за разработку новой CMS. Второй стоит дороже, потому что в нём заложены фазы аудита, маппинга, приёмки и постзапускового SEO‑сопровождения. Но если пересчитать в деньгах потерянный органический трафик и заявки — первый вариант почти всегда оказывается в разы дороже в итоговой стоимости владения.
301‑редиректы и маппинг URL — сердце SEO‑миграции
Если нужно выбрать единственный элемент миграции, от которого зависит сохранение SEO, это маппинг URL и 301‑редиректы. Всё остальное — метаданные, микроразметка, скорость — восстанавливается относительно быстро и не зависит от контекста «старого» сайта. А 301‑редиректы — это единственный способ объяснить поисковой системе, что страница со старым URL и страница с новым URL — это один и тот же документ, и весь накопленный SEO‑вес должен перейти на новый адрес.
«Главные страницы перекинем руками, остальное — на 404»
Команда размечает редиректы только для 50–100 топовых URL. Все остальные страницы — теги, фильтры, пагинация, старые статьи блога, товары в архиве — после запуска отдают 404 или редиректятся на главную. Google видит массовые 404 на страницах с накопленным весом и начинает снижать общий рейтинг домена. Потери — 30–70% органики на несколько месяцев.
«Каждому URL из полного inventory — максимально близкий новый»
На основе полного краулинга и выгрузки из GSC составляется исчерпывающая таблица: каждый URL с трафиком, входящими ссылками или индексированием получает прямой 301 на новый URL. Если точного аналога нет — редирект на ближайшую релевантную страницу раздела, а не на главную. 404 остаются только для страниц, которых осознанно не должно быть на новом сайте.[1]
Хороший маппинг опирается на три источника URL, которые обязательно объединяются в одну таблицу:
- Полный краулинг текущего сайта — все внутренние ссылки, включая фильтры, пагинацию, служебные страницы. Это скелет структуры.
- Выгрузка из Google Search Console и Яндекс.Вебмастер — реальные страницы, на которые идёт поисковый трафик или которые проиндексированы. Может включать старые URL, которых уже нет во внутренней перелинковке, но которые продолжают ранжироваться.
- Выгрузка бэклинков из Ahrefs / Semrush / Moz — страницы, на которые стоят внешние ссылки. Они могут быть «глубокими» и неочевидными, но каждая из них — это накопленный SEO‑вес, который нельзя потерять.[4]
После объединения и дедупликации этих источников получается полная матрица URL, с каждым из которых нужно определённо что‑то сделать: редирект 1:1, редирект на ближайшую релевантную страницу, или 410 (intentional gone — для страниц, которых осознанно быть не должно). Любой URL без решения в матрице — это потенциальная потеря трафика.
Правило «никаких цепочек редиректов»
Даже если у сайта уже есть исторические редиректы (со старой миграции 2018 года, например), при новой миграции их все нужно «выпрямить» — каждый исторический URL должен вести напрямую на актуальный, а не через цепочку «2018 → 2021 → 2026». Цепочки в 3+ переходов Google обрабатывает всё хуже с каждым звеном, и часть SEO‑веса теряется на каждом хопе. Технически это простая выгрузка всех существующих редиректов + пересчёт в финальную матрицу.[6]
Финансовая математика потерь от провальной миграции
Чтобы понять, сколько бизнес реально теряет на плохой миграции, полезно записать последствия в виде простой формулы. Исходные параметры — те же, что в обычной воронке: трафик × конверсия × чек. Но миграция добавляет модификатор «потеря трафика за период».
Возьмём реалистичный сценарий: сайт с 20 000 органических сеансов в месяц, просадка 50% в результате неподготовленной миграции, восстановление за 4 месяца (усреднённо), CR сайта 1,5%, средний чек 3 500 BYN. Потерянная выручка за период восстановления: 20 000 × 0,5 × 4 × 0,015 × 3 500 = 2,1 млн BYN. Это деньги, которые бизнес недополучил потому, что на миграции сэкономили пару недель работы SEO‑специалиста.
Отдельно стоит посчитать косвенные потери: не только органика, но и прямой трафик (если сайт стал медленным или визуально «незнакомым» — часть постоянной аудитории отвалится), и контекстная реклама (Landing Page Experience падает при изменении URL, Quality Score снижается — стоимость клика в Google Ads растёт). Скорость и хостинг новой CMS тоже оказывают прямое влияние на Quality Score и окупаемость рекламы — и это ещё один канал потерь, который не учитывается в «чистой SEO‑арифметике».
Восемь технических модулей, которые нужно проверить на staging
Приёмка staging — это единственная возможность поймать регрессии до того, как их увидит поисковая система. Ниже — минимальный набор из восьми модулей, каждый из которых закрывает отдельный класс ошибок. Пропуск любого из них на практике приводит к потере части трафика после запуска.
Краулинг staging vs прод
Screaming Frog или Sitebulb на staging, сравнение с краулингом прода по URL, title, H1, canonical, hreflang, meta robots, статус‑кодам. Цель — zero дефектов в «старый → новый» маппинге.
Проверка 301‑редиректов
Прогон всех URL из inventory через httpx/curl с проверкой: status=301, Location указывает на корректный новый URL, цепочка редиректов не превышает одного перехода.[6]
robots.txt и meta robots
robots.txt — финальный, без унаследованных Disallow со staging. meta robots на каждой странице согласован со старой версией (noindex там, где надо, индексация там, где надо).
sitemap.xml и hreflang
Sitemap сгенерирован, разбит на части (≤50 000 URL каждая), содержит только финальные URL с 200 OK. Для мультиязычных проектов — корректный hreflang, включая x‑default.[2]
Микроразметка Schema.org
Проверка через Rich Results Test и Schema Markup Validator. Ключевые типы: Article, Product, Organization, BreadcrumbList, LocalBusiness, FAQPage — перенесены один‑к‑одному или улучшены.
Core Web Vitals
Lighthouse / PageSpeed Insights на ключевых шаблонах: главная, карточка товара/услуги, категория, статья. LCP ≤ 2.5 с, INP ≤ 200 мс, CLS ≤ 0.1 — до запуска, не после жалоб.
Мобильная версия
Проверка через Mobile‑Friendly Test и ручное тестирование на реальных устройствах. Google индексирует mobile‑first, и если мобильная версия хуже десктопной — рейтинг просядет по всему сайту.
Внутренняя перелинковка
Ни одной внутренней ссылки не должно вести на 301 или 404. Все блоки «похожие», «категории», «тегами», футер — обновлены. Глубина ключевых страниц от главной не выросла.
Zero‑tolerance приёмка
Хороший подход к приёмке staging — нулевая толерантность к дефектам из этих восьми модулей. Любой 404 на URL из inventory, любая цепочка редиректов, любой потерянный canonical — блокер для запуска. Отладка после продакшена стоит в разы дороже, чем неделя задержки на staging. Это тот случай, когда «запустили и починим по ходу» — самая дорогая стратегия.
Cutover вечером пятницы, мониторинг «посмотрим в понедельник»
Классический сценарий катастрофы: релиз в пятницу вечером «чтобы не беспокоить пользователей», команда разошлась по домам, в выходные sitemap не обновлена, robots остался со staging, первые 404 никто не обрабатывает. К понедельнику бот уже успел переиндексировать часть структуры в плохом виде, и исправление занимает в разы больше времени.
Cutover в рабочее окно вторника‑среды, команда на связи 24 часа
Окно запуска выбирается осознанно: рабочее время, низкий сезонный трафик, команда полностью на связи ближайшие 24–48 часов. Сразу после переключения — краулинг прода, проверка sitemap и robots на живом домене, отправка новой sitemap в GSC и Вебмастер, активация мониторинга логов. Любая регрессия отрабатывается в часах, а не в днях.
Постзапусковый мониторинг: первые 24 часа, неделя, месяц
Миграция не заканчивается в момент переключения DNS. Самый рискованный период — первые 60–90 дней, пока поисковая система переобходит сайт, пересчитывает сигналы и переиндексирует новые URL. В это время нужно отдельно мониторить ряд метрик — регулярно и явно, а не «иногда заглядывать в Search Console».
- Первые 24 часа: краулинг прода, проверка 301‑редиректов, проверка sitemap и robots, отправка новой sitemap в Google Search Console и Яндекс.Вебмастер, активация Change of Address (при смене домена), проверка критичных шаблонов вручную на реальных устройствах.
- Первая неделя: ежедневный мониторинг лог‑файлов сервера (статус‑коды, 404, 500, всплески 301), GSC «Coverage» и «Pages» (новые индексируемые vs исключённые), Яндекс.Вебмастер «Индексирование», позиции ключевых запросов через Rank Tracker.
- Первый месяц: еженедельные отчёты по трафику (GA4, Яндекс.Метрика), сравнение с предмиграционной базой по категориям, выявление «пропавших» страниц, которые потеряли трафик, точечные правки (добавление редиректов, исправление пропавших метатегов, корректировка canonical).
- 2–3 месяц: полный повторный краулинг, сравнение со базовой базой, оценка Core Web Vitals в реальных данных (CrUX), оптимизация медленных шаблонов, анализ позиций по всем приоритетным запросам, закрытие проекта миграции.
Чеклист из двадцати пунктов в трёх фазах — до, во время, после
Ниже — сводный чеклист, которым стоит пользоваться как контрольной картой миграции. Он разбит на три блока по фазам проекта. Каждый пункт — это явная галочка и артефакт, а не «подразумевается».
Чеклист SEO‑миграции — 20 пунктов
- Фаза 1 · до миграции: полный краулинг текущего сайта, выгрузка всех URL, статус‑кодов, метатегов, H1, canonical, hreflang.
- Фаза 1: выгрузка из Google Search Console (страницы с трафиком, покрытие, очереди индексации) и Яндекс.Вебмастер.
- Фаза 1: выгрузка бэклинков из Ahrefs/Semrush — список страниц с внешней ссылочной массой.[4]
- Фаза 1: объединённая таблица URL‑inventory с пометкой «приоритет по трафику/бэклинкам» для каждой записи.
- Фаза 2 · проектирование: маппинг‑таблица «старый URL → новый URL», заполнена на 100%, без пропусков.
- Фаза 2: SEO‑ТЗ для разработки: шаблоны title/description, структура H1–H6, canonical, hreflang, разметка Schema.org.[3]
- Фаза 2: решения по robots.txt, meta robots, правилам обработки дубликатов и пагинации в новой CMS.
- Фаза 3 · staging: краулинг staging, сравнение со старым сайтом по всем метрикам, отчёт о дефектах.
- Фаза 3: проверка всех 301‑редиректов на staging (с учётом регистра, слэшей, параметров), отсутствие цепочек.[6]
- Фаза 3: тесты Core Web Vitals, мобильной версии, микроразметки, доступности — все в зелёной зоне.
- Фаза 3: формальная приёмка staging с zero‑tolerance списком блокеров.
- Фаза 4 · запуск: cutover в рабочее окно, команда на связи 24–48 часов, бэкап старой версии.
- Фаза 4: немедленный краулинг прода, проверка robots.txt, sitemap.xml, 301‑редиректов на живом домене.
- Фаза 4: отправка новой sitemap в Search Console и Яндекс.Вебмастер, активация Change of Address (при смене домена).[2]
- Фаза 4: проверка GA4 / Метрики — корректно ли проставлены коды счётчиков, работает ли отслеживание целей и событий.
- Фаза 4 · первая неделя: ежедневный мониторинг логов (404, 500, 301 chains), позиций, показов в GSC.
- Фаза 4 · первый месяц: еженедельные SEO‑отчёты, сравнение с предмиграционной базой по шаблонам и рубрикам.
- Фаза 4 · 2–3 месяц: повторный полный краулинг, закрытие остаточных регрессий.
- Фаза 4: оценка Core Web Vitals в CrUX (реальные данные пользователей), оптимизация медленных шаблонов.
- Фаза 4 · закрытие: итоговый отчёт стабилизации, фиксирование новой «базы» метрик, передача сайта в штатное SEO‑сопровождение.
Как ONTOP ведёт SEO‑миграцию на новую CMS
Мы подходим к миграции как к отдельному проекту, а не «дополнительной задаче внутри разработки». Уже на этапе выбора CMS — будь то Drupal для мультиязычного проекта или любая другая платформа под конкретную бизнес‑модель — мы проектируем не «сайт на новой платформе», а миграцию: маппинг, редиректы, метаданные, sitemap, robots. Это меняет структуру ТЗ и сроки разработки, но радикально снижает риск SEO‑просадки при запуске.
В ключевых проектах мы параллельно ведём разработку и SEO‑аудит: пока команда разработки собирает платформу, SEO‑специалист уже формирует inventory URL и маппинг. К моменту, когда staging готов к приёмке, у нас на руках полная таблица редиректов и чеклист из 50+ технических проверок. Это ровно те фазы, о которых SEO‑работа требует системности: миграция — самая концентрированная и рискованная точка, где системный подход окупается быстрее всего.
Наконец, важно, что миграцию на новую CMS не стоит рассматривать в отрыве от долгосрочной инвестиции в сайт. Если при миграции потерять накопленные 2–3 года органического трафика, ROI всей цифровой стратегии обнуляется. Именно поэтому мы встраиваем миграцию в сквозной процесс разработка → SEO → техподдержка — это даёт преимущество единого агентства, когда одни и те же люди проектируют, запускают и сопровождают новый сайт, не передавая его «через забор».
Планируете смену CMS или уже прошли миграцию и потеряли трафик? Мы проведём SEO‑аудит миграции, построим маппинг‑таблицу и дорожную карту восстановления за 10 рабочих дней.
Заказать аудит миграцииЧастые вопросы о SEO‑миграциях на новую CMS
FAQ — что чаще всего спрашивают владельцы сайтов
Если структура URL не меняется, нужен ли SEO‑аудит миграции вообще?
Да, нужен — и это одно из частых заблуждений. Даже если URL остаются прежними, меняется всё остальное: шаблоны title/description, структура H1, микроразметка, canonical, sitemap, robots, скорость, мобильная версия, внутренняя перелинковка. Google и Яндекс воспринимают сайт не только по URL, но и по совокупности этих сигналов. Миграция «без изменения URL» — это отдельный сценарий в официальной документации Google и требует почти той же приёмки, что и миграция с новыми URL, за исключением работы с 301.[1]
Сколько реально занимает правильная миграция?
Для типового коммерческого сайта на 1 000–10 000 URL (B2B‑услуги, каталог, средний интернет‑магазин) — 60–120 дней от аудита до закрытия проекта стабилизации. Из них 2–4 недели на аудит, 2–4 недели на маппинг и проектирование, 3–6 недель на разработку и приёмку staging, 4–12 недель на постзапусковый мониторинг и стабилизацию. Для крупных мультиязычных проектов и e‑commerce с десятками тысяч URL сроки растягиваются до 6–9 месяцев.
Можно ли мигрировать «этапно», по разделам сайта?
Технически да, и это даже рекомендованный подход для крупных сайтов. Например, интернет‑магазин с 50 000 товаров можно мигрировать по категориям: сначала «Бытовая техника», через 3–4 недели «Электроника», и т.д. Каждая категория — отдельный SEO‑подпроект со своим маппингом, staging‑приёмкой и мониторингом. Это увеличивает общие сроки, но резко снижает риск одновременной катастрофы по всему домену. Минус — нужно аккуратно управлять структурой robots и sitemap, чтобы не создать дубликатов между «старым» и «новым» разделами.
Что делать, если миграция уже прошла и трафик упал?
Во‑первых, не паниковать: большинство проблем можно «докрутить» постфактум. Во‑вторых, провести аварийный аудит: полный краулинг, выгрузка GSC/Вебмастер, сравнение с предмиграционной базой. Типовой алгоритм восстановления: закрыть массовые 404 редиректами на ближайшие релевантные страницы, починить пропавшие метатеги и canonical, исправить sitemap и robots, отправить обновлённую sitemap в GSC и Вебмастер, ждать 4–12 недель пересчёта сигналов. Реалистичная цель — вернуть 80–90% потерянного трафика за 2–3 месяца, остаток — за 6–9 месяцев.
Нужно ли менять домен при миграции, или лучше оставить старый?
Как правило, лучше оставить старый домен, если нет веских причин для смены (ребрендинг, юридическая смена владельца, освобождение от санкционных рисков). Смена домена — это дополнительный слой риска поверх обычной миграции: нужно пройти отдельную процедуру Change of Address в Search Console и Вебмастере, и перенос SEO‑веса занимает больше времени. Если же домен меняется вынужденно, это ровно тот кейс, где методология становится критичной, а любая «упрощённая миграция» приводит к полугодовой просадке трафика.[1]
Можно ли сохранить трафик в Яндексе так же, как в Google?
Базовые принципы идентичны: 301‑редиректы, sitemap, robots, метатеги, Core Web Vitals (Яндекс тоже учитывает скорость и удобство). Но Яндекс переиндексирует сайт медленнее Google — типовые 4–8 недель на полное обновление сигналов против 2–4 недель у Google. Поэтому стабилизация в Яндексе занимает 2–4 месяца даже при идеальной миграции. Ключевые инструменты Яндекса во время миграции — Вебмастер (раздел «Индексирование», «Переобход страниц»), Метрика (сравнение GA/Метрики для кросс‑проверки), IndexNow для ускорения переиндексации.
Какие CMS сложнее всего мигрировать и почему?
Сложнее всего переносить сайты со «старых» самописных CMS (где нет явной схемы данных), с конструкторов (Tilda, Wix, Webflow — там URL и метаданные жёстко привязаны к платформе) и с сильно кастомизированных инсталляций WordPress/Битрикс, где 70% логики прописано в плагинах и темах. Проще всего мигрировать между «серьёзными» платформами: Drupal, крупные e‑commerce‑движки (Magento, Shopware), современные headless‑стеки — у них есть предсказуемая структура данных и возможность автоматизировать маппинг. Отдельно стоит тема выбора CMS с учётом SEO‑перспективы — это влияет не только на текущую миграцию, но и на все будущие переезды.
Выводы: миграция — это проект на 60–120 дней, а не «переключение тумблера»
SEO‑миграция на новую CMS — одна из самых рискованных и одновременно самых недооценённых задач в жизненном цикле сайта. Её часто воспринимают как «техническую работу разработчика», хотя по факту это проект на стыке разработки, SEO, контент‑менеджмента и аналитики, который длится 60–120 дней и требует явной методологии, фаз и приёмки.
Успешные миграции похожи друг на друга: полный аудит, полный маппинг, staging с zero‑tolerance приёмкой, аккуратный cutover, интенсивный мониторинг первые 60–90 дней. Провальные миграции тоже похожи: «основные URL перекинем руками», «метатеги подвезём после запуска», «sitemap Google сам найдёт», «robots исправим если что». Разница между успехом и провалом — это не один большой секрет, а пара десятков методических шагов, каждый из которых по отдельности выглядит тривиально.
Экономика очень проста: правильная миграция стоит в 1,5–2 раза дороже «базовой разработки», но сохраняет весь накопленный органический трафик и заявки. Неправильная — «экономит» эту разницу в цене, но теряет 30–70% трафика на 3–6 месяцев, что в деньгах — миллионы BYN недополученной выручки. Поэтому любая смена CMS должна начинаться с SEO‑аудита и заканчиваться SEO‑приёмкой, а не «релизом новой версии сайта».
Источники
- Google Search Central — Site move with URL changes — официальное руководство Google по миграциям с изменением URL: пошаговый алгоритм подготовки, 301‑редиректов, отправки sitemap, использования отчёта Change of Address в Search Console.
- Google Search Central — Sitemaps overview — официальная документация Google по sitemap.xml: структура файла, лимиты (50 000 URL, 50 МБ), правила разбиения на части, способы отправки в Search Console для быстрой переиндексации.
- Google Search Central — Consolidate duplicate URLs — руководство по canonical‑тегам и консолидации дубликатов: как правильно указывать canonical, как обрабатываются конфликтующие сигналы и почему это критично при миграции, где меняется URL‑структура.
- Ahrefs — Website Migration: The Definitive SEO Guide — подробное практическое руководство Ahrefs по SEO‑миграциям: чеклисты, инструменты краулинга, типовые ошибки, данные по срокам восстановления трафика после плохой миграции.
- Semrush — Website Migration Checklist — практический чеклист Semrush по SEO‑миграциям, с разбором каждого этапа (аудит, маппинг, staging, запуск, мониторинг) и статистикой по типовым срокам восстановления трафика после миграции.
- Moz — Redirection (301 vs 302, Chains & Loops) — объяснение того, как работают перенаправления с точки зрения SEO: разница между 301 и 302, почему цепочки редиректов снижают скорость обхода и как это влияет на накопленный вес страницы при миграции.
