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

Аудит и планирование: фундамент успеха

Прежде чем нажать кнопку «Установить новую CMS», необходимо провести глубокий аудит текущего проекта. Ошибки на этом этапе стоят дороже всего.

Инвентаризация активов

• Контент: Количество страниц, типы записей (статьи, товары, лендинги, каталоги), медиафайлы (изображения, видео, документы).
• Функционал: Формы обратной связи, личные кабинеты, корзина/чекаут, фильтры, поиск, интеграции с CRM/ERP/1С, API сторонних сервисов.
• SEO-активы: Текущие URL-структура, мета-теги (Title, Description, H1), микроразметка (Schema.org), файл robots.txt, карта сайта sitemap.xml, редиректы (301, 302), внутренняя перелинковка.
• Технический стек: Версия PHP, база данных (MySQL/MariaDB/PostgreSQL), веб-сервер (Nginx/Apache), кэширование (Redis, Memcached, Varnish), CDN.

Выбор новой CMS

Выбор зависит от типа проекта и бюджета:

1. Коробочные решения (WordPress, Bitrix, OpenCart, MODX): Быстрый старт, большое сообщество, много плагинов. Подходят для большинства проектов.
2. Фреймворки (Laravel, Symfony, Django, Yii2): Максимальная гибкость, производительность, безопасность. Требуют команды разработчиков и высокого бюджета на поддержку.
3. Headless CMS (Strapi, Contentful, Sanity) + Frontend (Next.js, Nuxt, Astro): Современный подход для омниканальности и сложных интерфейсов.
4. SaaS (Shopify, Tilda, Wix, Webflow): Никакой администрирования сервера, но ограниченная гибкость и аренда, а не владение кодом.

Составление карты миграции (Migration Map)

Создайте таблицу соответствия: Старый URL -> Новый URL. Это главный документ для настройки редиректов.

Пример структуры:

Подготовка окружения и разработка

Настройка Staging/Dev окружения

Никогда не мигрируйте на продакшн напрямую. Поднимите копию сайта на поддомене staging..ru или dev..ru.

• Закройте доступ по паролю (Basic Auth) или по IP (только офис * / VPN ).
• Запретите индексацию в robots.txt: User-agent: Disallow: /.
• Настройте те же версии PHP и БД, что планируются на продакшне.

Перенос контента (Data Migration)

Есть три основных подхода:

1. Автоматизированный (скрипты/импорт/экспорт): Идеально для больших каталогов (10к+ товаров). Пишется парсер/скрипт, читающий старую БД и пишущий в новую через API или прямые SQL-запросы/ORM.
2. Полуавтоматизированный (CSV/XML/Excel): Экспорт из старой админки -> чистка/преобразование данных -> импорт в новую (например, через WP All Import, Bitrix CSV импорт).
3. Ручной: Только для маленьких сайтов (до 50-100 страниц) или уникальных лендингов.

Важно: При переносе товаров сохраняйте ID (SKU/Артикул) — это критично для интеграций с 1С/МойСклад/CRM менеджера *.

Верстка и функционал

• Пиксель-перфект верстка по Figma/Zeplin.
• Адаптивность (Mobile First).
• Доступность (a11y): ARIA-роли, контраст, навигация с клавиатуры.
• Интеграции: Настройте вебхуки для форм (Bitrix24, AmoCRM, Telegram бота *), синхронизацию остатков/цен с 1С.

SEO-сохранение: Самый критичный этап

Потеря трафика после миграции — частая проблема. Чтобы её избежать, выполните чек-лист:

Сохранение URL-структуры (Best Practice)

Если есть возможность — сохраните URL 1-в-1. Это исключает необходимость в редиректах и сохраняет вес ссылок мгновенно.

Настройка 301 редиректов (Если URL меняются)

Редиректы должны быть настроены на уровне веб-сервера (Nginx/Apache) или через middleware фреймворка, НЕ через плагины CMS (это медленно).

# Пример для Nginx (map directive ‒ быстро для тысяч правил)
map $request_uri $new_uri {
 /cat/phones/ /catalog/smartfony/;
 /product/old-slug /catalog/smartfony/new-slug;
 # ... тысячи правил из Migration Map
}

server {
 ...
 if ($new_uri) {
 return 301 $new_uri;
 }
 ...
}

Мета-теги и микроразметка

• Перенесите все Title, Description, H1.
• Проверьте микроразметку: Product, Article, BreadcrumbList, Organization, WebSite через валидатор Google / Яндекс.Вебмастер.
• Канонические ссылки (rel="canonical") должны указывать на новые URL.

Карта сайта и Robots.txt

• Сгенерируйте свежий sitemap.xml на новой CMS (только канонические, 200 OK страницы).
• Настройте robots.txt: откройте нужное, закройте админку, корзину, личный кабинет, поиск, фильтры (если не SEO-лендинги).

Работа с Яндекс.Вебмастер и Google Search Console

• Добавьте новый сайт (если меняется домен/протокол) или подтвердите права на старом.
• Используйте инструмент «Переезд сайта» в Яндекс.Вебмастере (если меняется домен).
• Отправьте новый sitemap.xml на переобход.

Тестирование (QA) перед запуском

Проводите тестирование на Staging по чек-листу:

Функциональное тестирование

