Как изменить cms сайта

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

Краткое отступление. Чтобы не повторить подобных ошибок (смены CMS-системы), рекомендуем внимательно изучить нашу статью от 2019 года про интернет-магазины на шаблоне. Там описаны основные проблемы каждого популярного движка сайта и взяты краткие интервью у программистов. Информация в статье актуальна по настоящее время (осень 2020 года), за исключением стоимости услуг программистов.

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

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

В кейсе присутствуют скриншоты из метрики. В целях конфиденциальности клиента и его интернет-магазина данные на графике частично скрыты (замазаны).

Краткая информация о проекте

Поставленные цели для переезда на новый движок

Этап 1. Сбор семантического ядра

Переезд сайта был запланирован на февраль-март 2019 года (спустя два месяца после старта работ). Контент-менеджер, программист и дизайнер активно занимались доработками сайта на новом движке. Работы по SEO начались в декабре 2018 года. В запасе было несколько месяцев на сбор и проработку семантического ядра с целью дальнейшего построения структуры на новом сайте.

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

Отчет по этапу 1

Трудозатраты:

Что сделано:

Этап 2. Позиции, структура, приоритизация

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

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

Рекомендации по наполнению служебных страниц, например, “О компании” или “Контакты”, вы также можете найти в нашем блоге.

Второй этап продлился несколько месяцев: с февраля по март. Программист клиента не укладывался в срок. Работы по переносу движка сдвигаем до следующего этапа. Чтобы не терять время, договариваемся с клиентом об оптимизации страниц услуг по сервису и ремонту техники. Сайт позиционируется как интернет-магазин, оказывающий услуги сервисного обслуживания и ремонта всей реализуемой продукции. Результаты съема позиций приведены на рисунке 2.

Исходя из данных, представленных на рисунке 2, делаем следующие выводы:

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

Отчет по этапу 2

Трудозатраты:

Что сделано:

На первом этапе мы проработали семантику и структуру сайта по его коммерческим категориям товаров, за исключением раздела “Сервис и ремонт”. На втором этапе собрано и кластеризовано семантическое ядро по указанному разделу с последующим переходом к составлению ТЗ на контент.

В феврале-марте 2019 года у нас отсутствовали чек-листы и готовые регламенты для наполнения служебных страниц сайта в соответствии с асессорскими требованиями (рекомендациями) от Google. В большей степени ТЗ по наполнению служебных страниц сводились к анализу конкурентов клиента, основных элементов на их посадочных страницах с дальнейшими рекомендациями по внедрению.

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

Этап 3. Перенос метатегов и редиректы

Ранее мы выявили, что большую часть трафика на сайте приносят товары и ряд категорий. Основными задачами на ближайшие два месяца (апрель-май) являются:

Важным условием на стадии переноса является наличие тестовой версии сайта (git), которую в дальнейшем планируется использовать после смены CMS-системы.

Алгоритм переноса метатегов

Как правило, метатеги импортируются со старого на новый сайт при использовании специальных модульных решений по импорту/экспорту. В нашем случае из-за изменения структуры сайта и “пряморукости” программиста на Joomla сделать это было невозможно. Перенос выполнялся в полуавтоматическом режиме по следующему алгоритму:

На данном этапе мы имеем три таблицы:

Объединяем все таблицы в общую, примерный вид которой представлен на рисунке 3. Затем передаем таблицу контент-менеджеру для переноса метатегов на новый движок.

Данный пункт рассмотрим подробнее с конкретным примером таблицы и формул Excel, так как для многих может быть непонятен сам процесс выявления отличающихся метатегов на старой и новой CMS системах сайта.

В столбцах с A до E (рисунок 4) указаны следующие данные:

В столбцах с F до J указаны данные, которые мы получили после повторного краулинга тестового сайта. Краулинг осуществлялся после переноса данных контент-менеджером.

В столбцах с K до N (рисунок 6) расположены формулы поиска соответствующего метатега в пределах одной строки и одной ячейки.

Формула выглядит следующим образом:

ЕСЛИОШИБКА(ЕСЛИ(ПОИСКПОЗ(B2;G2;0);»Совпадение»;»Ошибка»);»Ошибка»)

Расшифровка логики формулы для тех, кто, возможно, не понимает, как она работает. Рассмотрим алгоритм справа налево:

Итоговый вид работы формул в указанных ячейках для второй строки представлен на рисунке 6.

Обратите внимание! На стадии переезда сайта и смены CMS-системы важнейшим условием является не только сохранить целостность метатегов, но и по возможности сохранить структуру сайта, вложенность категорий, товаров. В таких ситуациях помогает карта редиректов.

Для автоматической подготовки редиректов вы можете воспользоваться вторым листом из нашей таблицы, который называется “Редиректы” (рисунок 7).

Получившиеся редиректы (столбец С) отдаем программисту для внедрения в файл .htaccess.

Обратите внимание! Программист их должен занести в файл в порядке убывания длины строки начального URL, с которого осуществляется редирект (от большего к меньшему). В противном случае веб-сервер обработает редиректы из файла htaccess некорректно.

Рассмотрим более конкретный пример. В таблице 1 представлены ссылки, которые вы получили ранее в пункте 5 третьего этапа. Ссылки записаны хаотично, без соблюдения вложенности начального URl-адреса (старого).

Если мы оставим ссылки в таком виде и передадим их разработчику для внесения в файл htaccess, то сервер их обработает следующим образом:

site.ru/catalog_old/ будет иметь редирект на

site.ru/catalog_new/category_new_1/pr2/

Чтобы не повторить подобной ошибки, ссылки в столбце “Старый URL” необходимо расположить в порядке убывания вложенности или убывания длины строки.

Отчет по этапу 3

Трудозатраты:

Что сделано:

Третий этап закончился на шестом месяце. На текущем сайте (старом движке) не осуществлялось никаких внедрений. Логично предположить, что позиции и трафик могли принять тенденцию нисходящего тренда. Окончательный переезд после неоднократной проверки всего контента состоялся в конце мая.

Поисковый трафик постепенно падает в соответствии со скриншотом из метрики — рисунок 8.

Этап 4. Завершение работ по переносу. Чек-лист

Финальный этап заключается в контроле успешности переноса. Стараемся “держать руку на пульсе”.

Краткий чек-лист. Что в первую очередь необходимо сделать сразу после переноса:

Финальный переезд на новую CMS-систему состоялся 1 июля 2019 года рано утром в понедельник.

Трудозатраты:

Что сделано:

Выводы

План работ на 4 этапе позволил нам переехать с Joomla на Bitrix без потери трафика и позиций. После успешного переезда трафик из Яндекс и Google увеличился в несколько раз, о чем свидетельствует рисунок 9.

Мы работаем над проектом по настоящее время. Несмотря на “коронавирусный кризис”, нам удалось достигнуть наиболее впечатлительных результатов. Если вам интересно, какие работы проводились в дальнейшем, оценивайте статью и задавайте вопросы, которые требуют дополнительных уточнений.

Небольшой спойлер: рисунок 10 — текущая ситуация с трафиком по проекту. Спад трафика в августе соответствует сезонности интернет-магазина и разделу сервиса.

Мы надеемся, что приведенный список работ и алгоритм действий наиболее подробно прояснили вопрос о том, как поменять CMS-систему сайта, и многие специалисты смогут сделать предстоящий переезд без ошибок.

Автор: Дмитрий Федосеев (Ant-team.ru)

Причин для переезда на новый движок много. Вот самые частые сценарии:

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

Теперь рассмотрим опасности, которые могут подстерегать вас после переезда на новый движок.

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

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

Вот главные опасности смены движка сайта:

1. Получение большого количества уязвимостей.
2. Утрата многих инструментов и функциональной части старой CMS.
3. Некорректное отображение контента — из-за изменения вида ссылок контент может отображаться частично или вовсе не отображаться после смены движка.
4. Потеря накопленных позиций.
5. Резкая просадка трафика.
6. Утрата всей или большей части ссылочной массы. В идеале нужно настроить 301-е перенаправление для каждой страницы старой версии на URL новой версии сайта.

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

Например, до переезда ссылка категории выглядела так: abc.com/category/blog. После смены CMS она приобрела такой вид: abc.com/blog.html

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

Достичь этой цели можно соблюдением всего 3 правил:

• Сохранение текущих url адресов страниц.
• Сохранение контента страниц.
• Сохранение структуры.

