Исходные данные: зачем вообще трогать работающий блог
Начну с контекста. Был у нас контентный блог:
— 5+ лет истории
— несколько тысяч страниц
— стабильный органический трафик
— приличное количество запросов в топ‑10
И была старая самописная CMS, которую поддерживали “по дружбе”. В какой‑то момент стало понятно:
- правки внедряются неделями;
- редакторам неудобно работать;
- безопасность на уровне “лишь бы не трогать”.
При этом задача стояла жесткая: перенос сайта на новую CMS без потери трафика. Клиенту было всё равно, какие технологии мы выберем, — важно, чтобы графики в аналитике не поехали вниз.
Ниже расскажу, как мы сделали кейс “как сменить CMS и сохранить позиции в поиске” на практике, а не в теории из докладов.
---
Ключевые термины простым языком
Чтобы дальше говорить на одном языке, коротко определим пару вещей.
Что такое CMS в этом контексте
CMS (Content Management System) — движок, на котором живет сайт.
Простее: панель, куда редактор заходит, чтобы:
- написать и отредактировать статью;
- загрузить картинку;
- настроить мета‑теги, тайтл, h1;
- опубликовать материал.
Мы как раз занимались задачей “миграция блога на другую CMS услуги под ключ” — то есть не только код и дизайн, но и полное сохранение SEO‑результатов.
Что такое миграция с точки зрения SEO
Миграция — это не просто “перекинуть файлы на другой сервер”.
Для SEO миграция = изменение:
- URL‑структуры (или её сохранение);
- шаблонов страниц;
- технических параметров (скорость, микроразметка, каноникал);
- внутренней перелинковки.
Отсюда рождается отдельный вид работ — SEO сопровождение миграции сайта на новую CMS. Это когда SEO‑специалист не просто “смотрит трафик”, а активно участвует в архитектуре, структуре URL, настройках редиректов и проверках.
---
План: как мы разложили миграцию по этапам
Чтобы не утонуть в хаосе, мы собрали весь процесс в понятную схему.
Текстовая “диаграмма” выглядела так:
1. Аудит текущего блога
2. Проектирование структуры и URL
3. Настройка новой CMS и шаблонов
4. Перенос контента и технических настроек
5. Настройка редиректов и проверок
6. Запуск и мониторинг
7. Доработки по итогам данных
Вид сверху (очень упрощенная ASCII‑диаграмма):
```
[Старый блог]
|
v
[Аудит] -> [Новая структура] -> [Новая CMS]
|
v
[Перенос контента]
|
v
[Редиректы и проверки]
|
v
[Запуск]
|
v
[Мониторинг и фиксы]
```
Дальше по шагам, с примерами.
---
Шаг 1. Аудит: что у нас есть сейчас и что нельзя сломать
Мы начали с инвентаризации. Если коротко — собрали всё ценное, что дает трафик.
1. Список URL и их метрики
Собрали:
- все страницы из sitemap;
- все страницы, которые реально получают трафик (из поисковой аналитики);
- URL с внешними ссылками;
- страницы с высокой конверсией (подписка, лид‑формы и т.д.).
Получилось несколько сотен “критичных” URL, за которые особенно переживали. Это те URL, где перенос сайта на новую CMS без потери трафика — прям критичен, любая ошибка может ударить по деньгам.
2. Технические настройки, которые надо сохранить
Мы зафиксировали:
- текущие Title и Description;
- заголовки H1;
- канонические URL (canonical);
- открытые/закрытые для индексации страницы;
- скорость загрузки.
Параллельно отметили “болячки” старой системы: дубли, кривые теги, избыточные параметры в URL. Миграция — отличный повод не только перенести, но и подчистить.
---
Шаг 2. Структура и URL: ломать или не ломать
Самый болезненный момент в любой миграции — URL.
Есть два варианта:
1. Сохранить структуру один в один.
Минимальный риск просадок, минимум работы с редиректами.
2. Изменить структуру, но настроить идеальные 301‑редиректы.
Больше пользы в долгую, выше риск временной просадки.
Мы выбрали гибридный вариант:
- для топовых страниц — сохранили URL полностью;
- для хвоста со старыми кривыми адресами — привели к человеку понятному виду, но строго через 301‑редирект.
Пример:
- Было: `/blog.php?id=1256`
- Стало: `/blog/kak-vybrat-cms-dlya-bloga/`
SEO‑риски компенсировали за счет точного соответствия “старый → новый” и аккуратной работы с картой редиректов.
---
Шаг 3. Выбор и настройка новой CMS
Сравнивали несколько вариантов:
- популярную коробочную CMS;
- headless‑решения;
- облачную платформу с визуальным редактором.
Сравнение с аналогами вживую, без маркетинга
Наш критерий был простой: что позволит миграция блога на другую CMS услуги сделать без танцев с бубном.
Что смотрели:
- Можно ли явно управлять Title, Description, H1, Open Graph.
- Есть ли нормальные ЧПУ‑URL.
- Доступна ли редактируемая карта сайта (sitemap).
- Легко ли внедрить счетчики, пиксели, разметку.
- Есть ли API для массовых операций.
В итоге взяли не самую модную, но предсказуемую CMS, где:
- есть адекватный контроль над SEO‑настройками;
- понятная роль редактора;
- нормальная система плагинов без “зоопарка”.
---
Шаг 4. Проработка шаблонов: не только дизайн
С точки зрения SEO шаблон — это не “чтобы было красиво”.
Это каркас, в котором живут:
- заголовки (h1–h3);
- блоки контента;
- хлебные крошки;
- блоки “похожие статьи”;
- мета‑теги.
Мы собрали текстовую диаграмму для типового поста:
```
[
- Title: {заголовок статьи} | {бренд}
- Meta Description: {краткое описание}
- Canonical: {основной URL статьи}
[/head]
[
]- H1: {заголовок статьи}
- Дата публикации + автор
- Основной текст
- H2/H3 подзаголовки
- Внутренние ссылки на соседние статьи
- Блок "Читать далее"
- Блок комментариев
```
Важно: мы добились, чтобы редактор мог:
- самостоятельно задавать мета‑теги;
- управлять ссылками внутри текста;
- использовать готовые блоки (списки, цитаты, код).
Это напрямую влияет на то, как сменить CMS и сохранить позиции в поиске: чем меньше ограничений для нормальной SEO‑верстки, тем проще поддерживать результат.
---
Шаг 5. Перенос контента: не просто “скопировать–вставить”
Здесь многие “горят”. Перенос контента — это не только тексты, но и:
- изображения и alt‑теги;
- внутренние ссылки;
- мета‑теги;
- данные о дате публикации.
Как мы переносили статьи
Мы сделали промежуточный экспорт:
1. Выгрузили все статьи из старой CMS в структурированный формат (JSON/CSV).
2. Дополнительно выгрузили мета‑данные: заголовки, descriptions, OG‑теги.
3. Для картинок — указали соответствие старых путей и новых.
И уже этот структурированный массив импортировали в новую CMS через её API.
Плюс руками прошлись по топовым материалам:
- проверили верстку;
- обновили устаревшие ссылки;
- почистили “битые” картинки.
---
Шаг 6. Редиректы: страховочная сетка
Редиректы = то, на чем держится услуги по переносу сайта на новую платформу с сохранением SEO. Без них поисковик будет считать, что старые страницы просто умерли.
Как мы строили карту редиректов
Алгоритм:
1. Берем полный список старых URL (из логов, sitemap, аналитики).
2. Для каждого URL определяем новый “потомок”:
- полностью совпадает по смыслу;
- в крайнем случае — перенаправляем на максимально близкую категорию.
3. Формируем карту вида:
- `/blog.php?id=1256` → `/blog/kak-vybrat-cms-dlya-bloga/`
- `/category/seo/` → `/blog/seo/`
Затем:
- на сервере прописали 301‑редиректы (постоянные, не 302);
- отдельно проверили, чтобы не было “цепочек” (A→B→C, должно быть A→C напрямую);
- прогнали список через краулер (Screaming Frog и аналоги).
Если коротко: пока карта редиректов не прошла автоматическую и ручную проверку — релиз не назначали.
---
Шаг 7. Запуск: что делали в “час Х”
Запуск делали ночью по локальному времени основной аудитории, чтобы минимально трогать пользователей.
Набор действий в момент старта:
1. Переключили домен на новый сервер с новой CMS.
2. Проверили:
- главную и несколько ключевых статей;
- работу редиректов (старый URL → новый);
- статус‑коды (всё важное должно отвечать 200 или 301).
3. Обновили sitemap и отправили в панели вебмастеров.
4. Оставили старый сервер “в живых” на резервное время (но без индексации).
Сразу после старта выкатили план мониторинга.
---
Шаг 8. Мониторинг: первые две недели решают всё
Мы заранее договорились с клиентом: после запуска сидим “на пульсе”.
Что отслеживали ежедневно:
1. Статус‑коды и ошибки.
- 404 (страницы не найдены);
- 500 (ошибки сервера).
2. Поведение пользователей.
- время на странице;
- показатель отказов;
- глубина просмотра.
3. Поисковые показатели.
- позиции по топовым запросам;
- трафик из органики по категориям;
- количество проиндексированных страниц.
Небольшие “колебания” видны почти всегда, даже при идеальной миграции. Важно, чтобы:
- не было массовых падений по группе URL;
- старые страницы быстро переиндексировались как новые;
- трафик вернулся на прежний уровень в течение нескольких недель.
У нас получилось удержать почти прямую линию: первые 3–4 дня увидели лёгкий “зубчик” вниз (примерно −5–7 %), потом график выровнялся и через месяц вырос примерно на 10 % за счет улучшенной структуры и скорости.
---
Где именно мы выиграли (и чем это отличается от “обычной” миграции)
Важно понимать: миграция блога на другую CMS услуги часто продаются как “мы всё перенесем и будет как раньше”.
Но на деле типичный сценарий выглядит так:
- меняют CMS без участия SEO‑специалиста;
- забывают про редиректы или делают их частично;
- ломают структуру URL;
- меняют шаблоны так, что заголовки и контент “прыгают”.
Мы пошли другим путем — SEO сопровождение миграции сайта на новую CMS было заложено в проект изначально:
- SEO участвовал в проектировании структуры;
- все макеты смотрели не только дизайнер, но и SEO;
- запуск переносился, пока карта редиректов не была в порядке.
Именно это и позволило сделать перенос сайта на новую CMS без потери трафика, а не “почти без потерь”.
---
Практическое резюме: как повторить подход на своем проекте
Соберу в один компактный список то, что можно применить у себя.
1. Не начинайте миграцию без полного списка URL и их метрик.
2. Решите заранее: сохраняете ли структуру или меняете её с продуманными 301.
3. Выбирайте CMS не по рекламе, а по возможностям для SEO (ЧПУ, мета‑теги, разметка, редиректы).
4. Делайте экспорт–импорт контента структурированно, а не “копировать–вставить” через браузер.
5. Стройте карту редиректов как отдельный проект, а не “доп. задачку”.
6. Планируйте запуск так, чтобы была команда дежурных и понятный чек‑лист проверок.
7. Следите за трафиком и ошибками минимум месяц после старта и будьте готовы быстро фиксить.
Если смотреть на это не как на разовый “переезд”, а как на комплексные услуги по переносу сайта на новую платформу с сохранением SEO, результат будет совсем другой: вы не просто избегаете падения, а получаете шанс улучшить структуру и выжать из блога больше, чем было до миграции.
