Как перенести сайт на другую CMS и сохранить позиции

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

Ниже разобрано, когда смена движка оправдана, какие риски она несет и как сохранить позиции: от резервной копии и таблиц URL до тестирования, запуска и проверок после релиза. Алгоритм подойдет и тем, кто переносит сайт самостоятельно, и тем, кто ставит задачу разработчику.

10 часов вебмастеринга на 3 месяца в подарок

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

Получить подарок

Читайте также:

Анализ позиции сайта в Яндексе и Google: как их снять, 11 лучших сервисов для проверки

Когда стоит менять движок сайта

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

1. Сайт не соответствует потребностям бизнеса — как в функциональном, так и в техническом аспекте.
2. Невозможно добавить необходимую функцию, например систему скидок на определенные категории товаров.
3. Сайт морально устарел, и внедрить необходимые технологии нельзя. Особенно эта проблема характерна для самописных движков и старых версий коробочных CMS.
4. Сайт работает на SaaS-платформе или конструкторе, а не на полноценной CMS.
5. В коде много технических ошибок и конфликтов.
6. Сайт загружается очень долго, и стандартные методы, например кэширование страниц, не помогают.
7. Сайт создает высокую нагрузку на хостинг.

CMS (система управления сайтом) — программное обеспечение, которое позволяет публиковать, упорядочивать, изменять и удалять разные виды контента: не только текст, но и встроенные изображения, видео, аудио и интерактивный код.

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

Пример из практики Kokoc: у оптово-розничного продавца стройматериалов «Вудсток» (Woodstock.ru) самописная админка не позволяла внедрить региональные папки. Агентство предложило перенести сайт на «Битрикс», и в мае 2018 года его перенесли и запустили региональные папки. Небрендовый поисковый трафик клиента вырос с 26 739 визитов в октябре 2016 года до 46 918 в октябре 2019 года, но этот результат дал комплекс работ, а не один переезд (кейс).

Риски при смене движка

Смена CMS меняет адреса и структуру страниц, поэтому влияет на индексацию и позиции сайта в поиске. Основные риски такие:

1. Старые адреса перестают открываться и со временем выпадают из индекса, если на них не настроены редиректы.
2. При отсутствии или ошибках редиректов ссылки на старые адреса перестают работать, а корректные постоянные редиректы, по данным Google, потерю PageRank не вызывают.
3. Позиции и трафик временно колеблются: по справке Google, при существенных изменениях сайта это происходит, пока поисковая система заново обходит и индексирует страницы.
4. Часть функций старой CMS может пропасть, поэтому их проверяют до переезда.
5. Метатеги и структура URL меняются, если их не перенести.

После смены CMS обычно меняется вид адресов, и старые страницы становятся недоступными. «Яндекс» рекомендует при смене адреса настраивать 301-й серверный редирект: тогда робот индексирует цель перенаправления и удаляет из поиска ранее известные ему страницы. Например, до переезда адрес категории выглядел так: abc.com/category/blog, а после смены CMS стал таким: abc.com/blog.html. Чтобы старые адреса не потерялись, их сопоставляют с новыми в таблицах URL.

Как сохранить позиции и трафик при переезде на новую CMS

Переезд безопаснее всего, когда адреса, контент и структура остаются прежними: тогда новый сайт воспроизводит старый на другом движке. Для этого соблюдают три правила:

• сохранить текущие URL страниц;
• сохранить контент страниц;
• сохранить структуру сайта.

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

Если движок не позволяет сохранить адреса, старые URL сопоставляют с новыми и настраивают постоянные редиректы по алгоритму ниже.

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

Егор Трушников

Директор по развитию и стратегическим продуктам в Kокос Group

5 классных SEO-кейсов

Круче, чем Гудини: как мы вырастили трафик в 2,2 раза

Все вы прекрасно знаете Гарри Гудини: этот фокусник мог выбраться из закрытой бочки, брошенной в воду. Примерно в таких же рамках оказались и мы, начиная работу с сайтом Eurorepar. Узкий функционал, жесткие требования. Но мы справились без магии, увеличив трафик х2!

Читать кейс

Читать кейс

Как выжать максимум из двадцатилетнего сайта

Можно ли выжать максимум из 20-летнего сайта и докрутить его до современных стандартов? А если есть отягчающие обстоятельства — накрутка поведенческих факторов, антиботы, да еще и админка капризничает и сама удаляет категории?

Читать кейс

Читать кейс

Долгая дорога в SEO и мощный прорыв

Наш клиент — интернет-магазин B2B промышленной тематики. Он достался нам после предыдущих подрядчиков, и первые год-два мы исправляли их ошибки. А потом началась долгая кропотливая работа, которая в итоге принесла желанный результат.

Читать кейс

Читать кейс

Qugo: вырастили трафик из блога платформы b2b в 9,7 раз!

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

Читать кейс

Читать кейс

Эффективное ссылочное продвижение для федеральной аптечной сети

