Переезд сайта на новую CMS без потери трафика и позиций

Переезд сайта на новую CMS — одно из самых нервных мероприятий в жизни любого владельца бизнеса и SEO-специалиста. С одной стороны, новый движок обещает гибкость, скорость и удобство управления контентом. С другой — за этим решением скрывается риск в одночасье обнулить позиции, которые нарабатывались годами, потерять органический трафик и поисковую видимость. Я видел десятки таких переездов: одни проходили гладко и почти незаметно для Яндекса, другие оборачивались катастрофой с обвалом посещаемости на 60–80% и долгими месяцами восстановления. Разница между этими сценариями почти всегда сводится к качеству подготовки и дисциплине на каждом этапе. В этой статье я подробно разберу, когда смена CMS действительно оправдана, какие риски подстерегают на пути, и дам пошаговый план с чек-листом и таймлайном, который позволит перенести сайт на новую систему управления без потери трафика и позиций.

Когда переезд на новую CMS действительно нужен

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

• Текущая CMS перестала развиваться или не поддерживается. Если разработчик забросил продукт, не выпускает обновления безопасности, а сообщество вокруг движка исчезло — вы сидите на бомбе замедленного действия. Уязвимости не закрываются, совместимость с новыми версиями PHP и серверного ПО ломается.
• Невозможно реализовать нужный функционал. Бизнес растёт, появляются новые задачи — личный кабинет, сложная фильтрация в каталоге, интеграция с CRM и складскими системами, маркетплейс. Если архитектура старой CMS не позволяет это сделать без костылей, переезд оправдан.
• Критические проблемы со скоростью и техническим состоянием. Когда движок генерирует «тяжёлый» код, не поддерживает кэширование, плохо работает с современными форматами изображений и тормозит даже на хорошем хостинге — это напрямую бьёт по ранжированию в Яндексе.
• Высокая стоимость владения и зависимость от подрядчика. Самописные системы и редкие движки часто привязывают вас к одному разработчику, который диктует цены и сроки. Переход на распространённую CMS снижает эти риски.
• Проблемы с безопасностью. Регулярные взломы, заражения вирусами, спам-инъекции — если CMS постоянно становится точкой входа для злоумышленников, это серьёзный аргумент.

А вот чего делать не стоит — менять движок просто потому, что «хочется чего-то нового» или «у конкурента стоит другая система». Если текущая CMS справляется с задачами, обновляется и не тормозит, переезд принесёт больше рисков, чем пользы. Иногда грамотная внутренняя оптимизация и техническая доработка существующего сайта решают проблему дешевле и безопаснее, чем полная миграция.

Главные риски переезда и почему падает трафик

Чтобы защититься от потерь, нужно понимать, что именно ломается при смене CMS. Поисковые системы, и в первую очередь Яндекс, воспринимают сайт как совокупность множества сигналов: адресов страниц, мета-тегов, контента, внутренней структуры, скорости загрузки. Переезд затрагивает все эти сигналы одновременно, и любая ошибка превращается в провал ранжирования. Вот основные источники риска.

• Изменение URL-адресов. Это риск номер один. Новая CMS почти всегда формирует URL по-другому: меняется структура, появляются или исчезают слеши, расширения, идентификаторы. Если старый адрес перестаёт открываться и не настроен редирект, поисковик получает ошибку 404, страница выпадает из индекса, а накопленный ею вес и позиции теряются.
• Потеря мета-тегов. Title и Description, которые вручную прописывались под каждую страницу, при миграции легко затираются шаблонными значениями или вообще исчезают. Для Яндекса title — один из важнейших факторов релевантности, и его потеря бьёт по позициям моментально.
• Утрата или искажение контента. Тексты могут перенестись не полностью, с битой вёрсткой, потерянными списками, таблицами и заголовками. Иногда теряются целые блоки, изображения отваливаются, alt-атрибуты исчезают.
• Отсутствие или поломка редиректов. Даже если карта редиректов составлена, ошибки в её реализации — цепочки переадресаций, циклы, неверные коды ответа (302 вместо 301) — приводят к тому, что вес не передаётся, а робот путается.
• Падение скорости загрузки. Новый движок без правильной настройки кэширования, сжатия и оптимизации может оказаться медленнее старого. Скорость — фактор ранжирования и поведенческий сигнал.
• Потеря внутренней перелинковки и структуры. Если меняется логика вложенности страниц, рушится привычная для поисковика архитектура, перераспределяется внутренний вес.
• Исчезновение микроразметки. Schema.org, Open Graph, разметка хлебных крошек, товаров, отзывов — всё это часто не переносится автоматически, и сайт теряет расширенные сниппеты.