Если по каким то причинам у вас не получается реализовать этот вариант, ниже мы опишем вариант с использованием серверной переадресации 301 на новые url адреса.

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

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

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

Далее мы посмотрим, как переехать на новую CMS самостоятельно — без разработчика.

Шаг №1 — сбор старых URL

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

Парсинг старого сайта

Сперва нам необходимо сохранить текущие URL. Другими словами — нам нужны ссылки со старой версии сайта. Чтобы их собрать, вы можете воспользоваться автоматическими инструментами, например, сервисом Screaming Frog или любым другим, который имеет встроенный парсер данных.

Я люблю работать с WebSite Auditor и далее покажу последовательность действий на примере этого инструмента.

1. Устанавливаем WebSite Auditor на компьютер.
2. Указываем домен старого сайта.
3. Ждем пока сервис просканирует домен:



4. Идем в раздел «Структура сайта» и открываем отчет по страницам:



5. Выбираем необходимые параметры, кликнув правой кнопкой в этой области:



Откроется контекстное меню, где нужно выбрать интересующие нас параметры.



6. Экспортируем данные. Нажимаем на эту иконку:



7. Указываем, куда сохранить таблицу:

Итак, как вы уже догадались, в таблице работать будем со следующими данными страницы:

1. URL.
2. Title.
3. Description.
4. H1.

Создание таблицы

Теперь нам нужно создать таблицу в Microsoft Office или в «Google Таблицах». В чистый лист вставляем данные, которые мы получили из парсера. Вы можете назвать эту таблицу «Составление URL»:

Новый адрес страницы пока не трогаем. Таким образом, мы создали таблицу «Составления URL» для старой версии сайта и успешно копировали в нее данные из парсера.

Парсинг нового сайта

Повторяем весь вышеописанный парсинг, но уже для новой версии сайта. Аналогичным образом экспортируем данные из парсера и возвращаемся в таблицу «Составление URL», где у нас ссылки на старый сайт. Нам нужно добавить новый столбик.

Теперь нужно внимательно проверить корректность каждой новой страницы, сопоставить старый / новый адрес и вписать его в столбик «Новый адрес страницы». Сделать это нужно для каждой ссылки.

После того как таблица «Составления URL» полностью готова, можно приступать к созданию следующий таблицы — условно назовем ее «Формирование редиректов». Внимательно анализируем предыдущую таблицу («Составление URL»): проверяем каждую ссылку со старой версии сайта на новую, затем вносим ее в таблицу «Формирование редиректов», в столбик «Новый URL»:

Обратите внимание: в столбике «Правило редиректа» может указываться не только 301-й редирект, но и другие виды перенаправлений.

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

Шаг №2 — инсталляция новой CMS

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

Перед релизом сайта на основной домен, файл robots.txt необходимо заменить на корректный или убрать из него запрещающую директиву Disallow: /. Иначе ваш сайт полностью выпадет из индекса.

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

Шаг №3 — копирование оптимизации и контента

Если вы работаете с разработчиком, обязательно передайте ему таблицу «Сопоставления URL» и таблицу «Формирование редиректов». Сложность переноса оптимизации и контента зависит от масштабов сайта. Если на вашем сайте тысячи страниц, то для импорта данных можно задействовать специально написанный для этого скрипт (сделать его поможет разработчик). Когда страниц мало, то можно обойтись и полностью ручным копированием контента.

Шаг №4 — настройка перенаправлений

Задача несложная: нужно вручную настроить 301-й редирект для всех старых страниц. Самый простой способ это сделать — прописать перенаправление в htaccess, но есть и много других способов настроить редирект.

Шаг №5 — тестирование

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

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

Обязательно обратите внимание на карточки товаров и фильтры — сразу же после переноса они должны формироваться корректно.

Шаг №6 — добавление скриптов

Если новая версия сайта работает корректно, можно приступать к добавлению скриптов веб-аналитики и других сервисов:

• Google Search Console.
• Google Tag Manager.
• Google Analytics.
• Google AdSense.
• «Яндекс.Вебмастер»
• «Яндекс.Директ»
• «Яндекс.Метрика»
• Любые другие инструменты, которые вы использовали на старой версии сайта.

Шаг №7 — формирование XML-карты

Для создания XML-карты можно воспользоваться любым сторонним инструментом: плагином или онлайн-сервисом. Например, для WordPress я рекомендую использовать плагин Google XML Sitemap Generator. Сгенерированную карту сайтов для роботов нужно загрузить в «Яндекс.Вебмастер» и Google Search Console.

Шаг №8 — работа с веб-аналитикой

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

6 действий, которые нужно выполнить после первоначального переезда на новый движок

Если первый этап переезда на новый движок признан успешным, не спешите удалять старую версию сайта! Она может пригодиться еще неоднократно. Кроме этого, выполните следующие действия:

1. Проверьте правильность привязки сайта в «Яндекс.Метрике» и Google Analytics.
2. Проверьте стандарт исключения для роботов. Новая версия сайта должна быть открыта для индексации.
3. Следите за позициями новой версии сайта. В идеале мониторить их нужно еще до начала переезда. Так вы сможете вовремя идентифицировать причину падения трафика, если она связана с утратой позиций сайта.
4. После завершения всех работ просканируйте новую версию сайта парсером Screaming Frog. Нужно убедиться в том, что отсутствуют критические ошибки, нет дублирования страниц, все они отдают корректный код, а теги страниц переехали правильно. Следите за битыми ссылками на сайте. Сделать это можно в том же Screaming Frog (раздел «Bulk Export», сортируем страницы по «Response Code» и кликаем «Client Error 4xx Inlinks»).
5. Просканируйте все цепочки редиректов при помощи Majento.
6. Проверьте все внутренние ссылки (включая атрибутивные, canonical, ссылки в меню). Они должны вести на новую версию сайта.

Резюме + бонус: когда переезд на новый движок может быть не оправдан

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

После того, как перенос завершен — обязательно проанализируйте цепочки редиректов на цикличность. Для решения этой задачи я советую использовать любой подходящий сервис — например, webmasta.org или Mainspy.

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

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

«Один переезд равен двум пожарам» – эта расхожая фраза вполне применима к миру digital.

Нередко дизайн и функционал сайта перестают соответствовать ожиданиям посетителей, не позволяют полноценно внедрять SEO-правки или просто не устраивают заказчика.

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

Существуют тонкости переноса, не приняв во внимание которые, можно потерять позиции сайта в поисковых системах и, как следствие – поисковый трафик.

Давайте разберемся, как без потерь в позициях и трафике организовать переезд на новую CMS, изменить структуру и обновить дизайн сайта.

Требования к новому сайту

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

Структура проекта

Самым простым вариантом было бы перенести проект на новый движок с сохранением текущей структуры страниц (говоря про e-commerce-сайт, имеем в виду в первую очередь каталог). Но такой вариант подходит не всем: в большинстве случаев владелец ресурса или SEO-специалист считают необходимым внести изменения в структуру. Более того, зачастую переезд осуществляется именно с целью создания эффективной для продвижения структуры сайта.

Как быть: убедиться, что все важные страницы, которые уже существовали на старом сайте – перенесены и на новый. Выгрузить из Яндекс.Метрики и Google Search Console данные по точкам входа на сайт с источником «Поисковая система». Выборку взять за длительный период (скажем, за год). Проверить, что для всех значимых страниц входа созданы аналогичные страницы на новом проекте.

Самый адекватный и простой вариант – перенести метатеги со старого сайта. Имеются в виду как генерируемые по шаблону страниц, так и «ручные» теги.

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

Перенос текстов

Аналогично предыдущему, если тексты нужны и не создают проблем (выборочная проверка проблемных кластеров на переспам/переоптимизацию), лучше всего перенести их в неизменном виде. Для отслеживания эффекта внесенных изменений заняться вопросами текстовой релевантности лучше после публикации и полной индексации нового проекта.

Перенос сквозных элементов

Необходимо перенести сквозные элементы, связанные с коммерческими или ссылочными факторами ранжирования.

В том числе следует уделить внимание таким блокам:

• коммерческие: блоки «Почему выбирают нас», «Схема работы» и подобные;
• ссылочные: сквозное выпадающее меню, элементы сквозной перелинковки.

Перенос пользовательских элементов

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

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

Настройка редиректов

