Перенос сайта на другую CMS без потери SEO

Что делать до, во время и после миграции, чтобы не потерять трафик и позиции

Почему перенос сайта — это не только «поставить новый движок»

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

Риски миграции хорошо описаны в специализированных разборах переноса сайтов: чаще всего страдают позиции из-за изменения структуры URL и перераспределения ссылочного веса между страницами, а также органический трафик в первые недели, пока поисковые системы заново обходят сайт [2]. Отдельно подчёркивается, что даже небольшая ошибка в редиректах, структуре URL или настройке индексации способна привести к заметной просадке позиций [2].

Материал рассчитан на владельцев сайтов, маркетологов и технических специалистов, которые планируют переезд с одной CMS на другую (например, с Tilda на 1С-Битрикс, с самописного движка на WordPress или с WordPress на Bitrix) и хотят заранее понимать, какие шаги обязательны для сохранения SEO.

Что такое SEO-миграция и чем перенос CMS отличается от смены домена

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

• Смена CMS без смены домена. Сайт остаётся на том же адресе, но полностью меняется движок, шаблоны и, как правило, структура URL. Это самый частый случай при переезде с конструктора (Tilda) на полноценную CMS (Bitrix, WordPress) или между «взрослыми» CMS.
• Смена CMS одновременно со сменой домена. Помимо переноса контента, меняется и сам адрес сайта. Здесь добавляется отдельный набор действий — прежде всего использование инструмента смены адреса в поисковых системах.

Для доменных миграций у Google есть отдельный инструмент — Change of Address в Search Console, который сообщает Google о переезде и переносит часть сигналов ранжирования на новый домен [4]. Если меняется только CMS, а домен и адреса страниц остаются прежними, этот инструмент не нужен — риски здесь в основном технические (скорость, вёрстка, поведение сервера), а не связанные со сменой адреса [3]. Если же вместе с CMS меняется и структура URL, Google рекомендует относиться к этому как к отдельному сценарию «переезда с изменением URL»: подготовить карту соответствия старых адресов новым и настраивать редиректы именно по ней [3].

Аналогичная логика действует и в Яндексе: при изменении структуры и дизайна сайта важно убедиться, что важные страницы не закрыты в robots.txt, а для отсутствующих страниц настроить 301-редирект на главную страницу соответствующего раздела или на близкую по теме страницу [5]. Если одновременно со сменой CMS меняется и домен, для этого предусмотрен отдельный инструмент «Переезд сайта» в Яндекс.Вебмастере, который ускоряет обработку изменений роботом [6].

Как поисковые системы «видят» перенос сайта

Когда меняется CMS, для робота меняется почти всё: HTML-код страниц, порядок элементов, скорость ответа сервера, а часто и адреса URL. Робот не знает заранее, что «/catalog/divany/» на старом сайте и «/catalog/divan/» на новом — это одна и та же страница с одним и тем же товаром. Единственный надёжный способ объяснить это — прямой 301-редирект со старого адреса на новый.

Если редиректа нет, происходит следующее:

• старая страница со временем выпадает из индекса как недоступная (404 или 410);
• новая страница индексируется «с нуля», без накопленной истории ссылок и поведенческих сигналов;
• ссылочный вес, который вела на старую страницу внешняя ссылка, никуда не передаётся.

Именно поэтому специалисты по техническому SEO подчёркивают: поисковику для сохранения позиций нужны однозначные сигналы — либо совпадающие URL, либо корректные постоянные редиректы, актуальный sitemap и стабильная работа сайта после переезда [9]. Там же отмечается практический риск: если команда, которая делает перенос, не различает постоянный (301) и временный (302) редирект или не умеет выгрузить полный список URL из старой CMS, любые обещания сохранить SEO остаются декларацией [9].

Российская специфика: Яндекс и Google одновременно

