Переход с WordPress на Movable Type: практические шаги «обратной» миграции

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

По запросу «миграция CMS» чаще всего находятся статьи о переходе с Movable Type на WordPress. На практике миграция в обратную сторону — с WordPress на Movable Type (или MovableType.net) — иногда оказывается вполне рациональной. Об этом обратном направлении пишут мало, поэтому здесь собраны и критерии решения, и рабочие шаги.

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

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

Термины, которые встречаются в статье

Чтобы статью мог прочитать и заказчик, а не только разработчик, сначала коротко разберём термины.

1. Сначала вывод

• Переход WordPress → Movable Type технически отработан: импорт MovableType.net принимает файл экспорта в формате WordPress (XML). Кроме записей и страниц подтягиваются изображения и файлы, на которые ссылаются текст и произвольные поля.
• Миграция оправдана для сайтов с невысокой частотой обновлений, небольшим числом редакторов и фиксированными требованиями к расширяемости. Сайтам, где членство или интернет-магазин собраны динамически на плагинах WordPress, этот путь не подходит.
• Успех решает не разница возможностей CMS, а проектирование URL, 301-редиректы и план замены функций плагинов. Если заранее это не зафиксировать и перенести только данные, споткнётесь и на SEO, и в повседневной работе.
• Произвольные типы записей и кастомизированный XML «как есть» могут не прочитаться — закладывайте время на конвертацию и ручную доработку (это прямо сказано и в официальном руководстве).

На схеме сплошная линия обозначает отношение, которое выполняется всегда, а пунктирная — условное отношение (условия указаны в пояснении к каждому отношению на странице сведений). Полный список отношений (всего 23, с доказательствами и степенью уверенности) и определения основных понятий собраны на странице сведений карты знаний (на японском). Данные: JSON-LD / Turtle

2. Почему миграция идёт «в обратную сторону»

WordPress — самая распространённая CMS в мире, и сама по себе это сильный выбор. Но у динамической CMS есть и своя эксплуатационная цена.

• Обновления нельзя просто остановить. Ядро, темы и плагины обновляются постоянно; оставлять их без внимания — уже риск. Об уязвимостях CMS и плагинов IPA предупреждает неоднократно; особенно заметны проблемы, которые тянутся от плагинов.
• Ответственный часто пропадает. Студия сдала сайт, договора на сопровождение нет — и появляются сайты, где «кнопку обновления никто ни разу не нажимал».
• Совместимость плагинов. Если каждое обновление ломает вёрстку или отключает функцию, обновляться страшно, и запущенность только растёт.

У Movable Type в основе статическая публикация: HTML генерируется заранее и отдаётся как файл (при необходимости можно включить и динамическую публикацию). Если посетителю уходят статические файлы, на публичной стороне программа CMS не выполняется — меньше поверхность атаки и меньше точек отказа.

Если взять SaaS MovableType.net, можно пойти дальше: обновления ядра CMS и безопасность выполняет провайдер, SSL (HTTPS) — без доплаты. Это схема для тех, кто хочет вкладываться в содержание сайта, но не хочет сопровождать саму CMS.

3. Куда переходить: Movable Type или MovableType.net

Вариантов по сути два.

Для корпоративного сайта или сайта профессиональной конторы с небольшой командой реалистичный порядок такой: сначала оценить MovableType.net и только если требования в него не укладываются — смотреть программную версию. Процесс согласования (заявка / утверждение) и стейджинг хорошо ложатся на работу контор вроде «публикуем только после проверки руководителя».

4. Общая схема миграции

Миграцию проводят в таком порядке. Главное — поставить инвентаризацию URL (шаг 2) раньше переноса данных (шаг 3).

1. Опись текущего состояния — список страниц, функций и плагинов
2. Проектирование URL — таблица соответствий старых и новых URL (маппинг 301)
3. Перенос данных — экспорт из WordPress → импорт
4. Пересборка шаблонов — дизайн и метаданные
5. Замена функций — формы, поиск и т. д.
6. Проверка — сверка старого и нового, фактические редиректы
7. Запуск — переключение DNS, отправка карты сайта, проверка Search Console