Почему важно настроить редиректы (перенаправления) со старых адресов на новые?

Редирект – это способ перенаправить пользователя либо робота поисковой системы на другую страницу. Здесь и далее мы будем говорить про постоянный редирект с кодом ответа сервера 301. Помимо переадресации пользователей и роботов, он позволяет сообщить поисковым системам, что страница перемещена навсегда и нужно передать на новый URL-адрес некоторые накопленные параметры: возраст документа, внутреннее и внешнее ссылочное, накопленные характеристики.

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

1. Наличие псевдораздела. Например, при переезде с безымянной системы управления на CMS Битрикс раздел каталога вида site.ru/televizory/ по умолчанию будет иметь адрес site.ru/catalog/televizory/ При таких изменениях в адресах страниц можно разом настроить массовые редиректы со страниц без псевдораздела на новые страницы.

2. Различные правила транслитерации букв кириллицы в латиницу в разных CMS. Например, ранее именовавшийся раздел /televizory/ может на новом сайте быть поименован /televisori/ Если на сайте с небольшим количеством страниц можно вопреки автоматической транслитерации задать ЧПУ адреса страниц вручную, то в масштабном каталоге придется смириться с изменением адресов и настраивать редиректы не массово, как в предыдущем пункте, а вручную постранично.

Как искать соответствия во втором случае, когда нет единой «маски URL»? Нужно получить выгрузки страниц со старого и нового сайтов. Это возможно сделать как выгрузкой из CMS, так и при помощи любой десктопной программы-парсера или аналогичного облачного сервиса. После чего сопоставить два списка по какому-либо из нижеследующих признаков:

1. По title страниц

Если при разработке нового проекта удалось сохранить шаблоны генерации title и ручные теги – можно сопоставить страницы по нему.

2. По H1 (наименованиям товаров и разделов)

Если title всё же менялся, разумно сопоставить страницы по заголовку H1. Для разделов это будет имя, для товаров – наименование. При переезде меняются редко.

3. По артикулам товаров

Если наименования товаров всё же менялись, остается беспроигрышный вариант – сопоставить URL карточек по полю артикул.

Ключевые моменты

1. Все предварительные работы, до полной проверки и констатации готовности проекта к публикации необходимо проводить на тестовом домене.

Нередко заказчик торопится с публикацией свежего сайта. Да и визуально, может показаться что «все готово», а «эту вашу техническую часть – уже на боевом доделаете».

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

1. Локальная копия сайта, либо копия на тестовом поддомене.

Когда связанные с переносом сайта на новую систему управления завершены, важно на всякий случай сохранить не только файлы выгрузки со старого сайта, но и его рабочую версию. Помимо резервной копии, рекомендуется развернуть сайт на поддомене old.site.ru и закрыть его от индексации поисковыми системами.

1. Двойной переезд: новая структура и протокол https.

Несмотря на сильно выросшую за последние два года популярность использования защищенного протокола https, множество сайтов, по старинке, так и используют http протокол. С виду, убить двух зайцев разом – выглядит хорошей идеей.

Однако, сама реализация нового сайта (новая структура проекта и URL страниц, новая компоновка посадочных страниц, изменения в сквозных блоках) довольно большой пакет правок, влияющих на релевантность страниц той или иной группе запросов. Подмешивать сюда влияние от смены протокола – просто усложнить анализ результатов и контроль за процессом переезда.

Плюс, переезд с http на https может осуществляться не только при помощи настройки 301 редиректа на https версию, но и методом настройки rel=canonical на защищенную версию страницы. В этом случае возникает цепочка из редиректа (проставленного при смене адреса страницы) и канонического адреса (настроенного на протокол https), что затрудняет роботу переобход страниц. Наша же приоритетная цель при переносе сайта – наиболее быстрый обход, индексация, склейка и смена релевантных страниц на новые.

Рекомендуется отложить подключение SSL-сертификата и переезд на https до полной индексации и корректного ранжирования обновленного проекта.

1. Для каких страниц нужно настраивать редирект?

Для всех, где есть возможность. В том числе:

1. Редиректы со всех существующих страниц старого сайта, найденных краулером.

2. Редиректы со всех страниц в индексе поисковых систем, которые по каким-то причинам не найдены краулером по ссылкам (отсутствует путь от главной до страницы). Проверяется парсингом выдачи или выгрузкой проиндексированных страниц из Я.Вебмастера.

3. Редиректы, которые уже существовали (частичная смена URL в пределах старого сайта), нужно перенастроить так, чтобы переадресация вела сразу на конечный целевой URL.

4. Редиректы со всех страниц сайта, на которые когда-либо был трафик по данным Яндекс.Метрики и Google Search Console. Возникают по многим причинам, в том числе из-за удаления товаров, линеек товаров (к примеру, определенного бренда), либо целых разделов сайта. Куда настроить редирект, если соответствующая страница отсутствует на новом сайте и ее создание недопустимо – расскажем ниже.

1. Цепочки редиректов

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

1. Куда настроить редиректы, если товаров и разделов не будет на новом сайте (удалены навсегда, исчезли из ассортимента/сняты с производства)?

Нередко, невозможно найти точные соответствия для существовавших ранее страниц для корректной настройки переадресаций. В таком случае, возможны:

1. Настройка редиректа на ближайшую по смыслу страницу. В контексте каталога и товаров, удаленных по причине снятия с производства, редирект с карточки можно настроить на наиболее близкую по характеристикам модель из новой линейки.
2. Если схожие смыслу страницы (схожие по потребительским качествам товары) отсутствуют, целесообразно настроить массовый редирект со всех таких карточек на страницу уровнем выше – конечный раздел каталога.
3. Если удален целый раздел – аналогично, переадресация настраивается уровнем выше (на родительский раздел).

А если все же?

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

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

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

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

Итак, корректность проверена, все необходимые правки внесены, редиректы донастроены. Но как заставить робота посетить страницы, полгода отдававшие 404 ошибку, чтобы редиректы были обработаны, накопленное на старых URL – передано?

Лайфхак: из списка страниц, для которых донастраивались перенаправления – собрать файл sitemap в формате xml или txt, добавить в панели Я.Вебмастера и GSC и запустить переобход.

Итого

Возвращаясь к значению фразы «Один переезд равен двум пожарам» – обычно имеется в виду суета, стресс и возможность забыть/упустить что-либо из виду. Аналогично можно утверждать и про перенос сайта на новую CMS. Главное – помнить, что при достойной организации и тщательном контроле за процессом проблем не возникает ни при офлайн, ни при онлайн переездах.

Чек-лист для самопроверки:

1. Структура нового сайта содержит все необходимые страницы.
2. Перенесены (или корректно изменены) шаблонные и «ручные» мета-теги.
3. Перенесены тексты.
4. Перенесены (или корректно изменены) сквозные элементы – блоки внимания, навигация.
5. Перенесены (или корректно изменены) элементы взаимодействия с пользователем.
6. Настроены корректные редиректы со всех индексируемых URL старого сайта. Особое внимание страницам, генерирующим значительный трафик, а также страницам, на которые присутствуют внешние ссылки.

Дальнейшая работа по новому сайту ничем не отличается от обычной SEO-оптимизации. Необходимо провести полный технический аудит, исправить ошибки по нему, искать новые точки роста и продолжать системно развивать проект.

Рост числа обращений по смене CMS отчетливо иллюстрирует сложившийся тренд — российский бизнес переходит на отечественное программное обеспечение. Клиенты хотят «переехать» с Wix, WordPress, Joomla и других иностранных CMS, но плохо представляют себе этот процесс.

Расскажем, с какими проблемами сталкиваются все при переносе сайта на другую платформу и какие риски можно минимизировать.

Две проблемы переноса сайта на другой движок  

«Один переезд равен двум пожарам» — эта известная поговорка в полной мере соответствует и смене движка сайта. Почему? Потому что цена ошибки — потеря трафика и клиентов, а для бизнеса — это гарантированные финансовые потери.

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

Опыт нашего IT-агентства показывает, что есть два принципиальных аспекта, которые лежат в основе успешного обновления движка.

Перенос сайта на новую CMS — это по сути создание нового сайта.

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

Во многом масштабы работ зависят от типа сайта. Например, переезд лендинга с Wix на отечественную Tilda, как правило, не занимает много времени и не требует участия программистов. С технической точки зрения мы просто дублируем имеющиеся блоки и контент на новые страницы инструментами, доступными в Tilda.

