WordPressのデメリットとは？やめるか残すかの決め方と乗り換えの進め方

この記事のポイント

• デメリットの重さは管理体制で変わる
• 誰が・何を更新するかで決める
• 移行前に戻れる道を用意する
• URLだけでなくメールとFTPも調べる
• 管理画面まで作り込んで確かめる

記事の概要

WordPressを残すべきか、別のCMSへ乗り換えるべきか迷っている中小企業の担当者・決裁者向けの記事です。個別のサイトに適した判断は、現在の機能や管理体制によって異なります。

1. WordPressのデメリットは「誰が管理するか」で重さが変わる

WordPressの負担は、CMSそのものよりも、継続して管理できる人がいるかどうかで決まります。

WordPressは幅広いサイトに使える一方、公開後も更新や保守が続きます。社内外の誰が担当するのか決まっていないと、次のデメリットが重くなります。

株式会社iTechでも、旧サイトをWordPressで運用していた頃、いちばん負担になっていたのは毎月の保守でした。

更新の止まったプラグインに頼り続けるリスク

プラグインは、WordPressに機能を追加する仕組みです。必要な機能を追加できる反面、利用中のものが閉鎖された場合は、そのまま使い続けるのか、別の方法へ切り替えるのかを判断しなければなりません。

WordPress公式によると、WordPress.orgのディレクトリで閉鎖されたプラグインは、ページに閉鎖と表示され、ZIPファイルの配布も止まります。
出典：WordPress Plugin Developer FAQ

2. WordPressはやめたほうがいい？残すか移すかの決め方

残すか移すかと、どこへ移すかは、「誰が触るか」と「何をどう触るか」で決めます。

ブログやお知らせだけを更新するサイトは、まず切り替えて問題ありません。一方、会員・予約・複雑なフォームなど、データベースを使う機能が多いサイトは、乗り換え先でどうなるかを先に検証します。

乗り換え先も、誰が触るか、何をどう触るかに合わせて選びます。株式会社iTechは自社サイトでEmDashを選びましたが、どの会社にも同じ答えになるわけではありません。

弊社の場合は、EmDashでデータベース型のサイトを作るとどうなるかが未知数なため、こうした機能が多いサイトでは、WordPressを残して管理体制を整える判断も現実的だと考えています。読者のサイトでも、使う人と更新する内容を基準に判断します。

WordPress以外の選択肢は、次の記事で紹介しています。
WordPressのセキュリティ対策｜最低限と継続の判断基準

相談を受けたときに弊社が聞くこと

• サイトを日々触っている人
  「サイトの更新は、普段どなたが、どのくらいの頻度でされていますか」「更新するとき、どの画面で、どんな手順で作業されていますか。画面を見せていただけますか」と聞きます。管理画面は毎日使う人の道具であり、弊社の移行先では日本語化が約59％だったため、誰が何の画面を使うかの把握が必要だと分かりました。
• ログインや契約を持っている人
  「ドメイン・サーバー・WordPressの管理画面には、それぞれどなたがログインできますか」「契約はどなたの名義ですか」と聞きます。弊社では、DNSとドメインの操作を代表しか行えず、その人が切り替え当日に必要でした。DNSとは、ドメインとサイトやメールの接続先を対応させる仕組みです。
• ドメインに同居しているもの
  「このドメインで、サイトのほかに何を使っていますか」「このドメインのメールアドレスを使っているのは何名くらいですか」と聞きます。弊社ではメールとFTPが切り替えに巻き込まれて止まりかけ、利用者への質問なしでは把握できない項目だと分かりました。
• サイトから外へ出ていくもの
  「問い合わせや予約は、誰のところに、どうやって届いていますか」「アクセス数や成果は、どなたが、何で見ていますか」と聞きます。弊社でも、問い合わせフォームとアクセス解析のタグが、切り替えによって止まるか抜けるかしました。
• 残したいもの・捨ててよいもの
  「今のサイトで、どうしてもなくしたくないものは何ですか」「もう使っていないページや機能はありますか」と聞きます。弊社では、記事以外の古いURLが旧サイトのサイトマップに残っており、聞き取りだけでなく全件の突き合わせが必要だと分かりました。
• 切り替えの都合
  「サイトやメールが止まると、いちばん困る時期・曜日・時間帯はいつですか」「切り替えの当日、連絡がつく方はどなたですか」と聞きます。切り替えには、サイトだけでなくメールや外部サービスを操作できる人との連絡が欠かせません。