Для сайтов, работающих на российскую аудиторию, миграцию нужно готовить сразу под два независимых робота — Яндекса и Google, — у которых разные инструменты и разная скорость реакции.

Google. Официальная документация Google Search Central описывает общий порядок действий при переезде сайта: подготовить и тщательно протестировать новую версию сайта, составить карту соответствия старых URL новым, настроить редиректы на сервере, отслеживать трафик на старых и новых адресах и, при необходимости, разбить перенос на этапы для крупных сайтов [3]. При смене домена отдельно рекомендуется подавать запрос через Change of Address для каждой подтверждённой версии старого домена — с www, без www и для всех поддоменов — и держать редиректы активными как можно дольше, как правило не менее года [3]. Google прямо предупреждает: в процессе переезда стоит ожидать временных колебаний позиций [3].

Яндекс. Если структура и дизайн сайта меняются в рамках одного домена, Яндекс рекомендует проверить ответ сервера инструментом «Проверка ответа сервера», убедиться, что важные страницы не закрыты в robots.txt, и настроить 301-редиректы там, где старые страницы больше не существуют [5]. При смене домена нужно подтвердить оба сайта в Яндекс.Вебмастере, настроить 301-редирект на сервере и подать заявку через инструмент «Переезд сайта» в разделе «Индексирование» [6]. Технически 301-редирект в файле .htaccess остаётся основным способом сообщить о постоянном переезде с одного адреса на другой [7]. Для большинства случаев Яндекс предлагает переезд с сохранением прежней структуры URL как более простой и безопасный вариант по сравнению с одновременной сменой структуры адресов [8].

Для российского контекста важно и то, что процесс подтверждения переезда в Яндекс.Вебмастере не завершается моментально: сообщение о переезде исчезает из панели постепенно, поэтому стоит подписаться на уведомления и не паниковать при временных задержках в обновлении поисковой базы [6].

Что происходит при переносе между конкретными CMS

Типовые пары миграций в России — переезд с конструкторов (Tilda) на «взрослые» CMS (1С-Битрикс, WordPress) и обратно, а также переходы между WordPress и Bitrix. У каждой пары свои технические ловушки.

С Tilda на CMS с базой данных (Bitrix, WordPress). Ключевая сложность в том, что Tilda — визуальный конструктор, где всё строится на готовых блоках и шаблонах, а структура данных недоступна напрямую, в отличие от Bitrix, где контент организован через инфоблоки, свойства и модули [10]. Из-за этого перенос с Tilda нередко превращается в почти новый проект: контент переносится вручную, а функциональность и дизайн реализуются заново, что заметно сложнее переноса с WordPress, где структура CMS уже стандартизована и экспорт-импорт можно частично автоматизировать [10]. Отдельная техническая проблема — в Tilda нет встроенного инструмента для 301-редиректов, поэтому для их настройки приходится использовать сторонние сервисы или возможности DNS-провайдера [11].

С Bitrix или WordPress на другую CMS. Здесь основной объём работы — не дизайн, а данные: карточки товаров, инфоблоки, пользовательские свойства, история заказов. Практика показывает, что при переносе с одной CMS на другую критично заранее выгрузить полный список URL старой CMS и не путать постоянные редиректы с временными — именно эти два фактора чаще всего определяют, «выживет» ли SEO после переезда [9].

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

Пошаговый процесс миграции с сохранением SEO

Этап 1. Подготовка и SEO-аудит текущего сайта

Прежде чем переносить сайт, нужно точно знать, что на нём есть сейчас. Для этого проводят полный краулинг боевого сайта специализированным краулером (например, Screaming Frog) и сохраняют результат — это станет эталоном для сравнения с новой версией сайта [12]. В рамках такого аудита фиксируют: полный список URL и их статус-коды, заголовки Title и Description, структуру заголовков H1–H6, внутреннюю перелинковку, статус индексации, alt-тексты изображений и разметку Schema.org / Open Graph [13].