Шаг 2 (проектирование URL) стоит раньше шага 3 (перенос данных) не случайно. Правила URL пронизывают и таблицу соответствий для 301, и внутренние ссылки в тексте записей. Если сначала загрузить данные, а потом решить «давайте всё-таки изменим правила URL», недостаточно пересобрать таблицу 301: придётся заново пройти все ссылки на старые URL, которые уже лежат в импортированных текстах, и повторить проверку. Если же правила URL зафиксировать заранее, перенос данных (шаг 3) и пересборку шаблонов (шаг 4) можно вести параллельно. Это порядок, в котором чем раньше принять решение, тем меньше придётся откатываться.

5. Как на практике переносят контент

5.1. Сторона WordPress — экспорт

В консоли WordPress делают так (официальный экран Tools Export).

1. В левом меню откройте «Инструменты» → «Экспорт».
2. Выберите объём выгрузки. Если взять «Все содержимое», в один файл попадут записи, страницы, комментарии, произвольные поля, термины (рубрики, метки), меню навигации и произвольные типы записей.
3. Кнопка «Скачать файл экспорта» сохраняет XML. Это файл в формате WXR.

Если файл получается слишком большим, его можно разрезать на этом же экране. Вместо «Все содержимое» выберите «Записи» — тогда можно сузить выгрузку по рубрике, автору, периоду (даты начала и конца) и статусу. «Страницы» тоже фильтруются по автору, периоду и статусу. На сайте с большим числом записей надёжнее резать по годам — «2023», «2024» и так далее — и загружать файлы по очереди. Можно выгрузить и только «Медиафайлы».

5.2. Сторона MovableType.net — импорт

1. В консоли в левой боковой панели выберите «Инструменты» → «Импорт».
2. Укажите файл. Поддерживаются экспорт MovableType.net, формат Movable Type, формат WordPress и CSV. XML, выгруженный из WordPress, читается как «формат WordPress» без дополнительной конвертации.
3. Если включить «Импорт элементов», из текста записей и произвольных полей извлекаются URL, файлы скачиваются и принимаются как элементы (изображения и вложения).

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

• Чтение может занять время. Когда импорт заканчивается, на зарегистрированный адрес приходит письмо. Не думайте, что «экран завис», и не прерывайте операцию. Ограничения по размеру файла и числу записей в руководстве не названы, но если за один проход не проходит или слишком долго — реалистичный обходной путь это нарезка по периодам из шага 5.1.
• BASENAME записи (строка, которая идёт в URL) наследуется только из латиницы и цифр, если они в нём есть. При совпадении с другой записью добавляется число. У сайтов с японскими ярлыками (slug) URL здесь меняется. Обязательно поймайте это таблицей соответствий старых и новых URL в главе 6.
• Веб-страницы импортируются как записи.

По официальному руководству охваты импорта такие:

Как починить иерархию рубрик, если она разъехалась, подробно описано на странице «Импорт» официального руководства. При импорте в формате Movable Type значения PRIMARY CATEGORY: и CATEGORY: в файле экспорта переписывают в вид имя-корневой-категории/имя-подкатегории — через слэш. Тогда иерархия сохраняется. Если иерархия рубрик для бизнеса обязательна, эту правку стоит заранее включить в процедуру миграции. Исходный текст шага — в руководстве по импорту MovableType.net.

В том же руководстве есть конкретный пример правки и для произвольных типов записей: например, <wp:post_type>portfolios</wp:post_type> заменить на <wp:post_type>page</wp:post_type>. Само по себе знание, что «не прочиталось» не всегда конец: XML можно поправить как текст и пройти импорт, уже меняет оценку трудозатрат.

Если произвольные типы записей и произвольные поля WordPress используются активно, смотрите официальный инструмент конвертации и описание процедуры и по каждому виду контента решите: «уйдёт автоматически», «нужна конвертация» или «собираем вручную». Эта таблица и есть оценка объёма миграции.

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