3. WordPressから乗り換える進め方

戻せる状態を保ちながら、移すものと影響範囲を順番に固めます。

① 移す先を決める前に、戻れる道を残す

移す先を決めきる前でも、作ったものが無駄にならない進め方を選びます。旧サイトには変更を加えず、問題が起きたときに戻れる状態を残します。

弊社の事例

弊社では2026年10月3日、CMSを決める前にAstro（サイトを組み立てる仕組み）でサイトの土台を作り始めました。EmDashはAstroの上で動くため、採用を見送った場合も、静的サイトとして今のサーバーに置けます。

新サイトの各ページを10月3日から10月7日に実装する一方、10月5日にはEmDashを検証環境に立てて実測し、10月9日に採用を決めました。本番のWordPressは記事を読み出しただけで最後まで変更せず、いつでも戻れる状態を残しました。

② 旧サイトから何を移すかを洗い出す

記事だけでなく、画像の状態、記事以外のURL、DNSまわりも洗い出します。古いURLは、持ち主の記憶だけに頼らず、旧サイトのサイトマップから全件を拾います。

弊社の事例

弊社が確認したのは、次の4種類です。

• 記事：99本、画像594枚
• 画像の状態：代替テキストが空の画像、他社サーバーから読み込む画像
• URL：実績、カテゴリ、タグ、著者ページなど、記事以外のURL
• DNSまわり：レコードの全量、メール、FTP、ドメインの有効期限、問い合わせフォームの仕組み

代替テキストは、画像の内容を文章で伝える情報で、altとも呼ばれます。記事内では、表103個、コード102個、ボタン15個、動画2本が崩れずに移るかも確認対象にしました。

画像594枚のうち、altが空のものは145枚、他社サーバーから読み込んでいるものは62枚ありました。その62枚のうち54枚は、Googleドキュメントの一時的なURLなどが期限切れになり、旧サイトでもすでに表示されていませんでした。

思っていたより多かったのは、記事以外のURLです。旧サイトのサイトマップを読むまで把握できておらず、そのまま公開すれば「ページが見つかりません」という404になっていました。

ほかにも、記事13本の説明文が「目次1…」になっていたこと、ドメインの有効期限が10月31日に迫っていたこと、なりすましメール対策の設定であるDMARCが未設定だったことが分かりました。

③ 記事データの移し方を決める

記事の移行では、WordPressから書き出したWXRを使うか、手元で整えたデータを使うかを決めます。WXRはWordPress eXtended RSSの略で、WordPressの投稿などを書き出すXML形式のファイルです。

WordPress公式によると、WXRには投稿、固定ページ、カスタム投稿タイプ、コメント、カスタムフィールド、カテゴリー、タグ、カスタムタクソノミー、ユーザーが含まれます。
出典：WordPress「Tools Export Screen」

弊社の事例

弊社が選んだEmDashは、WXR、WordPress REST API、WordPress.comから、投稿、固定ページ、メディア、タクソノミーを取り込めます。
出典：EmDash公式README

弊社は10月7日から10月9日に、記事99本を本番のWordPressから取り出し、手元で中身を整えました。WXRから取り込むと、2日かけて直したalt119枚、空のタグ18件、見出しの階層、外部画像の除去などの修正が消えるため、WXRは使わず、整備済みのデータから99本を入れました。

移行後は、旧サイトのURL、移行データ、新サイトの出力を突き合わせる検査を作り、99本すべてで題名と本文の全文が一致することを確かめました。

目次内のリンクは移行によって飛ばなくなったため、付け直しています。
WordPressに目次を追加する方法

④ URLを残す・転送する

記事のURLは可能な限り残し、変更するURLは旧URLとの対応表を作って恒久的に転送します。301転送とは、ページが恒久的に移動したことをブラウザや検索エンジンへ伝える仕組みです。

Googleは、旧URLと新URLの対応表を作り、可能なら301または308の永続的なリダイレクトを使うよう案内しています。移転後には、新しいサイトマップを送信します。
出典：Google検索セントラル「URLの変更を伴うサイト移転」

弊社の事例

弊社では、記事のURLである「/年/月/日/記事名/」を1本も変えませんでした。検索からの流入と、ほかのサイトからのリンクを落とさないためで、記事については転送自体が不要になりました。

記事以外の古いURLは、旧サイトのサイトマップから全件を拾い、新しいURLへ301転送しました。ただし、日本語を含むカテゴリURLは、検証環境でCloudflareの転送設定ファイルと一致しませんでした。最終的には、そのURLに実際のページを作って受けています。