Важно понимать: эти риски не теоретические. Подробнее о том, как технические недочёты обрушивают видимость, я писал в материале о технических ошибках сайта. А о том, почему страницы внезапно исчезают из выдачи, — в статье почему сайт выпал из индекса.

Этап 1. Полный аудит и выгрузка текущих URL и мета-данных

Любой безопасный переезд начинается с инвентаризации. Вы не сможете ничего сохранить, если не знаете точно, что у вас есть. Это фундамент, на котором держится вся миграция, и экономить на нём категорически нельзя.

Что нужно собрать на этом этапе:

• Полный список всех URL сайта. Не только тех, что в меню, но абсолютно всех проиндексированных страниц. Источники: краулер (Screaming Frog, Netpeak Spider), карта sitemap.xml, выгрузка из Яндекс.Вебмастера (раздел «Индексирование» → «Страницы в поиске»), серверные логи, выгрузка из самой CMS.
• Мета-теги каждой страницы. Title, Description, Keywords (если использовались), заголовки H1. Краулер выгрузит их в единую таблицу — это станет вашим эталоном для сверки после переезда.
• Контент страниц. Тексты, изображения и их alt-атрибуты, заголовки H2–H6, списки, таблицы.
• Микроразметку. Зафиксируйте, какие типы Schema.org и Open Graph используются и на каких страницах.
• Текущие позиции и трафик. Снимите срез позиций по ключевым запросам и зафиксируйте показатели посещаемости из Метрики. Это контрольная точка, относительно которой вы будете оценивать успех переезда.
• Список внешних входящих ссылок. Чтобы понимать, какие страницы получают ссылочный вес извне — их URL критически важно сохранить или корректно переадресовать.
• Действующие редиректы. Если на старом сайте уже настроены переадресации, их нужно учесть, чтобы не создать цепочки.

Результат этапа — единая таблица-реестр, где по каждому URL собраны все его атрибуты. Эта таблица станет рабочим документом на весь проект.

Этап 2. Карта соответствия старых и новых URL

Это сердце всего переезда. Карта соответствия (URL mapping) — таблица, где напротив каждого старого адреса стоит его новый аналог на новой CMS. Именно на основе этой карты будут настраиваться редиректы.

Принципы работы с картой:

• Стремитесь сохранить URL без изменений. Идеальный переезд — тот, при котором адреса страниц не меняются вообще. Если новая CMS позволяет настроить ЧПУ так, чтобы старые адреса остались прежними — сделайте это. Тогда редиректы вообще не понадобятся, а риск минимален. О том, как правильно формировать человекопонятные адреса, читайте в материале ЧПУ и структура URL.
• Если URL меняются — каждый старый адрес должен иметь пару. Не должно остаться ни одной страницы без соответствия. Для каждого старого URL определите: либо он остаётся таким же, либо ведёт на конкретный новый адрес через 301-редирект.
• Не сводите всё на главную. Частая грубая ошибка — переадресовывать все несуществующие старые страницы на главную страницу. Для поисковика это сигнал «мягкой 404», вес не передаётся. Редирект должен вести на максимально близкую по смыслу новую страницу.
• Обрабатывайте удалённые страницы осознанно. Если какие-то страницы решено не переносить, для них тоже нужно решение: редирект на ближайший по тематике раздел или корректный код 410 (Gone), если контент удалён навсегда.
• Учитывайте параметры и дубли. Страницы с GET-параметрами, версии для печати, пагинацию — всё это нужно отразить в карте.

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

Этап 3. Настройка 301-редиректов и склейка адресов

Когда карта соответствия готова, на её основе настраиваются постоянные редиректы. Здесь действует несколько строгих правил, нарушение которых сводит на нет всю предыдущую работу.

• Только код 301. Постоянный редирект (301 Moved Permanently) передаёт ссылочный вес и сообщает поисковику, что страница переехала навсегда. Временный 302 вес не передаёт и оставляет в индексе старый URL — для переезда он не подходит.
• Без цепочек. Редирект должен вести сразу на финальный адрес. Цепочка вида URL-A → URL-B → URL-C размывает вес и замедляет обход. Если в карте обнаружились промежуточные звенья — схлопните их в прямой переход.
• Склейка технических зеркал. Одновременно с переездом наведите порядок с зеркалами: www и без www, http и https, со слешем на конце и без. Все варианты должны вести на одну каноническую версию через 301. Подробно механику склейки я разбирал в статье редирект 301 и склейка зеркал.
• Проверка кода ответа. После настройки каждый редирект нужно проверить — отдаёт ли он именно 301 и ведёт ли на правильную живую страницу с кодом 200, а не на 404.