6. Как сохранить URL и SEO

Почти все случаи, когда миграция CMS бьёт по SEO, связаны не с типом CMS, а с тем, как обошлись с URL.

Настройки постоянных ссылок WordPress (/?p=123, /2024/05/post-name/, /category/post-name/ и т. п.) со структурой URL после перехода обычно не совпадают. Сохраняют их так:

1. Опись всех URL. Соберите все действующие адреса — записи, страницы, рубрики, метки, страницы изображений — по карте сайта или краулеру.
2. Зафиксируйте таблицу соответствий новым URL. Сначала утвердите правила URL после миграции, затем постройте таблицу «старый URL → новый URL» (маппинг 301). В первую очередь проверьте страницы с большим поисковым трафиком.
3. Поставьте 301-редиректы. На каждый изменившийся URL — постоянный редирект (301).
4. Перенесите элементы на странице. Заголовок, meta-описание, структуру заголовков и структурированные данные при пересборке шаблонов переносят сознательно. То, что раньше выводил SEO-плагин, после миграции реализуется в шаблоне.
5. Проверьте после запуска. Повторно отправьте XML-карту сайта, следите за индексацией и ошибками в Search Console, измерьте редиректы на ключевых страницах (коды состояния).

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

7. Замена функций плагинов: отделить «искать замену» от «больше не нужно»

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

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

8. Итог: каким сайтам это подходит (профессиональные услуги и корпоративные сайты с небольшой командой)

Краткий портрет сайта, которому переход WordPress → Movable Type (особенно MovableType.net) обычно подходит:

• Обновления — в основном новости, колонки и кейсы, места правок довольно однотипны
• Выделенного веб-специалиста нет, на сопровождение самой CMS людей не выделить
• Как на сайтах налоговых консультантов, судебных писарей и других профессиональных услуг, перед публикацией хочется шаг проверки и согласования
• Нет динамических функций вроде членства, интернет-магазина или бронирования (либо их можно вынести во внешний сервис)
• В отрасли инцидент безопасности сразу бьёт по доверию, и хочется уменьшить поверхность атаки

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

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

Если вы рассматриваете миграцию CMS

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

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

Похожие статьи

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

Связанные темы

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

Услуги по этой теме

Статья напрямую связана со следующими услугами.

Частые вопросы

Вопросы, которые часто возникают при консультациях по теме статьи.

Можно ли перенести записи WordPress в Movable Type «как есть»?

Базовый контент — записи и страницы — переносится. Импорт MovableType.net принимает файл экспорта в формате WordPress (XML) и подхватывает изображения и файлы, на которые есть ссылки в тексте и в произвольных полях. Произвольные типы записей и сильно кастомизированные данные «как есть» часто не читаются: нужна конвертация или ручная доработка. Перед миграцией важно отделить контент на стандартных возможностях WordPress от того, что завязано на плагины и кастомизацию.

Не упадёт ли SEO-оценка из-за смены CMS?

Важнее не тип CMS, а изменятся ли URL и правильно ли настроены редиректы. До миграции составьте опись всех URL, зафиксируйте таблицу соответствий новым адресам и поставьте 301-редирект на каждый изменившийся URL. Если сохранить заголовок, meta-описание и структуру заголовков, а после запуска повторно отправить XML-карту сайта и проверить Search Console, серьёзного падения именно из-за миграции обычно удаётся избежать. Если эту работу пропустить, оценка упадёт при любой CMS.

Что будет с функциями, которые давали плагины WordPress?

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

Что выбрать — Movable Type или MovableType.net?

Если сервер ведёте сами и хотите свободно расширять сайт плагинами и связкой с базой данных, берите программную версию Movable Type. Если сервер и обновления ядра CMS хочется отдать провайдеру и облегчить эксплуатацию — SaaS MovableType.net. Для организаций без выделенного веб-специалиста — корпоративных сайтов малого и среднего бизнеса, сайтов юридических и бухгалтерских контор — реалистично начинать с MovableType.net: обновления ядра и безопасность берёт на себя сервис.

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

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