А вот корпоративный сайт или интернет-магазин с индивидуальным функционалом — это совсем другое дело. Как же строится работа в таком случае?

Алгоритм анализа задачи по смене CMS:

1. Какие модули есть на текущем сайте.
2. Они стандартные  — корзина, фильтр в каталоге, отзывы, или разработаны специально по вашим запросам, например, сложное портфолио, личный кабинет или интеграция с CRM.
3. Все ли модули, которые есть на текущем сайте, популярны и будут востребованы на новой платформе. Например, часто на старых сайтах есть модуль «Форум» и клиенты настаивают на его переносе, хотя посетителей и активных пользователей таких площадок практически нет.
4. Какие модули еще не реализованы, но необходимы для бизнеса. Например, сайт с каталогом надо модернизировать до полноценного интернет-магазина — тогда не обойтись без модуля онлайн-оплаты.

На основании этого специалисты оценивают ситуацию и решают:

• Какая CMS наиболее полно отвечает сформированному запросу.
• Какие модули предстоит разрабатывать индивидуально.

Пример оценки переезда сайта с Wix

Например, один из наших заказчиков пришел с запросом отказаться от Wix в пользу отечественной CMS, т.к. платформа перестала сотрудничать с клиентами из России. Его бизнес заключался в производстве, розничной и оптовой продаже подарочных упаковок дизайнерских пакетов, сумок, упаковочной бумаги. Значит нужен был вариант со стандартным функционалом — простой каталог, оформление заказа, корзина. Кроме этого, одно из желаний клиента — максимально бюджетный переезд. В ходе анализа этих данных мы предложили запустить сайт на готовом шаблоне Canape CMS, на которую и переехал сайт заказчика всего за 55 тыс. рублей.

Пример оценки переезда сайта с Joomla

Другой пример — сайт по продаже элитной мебели на Joomla. После многолетних доработок силами фрилансеров сайт часто сбоил, «падал», а бизнес в это время терял деньги. На сайте был большой каталог и требовалась синхронизация с базой 1С Битрикс, он должен был работать на нескольких языках. В данном случае мы предложили клиенту перенос сайта на на 1С-Битрикс, так как эта CMS максимально подходила под требования заказчика.

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

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

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

Пример резкого падения трафика, при смене CMS без учета SEO

Сохранение SEO — это сохранение позиций в выдаче и трафика.

SEO — не просто точные вхождения ключевых слов в текстах на страницах сайта. Это годами накопленная история, отточенный контент, грамотно настроенные метатеги и многое другое, что позволяет вывести сайт в ТОП поисковой выдачи.

Обращаться с этой информацией, нажитой усилиями вашего SEO-специалиста, стоит очень бережно. Как это сделать — расскажем подробнее.

Как обновить движок и не обнулить SEO?

Секрет в осознанном формировании структуры, тщательном анализе контента и обязательной настройке редиректов.

Структура сайта, URL и магия редиректов

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

Кроме того, часто переносить весь контент без исключений не имеет смысла. Выборочное его сохранение особенно характерно для «старых» больших сайтов, накопивших много материалов.  

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

Иногда устаревшими могут быть не только отдельные страницы, но и целые разделы.

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

Отсюда и основная проблема — образование «битых» ссылок или дублей страниц. Поисковые роботы, как и пользователи, негативно относятся к 404 ошибке, поэтому крайне важно не допустить ее массового появления. Для этого, одновременно с выявлением ценного контента, составляют карту редиректов.

Как пошагово составить карту редиректов для переноса сайта на другую платформу:

1. Вручную пройтись по старому сайту, проанализировать наполнение и определить, что нужно/интересно/полезно/обязательно, а что уже неактуально.
2. С помощью сервисов Яндекс Вебмастер или Google Search Console скачать данные о всех проиндексированных поисковиками страницах.

Отчет из Яндекс Вебмастера «Страницы в поиске»

1. В Яндекс Метрике определить самые популярные у пользователей страницы.

Отчет Яндекс Метрики «Популярные страницы»

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

Пример карты редиректов

Как быть со страницами, которые не подлежат переносу? Чтобы даже редкие пользователи этих страниц или те, кто в своих целях сохранил ссылку на старый сайт, не попадали на 404 ошибку, можно настроить редиректы на близкие по смыслу разделы или на новую главную. Для товаров, изъятых из ассортимента — на ближайшие по характеристикам модели.

Задача программистов — настроить 301 редирект, который сообщает поисковикам, что старую страницу из поиска можно исключить, а индексировать теперь только новую.

Фото и изображения

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

Пример поиска по изображениям

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

Определите объем такого трафика с помощью Яндекс Метрики или Google Analytics. Если он значителен в масштабах вашего бизнеса, то ставьте задачу программистам, если невелик — не тратьте деньги впустую.

SEO-теги

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

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

Пример внесения SEO-тегов в Canape CMS

Контент

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

Далее обсудим, на что обратить внимание при наполнении страниц на обновленном сайте.

• Микроразметка

Это атрибуты и теги, которые обозначают для поискового робота, какая именно информация размещена на странице. Это могут быть контактные данные или вопросы и ответы. Микроразметка позволяет давать пользователям наиболее релевантные результаты поиска.

Если она присутствовала на страницах, то важно проверить, что после переноса контента функциональность сохранена. Это можно сделать в специальных сервисах, например, в валидаторе микроразметки Яндекса или shema.org.

Если же это понятие вам незнакомо, то самое время разобраться и в полной мере воспользоваться этим инструментом.

• Внутренняя перелинковка

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

Пример внутренней перелинковки

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

• Заголовки и подзаголовки

Корректное обозначение заголовков всех уровней от H1 и далее. Важно не только удобство читателя и его возможность быстро сориентироваться на странице. Поисковым роботам тоже так проще разобраться со структурой документа. Упорядоченные логичные заголовки «поощряются» поисковиками и положительно влияют на ранжирование. Облегчить визуальную проверку можно букмарклетом «Подсветка заголовков».

Букмарклет «Подсветка заголовков» в деле

• Сквозные коммерческие элементы

Коммерческие факторы ранжирования, например, блоки «Свяжитесь с нами», «Контакты», «Схема работы», «Адрес и схема проезда» и другие, должны после переноса оказаться на своих местах.

Пример таких блоков

В противном случае их отсутствие внесет свой вклад в потери заслуженных позиций.

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

Как правильно перенести сайт на живую

Ну вот и осталась за плечами огромная работа по минимизации потерь позиций или трафика после смены структуры и URL. Вы настроили множество редиректов, проанализировали и перенесли контент. Сайт готов к выкладке на живую!

Знаете, какая самая частая ошибка на этом этапе? Удаление старых метрик и установка новых счетчиков. Сайт в прямом смысле начинает жизнь с чистого листа, а его владелец теряет возможность оценить трафик и конверсии до/после переезда.

Проанализируйте действующие счетчики Яндекс Метрики или Google Analytics и обязательно перенесите нужные на новый движок!

Кроме того, в Google Analytics и Яндекс Метрике нужно актуализировать настройки — фильтры, события, целевые действия. Это особенно важно в том случае, если у вас настроена реклама в Яндекс Директ.

Что нужно проверить сразу после выкладки:

• В веб-мастерах поисковых систем наличие новой карты сайта, открытой для индексации. Старый файл sitemap нужно удалить.
• Ответы сервера для http/https, а также с/без www. Только главное зеркало должно иметь код ответа 200 ОК, остальные зеркала должны редиректом направляться на главное и возвращать код ответа 301.
• Отсутствие 404 ошибок и дублей страниц, просканировав весь сайт.
• Оптимизированную версию для мобильных. Это можно сделать в сервисе Яндекса «Проверка мобильных страниц» или «Mobile-Friendly Test» от Google.

Работоспособность внешних интеграций, например сервисы сквозной аналитики, не относятся напрямую к SEO, но и про них не стоит забывать.