Если переезд на новую CMS сопровождается ещё и переходом на защищённый протокол, обязательно изучите нюансы в материале переезд на HTTPS — там много подводных камней, связанных именно с одновременной сменой протокола и адресов.

Этап 4. Перенос мета-тегов, контента и alt-атрибутов

Сохранить адреса мало — нужно сохранить и наполнение страниц. Содержимое — это то, за что страница, собственно, и ранжируется. Здесь работаем по реестру, собранному на первом этапе.

• Title и Description. Переносятся один в один. Не позволяйте новой CMS подменить уникальные мета-теги шаблонными. После переноса сверьте каждую страницу с эталонной таблицей.
• Заголовки H1. Должны остаться прежними по содержанию. На новом движке проверьте, что H1 не дублируется, не исчез и не превратился в обычный текст без тега.
• Основной текст. Переносите полностью, сохраняя структуру: абзацы, подзаголовки, списки, таблицы, выделения. Битая вёрстка и потерянные блоки — частая беда автоматического импорта.
• Изображения и alt-атрибуты. Картинки должны сохранить свои пути или получить корректные новые с настроенными редиректами для картиночного поиска. Alt-атрибуты переносятся обязательно — они работают и на доступность, и на ранжирование в Яндекс.Картинках.
• Канонические теги. Проверьте, что rel=canonical настроены правильно и указывают на актуальные адреса, а не на старые URL или чужие страницы.

Совет из практики: автоматический перенос контента всегда нужно проверять выборочно вручную. Импорт может сработать на 95%, но именно оставшиеся 5% страниц с поломанной вёрсткой или потерянными мета часто оказываются самыми трафиковыми.

Этап 5. Сохранение структуры и внутренней перелинковки

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

• Сохраняйте логику вложенности. Если раздел был на втором уровне вложенности, он должен там и остаться. Резкое изменение глубины страниц меняет распределение внутреннего веса.
• Перенесите всю перелинковку. Контекстные ссылки внутри текстов, блоки «похожие материалы», «с этим товаром покупают», навигацию по категориям. Эти связи формируют ссылочный профиль внутри сайта.
• Проверьте, что внутренние ссылки ведут на новые адреса. После переезда все внутренние ссылки должны вести напрямую на финальные URL, а не через редиректы со старых. Иначе вы создаёте лишние цепочки переадресаций внутри собственного сайта.
• Сохраните хлебные крошки и навигационное меню. Они и для пользователя, и для робота служат ориентиром в структуре.
• Не плодите новые дубли. Новая CMS может создавать дополнительные точки входа на одни и те же страницы — следите за этим и закрывайте дубли каноническими тегами.

Грамотная архитектура и перелинковка — это половина успеха в ранжировании. Если вы планируете переезд заодно с пересмотром структуры, имеет смысл подойти к этому системно — об этом я подробно рассказывал в статье про SEO при редизайне сайта, поскольку смена CMS и редизайн часто идут рука об руку.

Этап 6. Перенос микроразметки Schema.org и Open Graph

Микроразметка — то, что часто забывают при переезде, потому что визуально на сайте она незаметна. Но именно она отвечает за расширенные сниппеты в выдаче: звёзды рейтинга, цены, хлебные крошки, информацию об организации.

• Schema.org. Перенесите разметку организации, товаров, статей, отзывов, FAQ, хлебных крошек — всё, что использовалось на старом сайте. Потеря разметки означает потерю привлекательного вида в выдаче и, как следствие, снижение кликабельности.
• Open Graph. Теги og:title, og:description, og:image отвечают за то, как ссылка на ваш сайт выглядит при репостах в соцсетях и мессенджерах. Их потеря делает превью «пустыми».
• Проверка валидности. После настройки прогоните страницы через валидатор структурированных данных Яндекса. Ошибки в разметке не только лишают расширенного сниппета, но иногда вредят восприятию страницы.

Зафиксируйте на этапе аудита, какие типы разметки и где использовались, — тогда на новом движке ничего не потеряется.

Этап 7. Robots.txt, sitemap.xml и управление индексацией

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