Федеральная аптечная сеть пришла в Kokoc Performance (входит в Kokoc Group) за ссылочным продвижением. Интересно, что в компании есть своя in-house команда по SEO, которая подготовила ссылочную стратегию, а за ее реализацией обратилась к нам.

Читать кейс

Читать кейс

1/5

Читайте также:

Что такое DNS сервер простыми словами

Пошаговый алгоритм при переезде на новую CMS

Переезд проходит в несколько этапов: подготовка, сбор старых URL, установка CMS и перенос данных, тестирование и запуск, контроль результата. Начинают с резервной копии: перед переездом сохраняют все файлы и базу данных сайта.

До начала переезда стоит зафиксировать точку отсчета: позиции по основным запросам, трафик и страницы с наибольшим трафиком и конверсиями. Это позволит после запуска понять, связано ли падение трафика с потерей позиций.

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

1. Метатеги для страниц делаются в виде шаблонов.
2. Сохранение существующей поисковой оптимизации страниц.
3. Сохранение структуры сайта и его главных разделов.
4. Сохранение существующих типов страниц.
5. Список обязательных мероприятий: генерация карты сайта, настройка robots.txt, проверка кодов ответа, проверка работы страниц фильтров и пагинации.

Для небольшого проекта переезд реально выполнить без разработчика, и порядок действий для такого случая описан ниже.

Сбор старых URL и таблицы редиректов

Адреса удобнее собирать в таблице: так проще сопоставить страницы старой и новой версий сайта и настроить корректное перенаправление. Понадобятся парсер и программа для работы с таблицами. Старые URL собирают инструментом со встроенным парсером, например Screaming Frog или WebSite Auditor. Ниже порядок действий показан на примере WebSite Auditor, но выгрузка таблицы в CSV в нем есть только в тарифах Enterprise и Max: возможность купить лицензию стоит проверить заранее.

1. Установить WebSite Auditor на компьютер и указать домен старого сайта.
2. Дождаться, пока сервис просканирует домен.



3. Открыть раздел «Структура сайта» и отчет по страницам.



4. Выбрать параметры, которые должны попасть в таблицу после экспорта.





5. Экспортировать данные по всем страницам с помощью значка экспорта.



6. Указать, куда сохранить таблицу.

В таблице понадобятся данные каждой страницы: URL, Title (заголовок страницы), код ответа, Description и количество H1. Выгрузку вставляют на чистый лист в Microsoft Office или «Google Таблицах», например в таблицу «Сопоставление URL». Столбец «Новый адрес страницы» пока остается пустым.

Тот же парсинг повторяют для новой версии сайта и вписывают новый адрес каждой старой страницы в добавленный столбец, проверив, как она открывается на новом сайте. Если аналога на новом движке нет, в таблице ставят пометку «404-й ответ».

Когда таблица «Сопоставление URL» готова, создают вторую, «Формирование редиректов», с тремя столбцами: «Старый URL», «Новый URL» и «Правило редиректа». В нее переносят каждую ссылку старой версии, для которой есть соответствие на новом сайте. Для постоянного переезда в правиле указывают постоянные редиректы 301 или 308, потому что временные оставляют в выдаче исходную страницу.

Установка CMS, перенос контента и редиректы

Новую версию разворачивают на локальном сервере или тестовом домене. Тестовую версию закрывают паролем или директивой noindex: по справке Google, robots.txt не убирает страницу из поиска, а закрытый в нем адрес может попасть в выдачу, если на него ссылаются. Если тестовый домен закрыт паролем, дополнительно в robots.txt можно прописать User-agent: * и Disallow: /. При использовании noindex не закрывайте эти же страницы в robots.txt: робот не прочитает директиву. Перед релизом пароль, noindex и эти директивы снимают, а «боевой» robots.txt готовят заранее, иначе новые страницы останутся закрытыми для обхода и не попадут в поиск.

Затем устанавливают выбранный движок. Новый движок формирует URL по своим правилам, поэтому вид ссылок настраивают заранее. Кроме того, настраивают основные разделы и структуру, меняют дизайн и подключают плагины.

Вместе с контентом переносят оптимизацию: Title, Description и H1, тексты, атрибуты alt у изображений, микроразметку, canonical и формы, а также базу данных и файлы сайта. При работе с разработчиком ему передают обе таблицы. Если на сайте тысячи страниц, данные импортируют скриптом, который поможет подготовить разработчик, а при небольшом числе страниц достаточно ручного копирования.

Редиректы настраивают серверные, 301 или 308, для всех старых страниц, у которых есть соответствие. Много старых адресов нельзя направлять на главную: Google предупреждает, что это может быть воспринято как soft 404. Цепочек редиректов лучше избегать, в идеале не больше трех переходов. Редиректы сохраняют как можно дольше, как правило не меньше года. На Apache без доступа к основной конфигурации (типично для виртуального хостинга) правила прописывают в .htaccess, на nginx — директивой return в конфигурации.

Тестирование, запуск и контроль результата