切り替え直後には古いURLを全件開き、すべて転送されることと、転送先が正常に表示されて200を返すことを確かめました。

⑤ 切り替えの日に確かめる

切り替え前に戻し方を用意し、公開直後はページの表示だけでなく、転送、フォーム、メール、FTPまで確かめます。サイトマップと、存在しないページの応答も確認対象です。

弊社の事例

弊社が本番ドメインを切り替えたのは、2026年10月9日22時07分です。操作そのものは2秒で終わり、メール系の8レコードには触れませんでした。

問題があれば、サイトの向き先を示すレコードを元に戻し、旧サイトへ戻せるように準備しました。切り替え直後には、次の項目を確認しました。

• 主要11ページが正常に表示される
• 古いURLが正しいページへ転送される
• 存在しないページで404が返る
• サイトマップ117件とrobots.txtが表示される
• 問い合わせフォームから実際に送信できる
• 問い合わせフォームが不正な送信を拒否する
• メールを送受信できる
• FTPを利用できる

⑥ 切り替え後に見つかったことを直す

公開直後に正常でも、実際の環境で初めて表面化する不具合があります。切り替え後も、サイトと管理画面を確かめ、見つかった問題を直します。

弊社の事例

弊社では、アクセス解析のGA4タグが入っておらず、公開から翌朝0時過ぎまで何も記録されませんでした。本番用とは異なる手順でサイトを組み立てたことが原因です。

管理画面はログインに成功しているのに無限リダイレクトとなり、URL末尾のスラッシュの扱いが原因で開けませんでした。管理画面では記事中の画像が表示されず、画像501枚をCMSのメディアへ移し直して解消し、公開前の下書きをプレビューで開けない問題も見つかりました。

トップページなどでは、Cloudflare Workersの処理上限を超えたことを示すエラー1102が発生し、トップページでは8回中4回出ました。原因は、同じデータを2回読んでいたことです。公開後の修正は10月13日まで続きました。

4. 切り替えの日にメールを止めないための確認

Webサイトと同じドメインで動くメールやFTPを、切り替え前にすべて洗い出します。

ドメインの切り替えは、Webサイトだけに影響するとは限りません。DNSレコードを一部だけ見るのではなく、全量を洗い出し、それぞれがサイト、メール、FTPのどれに使われているかを整理します。

メールの接続先を示すMXや、mail・ftpのレコードが「ドメイン自身」を指す書き方になっている場合は、サイトの向き先を変えたときの影響を確かめます。CNAMEは、あるドメイン名を別のドメイン名に対応させるDNSレコードです。AやAAAAなどのレコードも含めて確認します。

メールやFTPのレコードの向き先が「ドメイン自身」になっていると、サイトの向き先を新しいサーバーやサービスに変えたとき、メールとFTPの向き先も一緒に変わり、そこでメールとFTPのサーバーが動いていなければ止まります。防ぐには、切り替える前に、メールとFTPの向き先を、ドメイン自身ではなくサーバー会社が案内する接続先の名前で書いておきます。

Cloudflare公式によると、プロキシできるのはA、AAAA、CNAMEの各レコードだけで、MXとTXTは常にDNSのみです。メール用のレコードやHTTP以外のサービスも、DNSのみにします。
出典：Cloudflare「Proxy status」

弊社の事例

弊社では、メールの接続先を示すMXと、mail・ftpのレコードが「ドメイン自身」を指していました。そのままサイトの向き先をCloudflareへ変えると、メール23アドレスとFTPも一緒に向き先が変わり、止まる状態でした。

この問題を避けるため、メールとFTPの向き先をドメイン自身ではなく、サーバー会社が案内する接続先の名前で書き、メール用レコードの書き方を固定しました。

問い合わせフォームもPHPで動いており、PHPが動かないCloudflareへそのまま切り替えれば、問い合わせが1件も届かなくなるところでした。

切り替え当日のメール系レコードと戻し方の扱いは、「3. ⑤ 切り替えの日に確かめる」に書いています。

5. 乗り換え先にもデメリットはある

乗り換えるなら、サイトの見た目だけでなく、毎日使う人の管理画面まで作り込んで確かめます。

新しいCMSへ乗り換えても、運用上の課題がすべてなくなるわけではありません。弊社でも、管理画面が変わったので、最初は慣れるまで少し手間取りました。弊社が選んだEmDashでは、2026年10月時点の実測で管理画面の日本語化が約59％でした。