• Robots.txt. Главная опасность — забыть, что на тестовой версии сайт был полностью закрыт от индексации директивой Disallow: /. Если этот закрывающий robots.txt уедет на боевой сайт, поисковик выкинет из индекса вообще всё. Перед выкаткой robots.txt проверяется в первую очередь.
• Sitemap.xml. Сгенерируйте новую карту сайта со всеми актуальными URL новой CMS. В ней не должно быть старых адресов, страниц-редиректов и закрытых от индексации страниц. После выкатки отправьте новый sitemap в Яндекс.Вебмастер.
• Мета-тег robots и X-Robots-Tag. Убедитесь, что на нужных страницах нет случайного noindex, который мог остаться с тестового периода.
• Канонические адреса в карте сайта. В sitemap должны попадать только канонические версии страниц, отдающие код 200.

Эти файлы — последний рубеж перед поисковым роботом. Одна неосторожная строка способна перечеркнуть всю проделанную работу, поэтому их проверяют дважды: на стейджинге и сразу после выкатки на боевой домен.

Этап 8. Тестирование на стейджинге перед выкаткой

Никогда не переезжайте «вживую» на рабочем домене. Новая CMS должна быть полностью развёрнута и протестирована на отдельной тестовой площадке (стейджинге), закрытой от индексации. Это ваш полигон, где можно ошибаться без последствий для трафика.

Что проверяется на стейджинге:

• Целостность контента. Выборочно и по топовым страницам — на месте ли тексты, картинки, заголовки, мета-теги.
• Корректность вёрстки. Как страницы отображаются на десктопе и мобильных устройствах. Адаптивность критична для ранжирования в Яндексе.
• Работа редиректов. Прогоните весь список старых URL и убедитесь, что каждый отдаёт 301 и ведёт на верную живую страницу. Это удобно делать краулером по списку.
• Скорость загрузки. Замерьте время отклика и оптимизируйте: кэширование, сжатие, оптимизация изображений. Новый сайт не должен быть медленнее старого.
• Битые ссылки и 404. Прогоните полный краул нового сайта и устраните все внутренние ошибки до выкатки.
• Микроразметка и canonical. Проверьте валидность и корректность.
• Функционал. Формы, корзина, поиск, фильтры, интеграции — всё должно работать.

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

Этап 9. Выкатка и мониторинг в Вебмастере и Метрике

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

Первоочередные действия сразу после выкатки:

• Проверьте robots.txt боевого сайта. Первым делом — убедитесь, что сайт открыт для индексации и не уехал тестовый запрещающий файл.
• Проверьте главную и топовые страницы. Отдают ли код 200, на месте ли контент и мета.
• Прогоните редиректы на боевом домене. Старые URL должны корректно переадресовываться.
• Отправьте новый sitemap.xml в Яндекс.Вебмастер. Это ускорит переобход.
• Используйте переобход страниц. В Вебмастере отправьте на переобход ключевые и изменённые страницы.

Дальше — регулярный мониторинг. В Яндекс.Вебмастере следите за разделами «Диагностика», «Страницы в поиске», «Статистика обхода», количеством ошибок 404, изменениями в индексе. В Яндекс.Метрике контролируйте динамику поискового трафика, поведенческие показатели (отказы, глубина просмотра, время на сайте), отслеживайте резкие провалы по конкретным страницам. Параллельно снимайте позиции по ключевым запросам и сравнивайте с контрольным срезом, сделанным до переезда. Эта операционная работа — часть полноценной технической поддержки и доработки сайта, без которой ни один серьёзный переезд не обходится.

Контрольный период и нормальная динамика после переезда

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

• Первая неделя. Возможны временные просадки, рост числа 404 в Вебмастере по мере того, как робот находит старые URL. Главное — убедиться, что все они корректно переадресуются.
• Первые две-четыре недели. Робот активно переобходит сайт, новые URL входят в индекс, старые из него выходят. Позиции могут «штормить».
• Один-два месяца — контрольный период. К этому сроку при правильном переезде трафик и позиции должны вернуться к прежним значениям, а нередко и превысить их за счёт улучшенной скорости и техники. Если по истечении этого срока показатели не восстановились — значит, где-то допущена ошибка, и нужен повторный аудит.

Если вы видите, что после контрольного периода трафик так и не вернулся, не ждите «само наладится» — чем дольше тянуть, тем сложнее восстановление. Нужно искать причину: непроставленные редиректы, потерянные мета, проблемы с индексацией.

Типичные провалы при переезде на новую CMS

За годы практики я собрал коллекцию типовых ошибок, которые убивают трафик при миграции. Зная их заранее, вы убережёте себя от большинства проблем.

