Опыт переезда с WordPress на MaxSite CMS

Надавно обновил свой блог по созданию сайтов. К своему стыду он всё ещё работал на WordPress (старой версии). Сайт обновляется нечасто - главная его задача информация для клиентов по услугам и некая помощь в работе. Переезд я задумал давно, причём глобальный - со сменой дизайна и почти всех текстов (они были о WordPress, а нужно о MaxSite CMS).

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

Стояли следующие задачи:

• Сменить дизайн.
• Обновить все тексты.
• Удалить лишние тексты.
• Обеспечить бесперебойную работу с Sape (без error'ов).
• Сохранить индексацию в поисковиках.

Дизайн

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

Вёрсткой под MaxSite CMS заниматься одно удовольствие. Я вспоминаю сколько пришлось мудохаться со старым шаблоном: одно программирование чего стоило! Здесь же простой html-каркас, далее CSS (собственно это и была основная работа), вынес несколько блоков в components и буквально пара type_foreach-файлов с двумя правками. Ляпота! :coolsmile:

Установка тестового сайта на сервер

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

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

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

Сайт не очень большой, в общей сложности всего 60 записей. Причём многие записи уже потеряли актуальность, поэтому большого смысла их переносить их один в один не было. Поэтому я принял решение сделать ручной перенос. В комплекте MaxSite CMS есть плагин для экспорта текстов из WordPress, можно было бы им воспользоваться, но мне было важно заново просмотреть каждый текст сайта. Как я сказал тексты менялись сильно, поэтому автоматический перенос по сути принёс бы перенос только адреса и рубрики. Причём рубрики всё равно хотел переделать.

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

Скрипт простой. Размещается в каталоге text. В нём делаем еще один подкаталог txt, на который устанавливаются права на запись (777). После этого в браузере набирается http://сайт/text/export-txt.php. На выходе в каталоге txt получаем все тексты и информацию по каждой записи. В конце полный список всех записей. Скачать экспорт записей из WordPress ⁶⁸⁶ (поменяйте расширение на php).

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

Если текст менялся, то ссылка (slug) была старая - это чтобы обеспечить сохранность старого адреса.

Перенос на основной домен

Перенос тестового сайта делается так:

• Переименовываем старый index.php и .htaccess (от WordPress'а).
• Загружаем MaxSite CMS на сервер. Файлы и каталоги не пересекаются с WordPress, поэтому заменятся только несколько файлов, вроде sitemap.xml.
• Устанавливаем права на каталоги и файлы.
• C тестового сайта копируем config-каталог, .htaccess (или берем из дистрибутива), mso_config.php, а также свой шаблон.

На этом этапе сайт должен работать на MaxSite CMS. База у нас уже была прописана в тестовом сайте, поэтому ничего заново инсталировать не нужно. При этом, если вернуть старый index.php и .htaccess, то увидим WordPress.

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

Проверка Sape

После переноса нужно обеспечить сохранность адресов в сапе (или аналогичной бирже). У меня в WordPress'е ЧПУ всегда было настроена как «post_name», которые понимает MaxSite CMS. Таким образом мне не пришлось на этом этапе задействовать редиректы или какие-то другие ухищрения.

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

Как только появилась ошибочная страница нужно проверить её доступность на сайте. Если возвращается 404-страница, то по старым данным (те, что вытянули скриптом) смотрим почему данная запись не опубликована. Если она имеет ценность (даже на будущее), то делаем новую запись с этой короткой ссылкой. Если записей много, а текст еще не готов, то я делал так.

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

Удалённые страницы

У мня было несколько страниц, которые я хотел бы удалить навсегда. В этом случае я не делал им тип «sape», а удалял в самой Сапе. :roll:

Проверка индексации страниц поисковиками

Тут важно сделать так, чтобы сами адреса сохранились в поисковой базе. Теоретически поисковик должен сам обновить все данные и исключить лишние страницы. Гугл достаточно быстро делает переиндексацию, а вот что касается Яндекса, то с его роботом большие проблемы. У меня есть сайт, где робот Яндекса не может проиндексировать страницы с декабря 2009 года! Проблемы с индексацией Яндекса возникают у многих блогеров, поэтому лучше сделать так, чтобы не терять существующую базу.

Для проверки индексации нужно сделать две работы. Первая - проверить список старых адресов через какой-нибудь чекер битых ссылок. Например xseo.in. Копируете адреса по 30 штук и сервис выдаёт результат. Если 404-страница, значит следует либо сделать запись с этим адресом, либо поставить 301-редирект.

Редиректы проще всего делать с помощью плагина редиректа, который в комплекте MaxSite CMS. Указываете старый адрес, новый и 301 (тип редиректа).

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

Следующая работа - контроль через Яндекс. Для этого в браузере набираем адрес http://yandex.ua/yandsearch?serverurl=ВАШ-ДОМЕН. Получаем список всех проиндексированных страниц заданного домена. Дальше обезьянья работа - кликаем на каждую ссылку и проверяем, чтобы по ней не было 404-страницы. Думаю, что есть соответствующий SEO-софт для таких задач, но я, признаться так и не нашёл. Проще вручную проверить.

Есть еще один вариант проверки - сделать экспорт всех страниц площадки в самой Сапе и проверить их индексацию.

Быстрые ссылки для админа

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

Активируем плагин «Ссылки». Добавляем его в сайдбар и пишем условие:

links_widget админ is_login()

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

Заключение

В целом переезд оказался достаточно простым занятием. Главная задача - обеспечить сохранность адресов. Если бы у меня был другой ЧПУ, то пришлось бы прописывать редиректы для многих страниц. Переносы же текстов достаточно простая и тривиальная задача. Для большинства блогов вполне хватит встроенных в MaxSite CMS средств.

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