После установки CMS, переноса контента и настройки редиректов проверяют новую версию. Нужно проверить работу форм и кнопок, а основные разделы должны открываться через меню, если оно предусмотрено дизайном. Отдельно проверяют статические страницы, мобильную версию, страницу 404 и коды ответа: новые адреса должны отвечать 200 OK. В интернет-магазине дополнительно тестируют карточки товаров, корзину и оформление заказа, а также учитывают сложности сайта: фильтры, пагинацию.

Если новая версия работает корректно, подключают панели вебмастеров и веб-аналитику: Google Search Console, «Яндекс Вебмастер», «Яндекс Метрику» и Google Tag Manager. Код счетчика «Яндекс Метрики» добавляют в HTML всех страниц как можно ближе к началу, код Google Tag Manager при ручной установке — как можно выше в теге head; для многих CMS есть интеграции без правки кода каждой страницы. Если права в Search Console подтверждены файлом или метатегом, их переносят на новую версию.

Карту сайта формирует сама CMS или плагин: WordPress, например, начиная с версии 5.5 создает ее по адресу /wp-sitemap.xml, но отключает, если в настройках включен запрет индексирования. Готовую карту сайта загружают в «Яндекс Вебмастер» и Google Search Console.

После запуска следят за посещаемостью и позициями. По данным Google, у сайта среднего размера на показ новых адресов вместо старых уходит несколько недель и дольше, у крупных еще дольше, поэтому колебания в первые недели ожидаемы. Сравнивать нужно трафик старых и новых адресов: на старых он снижается, на новых растет. Если падение сильнее ожидаемого, проверяют редиректы, коды ответа, noindex на новых страницах и robots.txt. Инструмент «Смена адреса» в Search Console нужен при переезде на другой домен или поддомен, а при смене только CMS на том же домене не требуется. Владельцев сайтов, с которых на старые адреса ведут внешние ссылки, стоит попросить обновить ссылки.

Перед релизом составьте список ключевых URL: самые посещаемые страницы, посадочные страницы рекламы, страницы с формами. Приемку начинайте с них и проверяйте код ответа, редирект, Title и canonical. Пока по этому списку есть хотя бы одна ошибка, запуск лучше не подтверждать.

Рудакова Светлана

Руководитель комплексных проектов Kokoc Performance

Эффективное SEO

• Гарантия результатов
• Комплексное развитие
• При любом тарифе отслеживаем динамику заявок и звонков с сайтов
• Регулярный пересмотр семантического ядра

Узнать больше

Читайте также:

Что такое хостинг сайта: как выбрать хостинг в 2026 году

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

После успешного запуска старую версию сайта не удаляют: она может пригодиться для сравнения данных и отката. Сразу после релиза проверяют следующее.

1. Привязку сайта к счетчикам: данные «Яндекс Метрики» и другой системы аналитики должны поступать с новой версии.
2. Файл robots.txt: новая версия сайта должна быть открыта для индексации, ограничения тестовой версии сняты.
3. Позиции новой версии: их сравнивают со значениями, зафиксированными до переезда.
4. Сканирование новой версии краулером Screaming Frog (без лицензии — до 500 адресов): не должно быть критических ошибок и дублей страниц, все страницы отдают корректный код, а теги переехали правильно. Битые ссылки находят через Bulk Export, пункт Client Error 4XX Inlinks.
5. Цепочки и циклы редиректов: для всего сайта их выгружают в отчетах Screaming Frog Redirect Chains, а для выборочной проверки нескольких адресов подойдет онлайн-сервис Majento.
6. Внутренние ссылки, ссылки в меню, canonical и hreflang (если есть языковые версии): все они ведут на новые URL, а canonical каждой страницы — на нее саму.

Когда переезд на другой движок не нужен

Смена CMS не решает проблему, если сайт плохо ранжируется или на текущей платформе не хватает плагинов: такие вопросы часто решаются без глобального переезда. Если страницы не попадают в индекс, сначала проверяют технические причины. Google называет среди частых правило в robots.txt, закрывающее разделы сайта, большое число дублей и редиректы, при которых в индекс попадает только конечный адрес. Если технических причин нет, дальше работают над качеством сайта и контентом, добиваясь его пользы для читателей.

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

Коротко о главном

• Безопаснее всего сохранить прежние адреса, контент и структуру и менять их после переиндексации; иначе старые URL сопоставляют с новыми и настраивают редиректы.
• Перед переездом нужны резервная копия файлов и базы данных, снимок позиций и трафика и, при работе с подрядчиком, техническое задание.
• Основа переезда — таблицы «Сопоставление URL» и «Формирование редиректов»: 301 или 308 для страниц с аналогом, 404 или 410 для остальных.
• Тестовую версию закрывают паролем или noindex, перед релизом ограничения снимают, а после установки проверяют формы, коды ответа, карту сайта и счетчики.
• После запуска сравнивают трафик старых и новых адресов, проверяют цепочки редиректов, canonical и внутренние ссылки, а старую версию не удаляют.