• Оформление заказа (гость / авторизованный), оплата (тестовые карты ЮKassa / Сбербанк / Тинькофф ).
• Работа личного кабинета: история заказов, смена пароля, адреса доставки.
• Фильтры, сортировка, поиск (релевантность, морфология).
• Интеграции: уходит ли заказ в CRM ? Приходят ли остатки из 1С *?
• Формы обратной связи, обратный звонок, подписка на рассылку.

SEO-тестирование (Technical SEO Audit)

• Сканирование сайта скримингом (Screaming Frog / Netpeak Spider): проверка кодов ответа (200, 301, 404), дублей, отсутствия H1, длинных Title/Desc.
• Проверка редиректов: старые URL из Migration Map -> Новые URL (должен быть 301 -> 200).
• Проверка robots.txt и sitemap.xml на валидность.
• Мобильная удобство (Google Lighthouse / PageSpeed Insights).

Нагрузочное тестирование (Load Testing)

Используйте k6, JMeter или Yandex.Tank. Симулируйте пиковую нагрузку (Black Friday, запуск рекламы). Целевые метрики: Time to First Byte (TTFB) < 200мс, 95-й перцентиль ответа < 1с при нагрузке X RPS.

Запуск (Go-Live): День Х

План запуска (Runbook)

Создайте документ с пошаговым планом, ответственными и временем. Пример:

1. T-24ч: Финальный бекап БД и файлов старого сайта (хранить минимум 30 дней).
2. T-1ч: Постановка старого сайта в «Режим технического обслуживания» (возврат 503 кода с заголовком Retry-After: 3600 для ботов).
3. T-0: Деплой новой версии на продакшн-сервер (через CI/CD: GitLab CI / GitHub Actions / Jenkins).
4. T+0: Прогон Smoke-тестов на продакшне (главная, каталог, товар, корзина, оплата тестовой сделки).
5. T+15мин: Снятие 503 кода, открытие для пользователей.
6. T+30мин: Отправка нового sitemap в Яндекс/Google. Проверка редиректов на живых старых URL.
7. T+1ч: Проверка прихода лидов в CRM *, заказов в админку.

DNS и SSL

• Если меняется IP сервера, заранее снизьте TTL у A-записей до 300 секунд (5 мин) за сутки до миграции.
• SSL сертификат (Let’s Encrypt / платный EV/OV) должен быть выдан и настроен до переключения DNS. Настройте HSTS.

Пост-продакшн: Первые 2 недели

Миграция не заканчивается запуском.

Мониторинг ошибок

Логирование:
• Настройте сбор логов в ELK Stack (Elasticsearch, Logstash, Kibana) / Graylog / Sentry / Datadog.
• Алерты в Telegram/Slack/Email на 500-е ошибки, превышение времени ответа, ошибки БД.

Аналитика и поведение пользователей

• Сравните метрики (Яндекс.Метрика / GA4) до и после: отказы, время на сайте, конверсия в цель (заказ/лид).
• Смотрите Вебвизор / Session Replay на наличие багов в UI (кнопки не жмутся, формы не отправляются).
• Проверьте отчет «Ошибки сканирования» в Яндекс.Вебмастере / GSC ежедневно.

Работа с 404 ошибками

Ежедневно выгружайте отчет по 404 ошибкам из логов сервера или Яндекс.Вебмастера. Если это важные страницы, которые «упали» из карты миграции, срочно добавляйте 301 редирект.

Кэш и производительность

• Прогрейте кэш (Varnish / Nginx FastCGI Cache / Redis Object Cache) сразу после деплоя.
• Мониторьте Hit Rate кэша (должен быть > 90% для анонимных пользователей).

Чек-лист «Не забудь» (Cheatsheet)

• [ ] Бекап старой БД и файлов сделан и проверен на восстановление.
• [ ] robots.txt на продакшене открыт для индексации (убрать Disallow: /).
• [ ] sitemap.xml генерируется автоматически и доступен по /sitemap.xml.
• [ ] Все формы отдают данные в CRM/Email (проверить тестовую сделку *).
• [ ] Настроены цели в Яндекс.Метрике / GA4 (достижение чекаута, отправка формы, клик в телефон).
• [ ] Подключены Яндекс.Вебмастер и Google Search Console.
• [ ] Настроен мониторинг аптайма (UptimeRobot / Pingdom / Zabbix) — алерт, если сайт лежит > 1 мин.
• [ ] Документация для контент-менеджеров по новой админке передана (видео-инструкция / PDF).
• [ ] Доступы к админке/серверу/репозиторию переданы заказчику / ответственному лицу * по безопасному каналу (Bitwarden / 1Password / зашифрованный архив).

Смена CMS — это не просто техническая задача, а бизнес-процесс. Успех определяется тремя факторами: качественный аудит (чтобы ничего не потерять), грамотные 301 редиректы (чтобы не потерять трафик) и поэтапное тестирование (чтобы не потерять заказы в день запуска).

Следуя данной методологии, вы минимизируете риски и обеспечите плавный переход на новую платформу без проседаний в поисковой выдаче и конверсии. Удачной миграции!

Статья подготовлена для информационных целей. Для конкретного проекта всегда требуется индивидуальная техническая спецификация. Контакты ответственных лиц и доступы скрыты в соответствии с политикой безопасности (*).