WordPressの
WordPressをやめたい理由を分け、WordPressのままでよい場合と代替CMSの型、自社に合う選び方を整理。WordPress以外へ乗り換える前に確かめることと移行の進め方も解説します。
WordPressをやめたいと考えるきっかけは、たいてい日々の運用の中にあります。プラグインを更新するたびに表示が崩れないか気になる、ページの表示が遅くなってきた、脆弱性のニュースが出るたびに自社のサイトが関係あるのかを調べることになる、保守を頼める人がいない。WordPressのデメリットがはっきり見えていても、「代わりに何を選べばよいのか」「そもそも移るべきなのか」までは、すぐには決められません。
この記事では、WordPressの代替を探している企業のWeb担当者に向けて、次の順番で判断の材料を整理します。やめたい理由を分け、WordPressのままで解けるかを確かめ、解けない場合に代替CMSの型を選び、乗り換える前に今のサイトを確かめる、という順番です。WordPressを続けるのがよい、という結論になることもあります。
途中で判断に迷ったら、TamaTに相談することもできます。
WordPressをやめたい理由を、まず分ける
「脱WordPress」と一言でいっても、理由によって打ち手が変わります。WordPressの中で直せる問題なのか、WordPressという仕組みに由来する問題なのかを分けると、移行を考えるべきかどうかが見えてきます。
やめたい理由 | WordPressのままでできること | CMSを変えると変わること |
|---|---|---|
プラグインの更新が怖い | 検証環境で試してから更新する。使っていないプラグインを外す | プラグインに頼らない構成では、プラグインを更新する作業がなくなる。その代わり、必要な機能は別に作って保守する |
表示が遅い | 画像の最適化やキャッシュの設定を見直す | 前もって作ったページを配る構成では、表示のたびにデータベースへ問い合わせる処理がなくなる |
脆弱性への対応が追いつかない | 本体・テーマ・プラグイン・PHPを更新する。管理画面へのアクセスを制限する | 公開側でPHPやデータベースを動かさない構成では、攻撃を受ける入口が減る。どのCMSでも更新と保守は残る |
編集画面が使いにくい | 入力欄を整理し、マニュアルを整える | 入力項目を前もって決める型では、どこに何を入れるかが迷いにくくなる。その分、ページのレイアウトを自由に組み替えにくくなる |
ページやサイトが増えて管理しきれない | 不要なページやプラグインを整理する | サイトが増えるたびに増える保守の手間を、構成から見直せる |
作った人しか分からず、引き継げない | 保守の担当と範囲を決めて契約する | 作り直しの機会に、設計と運用の手順を引き継げる形で残せる |
表の真ん中の列で済むなら、移行より先にWordPressの中で直すことを先に考えます。右の列の理由が中心になっているなら、CMSを変えることを考える段階です。
それぞれの理由の詳しい切り分けは「WordPress運用でぶつかる「壁」の正体と、その先の選択肢」で、脆弱性への備えについては、PHPの脆弱性を扱った記事の「自分たちは関係あるのか」の節で、自社のサイトが当てはまるかを確かめられます。
WordPressのままでよい場合
次のような場合は、TamaTはWordPressを続けるほうが合理的だと見ています。
保守の担当がはっきりしていて、本体とプラグインの更新、バックアップ、管理画面へのアクセス制限が回っているサイトです。やめたい理由として挙がりやすい不安の多くは、この状態ならすでに手当てされています。表示速度や新しい機能など、別の動機が出てくるまで作り替えを急ぐ必要はないと考えます。
更新する人が、ブロックを組み合わせてページのレイアウトをその都度組み立てているサイトも、WordPressのほうが向いています。入力項目を前もって決めるCMSでは、この使い方がしにくくなります。
会員管理や予約などの業務がプラグインと強く結びついていて、作り直すための時間と予算を取れない場合も、まずは今の構成を整えるほうが現実的です。移行すれば、別の制約を抱えることになります。
運用にかけられる費用がサーバー代程度に限られる場合も、無理に移る理由はありません。CMSを変えると、構成によっては運用の費用が上がります。守れる範囲や手間の減り方と釣り合うかどうかは、サイトがどれだけ重要かによって変わります。
microCMSへの移行を例にした判断の分かれ目は「「脱WordPress」と言われた制作会社が、最初に確認すべきこと」でも扱っています。
WordPress以外の選択肢：代替CMSの型
製品の名前から比べ始めると、比べる軸が定まりません。まずは「管理画面と公開サイトがひとつか、分かれているか」と「サーバーを誰が見るか」で型に分けると、候補を絞りやすくなります。ここで言う管理画面は記事やページを入力する画面、公開サイトは訪問者が見るページのことです。
管理画面とサイトが一体のCMS（WordPress・EmDash）
WordPressと同じく、ひとつの仕組みで管理画面と公開サイトを動かす型です。新しい選択肢として、Cloudflareが開発するEmDashがあります。EmDashはWebサイトを作るための仕組みであるAstroの上で動き、プラグインは他から切り離された環境で動かせる設計です。
WordPressから書き出したファイル（WXR）や専用のプラグインを使って、記事や固定ページ、カテゴリーなどを取り込めます。一方で、WordPressのテーマやプラグインはそのままでは動かないため、デザインやプラグインが担っていた機能は作り直しになります。くわしくは「EmDash（エムダッシュ）とは？」で解説しています。
ヘッドレスCMS（microCMSなど）
ヘッドレスCMSは、管理画面と公開サイトを分けたCMSです。管理画面で入力した内容をAPI（ほかの仕組みからデータを受け取るための窓口）で渡し、公開サイトは別に作ります。microCMSのようなクラウド型（SaaS）では、CMSのサーバーや管理画面を提供会社が管理するため、WordPressのようにプラグインを自社で更新する作業はありません。
入力項目を前もって決めて作るので、どこに何を入れるかが決まり、更新する人が迷いにくくなります。その分、ページのレイアウトを担当者が自由に組み替える使い方には向きません。お問い合わせフォームや会員登録などの機能は、プラグインではなく実装や外部のサービスで用意します。
WordPressを入力の画面としてだけ残し、公開サイトを別の仕組みで作る構成もあります。WordPressには、記事などのデータをほかの仕組みに渡すREST APIが備わっているためです。編集する人の操作を変えずに、表示と公開の部分を作り替えたいときの選択肢になります。
主なヘッドレスCMSの違いは「JamstackのCMS比較」の記事で比べています。
Gitで管理するCMS（Decap CMSなど）
記事などのコンテンツを、サイトのプログラムと同じ場所（Gitのリポジトリ）にファイルとして保存する型です。Decap CMSはオープンソースで、以前はNetlify CMSという名前でした。
コンテンツの変更がプログラムと同じ履歴で残るため、更新や保守をエンジニアが担うサイトと相性がよい型です。エンジニアが近くにいない組織では、扱いにくい場面が出てきます。
ノーコードのサイト作成サービス（Studioなど）
プログラムを書かずに、画面の操作でデザインとページを作るサービスです。Studioの場合、サーバーを別に契約・管理する必要はないとされています。デザインの調整まで社内で進めたい場合に候補になります。
WordPressからの移行では、書き出したファイルを使って記事や固定ページなどの一部を取り込めるサービスもあります。ただし、デザインや設定はそのまま移らず、ページの構成やURLは移行後に確かめ直す必要があります。外部のシステムとの連携や独自の機能は、そのサービスの機能でどこまでできるかを先に確かめておきます。
自分のサイトに合う代替の選び方
型を選ぶときは、製品の機能表を見る前に、次の点を社内で答えておくと候補が絞れます。
- 誰が更新するか：Web担当者や現場の社員か、エンジニアか、制作会社か
- 何を更新するか：決まった形の記事やお知らせが中心か、ページのレイアウトまで変えるか
- 誰が保守するか：社内に担当がいるか、外部に任せるか
- どんな機能が要るか：お問い合わせ、サイト内検索、会員・ログイン、決済、予約、多言語、外部システムとの連携
答えと型の関係は、おおよそ次のとおりです。
社内の答え | 合いやすい型 |
|---|---|
担当者が記事やお知らせを決まった形で更新し、レイアウトは制作会社に任せる | ヘッドレスCMS、またはEmDashのような一体型 |
担当者がページのレイアウトまでその都度組み立てる | WordPressを続ける、またはノーコードのサービス |
更新も保守もエンジニアが担う | Gitで管理するCMS、またはヘッドレスCMS |
会員や決済、予約が業務の中心にある | 機能ごとに外部のサービスと組み合わせる設計が前提。型より先に機能の要件を固める |
ひとつの型に決めきれない場合もあります。たとえば、記事はヘッドレスCMSで管理し、会員登録や決済は別のサービスと組み合わせる、という分け方です。機能ごとにどこが担うかを決めておくと、型の選択で迷う範囲が狭まります。
乗り換える前に確かめること
どの型を選ぶにしても、乗り換えの前に今のサイトを確かめておくと、移行の途中で見落としが出にくくなります。
ページとURL
今のURLを残すのか、変えるのかを決めます。変えるURLには、古いURLから新しいURLへ転送する設定（リダイレクト）を用意します。検索エンジンからの評価や、ほかのサイトから貼られたリンクを引き継ぐためです。
コンテンツの種類と量
記事や固定ページのほか、独自の投稿タイプ、カテゴリーとタグ、画像などのメディアを洗い出します。ショートコードやページビルダーで作ったページは、移行先で見た目が変わりやすいため、代表的なページを先に確かめておきます。
プラグインが担っている機能
お問い合わせフォーム、サイト内検索、会員・ログイン、決済、予約、多言語、外部システムとの連携のうち、移行後も必要なものを決めます。プラグインで済んでいた機能は、移行先では作るか、別のサービスで用意することになります。
更新と保守の体制
移行後に誰が何を更新し、誰が保守するかを決めます。更新する人が新しい管理画面で迷わないように、入力の手順も合わせて考えます。
今のサイトを残せるか
新しいサイトを確かめ終えるまで、今のWordPressを残しておけるかを確かめます。切り替え後に問題が出たとき、元に戻せる状態を残しておくためです。
こうした点は、TamaTのWordPress移行診断でも整理できます。公開中のサイトのURLかWXRファイルから読み取ったサイトの状態と、移行の目的や残したい機能などの質問への答えをもとに、移行の前に確かめる点をまとめます。
移行の進め方
TamaTでは、移行を次の順番で進めます。
- 現状調査・課題整理：更新、表示速度、保守の課題を伺い、今あるコンテンツと運用の環境を確かめます。
- 改善範囲の決定：一部の改善、段階的な移行、全面的な作り直しを比べ、予算と運用に合う方法を決めます。WordPressを続けて改善する方法も、ここで比べる対象に入ります。
- 設計・実装・移行：新しい環境を作り、コンテンツを移します。URLと必要なリダイレクトもここで設計します。
- 切替・引継ぎ：切り替えの手順、確認する項目、影響が出る範囲を前もって相談し、公開を切り替えます。そのあと、更新する人が運用できるように引き継ぎます。
一度にすべてを作り替える必要はありません。先に一部のページから新しい仕組みに移し、確かめながら範囲を広げる進め方もあります。サイトを止めずに移せるか、検索からの評価はどうなるか、といった移行の不安と答えは「「Jamstackに移行したいのに、踏み切れない」を解消する」にまとめています。
TamaTに相談する場合
TamaTは、今あるサイトの構成を確かめたうえで、移行の方法を提案しています。WordPressで運営していたWebメディアを、Next.jsとmicroCMSで作り直した実績もあります。サービスの内容は「サイト刷新とCMS移行」をご覧ください。
費用は、コンテンツの量、今ある機能、引き継ぐ環境によって変わるため、個別にお見積もりします。初期の開発と月々の運用は分けてお出しします。目安を知りたい場合は、見積もりシミュレーターを使えます。
移行するかどうかを決める前、WordPressをやめるか続けるかで迷っている段階でも、お問い合わせフォームからご相談ください。
参考
- EmDash Docs「EmDash for WordPress Developers」
- EmDash Docs「Migrate from WordPress」
- WordPress Developer Resources「REST API Handbook」
- microCMS 公式サイト
- Decap CMS「Overview」
- Studio「よくある質問」
- microCMS ヘルプ「インフラは何を用意したら良いですか？」
- Cloudflare Blog「Introducing EmDash — the spiritual successor to WordPress that solves plugin security」