ПЕРЕНОС САЙТА НА НОВЫЙ ДВИЖОК

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

• Подходящие причины для переезда сайта
• Неизбежные трудности при переносе сайта на новый движок
• Перенос сайта на новую 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.