「3. ⑥ 切り替え後に見つかったことを直す」で挙げた不具合のうち、管理画面に関わるものとして、無限リダイレクト、記事中の画像が表示されない問題、下書きのプレビューが開けない問題がありました。

振り返ると、弊社は乗り換え先の管理画面の構築を、もっとしっかり行うべきでした。乗り換え前には公開されるサイトだけでなく、日常的に更新する人が使う管理画面まで作り込み、実際に確かめる必要があります。

また、PHPで動く問い合わせフォームは、Cloudflareではそのまま動きません。乗り換え先を選ぶときは、記事の編集だけでなく、WordPress上で動いているフォームなどの機能も確認対象にします。

一方、弊社は MCP（AI から CMS を操作する仕組み）で CMS を動かしているので、サーバーまわりの手間はあまり感じていません。パスキーでログインでき、パスワードを覚えなくてよい点も楽になりました。
出典：EmDash公式README

乗り換えれば手間がなくなるのではなく、手間の種類が変わります。残すか移すか、どこへ移すかは、「2. WordPressはやめたほうがいい？残すか移すかの決め方」の判断軸で選びます。

6. WordPressの乗り換えでよくある質問

乗り換えの可否は、CMSの評判ではなく、更新する人、必要な機能、移すデータから判断します。

WordPressはオワコン・時代遅れですか？

WordPressを一律に時代遅れとは判断できません。日常的に誰が触るのか、何をどのように更新するのかを整理し、毎月の保守を続けられるなら、WordPressを残す判断ができます。

ブログやお知らせだけの場合と、会員・予約・複雑なフォームなどの機能がある場合の判断は、「2. WordPressはやめたほうがいい？残すか移すかの決め方」のとおりです。

乗り換えると検索順位は下がりますか？

一時的に変動することはありますが、URLを変えないか、変えるURLを正しく301転送すれば、下がる原因を減らせます。Googleは、サイトの移転中は検索結果での掲載順位が一時的に変動することがあると案内しています。
出典：Google検索セントラル「URLの変更を伴うサイト移転」

Googleは、検索結果に出るURLを変える場合、可能な限りサーバー側の永続的なリダイレクトを使うよう案内しています。Googlebotは転送先をたどり、正規URLを判断するためのシグナルに使います。
出典：Google検索セントラル「リダイレクトとGoogle検索」

弊社では、記事のURLを1本も変えませんでした。記事以外の古いURLは旧サイトのサイトマップから拾い、新しいURLとの対応を決めて301転送しました。

WordPressからの乗り換えにはいくらかかりますか？

費用は、洗い出すページや画像の量、記事データを整える方法、フォームなどの機能、同じドメインで動いているメールやFTPの有無で変わります。

既存のデザインとサイト構成を引き継ぐのか、それらも作り直すのかによっても、必要な作業は大きく変わります。

WordPressの記事は自分で書き出せますか？

WordPressでは、投稿や固定ページ、カテゴリー、タグなどを含むXMLファイルをWXR形式で書き出せます。

弊社がWXRを使わなかった理由と整備済みデータの移行方法は、「3. ③ 記事データの移し方を決める」のとおりです。

書き出せるかだけでなく、移行前に加えた修正をどのデータへ反映するのかまで決めることが重要です。

7. まとめ

WordPressを残すか、保守を任せるか、別の仕組みへ移すかは、管理する人と必要な機能で決めます。

WordPressのデメリットは、毎月の保守を続ける人がいない場合や、多くの機能をプラグインに頼っている場合に重くなります。ブログやお知らせだけのサイトは移しやすい一方、会員・予約・複雑なフォームがある場合は、WordPressを残す選択も含めて判断します。

乗り換える場合は、記事だけでなく、画像、古いURL、問い合わせフォーム、アクセス解析、メール、FTP、ドメインの状態まで洗い出します。公開されるサイトに加え、日常的に使う管理画面も作り込んで確かめます。

株式会社iTechでは、WordPressを残すか移すかのご相談と、現在のWordPressの状態を調べる無料診断を受け付けています。個別の判断は、サイトの構成、契約状況、必要な機能を確認したうえで行います。

執筆者

株式会社iTech愛知県豊田市の、Web制作とSEOを得意とするWebマーケティング会社です。ホームページやLPの制作から、公開後の保守・運用、SEO・SNSなどの集客支援まで、伴走型で中小企業のサイトをお手伝いしています。