• Обязательно перед началом работ проконтролируйте создание резервной копии существующего сайта. Ее можно сделать инструментами самой CMS или через панель управления сервером. И не забудьте убедиться в работоспособности бэкапа — разверните его на локальном сервере.
• Убедитесь, что тестовый домен закрыт от пользователей и от индексации на весь период разработки. Как правило, это можно сделать инструментами CMS или прописать параметры в файле robots.txt. Иначе тестовая площадка попадет под обход робота, а контент на основном ресурсе станет дублем.
• Даже после того как перенесли сайт на другой движок и успешно его запустили, не спешите удалять старую версию. Опыт показывает, что часто она бывает нужна после обновления. Лучше на полгода-год перенесите на поддомен, например, old.site.ru и закройте от поисковиков. Так вы какое-то время будете иметь источник для восстановления информации.
• Внешний ссылочный вес не менее важен, чем внутренний. Поэтому очень желательно его сохранить — актуализировать все трастовые ссылки на авторитетных ресурсах. Особенно, если по этим каналам вы наблюдали существенный трафик. Список таких упоминаний можно найти в Яндекс Метрике или Google Search Console.
• Контролируйте метрики эффективности ежедневно в течение месяца после переезда. Наблюдаете неуклонное падение позиций или трафика? Прежде всего проверьте корректность редиректов, скорость загрузки страниц, юзабилити.

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

Хотите и вы перенести сайт на стабильную CMS без рисков и с гарантией в договоре? Тогда звоните 8 (800) 200-94-60, доб. 321 или оставьте запрос на электронную почту rop@web-canape.com. Мы создаем сайты для решения бизнес-задач, и выводим их в ТОП поисковой выдачи!

Зачем это нужно

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

Все админки сайтов можно условно разделить на три группы:

Как выбрать админку сайта для замены:

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

Техническое задание на смену CMS:

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

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

• создание тестового сервера и установки новой CMS;
• настройка модулей, добавление/доработка нужных функциональностей;
• перенос контента: информационных страниц сайта, новостей, фотографий, файлов, товарного каталога, заказов и т.п.;
• перенос дизайна сайта, доработка верстки;
• учет особенностей, связанных с seo: проставление 301 редиректа со старых страниц на новые, проверка корректности значений тегов h1, title, keyword, decription; перенос кодов счетчиков;
• при достижении желаемого результата перенос сайта с тестового на “боевой” сервер.

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

Порядок действий:

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

• Подготовка технического задания на замену CMS;
• Заключение договора на замену админки сайта;
• Смена CMS по ТЗ и перенос контента;
• Техническое сопровождение сайта.

Наша веб-студия имеет достаточный опыт по смене админок, наши специалисты имеют опыт настройки и доработки самых разных CMS: коммерческих, бесплатных и “самописных”.
Мы работаем по договору от юридического лица с 50% предоплатой. По завершению договора даем гарантию на сделанную работу – 6 месяца.

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

Если машина времени не работает, а разработчик самописа быстро бегает, выбора нет. Из этого руководства вы узнаете, как перенести сайт на другой движок.

В каких случаях перенос сайта на новый движок целесообразен

Смена движка – трудоемкая, дорогая и рискованная задача. О рисках мы еще поговорим, а пока оцените историю от моей коллеги Ольги Кочкиной.

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

Спустя пару месяцев прочитала книжку про юзабилити и решила внедрить некоторые фишки на своем сайте. Сделать что-либо самостоятельно у меня не получилось. Разработчик согласился помочь бесплатно, но смог поправить буквально пару моментов. Остальное – дополнительная разработка.

Через год сайт морально устарел, да и мучиться с кривой админкой уже не было сил. Решили переносить на OpenCart – шустрый и функциональный движок для интернет-магазинов. Написали разработчику. Перенести на другой движок сайт, который обошелся в 5 тыс. рублей, нам предложили за 70 тыс. рублей. Мораль, думаю, ясна.

Создание сайта обошлось Ольге в 5 тыс. рублей, а перенос сайта с самописа на нормальную CMS стоил 70 тыс. рублей. Вот вывод: менять движок нужно в крайнем случае, когда без этого не обойтись. Варианты типа «Drupal круче Joomla», «на WordPress больше красивых бесплатных тем», «движок с открытым кодом могут взломать, «надо перейти на коммерческую CMS» – не повод для переноса сайта. Этот шаг неизбежен в более серьезных ситуациях.

Статичный сайт на HTML больше не отвечает вашим потребностям

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

Самописный движок стал неактуальным

Самописный движок – это не плохо и не хорошо. Например, интернет-магазин Ozon работает на крутом самописе. Но есть и движки за 5 тыс. рублей, об одном из которых вспоминала выше Ольга Кочкина. С ними случаются разные неприятности:

• Движок устарел, а разработчик исчез.
• Сторонний разработчик просит за обновление чужого кода больше, чем за создание сайта с нуля.
• За любое расширение функциональности нужно платить разработчику. Например, захотели подключить AMP – платите. А для популярных движков есть готовые бесплатные или дешевые решения.

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

Возможности конструктора вас больше не устраивают

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

О переносе коммерческого сайта с SaaS-платформы на CMS можно думать в таких случаях:

• Функциональность конструктора не соответствует вашим потребностям.
• Вы не хотите платить за использование платформы.
• Вас не устраивает шаблонный дизайн сайта, а конструктор не поддерживает сторонние шаблоны.
• Серверы конструктора находятся за границей. Это может быть проблемой для бизнес-сайта.
• Вы хотите полностью контролировать сайт.

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

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

Еще одна уважительная причина для переезда: вы не можете или принципиально не хотите платить за CMS. Например, держать форум на платном vBulletin не выгодно, и вы переезжаете на бесплатный phpBB.

В остальных случаях надо тщательно взвешивать риски:

• Хорошо знаете WordPress, поэтому переезжаете с Drupal? Если сайт достаточно большой и давно работает, лучше выучить и полюбить Drupal.
• Для Joomla! нет столько бесплатных шаблонов и плагинов, сколько есть для WordPress? Переезд может в прямом и переносном смысле обойтись вам дороже, чем покупка платного плагина или разработка шаблона с нуля.
• Сайт на WordPress неактуален, вашей крутой компании нужен солидный движок? Это откровенная глупость. Лучше потратьте время и деньги на что-то полезное.
• Движки с открытым кодом могут взломать или скопировать? Взломать могут любой сайт. Более того, CMS с открытым кодом реагируют на угрозы быстрее коммерческих движков. Над тем же WordPress круглосуточно работает сообщество разработчиков.

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

Какие проблемы нужно решить при переносе сайта

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

Потеря контента

Чтобы не потерять контент, сделайте резервную копию сайта до переезда. Резервную копию можно создать средствами старой CMS. Например, в Drupal такая возможность реализуется с помощью встроенного модуля, а в WordPress с помощью плагина.

Без привязки к движкам резервную копию можно сделать через панель управления сервером. Данные доступа к панели управления предоставит хостер.

В панели управления войдите в «Менеджер резервных копий», который находится в разделе «Файлы».

Заархивируйте и скачайте актуальные копии файлов сайта и базы данных.

Убедитесь в работоспособности резервной копии. Для этого восстановите сайт на локальном сервере. Если восстановить сайт из копии не удается, сделайте бэкап еще раз или обратитесь к хостинг-провайдеру. Не начинайте переезд без работоспособной резервной копии ресурса.

Изменение структуры сайта и структуры URL

CMS формируют человеко-понятные URL по-разному. Из-за этого при смене движка «урлы» обычно меняются. Также URL изменятся, если вы меняете структуру сайта.

Например, адрес страницы товара может поменяться с https://primer/pages/catalog/tovar.html на https://primer/shop/tovar.html/. Из-за изменения структуры URL появляются битые ссылки, дубли в поисковой выдаче, неработающие виджеты и кнопки. Поисковики и живые пользователи негативно реагируют на такие проблемы.

Сохранение понятной структуры URL – одна из ключевых задач при переносе сайта на новый движок.

Трудоемкость настройки редиректов

Эта проблема – следствие предыдущей. Если при смене движка приходится менять URL, нужно работать с редиректами. Настроить постраничные редиректы для сайта с несколькими десятками страниц – не проблема. Если количество страниц исчисляется сотнями или тысячами, работа с редиректами будет едва ли не самым трудозатратным этапом переезда.

Например, представьте, что на старом движке все телефоны, смартфоны и фаблеты были доступны в разделе «Смартфоны и телефоны» по URL example-shop/catalog/phones/. Каждый телефон доступен по адресу типа example-shop/catalog/phones/phone1.

Если при переезде на новую CMS вы создаете отдельные разделы каталога для телефонов, смартфонов и фаблетов, товары будут доступны по URL типа example-shop/catalog/phablets/phablet1 и example-shop/catalog/smartphone/smartphone1. Здесь редиректы придется делать вручную.