Отдельно стоит проверить сайт с User-agent Googlebot и Yandexbot: некоторые сайты по ошибке отдают разный контент разным роботам, и такие расхождения важно найти до переноса [14].

Итог этапа — таблица с полным списком существующих URL, их метаданными и текущими позициями/трафиком по ключевым страницам (данные можно выгрузить из Яндекс.Метрики, Google Analytics, Яндекс.Вебмастера и Search Console).

Этап 2. Карта редиректов

На основе выгруженного списка URL составляется таблица соответствия: «старый адрес → новый адрес». Она должна покрывать 100% страниц, у которых был хоть какой-то трафик, входящие ссылки или индексация — не только «главные» разделы. Если у части старых страниц на новом сайте нет прямого аналога, их направляют на ближайшую по смыслу страницу (категорию, раздел), а не просто на главную — это рекомендация, которую даёт и Яндекс для случаев, когда конкретная страница пропала, но тематика сайта осталась прежней [5].

Здесь же важно на уровне процесса зафиксировать разницу между 301 (постоянный) и 302/307 (временный) редиректом: для завершённого переезда должен использоваться исключительно 301, иначе поисковая система будет и дальше считать старый адрес основным [9].

Этап 3. Перенос контента и SEO-элементов

На новую CMS нужно перенести не только тексты, но и весь набор SEO-значимых элементов: title, description, H1, alt-атрибуты изображений, канонические ссылки, микроразметку Schema.org, hreflang (если есть мультиязычность) и структуру внутренней перелинковки. Разные CMS по-разному организуют хранение этих полей, поэтому автоматический перенос почти никогда не бывает стопроцентным — обязательна ручная сверка выборки страниц с эталонным краулингом из этапа 1.

Отдельно стоит проверить технические особенности новой CMS: как она генерирует sitemap.xml, robots.txt, канонические адреса для пагинации и фильтров, и не создаёт ли она новые дубли страниц (например, одну и ту же карточку товара по нескольким URL с параметрами).

Этап 4. Тестирование на закрытом стенде

Новую версию сайта разворачивают на тестовом домене или поддомене, закрытом от индексации через robots.txt (Disallow: /) и, желательно, через noindex — либо ограничивают доступ по паролю или IP, чтобы исключить случайную индексацию черновой версии. На этом стенде:

• сверяют список URL с картой редиректов;
• проверяют корректность статус-кодов;
• тестируют скорость загрузки и Core Web Vitals — это отдельный фактор ранжирования Google, использующий такие показатели, как LCP, CLS и общий вес страницы [14];
• проверяют мобильную версию: Google использует именно мобильную версию сайта для индексирования и ранжирования в рамках mobile-first indexing.

Этап 5. Запуск и настройка редиректов на боевом сайте

После успешного тестирования редиректы включают на реальном домене. Для CMS-миграции без смены домена достаточно корректно настроенных 301-редиректов и обновлённого sitemap.xml, отправленного в Яндекс.Вебмастер и Google Search Console. Если одновременно меняется домен, дополнительно:

• подают заявку через «Переезд сайта» в Яндекс.Вебмастере с обеих подтверждённых версий сайта [6];
• отправляют запрос Change of Address в Google Search Console для всех подтверждённых вариантов старого домена — с www, без www, для всех поддоменов [3];
• держат редиректы активными долго: Google рекомендует не менее года для передачи всех сигналов ранжирования, а с точки зрения пользователей — рассматривать возможность держать их бессрочно [3].

Этап 6. Мониторинг после запуска

Первые недели после переноса — самый критичный период. Рекомендуется отслеживать не только позиции и трафик, но и число страниц в индексе, ошибки сканирования, доступность аналитики и конверсии, поскольку резкие отклонения от привычной динамики требуют немедленной проверки [15]. Тревожными сигналами считаются: массовое исчезновение страниц из индекса, резкий рост числа ошибок 404, длительное (несколько недель) снижение органического трафика без признаков восстановления, более сильная потеря позиций по коммерческим запросам по сравнению с информационными и сообщения поисковых систем о проблемах со сканированием сайта [15].

