「WordPressをやめたい」という相談は、たいてい具体的な不満から始まります。プラグインの更新通知が毎週のように来る、表示が遅い、管理画面が複雑で担当者が触りたがらない、セキュリティの警告メールが届いた、などです。
ただ、不満の原因がWordPressそのものにあるとは限りません。古いテーマ、増えすぎたプラグイン、更新されていないPHPが原因なら、WordPressのまま作り直すほうが安く、早く、確実なこともあります。逆に、サイトの使い方がWordPressの得意分野から外れているなら、別の仕組みに移ったほうが運用は軽くなります。
この記事では、まずWordPressがいまどのくらい使われ、どんな保守の負担を抱えているかを一次情報の数字で確かめます。そのうえで、続けるか移るかの判断基準と、移る場合の手順（棚卸し、エクスポート、データ構造の対応表、プラグイン機能の置き換え、多言語、公開切り替え）を順に整理します。URLを変える場合のリダイレクトの詳細は「サイトリニューアルで検索順位を落とさない301リダイレクトの手順」、費用全体の見積もりの読み方は「ホームページリニューアルの費用相場と見積もりの読み方」で扱っています。
この記事が主に根拠にした情報
- W3Techs「Usage statistics of content management systems」（2026年10月24日時点）
- WordPress.org の利用統計（PHPとWordPressのバージョン分布、2026年10月24日取得）と公式ドキュメント（エクスポート、REST API、動作環境）
- HTTP Archive「Web Almanac 2025」CMS の章（2026年1月公開）
- PHP 公式のサポート期間の表、Patchstack「State of WordPress Security in 2026」
- Google Search Central のサイト移転・hreflang・JavaScript SEO の案内、欧州アクセシビリティ法（指令 (EU) 2019/882）
| この記事で分かること | 答えの要点 |
|---|---|
| WordPressはどのくらい使われているか | 全サイトの39.6%、CMS利用サイトの58.3%（第1章） |
| 保守の負担はどこにあるか | 古いPHPとプラグインの脆弱性（第2章） |
| 移行先にはどんな種類があるか | 静的サイト生成、ヘッドレスCMS、SaaS型ビルダー、自前CMSの4つ（第3章） |
| 続けるか移るかはどう決めるか | 更新の頻度・人数と、機能の量の2軸（第4〜5章） |
| 移行は何から始めるか | 棚卸しと対応表。書き出しはその後（第6〜9章） |
| 多言語と公開切り替えはどうするか | 翻訳の対応表、URLの維持、切り戻しの準備（第10〜11章） |
1. WordPressはいまどのくらい使われているか
全サイトの約4割、CMSの約6割
最初に、WordPressの立ち位置を数字で確かめておきます。Webで使われている技術を調べている W3Techs によると、2026年10月24日時点でWordPressは全Webサイトの39.6%に使われ、CMS（コンテンツ管理システム）を使っているサイトに限るとシェアは58.3%です。2位の Shopify は全サイトの5.3%で、差は大きく開いています。
次の表は、同じ調査の上位の数字を並べたものです。「CMSなし」は、W3Techs が判別できる仕組みを使っていないサイトで、手書きのHTMLや独自開発のサイトがここに入ります。
| 仕組み | 全Webサイトに占める割合 | CMS利用サイトでのシェア |
|---|---|---|
| WordPress | 39.6% | 58.3% |
| Shopify | 5.3% | — |
| Wix | 4.2% | — |
| Squarespace | 2.4% | — |
| Joomla | 1.1% | — |
| CMSなし（判別できない） | 32.1% | — |
数字から言えるのは、WordPressが少数派の古い仕組みになったわけではないということです。対応できる制作会社や人材、解説の情報も、ほかの仕組みより多く見つかります。移行を考えるときは、この「人と情報の多さ」も一緒に手放すことになる点を覚えておいてください。
実測データでも、CMSを使うサイトの6割超がWordPress
W3Techs は上位1,000万サイトを対象にした調査です。もっと広い範囲を実際にクロールしている HTTP Archive の「Web Almanac 2025」でも、CMSを使うサイトは観測したサイトの54%を超え、そのうちモバイルで約64.3%がWordPressでした。Shopify は約7.3%、Wix は約5.2%、Squarespace は約3%です。
調べ方が違うので数字は合いませんが、「CMSの過半はWordPress」という結論は同じです。
WordPress.org の公式プラグインディレクトリには、2026年10月24日時点で72,476件のプラグインが登録されています（WordPress.org のプラグイン検索APIの件数）。本体の最新版は7.1系で、WordPress.org の統計では稼働中のサイトの63.7%が7.1系を使っています。
この「何でもプラグインで足せる」性質が、最大の強みであり、保守の負担の出どころでもあります。
2. 移行を考えるきっかけ：保守の負担を数字で見る
サポートの切れたPHPで動くサイトが3分の1
WordPressはPHPというプログラミング言語で動きます。PHPは各バージョンに2年間の通常サポートと、その後2年間のセキュリティ修正だけの期間があり、それを過ぎると脆弱性が見つかっても修正されません。
PHP公式のサポート期間と、WordPress.org の統計にあるPHPのバージョン分布を並べたのが次の表です。WordPress.org は動作環境としてPHP 8.3以上を推奨しています。
| PHPのバージョン | セキュリティ修正の期限 | WordPressサイトでの割合 |
|---|---|---|
| 7.4以前 | 終了（7.4は2022年11月28日） | 20.8% |
| 8.0 | 終了（2023年11月26日） | 3.6% |
| 8.1 | 終了（2025年12月31日） | 9.8% |
| 8.2 | 2026年12月31日 | 23.3% |
| 8.3 | 2027年12月31日 | 27.2% |
| 8.4 | 2028年12月31日 | 10.0% |
| 8.5 | 2029年12月31日 | 5.3% |
合計すると、約34%のWordPressサイトが、すでにセキュリティ修正の終わったPHP 8.1以前で動いています。さらに約23%が使うPHP 8.2も、2026年12月31日で修正が終わります。年が明けると、半数を超えるサイトが期限切れのPHPで動く計算です。
ただし、PHPが古いことはWordPressをやめる理由にはなりません。PHPの更新はサーバー側の作業で、多くのサーバーでは管理画面から切り替えられます。問題は、古いプラグインやテーマが新しいPHPで動かない場合で、そのときは作り直しが必要になり、移行と同じ規模の作業が見えてきます。
脆弱性の9割はプラグインから
WordPressのセキュリティ企業 Patchstack の年次報告によると、2025年にWordPressの周辺で新たに見つかった脆弱性は11,334件で、前年の7,966件から42%増えました。91%がプラグイン、9%がテーマで、本体（コア）で報告されたのは6件、いずれも優先度の低いものでした。さらに46%は公表の時点で開発者の修正がありませんでした。
Patchstack は脆弱性対策の製品を売る企業で、件数は同社が集めた報告にもとづきます。それでも、リスクが本体ではなくプラグインとテーマの数と質に比例するという傾向ははっきりしています。
保守の負担を自社の数字で測る
一般論より、自社のサイトで次の4つを数えるほうが判断に役立ちます。どれも30分ほどで確かめられます。
| 測るもの | どこで見るか | 移行を考える目安 |
|---|---|---|
| 有効なプラグインの数 | 管理画面のプラグイン一覧 | 20個を超え、用途を説明できないものがある |
| 2年以上更新のないプラグイン | WordPress.org の各プラグインのページ | 1つでも中核機能を担っている |
| PHPのバージョン | 管理画面の「ツール → サイトヘルス」 | 8.2以下で、上げると動かない部分がある |
| 過去12か月の保守の時間 | 作業記録・請求書 | 更新した記事の数より、保守の回数が多い |
「目安」の列は DevNJ の経験にもとづくもので、公的な基準ではありません。4つのうち2つ以上に当てはまるなら、次の章からの比較に進む価値があります。
3. 移行先の4つの選択肢と「WordPressのまま作り直す」
5つの選択肢を並べる
WordPressから移る先は、大きく4種類に分けられます。ここにWordPressのまま作り直すという選択肢を加えた5つを、同じ軸で比べます。製品名ではなく仕組みの種類で書いているのは、同じ種類の中でも製品ごとに差が大きく、種類を決めてから製品を選ぶほうが迷わないためです。
| 選択肢 | 仕組み | 向いているサイト | 主な弱点 |
|---|---|---|---|
| WordPressのまま作り直す | テーマ刷新とプラグイン整理 | 更新者が多い記事中心のサイト | 保守の手間は残る |
| 静的サイト生成 | 原稿から事前にHTMLを作る | 更新が少なく速さ重視 | 非技術者の更新が難しい |
| ヘッドレスCMS | 管理画面と表示を分ける | 複数の媒体に配信する | 2つの仕組みを運用する |
| SaaS型ビルダー | 事業者のサービスで作る | 担当者が自分で更新したい | 書き出しと自由度に制限 |
| フレームワーク製の自前CMS | 必要な機能だけを開発 | 業務システムと一体のサイト | 開発者への依存 |
弱点はどれも致命的ではありません。自社の体制で引き受けられるかが問題です。
静的サイト生成
静的サイト生成（SSG、Static Site Generator）は、Markdown などで書いた原稿とテンプレートから、公開前にすべてのページをHTMLとして作っておく仕組みです。表示のたびにデータベースを読まないので速く、攻撃される入口も少なくなります。
一方で、フォーム・サイト内検索・会員機能など、その場で処理が必要な機能は外部のサービスか別のプログラムで補います。更新もGitなどの開発の道具を通すことが多く、非技術者が毎日更新するサイトには向きません。
ヘッドレスCMS
ヘッドレスCMSは、原稿を管理する画面だけを提供し、表示は別に作る仕組みです。原稿はAPIで取り出し、Webサイト・アプリ・店頭の画面など複数の場所に配信できます。WordPress自体も REST API を備えており、「WordPressを管理画面として残し、表示だけを作り直す」という使い方もあります。
注意点は、管理画面と表示側の2つを運用することです。プレビューを作り込まないと、編集者は公開するまで見た目を確かめられません。表示を JavaScript で組む場合は、Google の JavaScript SEO の案内に沿って、検索エンジンが内容を読める描画の方法を選びます。
SaaS型ビルダー
SaaS型ビルダーは、事業者が提供するサービスの上で、画面を見ながらサイトを組み立てる仕組みです。サーバーの保守、本体の更新、セキュリティ対策は事業者が受け持ちます。保守を社内から手放したいときに最も効果があります。
その代わり、サービスの機能の範囲でしか作れません。URLの形、多言語の扱い、書き出しの可否は製品ごとに違い、将来別の仕組みに移るときに、原稿を一括で取り出せない場合もあります。契約前に、書き出しの機能と形式を必ず確かめてください。
フレームワーク製の自前CMS
Laravel や Django、Next.js などの開発の枠組み（フレームワーク）で、必要な機能だけを持つ管理画面を開発する方法です。予約・在庫・顧客管理など、業務システムとつながる部分が大きいサイトでは、プラグインを組み合わせるより見通しがよくなります。
ただし作った開発者に依存しやすいため、設計書・データ構造・手順書を残すことを契約に入れるのが前提です。
4. 続けるか移るかの判断基準
2つの軸で考える
判断の軸は、突き詰めると2つです。1つは誰がどのくらいの頻度で更新するか、もう1つはどれだけの機能・連携を載せるかです。この2軸で区切ると、選択肢はおおむね4つの区画に分かれます。
図の区画はあくまで出発点です。たとえば右上の「更新も機能も多い」サイトは、WordPressが最も力を発揮する場所で、移行するとかえって作るものが増えることがあります。
判断に使う8つの問い
2軸だけでは決めきれないときは、次の8つの問いに答えていくと、候補が絞れます。
| 問い | WordPress継続に傾く答え | 移行に傾く答え |
|---|---|---|
| 更新するのは誰か | 複数の非技術者 | 1〜2人、または開発者 |
| 更新の頻度は | 週1回以上 | 月1回以下 |
| 必要な機能は | 記事・フォーム・検索程度 | 予約・会員・業務連携 |
| プラグインの数は | 10個前後で用途が明確 | 20個超で用途不明がある |
| 多言語は | 不要か2言語まで | 3言語以上を同じ構成で |
| 保守を誰が担うか | 契約した保守会社がいる | 担い手がいない |
| 3年後の予定は | 今の形で記事を増やす | 事業や機能が大きく変わる |
| 社内の技術力は | WordPressに慣れた担当がいる | 別の技術に慣れた開発者がいる |
左右が半々に分かれる場合は、移行を急がないほうが安全です。まずプラグインを整理し、PHPを上げ、保守契約を決めるだけで、問題の多くが片づくことがあります。
5. 速さと品質はCMSで決まるのか
Core Web Vitals の合格率はCMSで差がある
「WordPressは遅い」という評判を、実測のデータで確かめておきます。Google が表示の体験を測る指標として示している Core Web Vitals は、LCP（最大の要素が表示されるまで）2.5秒以内、INP（操作への反応）200ミリ秒以内、CLS（レイアウトのずれ）0.1以下を「良好」とします。
Web Almanac は、実際の利用者のデータ（Chrome UX Report）をもとに、CMSごとの合格率を出しています。2024年版と2025年版のモバイルの数字を並べたのが次の表です。
| CMS | 2024年（モバイル） | 2025年（モバイル） |
|---|---|---|
| Duda | 73% | 85% |
| Wix | 57% | 74% |
| Squarespace | 60% | 上昇（率の記載なし） |
| Drupal | 56% | 上昇（率の記載なし） |
| Joomla | 45% | 上昇（率の記載なし） |
| WordPress | 40% | 45% |
WordPressの合格率は、2025年で45%と、SaaS型の Wix（74%）や Duda（85%）より低い結果でした。
差の大部分は「作り方」から来る
ただし、これを「WordPressだから遅い」と読むのは早計です。WordPressは作り方の幅が広く、古いテーマや重いページビルダーのサイトが平均を下げています。SaaS型は事業者が画像の配信などをまとめて最適化しているため、平均が上がりやすいのです。
言い換えると、よく作られたWordPressのサイトは十分に速く、雑に作られた移行先のサイトは遅くなります。速さだけを理由に移行するなら、まず今のサイトの PageSpeed Insights の結果を見て、遅さの原因が画像なのか、スクリプトなのか、サーバーなのかを特定してください。原因がテーマやプラグインなら、WordPressのまま直せます。
6. 移行の全体像：6つの段階と期間
書き出しは3番目の段階
移行を決めると、すぐにデータを書き出したくなります。しかし書き出しは3番目の段階です。何をどの形で移すかが決まっていないと、加工のやり直しが増えます。
| 段階 | やること | 成果物 |
|---|---|---|
| 1. 棚卸し | ページ・投稿の種類・プラグイン・フォームを数える | 棚卸し表 |
| 2. 対応表と設計 | 旧データと新データの項目を対応させる | データ構造の対応表、URLの方針 |
| 3. 書き出しと変換 | WXR・画像・フォームのデータを取り出し変換する | 変換スクリプトと変換結果 |
| 4. 機能の置き換え | プラグインの役割を新しい仕組みに移す | 機能の置き換え表と実装 |
| 5. 検証と凍結 | 旧サイトと新サイトの差分を確認し、更新を止める | 検証結果、凍結期間の告知 |
| 6. 公開切り替えと監視 | DNSの切り替え、リダイレクト、監視 | 切り替え手順書、監視の記録 |
段階1と2で全体の3〜4割の時間を使うのが、うまくいく移行の典型です。ここを短くすると、段階3以降で手戻りが増えます。
7. 棚卸しと書き出し：コンテンツ・メディア・ユーザー・フォーム
まず数える：棚卸し表の作り方
棚卸しでは、WordPressの中にあるものを種類ごとに数え、移すか・捨てるか・作り直すかを決めます。公開中のページ数だけでなく、下書き・非公開・添付ファイルのページなど、普段は見えないものも数えます。
| 数えるもの | 確かめる場所 | 決めること |
|---|---|---|
| 投稿・固定ページ | 管理画面の一覧（状態ごと） | 移す・統合する・削除する |
| カスタム投稿タイプ | 管理画面のメニュー、テーマのコード | 新しい仕組みでの型 |
| カテゴリー・タグ | 管理画面の一覧 | 残す分類と統合する分類 |
| 画像・添付ファイル | メディアライブラリ、uploadsフォルダ | 使われていないファイルの扱い |
| ユーザー | ユーザー一覧（権限ごと） | 移す人と、移さない人 |
| フォームと送信データ | フォームのプラグイン | 保存期間と移す範囲 |
| ショートコード・ブロック | 本文の検索 | 置き換えの方法 |
アクセスがなく内容も古いページはこの段階で整理します。移す量が減れば、変換と検証の時間も減ります。削除するページのURLは、リダイレクトの対象として記録しておきます。
コンテンツ：WXRで書き出せるもの、書き出せないもの
WordPressの管理画面の「ツール → エクスポート」は、WXR（WordPress eXtended RSS）というXML形式のファイルを作ります。公式ドキュメントによると、対象は投稿・固定ページ・カスタム投稿タイプ・コメント・カスタムフィールド・カテゴリー・タグ・カスタムタクソノミー・ユーザーで、「すべてのコンテンツ」を選ぶとナビゲーションメニューも含まれます。同じ形式は、コマンドラインの WP-CLI の wp export でも作れます。
| 種類 | WXRに含まれるか | 含まれないときの取り出し方 |
|---|---|---|
| 本文・タイトル・日付・URLスラッグ | 含まれる | — |
| カテゴリー・タグ・カスタムタクソノミー | 含まれる | — |
| カスタムフィールド | 含まれる | 複雑な入れ子は別途確認 |
| 画像ファイルそのもの | 含まれない（URLのみ） | uploadsフォルダをコピー |
| ユーザーのパスワード | 含まれない | データベースから取り出す |
| テーマ・プラグインの設定 | 含まれない | 画面を記録し、作り直す |
| フォームの送信データ | 多くは含まれない | 各プラグインのCSV書き出し |
| SEOの設定（タイトル・説明文） | プラグインによる | カスタムフィールドとして確認 |
WXRは WordPress どうしで移すための形式で、ほかの仕組みは直接読み込めないことが多いため、中間の形式（JSONやMarkdownなど）に変換するスクリプトを書くか、REST API から必要な項目だけを取り出すのが一般的です。REST API では、たとえば投稿は /wp-json/wp/v2/posts から JSON で取り出せます。
本文に残る「WordPressの部品」に注意する
本文のHTMLには、WordPress特有の部品が残っています。ブロックエディタで書いた記事には <!-- wp:paragraph --> のようなコメントが入り、ショートコード（[gallery] のように角括弧で書く部品）は、WordPressの外では文字のまま表示されてしまいます。
ショートコードは、本文を全件検索して種類と件数を数え、1種類ずつ変換方法を決めます。件数の多いものはスクリプトで変換し、少ないものは手で直すほうが早いこともあります。
メディア：ファイルとURLの両方を移す
画像は、サーバーの wp-content/uploads フォルダを丸ごとコピーするのが確実です。WordPressは1枚の画像から複数のサイズを自動で作るため、元画像だけを移し、サイズ違いは新しい仕組みで作るほうが整理できます。本文中の画像のURL（/wp-content/uploads/...）は、新しい保存先のURLに置き換えます。
ユーザー：パスワードと個人データの扱い
会員機能があるサイトでは、ユーザーの移行が最も慎重さを要します。WXRにはユーザーの名前やメールアドレスは含まれますが、パスワードは含まれません。データベースから直接取り出す必要があり、保存形式は WordPress のバージョンで変わります。
| WordPressのバージョン | パスワードの保存形式 | 移行先での扱い |
|---|---|---|
| 6.7以前 | phpass（$P$ で始まる） |
互換の検証を実装するか、再設定 |
| 6.8以降 | bcryptをもとにした形式（$wp$2y$ で始まる） |
同上。ログインした人から順に新形式へ |
| どちらでも | アプリケーションパスワードは別形式 | 移さず、再発行してもらう |
WordPress 6.8 では、ユーザーがログインしたときに古い phpass の形式から新しい形式に順に置き換わります。移行先がどちらの形式も検証できない場合は、初回ログイン時にパスワードを再設定してもらう運用にします。その場合は、移行の前にユーザーへ案内を出してください。
また、ユーザーのデータは個人データです。EUの一般データ保護規則（GDPR）でも、日本の個人情報保護法でも、新しいサービスに預けるときの契約と説明が必要になります。詳しくは第15章で扱います。WordPress には個人データの書き出し・削除の機能（「ツール → 個人データのエクスポート」）があり、移行前に本人から求められた場合の対応にも使えます。
フォーム：送信データは移すか、捨てるか
問い合わせフォームの送信データは、フォームのプラグインが独自の表や投稿として保存しているため、WXRに含まれないことが多いです。各プラグインのCSV書き出しで取り出せますが、そもそも移す必要があるかを先に考えます。
履歴がメールや顧客管理システムに残っているなら、移さずに保存期間を決めて削除するのも選択肢です。GDPRの「必要な期間を超えて保存しない」という考え方にも沿います。
8. データ構造の対応表を作る
対応表は移行の設計図
データ構造の対応表は、WordPressの項目が、新しい仕組みのどの項目になるかを1行ずつ書いた表です。これがないまま変換スクリプトを書くと、「この情報はどこに行ったのか」が後から分からなくなります。
| WordPressの項目 | 例 | 新しい仕組みでの項目 | 注意点 |
|---|---|---|---|
| 投稿（post） | ブログ記事 | 記事の型 | 公開日と更新日を両方移す |
| 固定ページ（page） | 会社概要 | ページの型 | 親子関係をURLに反映 |
| カスタム投稿タイプ | 施工事例 | 専用の型 | 型ごとに項目を設計 |
| カスタムフィールド | 価格・所在地 | 型の項目 | 値の形式（数値・日付）を揃える |
| カテゴリー・タグ | お知らせ | 分類 | 統合する分類を決める |
| アイキャッチ画像 | 記事の代表画像 | 画像の項目 | 代替テキストも移す |
| 投稿者 | 執筆者 | 著者の型 | 退職者の扱いを決める |
| リビジョン | 編集履歴 | 原則移さない | 必要なら書き出して保管 |
URLの方針も対応表に入れる
対応表には、旧URLと新URLの列も入れておきます。WordPressのURLは「パーマリンク設定」で決まり、/2023/05/slug/ のように日付を含む形や、/category/slug/ のように分類を含む形があります。
最も安全なのは、URLを1つも変えないことです。Google はURLを変えずに仕組みやサーバーを入れ替えることを「URLの変更を伴わない移転」として案内しており、手続きはずっと軽くなります。移行先がURLの形を自由に決められるかは、選択肢を比べる段階で確かめておく項目です。URLを変える場合の手順は「サイトリニューアルで検索順位を落とさない301リダイレクトの手順」を参照してください。
SEOの情報を落とさない
検索用のタイトルや説明文、noindex の指定は、SEOのプラグインがカスタムフィールドに保存していることが多く、対応表に明示しないと移行で消えます。「検索用のタイトル」「説明文」「canonical」「noindex」「OGP画像」の列を作り、検証の段階で旧サイトの値と比べてください。
9. プラグイン機能の置き換え
プラグインを「機能」に言い換える
プラグインの一覧をそのまま移行先で探すと、同じ名前の部品は見つかりません。まずそれぞれのプラグインが担っている機能を、言葉で書き出します。「SEOプラグイン」ではなく「検索用タイトルの設定、XMLサイトマップ、パンくずの構造化データ」のように分解します。
| よくある機能 | WordPressでの実現 | 移行先での置き換え方の例 |
|---|---|---|
| 検索用タイトル・サイトマップ | SEOプラグイン | テンプレートの項目と自動生成 |
| 問い合わせフォーム | フォームプラグイン | フォームの外部サービスか自前の処理 |
| 表示の高速化 | キャッシュプラグイン | 静的配信とCDN |
| 不正ログイン対策 | セキュリティプラグイン | 管理画面の分離・二段階認証 |
| 多言語 | 多言語プラグイン | 言語ごとの項目と対応関係 |
| リダイレクト | リダイレクトプラグイン | サーバーかCDNの設定 |
| Cookie の同意 | 同意管理プラグイン | 同意管理の仕組みを選び直す |
| バックアップ | バックアッププラグイン | ホスティングとGitの履歴 |
置き換えずに「やめる」機能を探す
プラグインを機能に言い換えると、移行先では不要になる機能が見つかります。キャッシュやセキュリティのプラグインは、静的サイト生成やSaaS型では仕組みの側で担われるため、置き換える必要がありません。
逆に、予約投稿、編集者ごとの権限、公開前のプレビュー、サイト内検索のように、移行先で新しく作る必要がある機能もあります。
編集体験も置き換えの対象
見落とされやすいのが、編集する人の使い勝手です。移行前に、担当者に新しい管理画面で実際に1本記事を書いてもらい、つまずいた点を設計に戻すと、公開後に「更新されないサイト」になるのを防げます。
10. 多言語サイトの移行
WordPressの多言語は「プラグインごとの作法」
WordPress本体には、1つの記事を複数の言語で持つ仕組みがありません。多言語は、プラグインかマルチサイト（1つのWordPressで複数のサイトを動かす機能）で実現されています。方式によって、データの持ち方が大きく違います。
| 方式 | データの持ち方 | 移行で取り出すもの |
|---|---|---|
| 言語ごとに別の投稿 | 翻訳どうしを関係づけて保存 | 投稿と、翻訳の対応関係 |
| 1つの投稿に複数言語 | 本文の中に言語ごとの区切り | 区切りの分解 |
| マルチサイト | 言語ごとに別のサイト | サイトごとの書き出しと対応関係 |
| 自動翻訳の表示 | 翻訳を外部や別の表に保存 | 翻訳文の保存先と権利の確認 |
どの方式でも、移行で最も大事なのは「どの記事とどの記事が翻訳どうしか」という対応関係です。WXRには、プラグインが独自に持つ対応関係が含まれないことがあるため、移行前に「日本語版のURL｜英語版のURL｜オランダ語版のURL」の表を書き出しておきます。
hreflang は相互に指し合う
多言語サイトでは、Google に言語版の関係を伝える hreflang を設定します。Google の案内では、各言語版が自分自身とほかのすべての言語版を指し、相手からも指し返されている必要があります。片方向だけの指定は無視されることがあります。
移行後は、全ページの hreflang を機械的に取り出して対応表と突き合わせます。どの言語にも合わない利用者には、x-default で言語の選択画面などを示せます。
11. 公開切り替え：凍結、DNS、切り戻し
切り替えの2週間前から当日後まで
公開切り替えは、移行の中で最も短く、最も失敗が目立つ段階です。DevNJ では、次のような順で進めることが多いです。
| 時期 | やること | 確認すること |
|---|---|---|
| 2週間前 | DNSのTTL（情報を保持する時間）を短くする | 現在の値と新しい値 |
| 1週間前 | 更新の凍結期間を社内に告知する | 凍結中の緊急の更新の手順 |
| 3日前 | 最終の書き出しと差分の取り込み | 記事数・画像数・フォーム |
| 前日 | 新サイトを本番と同じ設定で最終確認 | リダイレクト・hreflang・noindex |
| 当日 | DNSを切り替え、旧サイトは止めずに残す | 主要ページの表示とフォーム送信 |
| 1〜30日後 | Search Console とアクセスの監視 | エラーの増加、404、送信数 |
凍結期間を短くする
最終の書き出しの後に旧サイトで更新した内容は、新サイトに入りません。そのため更新を止める凍結期間を設けます。変換をスクリプトで自動化しておけば、凍結は数時間から1日で済みます。
切り戻しの準備を残す
重大な問題に備え、旧サイトはDNSを戻せばすぐ表示できる状態で一定期間残します。残す間は、アクセスを制限して検索エンジンにも見せないようにしてください。
公開後に見る指標
公開後の30日間は、Search Console のインデックス登録の状況とエラーを毎週確かめます。URLを変えた場合は、リダイレクトを少なくとも1年間維持します。最も気づかれにくい失敗はフォームの通知メールが届かなくなることで、送信数も前の月と比べてください。
12. 費用と期間の幅
デザインを変えない移行作業の目安
移行の費用は、ページの数よりも、データの種類の数・機能の数・言語の数で決まります。次の表は、デザインの刷新を含まない「仕組みの移行作業だけ」の時間を、DevNJ の見積もりの目安で示したものです。金額は、オランダの時間単価の調査（フリーランスのWeb開発者€73、制作会社の平均€106、いずれも税抜）で掛け、1ユーロ＝175.51円（欧州中央銀行の参照レート、2026年10月23日）で円にしました。
| 規模 | 想定 | 作業時間 | 金額の幅（€） | 金額の幅（円） |
|---|---|---|---|---|
| 小規模 | 30ページ前後・1言語・フォーム1つ | 40〜80時間 | 約2,900〜8,500 | 約51万〜149万 |
| 中規模 | 記事数百本・2言語・フォーム数個 | 120〜250時間 | 約8,800〜26,500 | 約154万〜465万 |
| 大規模 | 会員・業務連携・3言語以上 | 300〜600時間 | 約21,900〜63,600 | 約384万〜1,116万 |
この表は「仕組みの種類」を問わない目安で、一次情報の統計ではありません。デザインの刷新、原稿の書き直し、翻訳の追加は別にかかります。見積書の全体の読み方は「ホームページリニューアルの費用相場と見積もりの読み方」で扱っています。
作業の内訳
中規模のサイトでの内訳の目安は次のとおりです。棚卸しと対応表に時間をかけるほど、変換と検証の時間が読みやすくなります。
| 作業 | 時間の目安（中規模） | 増えやすい条件 |
|---|---|---|
| 棚卸しと対応表 | 16〜32時間 | カスタム投稿タイプが多い |
| 書き出しと変換スクリプト | 24〜48時間 | ショートコードが多い |
| 機能の置き換え | 32〜80時間 | 予約・会員などの業務機能 |
| 多言語の対応関係 | 16〜32時間 | 翻訳の対応が崩れている |
| 検証とリダイレクト | 16〜32時間 | URLを変える |
| 公開切り替えと監視 | 16〜26時間 | 凍結期間を短くしたい |
判断の際は、初期費用だけでなく3〜5年の運用費で比べます。WordPressではサーバー代・有料プラグインのライセンス・保守の時間、SaaS型では月額の利用料、静的サイト生成や自前CMSでは更新の手間と開発者への依頼の費用がかかります。具体的な金額は、各サービスの料金ページと保守の見積もりで確かめてください。
13. よくある失敗例
移行で起きやすい8つの失敗
移行の失敗は、技術の難しさより、確かめる順番の誤りから起きることがほとんどです。DevNJ が相談を受けた中で多いものを並べます。
| 失敗 | 何が起きるか | 防ぎ方 |
|---|---|---|
| 書き出しから始める | 変換を何度もやり直す | 棚卸しと対応表を先に作る |
| ショートコードを見落とす | 本文に角括弧の文字が出る | 本文を全件検索して数える |
| SEOの設定を移さない | 検索用のタイトルが消える | 対応表に専用の列を作る |
| 画像の代替テキストが消える | アクセシビリティが下がる | 代替テキストを項目として移す |
| 翻訳の対応関係が崩れる | hreflang が誤る | 言語ごとのURLの表を作る |
| フォームの通知が届かない | 問い合わせを取りこぼす | 公開当日にテスト送信する |
| 旧サイトをすぐ消す | 問題が出ても戻せない | 一定期間は非公開で残す |
| 担当者が使えない | 公開後に更新が止まる | 移行前に試し書きをしてもらう |
14. ケースで考える（架空の例）
ここからは、判断の考え方を具体的にするための架空の例です。実在の企業ではありません。
ケース1：更新が年数回の製造業の会社サイト
日本の部品メーカーが、欧州の取引先向けに日英2言語のサイトを持っています。ページは25ほどで、更新は年に3〜4回、製品カタログのPDFを差し替える程度です。プラグインは18個入り、PHPは8.1のまま止まっていました。
更新が少なく、機能もフォームだけなので、静的サイト生成に移り、フォームは外部のサービスで受けることにしました。URLは変えていません。
ケース2：毎週記事を出す飲食店グループ
オランダで飲食店を3店舗営む会社が、日本語・英語・オランダ語でお知らせとメニューを毎週更新しています。更新するのは店長3人で、いずれもWordPressの管理画面に慣れています。
不満は表示の遅さでしたが、原因は重いページビルダーと写真でした。WordPressのまま作り直し、プラグインを8個まで減らすことにしました。慣れた管理画面を残せることが決め手です。
ケース3：予約と会員のある教室
デン・ハーグで語学教室を営む事業者が、予約・会員・支払いをプラグインの組み合わせで動かしていました。プラグインどうしの相性で予約が二重になる不具合が続き、保守の会社も原因を特定できませんでした。
この事業者は、フレームワーク製の自前CMSで予約と会員を作り直しました。パスワードは互換の検証を実装せず、事前にメールで案内して初回ログイン時に再設定してもらいました。
| ケース | 判断 | 決め手 |
|---|---|---|
| 1. 製造業の会社サイト | 静的サイト生成 | 更新が少なく、機能もフォームだけ |
| 2. 飲食店グループ | WordPressのまま作り直す | 担当者が慣れた管理画面を残せる |
| 3. 予約のある語学教室 | 自前CMS | 業務の機能が中心で、相性の問題が続いた |
15. 日本と欧州の両方に向けたサイトで変わること
法令と、データを置く場所
日本と欧州の両方に向けたサイトでは、移行先を選ぶときに法令とデータの置き場所も確かめます。
| 項目 | 日本 | 欧州（EU・オランダ） |
|---|---|---|
| 個人データの法律 | 個人情報保護法 | 一般データ保護規則（GDPR） |
| 外部に預けるとき | 委託先の監督。外国の事業者には第28条の規律 | 処理者との契約（第28条） |
| 国外への移転 | 外国にある第三者への提供の規律 | 十分性認定などの条件（日本は十分性認定あり） |
| アクセシビリティ | 障害者差別解消法の合理的配慮 | 欧州アクセシビリティ法（2025年6月28日から適用） |
個人情報保護委員会のガイドラインでは、外国にある事業者に個人データの取り扱いを委託する場合も、外国にある第三者への提供の規律がかかる場合があると整理されています。SaaS型の仕組みや海外のフォームサービスに移るときは、サービスの事業者がどの国でデータを扱うかを契約前に確かめてください。
欧州アクセシビリティ法の対象か
欧州アクセシビリティ法（指令 (EU) 2019/882）は、2025年6月28日から、EUの消費者向けの電子商取引などのサービスに適用されています。従業員10人未満で、年間売上高または貸借対照表の総額が200万ユーロ以下の零細事業者がサービスを提供する場合は、対象から外れます。
EUの消費者にオンラインで商品やサービスを売る日本の事業者も、対象になりえます。移行先の仕組みやテーマが、W3C の WCAG 2.2 に沿った見出し・代替テキスト・キーボード操作を実現できるかは、移行先を選ぶ判断の材料になります。オランダでの扱いは、オランダ政府の事業者向けサイト business.gov.nl が案内しています。
16. 移行前のチェックリスト
判断の段階
- 有効なプラグインの数と、2年以上更新のないプラグインを数えた
- PHPのバージョンと、上げたときに動かない部分を確かめた
- 誰がどのくらいの頻度で更新するかを書き出した
- 3〜5年の運用費で比べた
準備の段階
- 棚卸し表を作り、移す・統合する・削除するを決めた
- データ構造の対応表に、SEOの設定と代替テキストの列を入れた
- 旧URLと新URLの列を作り、URLを変えるかどうかを決めた
- 翻訳どうしの対応関係を、言語ごとのURLの表にした
- 移行先で書き出しができることを確かめた
公開の段階
- ユーザーへのパスワード再設定の案内を準備した（会員がある場合）
- DNSのTTLを2週間前に短くした
- フォームのテスト送信と通知メールの受信を確かめた
- 旧サイトを非公開で残し、切り戻しの手順を書いた
- Search Console の監視を30日間の予定に入れた
まとめ
- WordPressは全Webサイトの39.6%、CMS利用サイトの58.3%が使う最大の仕組みで、やめること自体が目的にはならない
- 保守の負担は、サポートの切れたPHP（WordPressサイトの約34%）と、脆弱性の91%を占めるプラグインに集まっている
- 判断の軸は、更新の頻度・人数と機能の量の2つ。半々なら、まずWordPressのまま整理する
- 移行は、棚卸し → 対応表 → 書き出しの順に進める。WXRには画像ファイル・設定・フォームのデータ・パスワードが含まれない
- プラグインは機能の言葉に言い換えて置き換え、不要になる機能と新しく作る機能を分ける
- 多言語は翻訳どうしの対応関係を表にし、hreflang の相互参照を全ページで確かめる
- 公開切り替えではURLを変えないことを第一にし、凍結期間を短くし、切り戻しの準備を残す
参考にした情報源
利用状況の統計
- Usage statistics of content management systems — W3Techs：WordPress 39.6%、CMSシェア58.3%、各CMSの割合
- Usage statistics and market share of WordPress — W3Techs：WordPressの利用の推移
- WordPress Stats — WordPress.org：PHPとWordPressのバージョン分布
- CMS — Web Almanac 2025, HTTP Archive：CMS利用54%超、WordPress約64.3%、Core Web Vitals の合格率
- CMS — Web Almanac 2024, HTTP Archive：CMSごとの合格率と Lighthouse の中央値
WordPress の公式ドキュメント
- Tools Export Screen — WordPress.org：WXRに含まれるもの
- WordPress Importer — WordPress.org：WXRの読み込みと添付ファイル
- wp export — WP-CLI：コマンドラインでの書き出し
- REST API Handbook — WordPress Developer Resources：REST API の概要
- Posts — REST API Reference：投稿の取り出し
- Shortcode API — WordPress Developer Resources：ショートコードの仕組み
- Tools Export Personal Data Screen — WordPress.org：個人データの書き出し
- WordPress 6.8 will use bcrypt for password hashing — Make WordPress Core：パスワードの保存形式
- Requirements — WordPress.org：PHP 8.3以上の推奨
PHP とセキュリティ
- Supported Versions — PHP：8.2〜8.5のサポート期限
- Unsupported Branches — PHP：8.1以前のサポート終了日
- State of WordPress Security in 2026 — Patchstack：2025年の脆弱性11,334件、プラグイン91%
- State of WordPress Security in 2025 — Patchstack：2024年の脆弱性7,966件
検索と表示の速さ
- Site moves with no URL changes — Google Search Central：URLを変えない移転
- Site moves with URL changes — Google Search Central：URLを変える移転とリダイレクトの維持
- Change of Address tool — Search Console Help：ドメインを変えるときの手続き
- Tell Google about localized versions of your page — Google Search Central：hreflang と x-default
- JavaScript SEO basics — Google Search Central：JavaScriptで描画するサイトの注意点
- Web Vitals — web.dev：LCP・INP・CLS の基準
法令とアクセシビリティ
- Directive (EU) 2019/882 — EUR-Lex：欧州アクセシビリティ法の条文と零細事業者の定義
- European Accessibility Act — European Commission：対象のサービス
- European Accessibility Act for products and services — business.gov.nl：オランダの事業者向けの案内
- WCAG 2.2 — W3C：アクセシビリティの達成基準
- Regulation (EU) 2016/679 (GDPR) — EUR-Lex：処理者との契約、国外への移転
- 個人情報保護法ガイドライン（外国にある第三者への提供編） — 個人情報保護委員会：外国の事業者に預ける場合の規律
費用の計算
- Euro foreign exchange reference rates — European Central Bank：1ユーロ＝175.51円（2026年10月23日）
いずれも2026年10月24日に確認したものです。利用状況の統計は調査ごとに対象と方法が違い、数字は一致しません。費用と期間の表、判断の目安、図3と図4は、上の情報源とオランダの時間単価の調査（ホームページリニューアルの費用相場と見積もりの読み方で紹介）をもとに DevNJ が作成した目安で、統計ではありません。法令の扱いは事業の内容によって変わるため、契約の前に専門家に確認してください。
よくある質問
- WordPressをやめて別のCMSに乗り換えるべきなのは、どんなときですか？
- 更新する人と機能の量がWordPressの強みと合わなくなったときです。たとえば、更新は年に数回なのにプラグインの更新と脆弱性対応に毎月手間がかかっている、または業務システムとの連携が増えてプラグインの組み合わせで無理をしている場合です。逆に、複数の担当者が毎週記事を出すサイトは、WordPressのまま作り直すほうが合理的なこともあります。
- WordPressの記事や画像は、まとめて書き出せますか？
- 管理画面の「ツール → エクスポート」で、投稿・固定ページ・カスタム投稿・コメント・カスタムフィールド・カテゴリー・タグ・メニューなどをWXRという形式のXMLで書き出せます。ただし画像ファイルそのもの、テーマやプラグインの設定、フォームの送信データは含まれません。画像はuploadsフォルダを別にコピーし、フォームのデータは各プラグインの書き出し機能を使います。
- 会員のパスワードも新しい仕組みに移せますか？
- WXRにはパスワードが含まれないため、データベースから直接取り出す必要があります。WordPress 6.8以降はbcryptをもとにした形式（$wp$2y$で始まる）、それより前はphpass形式（$P$で始まる）で保存されており、移行先がこの形式を検証できなければ、初回ログイン時にパスワードを再設定してもらう運用になります。
- WordPressから移行すると、検索順位は下がりますか？
- URLを変えずに仕組みだけを入れ替えるなら、Googleはこれを「URLの変更を伴わない移転」として扱い、影響は小さく抑えられます。URLが変わる場合は、旧URLから新URLへの301リダイレクトを1年以上維持するなどの手順が必要です。どちらでも、タイトル・本文・内部リンク・構造化データが移行で欠けないことが前提です。
- WordPressからの移行には、どのくらいの費用と期間がかかりますか？
- デザインを変えない移行作業だけで、DevNJの見積もりの目安では、30ページ程度の小規模サイトで40〜80時間、記事が数百本ある2言語のサイトで120〜250時間です。オランダの時間単価€73〜€106で掛けると、それぞれ約€2,900〜€8,500、約€8,800〜€26,500になります。期間は前者で4〜6週間、後者で2〜4か月が目安です。
- 多言語のWordPressサイトを移行するときの注意点は？
- WordPress本体には1つの記事を複数言語で持つ仕組みがなく、多言語はプラグインやマルチサイトで実現されています。そのため、どの記事とどの記事が翻訳どうしなのかという対応関係を、移行前に表に書き出しておく必要があります。移行後はhreflangが相互に指し合っているかを全ページで確かめます。
日本と欧州の両方で機能するサイトをお考えですか？
無料で相談する