Несоответствие функциональности старого и нового движка

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

Таких примеров очень много, поэтому при смене CMS нужно быть готовым искать или покупать нужные решения.

Проблемы с дизайном

Если вы пользуетесь дизайн-шаблоном, сохранить внешний вид при переезде на новый движок не удастся. Можно найти более или менее похожий шаблон для новой CMS или потратить деньги на услуги дизайнера. Сама по себе смена дизайна – не проблема. Просто будьте готовы к дополнительным расходам.

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

Как перенести сайт: пошаговые инструкции

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

Итак, вы выбрали новую CMS и сделали резервную копию сайта. Действуйте так.

1. Зафиксируйте текущую эффективность сайта

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

• Посещаемость за выбранный период.
• Позиции ресурса в выдаче по важным запросам.
• Список самых трафиковых страниц.
• Поведенческие метрики.

Для небольших сайтов достаточно проверить вручную и внести в таблицу 10–15 самых важных запросов в «Яндексе» и Google. Для сайтов с количеством страниц от сотни и выше лучше использовать сервисы для мониторинга позиций, например, Serpstat, Seolib, Rush Analytics, Topvisor и так далее.

Список самых трафиковых страниц можно найти в системах аналитики. Например, в Google Analytics выберите меню «Поведение – Контент сайта – Страницы входа». Укажите дополнительный параметр «Источник или канал».

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

2. Сделайте таблицу соответствия URL

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

Действуйте так:

1. Сделайте таблицу существующих URL сайта с кодом ответа сервера

Воспользуйтесь Netpeak Spider или аналогичным инструментом для парсинга сайта. На этом этапе нужно получить список всех страниц с кодами ответа сервера. Добавьте полученные данные в таблицу.

1. Отсортируйте URL по коду ответа сервера

На этом этапе должно получиться три таблицы или вкладки: на первой доступные страницы с кодом ответа 200, на второй страницы с переадресацией с кодом 301, на третьей несуществующие страницы с кодом 404.

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

1. Сделайте таблицу с новыми URL

Если структура URL старого сайта была логичной, сделать таблицу соответствия будет относительно просто. Например, если в интернет-магазине товары были доступны по адресам типа example-site/catalog/phones/nokia1100/, на новом структура URL может быть такой: example-site/phones/nokia/nokia1100/.

Если на старом сайте были нелогичные URL типа example-site/catalog/nokia1100/ и example-site/catalog/samsung-galaxy/, трудоемкость процесса и вероятность ошибок увеличится.

Не забудьте настроить переадресацию для страниц с кодом 301. Если этого не сделать, на новом сайте будут отображаться несуществующие страницы старого сайта.

Уделите внимание URL с кодом ответа 404. Если это неактуальные адреса, не включайте их в таблицу соответствия. Страницы с такими URL можно не генерировать на новом движке. Если страница важная, на нее есть входящие внешние и внутренние ссылки, включите ее в таблицу и корректно настройте редиректы.

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

Проверить входящие ссылки можно с помощью инструментов типа Megaindex или Ahrefs.

3. Настройте новую CMS на тестовом домене или локальном сервере

Запустить сайт на локальном сервере поможет наше руководство. Также можно развернуть новый движок на поддомене вида test.example-site.com. Обязательно закройте тестовый поддомен от индексации. Это можно сделать средствами CMS или через файл robots.txt. Например, в WordPress закрыть сайт от индексирования можно в разделе админки «Настройки – Чтение».

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

4. Перенесите контент со старого сайта на новый

Если на сайте 5–10 страниц, контент можно перенести вручную. С переносом контента большого сайта будут работать программисты.

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

Статические страницы обычно переносятся вручную без шаблона. Например, речь идет о страницах «О компании», «Условия доставки», «Контакты», «Наша команда» и так далее.

5. Настройте редиректы

Запомните: вам нужен постоянный редирект 301. То есть после указания редиректов в файле .htaccess старые URL должны возвращать код ответа 301, а новые – код 200.

Редирект 301 сообщает поисковым системам, что страница навсегда переехала на новый адрес. В этом случае вся SEO-карма старого URL, включая входящие ссылки и внутренний ссылочный вес, передается на новый URL.

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

6. Проверьте корректность работы сайта

После переноса контента проверьте, как работает тестовый ресурс:

• Протестируйте работоспособность форм, кнопок, страницы оформления заказа.
• С помощью Broken Link Checker или аналогичного инструмента найдите битые ссылки и исправьте ошибки.
• Уделите внимание юзабилити. Для объективной оценки со стороны воспользуйтесь сервисом AskUsers.
• Оцените внутреннюю оптимизацию. Поможет наш чеклист для экспресс-аудита.

Если сайт работает корректно, откройте доступ к нему по основному URL. Сразу же выполните шаги 7 и 8.

7. Добавьте на сайт коды внешних служб и перенастройте системы аналитики

Добавьте на новый сайт контейнер диспетчера тегов, если вы его используете. Остальные службы можно подключать через Tag Manager или прямо на сайт. Необходимо:

• Добавить коды верификации «Яндекс.Вебмастер», Search Console Google и других поисковиков.
• Добавить коды отслеживания «Метрики», Google Analytics, Liveinternet.ru и других систем аналитики. Не забудьте перенастроить цели, электронную торговлю и другие параметры, на которые может влиять изменение URL.
• Установите коды рекламы и партнерских блоков, систем комментирования, обратного звонка, коллтрекинга, всплывающих окон, вывода рекомендаций и других сервисов, которые обеспечивают функциональность сайта.

Проверьте работоспособность внешних служб и при необходимости укажите корректные настройки.

8. Сгенерируйте актуальную карту сайта и сообщите о ней поисковым системам

Создать актуальную карту сайта можно с помощью внешних сервисов, например, XML-Sitemaps, или средствами нового движка.

• В WordPress воспользуйтесь плагинами All in One SEO Pack или Google XML Sitemaps.
• В Joomla! есть расширения Sitemap Generator и OSMap.
• В Drupal используйте модуль XML sitemap.
• В OpenCart задача решается с помощью модуля Yandex Sitemap.

После создания и настройки карты сайта перейдите в Search Console Google. В разделе «Сканирование – Файлы sitemap» отправьте новый файл на проверку. Это можно сделать с помощью кнопки «Добавление/Проверка файла sitemap».

В «Вебмастере» отправить новую карту сайта на проверку можно в разделе «Индексирование – Файлы sitemap».

9. Отслеживайте эффективность сайта после переезда

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

В случае стабильного падения поискового трафика ищите причины. Это могут быть:

• Технические проблемы, например, некорректно настроенные редиректы, дублирующийся контент, низкая скорость загрузки страниц и так далее.
• Ухудшение юзабилити и негативная реакция пользователей. Воспользуйтесь «Вебвизором», чтобы понять поведение посетителей нового сайта.

Корректная реализация описанного алгоритма позволяет перенести сайт на новую CMS без длительного падения трафика и других метрик эффективности. А если новый движок более удобный и функциональный, эффективность ресурса после переезда должна вырасти.

Особенности переноса сайта в популярных направлениях

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

Как перенести статичный HTML-сайт на WordPress

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

Алгоритм переноса такой:

1. Скопируйте и сохраните на локальном диске файлы старого сайта на HTML

Для этого можно использовать FTP-клиент, например, FileZilla. Данные для доступа к серверу возьмите у провайдера. Скачайте на локальный диск все папки и файлы из корневого каталога сайта. Корневой каталог имеет имя сайта.

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

1. Удалите с сервера старый сайт и установите движок

В нашем гайде есть наглядная инструкция по установке WordPress. Если вместо доступа к серверу по FTP-протоколу вы предпочитаете работать с cPanel или аналогичными панелями, воспользуйтесь инструкцией по установке движка с помощью автоустановщика скриптов Softaculos.

1. Конвертируйте дизайн сайта в тему WordPress

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

• HTMLtoWordPress. Платный сервис. В течение минуты конвертирует дизайн HTML-сайта в тему WordPress. Стоимость конвертации 5 долларов.
• HTML to WordPress Converter. Плагин для WordPress, который автоматически трансформирует дизайн HTML-сайта в тему WordPress. Стоит 20 долларов.
• CMS2CMS: Automated HTML To WordPress Content Migration. Условно бесплатный плагин, который переносит HTML-сайт на WordPress.

