Переезд на новую CMS можно провести без заметной потери органического трафика, если переносить всю систему страниц. До запуска соберите полезные URL, определите судьбу каждого адреса, перенесите контент и SEO-настройки, проверьте формы и аналитику. После переключения пройдите ключевые маршруты с публичной стороны. Сначала выпускать сайт, а потом искать пропавшие страницы и заявки - опасная стратегия.
Что сохранять при смене CMS
Поисковой системе и посетителю важны URL, код ответа, содержание, ссылки и работающие функции. Риск связан не с названием CMS, а с изменениями вокруг неё.
Сохранить или осознанно заменить нужно:
- адреса и назначение страниц;
- тексты, заголовки, списки, таблицы и FAQ;
- title, description, canonical и правила индексации;
- внутренние ссылки, навигацию и пагинацию;
- изображения, alt, документы и другие файлы;
- микроразметку, sitemap.xml и robots.txt;
- формы, кнопки, аналитику и передачу заявок в CRM;
- региональные и языковые версии, если они есть.
Если меняется только управление сайтом, URL лучше оставить прежними. При новой структуре важной странице назначают прямой аналог. Если замены нет, корректный 404 или 410 лучше редиректа на главную.
Шаг 1. Снимите исходное состояние сайта
Экспорта из CMS недостаточно: часть страниц создаётся фильтрами, модулями и шаблонами. Соберите URL из sitemap.xml, обхода краулером, веб-аналитики, поисковых панелей и отчёта по внешним ссылкам. Добавьте страницы заявок, оплаты, скачивания, личного кабинета, а также PDF и изображения, на которые ведут ссылки.
Для каждого адреса зафиксируйте код ответа, title, H1, canonical, входящие внутренние ссылки, органические переходы и роль страницы. Таблица должна отвечать на два вопроса: что нельзя потерять и что произойдёт с этим в новой системе.
Сохраните показатели для сравнения: трафик по разделам, страницы входа, заявки по каналам, конверсию форм и ошибки. Сравнивайте одинаковые периоды с учётом выходных и сезонности, а не два случайных дня.
Если обнаружились технические копии, поможет разбор про дубли страниц в SEO. Не объединяйте материалы только из-за похожих заголовков: сначала сравните их интент и задачу.
Шаг 2. Составьте карту старых и новых URL
Карта URL - главный документ миграции. В строке указывают старый и новый адреса, решение, причину и результат проверки.
Обычно решений четыре:
- сохранить URL - если роль страницы не меняется;
- поставить 301 - если у страницы появился новый постоянный адрес и близкий аналог;
- объединить - если несколько страниц действительно отвечают на один запрос, а новая сохраняет их полезное содержание;
- удалить с 404 или 410 - если материал больше не нужен и релевантной замены нет.
Редирект должен вести сразу на конечный адрес. Замену выбирают по смыслу: страницу услуги нельзя вести на статью, если человек ожидает условия заказа.
Пример: прежняя страница /services/audit-site/ переезжает на /seo/audit/, а услуга и содержание сохраняются. В этом случае уместен прямой 301. Старые новости нельзя автоматически отправлять на корень блога. Для каждой ищут тематический аналог или возвращают корректный статус удаления.
Логику статусов можно сверить с руководством HTTP-коды ответа и SEO. Для крупного сайта карту стоит проверить скриптом: старый URL отдаёт один 301, конечный отвечает 200, а в его HTML указан self-canonical.
Шаг 3. Убедитесь, что контент перенесён полностью
Запись в новой базе ещё не равна готовой странице. Редактор может превратить списки в сплошной текст, убрать подписи к изображениям или экранировать HTML. Шаблон иногда показывает только анонс вместо полного материала.
Возьмите по несколько страниц каждого типа и проверьте:
- весь ли основной текст виден посетителю;
- остался ли один H1 и понятная иерархия H2-H3;
- корректно ли выглядят списки и таблицы;
- работают ли внутренние и внешние ссылки;
- перенесены ли изображения, alt и подписи;
- нет ли битых относительных путей;
- не дублируются ли заголовок, хлебные крошки и FAQ;
- не появились ли в тексте переменные шаблона, Markdown или JSON.
Необязательно сохранять каждую фразу дословно. Устаревшее можно убрать, а структуру - улучшить. Но массовый перенос одновременно с полной редактурой усложняет диагностику. Если меняются и URL, и шаблоны, и тексты, при падении трафика трудно понять причину. Для ключевых разделов надёжнее сначала выпустить содержательно эквивалентную версию, проверить её, а затем улучшать отдельными итерациями.
Шаг 4. Перенесите SEO-настройки и шаблоны
Новая CMS может автоматически дописать бренд в title, создать несколько canonical, открыть архивы для индексации или сохранить noindex от тестовой версии. Поэтому для каждого шаблона проверьте:
- уникальные title и description, один видимый H1;
- canonical на основной публичный URL и корректный meta robots;
- Open Graph, хлебные крошки и подходящую микроразметку;
- согласованность canonical, редиректов и sitemap;
- единый протокол, главное зеркало и настоящую страницу 404.
Отдельно разберите категории, теги, авторов, даты, фильтры, поиск и пагинацию. Полезную категорию можно развивать как посадочную. Техническую выдачу лучше не открывать для индексации и не оставлять в ссылочных маршрутах.
Шаг 5. Проверьте тестовый контур
Тестовый сайт должен быть закрыт от индексации, но доступен команде и краулеру. До переключения проверьте, что:
- Запланированные страницы отвечают 200 и не содержат noindex.
- Robots.txt не закрывает будущие публичные разделы.
- Canonical ведёт на будущий основной домен, а не на staging.
- Внутренние ссылки сразу ведут на конечные URL.
- В sitemap входят только индексируемые страницы с ответом 200.
- Изображения, стили и скрипты загружаются без ошибок.
- Формы доставляют заявки в почту или CRM.
- События аналитики срабатывают один раз.
- Мобильная версия сохраняет текст, меню и кнопки.
- Несуществующая страница возвращает 404.
Проверяйте не только главную: в выборке нужны услуга, статья, категория, кейс, пагинация, форма и страница с файлом. Ошибка шаблона затрагивает весь тип материалов.
Шаг 6. Подготовьте переключение
Назначьте, кто переключает домен, включает редиректы, проверяет сайт, отслеживает заявки и решает вопрос об откате. Сам порядок лучше записать заранее:
- Заморозить изменения или выполнить финальную синхронизацию.
- Сделать резервную копию базы, файлов и конфигурации.
- Опубликовать новую версию и снять защиту тестового контура.
- Включить серверные редиректы.
- Проверить HTTPS, зеркало, robots.txt и sitemap.xml.
- Пройти критические URL и пользовательские сценарии.
- Отправить sitemap в панели вебмастеров.
- Подтвердить доставку тестовой заявки.
Заранее определите признаки для отката и ответственного за решение. Сразу после релиза не смешивайте миграцию с новым дизайном, аналитикой и рекламными экспериментами: иначе источник проблемы будет трудно установить.
Шаг 7. Проверьте сайт после запуска
Проверяйте публичную версию без входа в админку и локального кэша. Возьмите страницы с трафиком, ключевые услуги, длинные статьи, старые URL с редиректами и удалённые адреса. Убедитесь, что старый URL отдаёт ожидаемый статус, редирект не образует цепочку, конечная страница отвечает 200, а её title, H1, canonical, текст, изображения и форма работают.
Полный обход выявит массовые 404, ссылки на staging, циклы и потерянные ресурсы. Затем следите за логами и панелями вебмастеров. Обращения к старым адресам после запуска нормальны, но рост 5xx, циклов и незапланированных 404 требует исправления.
Практику дополняет материал Редиректы при переезде сайта: как не потерять SEO. Если меняются и домен, и структура, фиксируйте смену хоста и пути отдельно, чтобы не создавать цепочки.
Практический сценарий
Представим сайт услуг с регионами, кейсами и блогом. Экспорт из старой панели даёт 180 URL, но краулер и аналитика находят ещё 36: старые кейсы, PDF и рекламные посадочные.
После разбора 142 адреса сохраняются, 31 страница получает прямой 301, 18 дублей объединяются в 7 материалов, 14 устаревших страниц удаляются без нерелевантного редиректа, а 11 файлов и служебных адресов проверяются отдельно.
Цифры условны и показывают процесс, а не обещают результат. Главное - ни один адрес не меняется по умолчанию. После запуска команда проверяет услуги, выборку других шаблонов и доставку тестовой заявки. Не готовые к релизу полезные страницы лучше временно оставить доступными, чем заменить пустыми заготовками.
Частые ошибки
Менять URL ради красоты
Короткий адрес не всегда оправдывает перенос работающей страницы. Без реальной пользы для архитектуры и пользователя старый URL лучше сохранить.
Готовить редиректы после релиза
Даже короткий период массовых 404 мешает пользователям, рекламе и роботам. Карта и правила должны быть готовы заранее.
Забывать о файлах
PDF, фотографии и документы тоже нужно перенести, сохранить по прежним адресам или корректно перенаправить.
Проверять только метатеги
Наличие title не подтверждает полноту страницы. Сравнивайте видимый текст, заголовки, изображения, таблицы и ссылки.
Оставлять настройки staging
Noindex, запрет в robots.txt, canonical на тестовый домен и ссылки на закрытые ресурсы могут быть незаметны визуально.
Верить сообщению «отправлено»
Подтвердите появление тестовой заявки в CRM или почте, её источник и событие аналитики.
Считать любой спад провалом
На метрики влияют спрос, сезонность и ошибки счётчика. Оценивайте вместе доступность, обход, показы, переходы и заявки.
Чек-лист владельца сайта
До разработки:
- собрать URL из sitemap, краулера, аналитики и поисковых панелей;
- отметить страницы с трафиком, заявками и внешними ссылками;
- сохранить метатеги, микроразметку и цели;
- согласовать структуру и правила удаления.
До запуска:
- завершить карту URL и прямые 301;
- проверить контент и SEO всех шаблонов;
- проверить sitemap.xml, robots.txt, canonical и 404;
- пройти формы, мобильную версию и передачу в CRM;
- подготовить резервную копию и откат.
После запуска:
- проверить коды, редиректы, тексты и изображения;
- выполнить обход сайта;
- убрать внутренние ссылки на старые URL;
- отправить sitemap в панели вебмастеров;
- следить за 404, 5xx, трафиком и заявками;
- повторно проверять исправления.
FAQ
Обязательно ли сохранять старые URL?
Нет, но для страниц с прежней ролью это самый безопасный вариант. При смене адреса настройте прямой 301 и обновите внутренние ссылки, canonical и sitemap.
Можно ли переносить сайт по частям?
Да, если граница этапа понятна: например, сначала блог, затем каталог. Для каждого этапа нужны своя карта URL, маршрутизация и проверка.
Нужно ли закрывать тестовый сайт от индексации?
Да, оставив доступ команде и краулеру. Перед публикацией удалите временные запреты и проверьте, что canonical не ведёт на staging.
Как долго сохранять редиректы?
Не удаляйте их сразу. Старые ссылки остаются в письмах, закладках, документах и на внешних сайтах. Редиректы для ценных URL разумно сохранять длительно.
Когда менять контент?
Критические ошибки исправьте до запуска. Полную переработку лучше отделить от миграции: сначала перенести эквивалентную версию, затем улучшать её.
Что важнее в первые часы?
Доступность ключевых страниц, правильные редиректы, отсутствие блокировки индексации, работа форм и аналитики. Косметику можно исправить позже.
Переезд на новую CMS становится управляемым, когда у каждой страницы есть решение, у каждого сигнала - способ проверки, а у команды - понятный порядок запуска. Если нужна независимая проверка карты URL и технических рисков, напишите в Telegram. Для подготовки структуры, FAQ и редакторских черновиков можно использовать XelaGroup, но итоговые URL, факты и работу публичного сайта должен проверить человек.
Планируете смену CMS?
Проверим карту URL, редиректы, шаблоны и критические пользовательские маршруты до запуска.