Скорость переиндексации зависит от размера сайта: небольшой сайт поисковые системы могут обработать за несколько дней, а крупный каталог или интернет-магазин — за несколько недель или дольше [15].

Сроки восстановления позиций и трафика

Даже при аккуратной миграции временная просадка почти неизбежна — это нормальная часть процесса, а не признак ошибки. По оценкам практикующих специалистов, при корректно настроенных редиректах и полностью сохранённом контенте позиции обычно возвращаются к исходному уровню в течение 2–6 недель, при смене домена этот срок увеличивается до 2–4 месяцев, а при серьёзных ошибках — отсутствии редиректов или потере контента — восстановление может растянуться на 6–12 месяцев и не гарантировано вовсе [16]. Оценивать успех миграции корректно не раньше, чем через 3–6 месяцев после запуска, ориентируясь на сохранение или рост органического трафика и позиций по ключевым страницам [17].

Это стоит держать в голове при планировании: если перенос затрагивает интернет-магазин с высоким сезонным трафиком, миграцию логично планировать заранее, вне пиковых периодов продаж.

Типичные ошибки при переносе CMS

• Редиректы 302 вместо 301. Временный редирект не передаёт полноценно сигналы ранжирования и не сообщает поисковику, что старый адрес больше не актуален.
• Редирект «всё на главную». Массовое перенаправление всех старых URL на главную страницу вместо релевантных разделов резко снижает релевантность и обычно ускоряет потерю позиций, а не сохраняет их.
• Закрытая индексация после запуска. Частая ошибка — забыть снять Disallow: / или noindex, которые стояли на тестовом стенде, при переносе конфигурации на боевой сайт.
• Несовпадающий или неотправленный sitemap.xml. Устаревшая карта сайта тормозит обнаружение новых URL и продлевает переиндексацию.
• Потеря части контента и метаданных. Автоматические миграторы часто переносят тексты, но теряют alt-теги, микроразметку или канонические ссылки — без ручной сверки это остаётся незамеченным до просадки трафика.
• Отсутствие карты редиректов для «длинного хвоста». Команды часто прорабатывают редиректы для главных разделов, но забывают про архивные статьи, карточки товаров, снятые с продажи, и старые посадочные страницы, на которые всё ещё ведут внешние ссылки.
• Игнорирование Яндекса при фокусе на Google (или наоборот). У каждой системы своя панель, свои инструменты подтверждения переезда и своя скорость обработки — процесс нужно вести параллельно в обеих.
• Одновременный редизайн и смена CMS без разделения рисков. Полная смена дизайна, структуры и платформы за один релиз усложняет диагностику: если позиции просели, сложно понять, что стало причиной — редиректы, контент или новая вёрстка.

Когда достаточно точечных доработок, а когда нужна полноценная миграция

Не каждая проблема с CMS требует полного переноса. Если сайт работает медленно, но структура и SEO-показатели устраивают, зачастую достаточно точечной технической доработки — оптимизации кеширования, базы данных, изображений и серверной части — без смены платформы. Показателен пример проекта на 1С-Битрикс, где ручная оптимизация фронтенда, компонентов CMS и сервера позволила поднять оценку Lighthouse главной страницы с 38 до 89 баллов и снизить вес главной страницы примерно на 98% без миграции на другую CMS [18].

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

Как может помочь «Пятый фактор»

Команда «Пятого фактора» специализируется на точечной технической работе с сайтами на 1С-Битрикс: ручном ускорении интернет-магазинов, техническом SEO-аудите и настройке интеграций с 1С и внешними системами. Применительно к переносу сайта на другую CMS это может выглядеть так: перед миграцией — техническое SEO-обследование текущего магазина на Битрикс, чтобы зафиксировать эталонное состояние сайта и список критичных URL; после переноса — проверка корректности редиректов, индексации, скорости и интеграций с 1С на новой платформе. Если решение о полной смене CMS ещё не принято, а проблема в первую очередь в скорости и стабильности существующего магазина на 1С-Битрикс, команда может сначала оценить, достаточно ли точечного ускорения без миграции.