1. Установите тему WordPress

Используйте созданную на предыдущем этапе тему или выберите любой подходящий шаблон.

1. Перенесите контент на новый сайт

Контент небольшого сайта можно перенести вручную. Если сайт большой, доверьте перенос контента разработчикам. В качестве альтернативы обратите внимание на сервис CMS2CMS. Для автоматического переноса HTML-сайта на WordPress создатели сервиса предлагают пользоваться плагином.

После установки плагина в соответствующем разделе админки сайта появляется пункт меню HTML to WordPress. Войдите в него и зарегистрируйтесь.

Укажите URL сайта на HTML. Если планируете сделать сайт на WordPress на том же URL вместо сайта на HTML, сначала установите WordPress на локальный сервер.

Укажите подходящие настройки и запустите перенос. Доступны такие настройки:

• Трансформация страниц HTML-сайта в страницы или посты сайта на WP.
• В дополнительных настройках можно выбрать статус контента: опубликованный или черновик.
• За плату можно автоматически настроить редиректы, перенести мета-данные страниц и изображения.

Лайфхак: если при переносе сайта с HTML на WordPress вы не планируете сохранять дизайн, можно обойтись бесплатной версией плагина CMS2CMS. С ее помощью можно быстро перенести контент HTML-страниц на новый сайт. Останется только оформить страницы и поменять ссылки.

На анимации ниже показана исходная страница сайта на HTML и ее клон после переноса на WordPress.

Плагины CMS2CMS можно использовать для переноса на WordPress сайтов с Joomla!, Drupal, Weebly, Wix и других популярных движков и конструкторов.

Как переехать с Wix на WordPress

В начале лета 2018 года владельцы сайтов на популярном конструкторе Wix получили неприятный сюрприз: «Яндекс» разучился индексировать ресурсы на этой SaaS-платформе. Представитель «Яндекса» Михаил Сливинский пообещал решить проблему. Но эта ситуация – весомый аргумент в пользу переезда с Wix на полноценную CMS.

При переезде с Wix на WordPress возможны две ситуации.

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

Если при переезде вы меняете платформу и URL, достаточно настроить редирект 301 с Wix на новый сайт. Для этого воспользуйтесь соответствующей опцией в разделе «Управление сайтом – SEO». Обратите внимание, для настройки редиректа у вас должен быть подключен платный домен.

Wix не поддерживает экспорт сайтов на сторонние сервера. Но вы можете перенести контент вручную или с помощью программных решений, например, Automated WiX To WordPress Migration Plugin.

Как перенести сайт с Joomla! на WordPress

Для автоматического переезда с Joomla! на WordPress есть готовые программные решения:

• FG Joomla to WordPress.
• Automated Joomla To WordPress Migration.

Плагин FG Joomla to WordPress позволяет перенести контент на новый движок, а также сохранить структуру сайта: теги и категории. После установки надстройки запустить импорт можно в разделе админки WordPress «Инструменты – Импорт».

В настройках импорта можно автоматически удалить контент с сайта на WordPress. Для этого отметьте опцию Remove all WordPress content. Укажите URL сайта на Joomla.

Укажите данные базы данных сайта на Joomla. Их можно найти в разделе «Система – Информация о системе – Конфигурационный файл Joomla».

Если сайты находятся на разных хостах, разрешите удаленный доступ к базе данных Joomla. Для этого в cPanel в разделе «Базы данных» выберите раздел «Удаленный MySQL».

Добавьте узел доступа и сохраните изменения.

Настройте параметры импорта. Обратите внимание на возможность трансформировать публикации на сайте Joomla! в посты или страницы на сайте WordPress. Если нужны страницы, отметьте пункт Create Pages. Начните импорт с помощью кнопки Start/Resume the import.

Как перенести сайт с WordPress на Drupal

Сделайте резервную копию сайта на WordPress. Убедитесь в ее работоспособности. Для этого можно развернуть сайт на локальном сервере.

Экспортируйте сайт с WordPress. В админке выберите раздел «Инструменты – Экспорт». Отметьте опцию «Все содержимое».

Удалите WordPress с сервера и установите Drupal. Установите и активируйте следующие модули:

• Migrate. В Drupal 8 он есть в ядре, поэтому достаточно его активировать.
• WordPress Migrate. Нужен для импорта контента с WordPress.
• Migrate Extras. Обеспечивает корректную работу Migrate.
• Pathauto. Обязательный модуль для Drupal, формирует удобные URL.

После установки и активации модулей перейдите в раздел Content – Migrate. Выберите вкладку Import from WordPress. Укажите путь к скрытым файлам. Для этого перейдите по ссылке configured (см. иллюстрацию) и укажите параметры. Скрытые файлы можно хранить в одном каталоге с публичными.

Загрузите файл экспорта WordPress. Также можно указать URL старого сайта. Этот вариант работает, если со сменой движка вы меняете URL.

Создайте новые учетные записи для авторов публикаций на WordPress.

Настройте параметры импорта. Например, посты с сайта WordPress можно конвертировать в статьи, а статические страницы оставить статическими страницами.

Укажите параметры конвертации таксономий. Модуль миграции может конвертировать теги и категории WordPress в теги и категории Drupal.

Запустите импорт. После завершения работы модуля проверьте, как отображается контент. На иллюстрации ниже видно, как отображается контент на сайте-доноре (WP) и на сайте-акцепторе (Drupal).

Перенос сайта: возможно, но рискованно и хлопотно

В теории перенос сайта выглядит простой задачей. По сути для переезда нужно только настроить новый сайт с учетом актуальной структуры, перенести контент и прописать редиректы. На практике переезд с одной CMS на другую – трудозатратное и рискованное мероприятие. Поэтому воспринимайте смену движка как крайний шаг. А чтобы избежать необязательных хлопот и расходов, ответственно планируйте сайт и выбирайте подходящую CMS на старте.

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

• Подходящие причины для переезда сайта
• Неизбежные трудности при переносе сайта на новый движок
• Перенос сайта на новую cms

Подходящие причины для переезда сайта

Сразу нужно понять, что замена движка веб-сайта это перспектива угрохать массу времени и денег при больших рисках. История вебмастеринга знает примеры, когда самопальные движки стоимостью в несколько тысяч рублей морально и технически устаревали буквально через год, а стоимость их переноса на новую cms обходилась (или в итоге не обходилась – об этом история умалчивает) уже в несколько десятков тысяч.

Поэтому, мысль первая – замена движка требуется, когда иначе вообще никак. Доводы что «OpenCart уделает WooCommerce», а «на WordPress завезли свежие html5 шаблоны, поэтому быстрей переезжаем» – вообще не доводы. Причины для переноса сайта должны быть намного серьезнее:

• Ваш старый-добрый html-ресурс более не подходит функционально. Если задача сводится лишь к содержанию нескольких страниц или нужен простенький полезный сайт-визитка с контактами – то перенос сайта на cms не так уж и необходим. Другое дело, если вашу визитку требуется преобразовать в блог с постоянным постингом.

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

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

Другими словами, если самописка «не тянет», а допиливать – дорого, то стоит обдумать    как перенести сайт на другую платформу.

• Вам больше не подходит конструктор. Конструктор – вещь удобная, но ограниченная. Доступа ко внутренностям у вас нет, значит регулярные апдейты зависят от разработчиков. Имея в наличии движок вы можете спокойно прокачивать свой ресурс, аутсорсом или самому. Уходить с конструктора надо, если он функционально устарел, либо платформа стала обходиться дорого, либо с шаблонами беда, либо не хватает свободы для действий. Для бизнеса еще и важно место размещения серверов конструктора.

Особо нужно рассмотреть причины для рокировки между двумя полноценными движками, благо их немного. К примеру ваш форум на вордпресс-сайте стал очень посещаемым и тогда разумно поинтересоваться специальным форумным движком. Или причина может быть банально в деньгах. Тот же форум можно содержать платно, а можно – дешево и сердито, phpBB вам в помощь.

Все остальные причины и доводы следует разбирать детально и оценивать риск: Вордпресс для вас так и остался сложен и советуют Joomla? Если сайт уже что-то весит, то разумнее взять и освоить WordPress.

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

Друпал не солиден? Это вообще не довод – «причесать» красиво можно все, было бы желание и деньги.

