WordPressからmicroCMSへ、過去の記事とこれからの更新をどう引き継ぐか

WordPressの投稿一覧には、これまでに書いた記事が並んでいます。1本開けば写真やキャプション、文字の装飾が書いたときのまま残っています。

microCMSを調べていると、移したあとのことが気になってきます。この写真や装飾は移した先でも残るのか。担当者はどの画面で新しい記事を書くのか。昔の記事に誤字を見つけたら同じように直せるのか。

自社メディアの2.5DGEEKも2026年10月に記事の管理をWordPressからmicroCMSへ移しました。移した公開記事は全部で881本です。

移すにあたって過去の記事と新しく書く記事で本文の持ち方を分けました。

WordPressを離れた理由は、本体や拡張機能の更新と安全面の備えを続ける負担でした。その話は「WordPressを使い続けるか」に書いています。ここでは、記事と編集作業の側で何を決めたかを書きます。

過去の記事はそのまま新しいエディタには移せなかった

移す前に、過去の記事をmicroCMSのリッチエディタの欄に保存して読み戻してみました。リッチエディタは見出しや画像を画面で見ながら入れていく欄です。

実際の記事17本の本文で試すと16本で中身が変わって戻ってきました。落ちていたのは画像や上付きの文字、太字などです。引用元の表記や装飾のための指定も消えていて残ったのはリンク先のほうでした。

これは試した時点の欄の設定での結果です。その欄はまだ画像を入れられる設定にしていませんでした。

同じ17本をWordPressが出力したHTMLのまま受け取る欄でも試しました。こちらは17本とも送った内容と同じものが返ってきました。

文章が保存できることと書いたときの姿で残ることは別でした。過去の記事は、WordPressで作られたHTMLのまま持たせることにしました。

ただ、HTMLのまま移せば表示まで元どおりになるわけでもありません。WordPressは記事を表示するときに、段組みを横に並べるための指定を書き足していました。移したHTMLにはその指定が無いので、横並びの見た目はサイトの側で補っています。

記事ページや一覧、検索やサイトマップなど16か所で、WordPress版とmicroCMS版の出力を突き合わせました。差が出たところは理由を確かめてから切り替えています。

過去の記事に合わせたHTMLの欄で、新しい記事までライターに書いてもらう形にはしませんでした。

新しい記事はリッチエディタの欄1つに本文のほとんどを書きます。見出しや箇条書きを打ち、画像も文章の途中に入れられます。

このリッチエディタでは、マークダウンという書き方も使えます（microCMSの操作マニュアル）。行の頭に「##」と打てば見出しに、「-」と打てば箇条書きになります。ツールバーのボタンを押さなくても、文字を打つ流れのまま形を付けられます。

WordPressの画面で書いてきた人には、意外と知られていない書き方かもしれません。2.5DGEEKでも、ライター向けの書き方の説明にこの打ち方を入れています。

準備の途中までは、本文は部品を1つずつ足して組み立てる形でした。画像を1枚入れるたびに文章の部品を区切り、画像の部品を足すことになります。この手間は大きいと判断し文章の欄で画像を扱えるようにしました。

部品として足すのは購入ボタンや関連記事のように、サイトの側で形が決まっているものだけです。

その代わり過去の記事を直すときは書き方が変わります。移した記事の本文はHTMLのままです。誤字を1文字直すにもHTMLを書き換えることになります。

過去の記事をよく書き直すサイトなら、この違いの重みは増します。今回の分け方が、どのサイトにも合うとは限りません。

本文の持ち方を決めても書く人の作業はそれだけでは終わりませんでした。

2.5DGEEKには取材の現場で撮った写真を出演者ごとにたどれるPhotologがあります。

WordPressでは、記事に写真を入れたあとメディアの画面に移って写真ごとに出演者のタグを付けていました。タグがまだ無い出演者はメモしておいて別の画面で登録します。

移行を始めたときのmicroCMSの形も、写真1枚ごとに別の項目として登録するものでした。このままだと、新しい写真を足すたびに記事とは別の場所で作業が要ります。

ライターに聞くと、本文に入れない写真は無いという答えでした。新しいタグも、同じ場所で登録したいということでした。

そこで記事の編集画面にPhotologの欄を置き、写真と出演者タグを記事と一緒に入れる形にしました。新しいタグを作るときは、欄から別のタブが開きます。過去の634枚もこの欄へ移しています。

移したことで、かえって危うくなった欄もありました。購入ボタンの提供元は、WordPressでは選択肢から選ぶ欄でした。microCMSでは最初、手で打ち込む欄になっていて、打ち間違えるとその記事のページが開けなくなる作りでした。切り替える前に選択肢から選ぶ欄に戻しています。

データが正しく移っていても、書く人の手順は別に決める必要があったということです。

移行先を比べるときは、新しい記事の書きやすさと過去の記事の直しやすさを別々に見ることになります。片方だけを見て選ぶと、もう片方の手間は移したあとに分かります。

自社の更新作業では、新しい記事を書くことと過去の記事を書き直すことどちらが多いでしょうか。その答えによって、過去の記事に残してよい手間の大きさも変わってきます。

移行の範囲や、切り替える前に確かめたことは、事例「2.5DGEEKのCMS移行」にまとめています。