• Запустили сайт вообще без редиректов. Самая катастрофичная ошибка. Все старые URL отдают 404, поисковик массово выбрасывает страницы из индекса, трафик обваливается. Восстановление занимает месяцы.
• Сменили все URL без необходимости. Новая CMS «из коробки» сформировала другую структуру адресов, и её оставили как есть, хотя можно было настроить старые ЧПУ. Тысячи редиректов вместо нуля — это лишний риск на ровном месте.
• Забыли перенести мета-теги. Title и Description затёрлись шаблонными значениями. Релевантность падает, позиции уходят.
• Все редиректы на главную. Вместо постраничного соответствия всё свели на главную страницу. Для Яндекса это «мягкие 404», вес не передаётся.
• Уехал тестовый robots.txt. На боевой сайт попал запрещающий индексацию файл со стейджинга. Сайт целиком выпадает из индекса.
• Цепочки и циклы редиректов. Несколько последовательных переадресаций размывают вес и замедляют обход.
• Потеряли скорость. Новый движок без оптимизации оказался медленнее старого, поведенческие факторы просели.
• Не настроили мониторинг. Переехали и забыли. Проблему заметили только через два месяца по упавшей выручке, когда восстанавливать уже долго и дорого.

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

Чек-лист переезда на новую CMS

Сведу всё сказанное в практический чек-лист, по которому удобно сверяться на каждом этапе проекта.

1. Подготовка. Выгрузить полный список URL из краулера, sitemap, Вебмастера и логов. Собрать реестр мета-тегов, контента, alt-атрибутов, микроразметки. Зафиксировать текущие позиции и трафик как контрольную точку.
2. Карта URL. Составить таблицу соответствия старых и новых адресов. По возможности сохранить URL без изменений. Для каждого старого адреса определить пару или осознанное решение.
3. Контент. Перенести title, description, H1, тексты, изображения, alt — сверить с эталонной таблицей вручную по топовым страницам.
4. Структура. Сохранить вложенность, перелинковку, хлебные крошки. Внутренние ссылки направить на финальные URL.
5. Микроразметка. Перенести Schema.org и Open Graph, проверить валидатором.
6. Технические файлы. Подготовить корректный robots.txt и новый sitemap.xml. Убедиться в отсутствии случайных noindex.
7. Редиректы. Настроить 301 по карте, без цепочек, со склейкой зеркал. Проверить коды ответа.
8. Стейджинг. Полностью протестировать на закрытой площадке: контент, вёрстку, редиректы, скорость, битые ссылки, функционал.
9. Выкатка. Переключиться в период низкой активности. Сразу проверить robots.txt, топовые страницы, редиректы. Отправить sitemap и страницы на переобход в Вебмастер.
10. Мониторинг. 1–2 месяца следить за Вебмастером и Метрикой, отслеживать 404, индексацию, позиции, поведенческие факторы. Оперативно править найденные ошибки.

Примерный таймлайн проекта

Сроки зависят от размера сайта, но для ориентира приведу типовую раскладку для среднего корпоративного сайта или интернет-магазина.

• Неделя 1–2. Аудит и выгрузка. Сбор полного реестра URL, мета, контента, разметки. Снятие контрольных срезов позиций и трафика.
• Неделя 2–4. Разработка и карта URL. Развёртывание новой CMS на стейджинге, перенос контента, составление карты соответствия адресов. Эти процессы идут параллельно.
• Неделя 4–6. Настройка и тестирование. Редиректы, микроразметка, robots, sitemap. Полный прогон стейджинга, устранение ошибок, оптимизация скорости.
• Неделя 6. Выкатка. Переключение на новую CMS в период низкой нагрузки, немедленная проверка ключевых параметров, отправка sitemap и переобход.
• Неделя 6–14. Контрольный период. 1–2 месяца активного мониторинга и точечных правок до полного восстановления и стабилизации показателей.

Эти сроки — ориентир. Крупные порталы с десятками тысяч страниц требуют больше времени на аудит и тестирование, а небольшие сайты-визитки переезжают быстрее. Но пропускать или сжимать этапы аудита и тестирования нельзя ни при каком размере проекта.

Вывод

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

Честно говоря, переезд — это та задача, где самодеятельность обходится особенно дорого. Слишком много мелких деталей, каждая из которых способна стоить вам позиций, нарабатывавшихся годами. Если вы не уверены в своих силах или цена вопроса высока, разумнее доверить миграцию специалистам, которые проводили подобные переезды десятки раз и знают, где скрыты подводные камни. В SEO ПРОГРЕСС мы переносим сайты на новые CMS без потери трафика и позиций под ключ — от аудита до полного восстановления показателей. Посмотрите наши кейсы, чтобы оценить результаты, и свяжитесь с нами — поможем спланировать и провести переезд так, чтобы он стал точкой роста, а не источником проблем.