Команда «Пятого фактора» может изучить задачу, оценить возможные варианты и помочь с технической частью — от аудита перед переносом до настройки интеграций и проверки SEO после запуска на новой платформе.

Вывод

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

Источники

[1] advermedia.ua — Миграция сайта без потери SEO: полное руководство для бизнеса и маркетологов — https://advermedia.ua/ru/blog/migratsiya-sayta-bez-poteri-seo-poshagovyy-gayd/

[2] arcticlab.pro — Перенос сайта на другую CMS: как перенести сайт без потери позиций и трафика — https://arcticlab.pro/blog/seo/perenos-sajta-na-druguyu-cms/

[3] developers.google.com — Site Moves and Migrations, Google Search Central — https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes

[4] support.google.com — Change of Address tool, Search Console Help — https://support.google.com/webmasters/answer/9370220?hl=en

[5] yandex.ru — Смена структуры и дизайна сайта, Яндекс.Вебмастер — https://yandex.ru/support/webmaster/ru/recommendations/changing-site-structure

[6] yandex.ru — Переезд сайта на новое доменное имя, Яндекс.Вебмастер — https://yandex.ru/support/webmaster/ru/yandex-indexing/moving-site

[7] ddsi.ru — Переезд сайта в Яндекс Вебмастер и Search Console: смена домена — https://ddsi.ru/blog/pereezd-sajta-v-yandeks-vebmaster-i-search/

[8] romikey.ru — Как организовать переезд сайта на новый домен — https://romikey.ru/blog/pereezd-sajta-na-novyj-domen/

[9] dev.to — Почему миграции с WordPress на Bitrix рушат SEO — https://dev.to/_vproger_/pochiemu-mighratsii-s-wordpress-na-bitrix-rushat-seo-12k7

[10] mediahead.ru — Перенос сайта на 1С-Битрикс без потери SEO — https://mediahead.ru/blog/1c-bitrix/perenos-saytov-na-1s-bitriks/

[11] seohead.pro — Миграция сайта с Битрикс на Тильда: типичные риски и решения — https://seohead.pro/blog/migratsiya-sayta-s-bitriks-na-tilda-tipichnye-podvodnye-kamni-i-resheniya/

[12] 1seller.ru — Screaming Frog SEO Spider: полный гид по краулеру для SEO — https://1seller.ru/screaming-frog-seo-spider-polnyj-gid-po-instrumentu

[13] skyeng.ru — Узнайте всё о Screaming Frog для анализа сайтов — https://skyeng.ru/it-industry/it/uznayte-vse-o-screaming-frog-dlya-analiza-sayta/

[14] mamontov.top — Screaming Frog: как проводить технический аудит сайта — https://mamontov.top/screaming-frog-kak-provodit-tehnicheskij-audit-sajta

[15] serptop.ru — Переезд сайта без потери трафика: пошаговый план миграции — https://serptop.ru/blog/migraciya-sayta-bez-poteri-trafika-kak-pravilno-perenesti-sayt-i-sohranit-pozicii/

[16] mamontov.top — Миграция сайта и SEO: как сохранить позиции при переезде — https://mamontov.top/migracija-sajta-i-seo-kak-sohranit-pozicii-pri-pereezde

[17] tadviser.ru — Миграция сайта – это стратегическое решение, а не просто перенос данных — https://www.tadviser.ru/index.php/Новости:Миграция_сайта_–_это_стратегическое_решение,_а_не_просто_перенос_данных

[18] 5factor.ru — Пятый фактор — https://5factor.ru/