И частый довод про взломы. Открытые движки считаются уязвимыми. Это не так, изучите основы open source и принципы взаимосотрудничества сообщества и знайте, что от целенаправленного взлома вас мало что может уберечь.

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

Неизбежные трудности при переносе сайта на новый движок

Разумеется, тонкости, проблемы и подвохи при смене «начинки» будут. Какие-то из них легко преодолимы, какие-то не решаемы вовсе. Разберем самые частые проблемы:

• Миграция содержимого и потенциальный content loss. Тренируемся создавать бекап сайта до начала вообще всего, если по-хорошему. Обычно сами cms-ки предусматривают такую опцию, либо встроенными инструментами либо плагинами. Если разговор идет о создании копии на стороне сервера (что кстати снимает привязку к любому движку), то бекапить возможно через админ-панель. Как в нее попасть – спрашивайте у хостинга.

В стандартную копию кладите все содержимое сайта и обязательно базу данных. Также необходимо проверять целостность сделанной копии. Пробуйте восстановить из нее сайт и если все в порядке – отлично, если нет, значит штурмуем поддержку. Без рабочей копии данных переезд начинать нельзя.

• Структура сайта и URL. Каждый движок генерирует URL по-своему, значит при смене cms адреса будут выглядеть иначе. Было www.вашсайт/tovari/katalog/kofe.html станет www.вашсайт/magazin/kofe/ или навроде. Вследствие этого неизбежны дубли результатов поиска, битые ссылки, ну и как результат – запинки ПС и негодование посетителей. Работа с url-организацией – вторая по важности после бекапа.

• Редиректы. Это логическое продолжение предыдущего пункта, если адреса все же поменялись. Постранично прописывать редирект со старой ссылки на новую, если количество страниц невелико, не трудно. Но, если страниц сотни и тысячи – то повозиться придется. Вооружайтесь плагинами и поддержкой профи.

• Функциональные различия движков. Допустим, что магазинчик на вордпрессе съезжает на OpenCart. WP идеально подходит для блоггинга, а вот статьи на OC в хороший блог превратить трудно, а они нужны. Значит придется подключать доп.модули, либо создавать отдельный субдомен на WP итд. Вариантов всегда множество – скучать не придется.

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

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

Перенос сайта на новую cms

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

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

      Если сайт небольшой, то делаем простую табличку и вписываем в нее штук 15 главных ключевых запросов в Яндекс и Гугл. Для крупного ресурса подойдут сторонние разработки по мониторингу позиций выдачи, например SerpStat.

Что касается богатых на трафик страниц, то эти показатели найдете в аналитике. Для Google Analytics в админке выбирайте пункты «Поведение >> Контент сайта >> Страницы входа»

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

2.       Таблица соответствий URL. Этот пункт пригодится, если url-структура действительно меняется и как говорилось выше – придется повозиться. Возимся:

•  Пишем табличку имеющихся адресов сайта с кодами ответов. Нам потребуется парсер сайта (извечное противостояние между Netpeak Spider и Screaming Frog каждый для себя решит лично). Главное, что на выходе должен быть лист абсолютно всех страниц с кодом ответа. Заносим эту информацию в табличку.

• Сортируем ответы. К этому моменту в вашем excel-доке должны быть три таблицы – первая с 200-м кодом, во второй – 301-й редирект, третья – 404-е.

• Сводим данные в таблицу новых адресов. Хорошо, если урлы прошлого сайта прописывались логично – тогда работы не много. К примеру товары располагались на полках вида vash_site/katalog/kofe/jokey, а станут располагаться на vash_site/kofe/arabika/jokey. Редирект можно делать пакетно.

Хуже, если все было нелогично и каталог был раскидан по страницам вида   vash_site/katalog/jokey и vash_site/katalog/jardin . В таком случае все будет долго. Но не сдавайтесь!

Все 301-е страницы редиректим на новые адреса, чтобы не получить кучу 404-ых.  Что же касается «старых» 404-ых, то ненужные страницы-заглушки в нашу табличку не заносим. Если же страница имеет значение и на нее ссылаются изнутри или снаружи, то вносим в таблицу соответствия и настраиваем редирект.

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

 Кстати комплексно проверить входящие ссылки можете пакетом Megaindex.

3.    Запускаем тестовый вариант новой cms. Это будет либо тестовый домен либо локальный сервер – решите сами. На втором варианте останавливаться не будем – манулов в сети по OpenServer полно. В случае тестового домена (а точнее — субдомена вида test.vash_site.ru), который вы развернете на хостинге, не забудьте важную вещь – закрыть его для индексации. Сама CMS должна это уметь (для WP в админке найдите «Настройки>>Чтение» и попросите роботов проходить мимо), либо ручками через файл robots.

Теперь, можно установить CMS и заняться ее настройкой – подобрать дизайн, сделать всю нужную оптимизацию, подобрать и подключить плагины, задействовать ускорение страниц, оснастить сайт микроразметкой и многое многое другое. Наслаждайтесь

4.       Переносим содержимое на новый сайт. Маленький сайт в несколько страниц переносим «ручками». Для больших ресурсов придется подключать программистов.

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

 Простые инфо-страницы, типа контактов или «О нас» переводим тоже руками.

5.       Настраиваем редирект. В этом моменте главное – наличие постоянного 301-го редиректа. После прописывания всех перенаправлений в htaccess url-ы старого сайта должны отвечать именно 301-м кодом, а новые – 200-м. Потому что код 301 объясняет поисковикам об окончательном переезде на другой адрес. Если все сделано правильно, то сеошный вес «прошлых» адресов осядет на новых.

6.       Чекаем сайт на предмет корректной работы. Львиная доля работы проделана, теперь нужно удостовериться, что тестовый ресурс в порядке:

• Включите «клиента» и проверяйте работу всех форм, нажимайте кнопки, пробуйте оформлять заказы.

• Просканируйте сайт на наличие битых ссылок и исправляйте то, что проглядели.  Плагинов масса, ресурсов тоже – например Dead Link Checker.

• Оцените юзабилити сайта —  удобно ли стало. Не стесняйтесь привлекать сторонних людей.

• Не лишним будет пройтись по некоторым пунктам этого пособия и финально убедится в том, что мы молодцы.

Если все в норме и вы готовы, то переводите тестовый суб-домен в основной и открывайте доступ по вашему главному адресу.

7.       Внедряем аналитику и внешние службы. Google Tag Manager – очень удобная штука, к использованию строго рекомендована. Через него удобно подключать все, что нам нужно. А нужно нам:

• Верифицировать Я.Вебмастер и GSC с помощью кодов.

• Поставить аналитику от всех популярных сервисов

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

8.       Генерируем sitemap. Сервисов для создания карты сайта полно, смело берем XML-sitemaps и радуемся, либо используем новую CMS на всю катушку. Вот плагины для самых популярных: WP – All in One SEO Pack, Drupal – XML Sitemap, OpenCart – Yandex Sitemap, Joomla! – OSMap.

Очень важно после генерации sitemap.xml в Google Search Console «скормить» его проверке. Идем в «Файлы Sitemap>>Добавление/Проверка файла Sitemap»

Я.Вебмастер тоже проблем не доставит – идем в раздел Индексирования и добавляем сгенерированный файл.

9. Фиксируем положительную динамику эффективности. Замеряли мы «старую» эффективность не зря – она понадобится сейчас. В первое время после смены движка сайта смотрите выбранные значения и мониторьте свежую метрику. Сопоставляйте цифры и если трафик сильно проседает, то скорее всего что:

• возникли проблемы технического характера – неверные или ненастроенные редиректы, контент-дубли, возможно снижение скорости загрузки и прочее.

• Пользователям «не зашло». Значит косяки кроются в юзабилити.

Проседание в первое время – это абсолютно нормально, а если следовать рекомендациям статьи, то это время сократится до минимума. Когда новая начинка сайта удобнее и мощнее, то вскоре после спада начнется ощутимый рост эффективности, не переживайте!

Получается, что вся задача сводится к настройке нового сайта с сохранением или адаптацией структуры, переносу контента и менеджменту редиректов. На деле же перенести сайт – процедура рискованная и трудоемкая. Прибегайте к этому лишь в случае острой необходимости, когда достигнут «потолок». А чтобы сэкономить средства и избежать трат – на стадии подготовки серьезно отнеситесь к выбору самой лучшей для вас cms.