WordPressマルチサイトをシングルサイトへ移行する方法と注意点

「使いたいプラグインがマルチサイトに対応していない」
「子サイトはもう使わないので、メインサイトだけの普通のWordPressに戻したい」

WordPressマルチサイトをやめてシングルサイトへ移行したいというご相談は、サイト引越し屋さんにもたびたび寄せられています。

ただ、マルチサイトはユーザー情報を全サイトで共有し、子サイトの画像も専用フォルダに分けて保存する仕組みです。設定ファイルを数行消すだけでは戻せず、手順を誤ると画像が表示されない、ログインできない、記事URLが変わって検索順位が落ちるといったトラブルにつながります。

この記事では、マルチサイトを解除してシングルサイトへ移行する2つの方法と、切り出し時に必ず押さえるポイント、作業前の確認事項と期間の目安を、実際のご相談事例をもとに解説します。

WordPressマルチサイトをやめてシングルサイトにすべきケース

マルチサイトは、1つのWordPressで複数のサイトをまとめて管理できる便利な機能です。一方で、サイト同士が「ユーザー」「プラグイン」「テーマ」「サーバー」を共有するため、運用が進むと制約のほうが大きくなることがあります。

次の4つに当てはまるなら、シングルサイトへの移行を検討するタイミングです。

使いたいプラグインがマルチサイトに対応していない

ご相談でよく伺う理由のひとつです。プラグインは通常のWordPressを前提に作られているものが多く、マルチサイトでは「インストールできない」「ネットワーク全体でしか有効化できない」「動作はするが一部の機能が動かない」といった制約が出ます。

また、プラグインやテーマを追加できるのはネットワーク管理者（特権管理者）だけで、各サイトの管理者は自由に入れられません。

弊社にも「使いたいプラグインがマルチサイトに対応していなくてインストールできない。マルチサイトが色々と邪魔をしている」という理由で、子サイトを削除してメインサイトだけを残したいというご相談がありました。

子サイトをもう使っていないのであれば、マルチサイトを続けるメリットはほぼなく、弊社もシングルサイト化をおすすめしました。

管理や保守の手間が増えている

マルチサイトでは、プラグインを1つ更新するだけでも全サイトに影響します。ある子サイトでは問題なくても、別の子サイトで表示が崩れるといったことが起きるため、更新後の確認はサイト数分必要です。

また、担当者が変わったときに「ネットワーク管理」と「各サイトの管理画面」の違いが引き継がれず、設定の場所が分からなくなるケースもよくあります。

運用しているのが実質1サイトだけ、あるいは各サイトの担当者が別々になっているなら、まとめて管理する利点よりも、影響範囲が広いことのデメリットのほうが大きくなります。

サーバー移転やバージョンアップが難しい

マルチサイトは、サーバー会社の移行ツールや簡単移行機能の対象外になっていることがあり、移転のたびに手作業が増えます。ドメインやサブドメインの設定も複雑で、WordPress本体やPHPをバージョンアップするときも、全サイトを一度に検証しなければなりません。

AWSでサブドメイン型マルチサイトを運用していた企業からは、古い環境から最新の環境へ移るのを機に「マルチサイトをやめて、URLはそのままでそれぞれ分離したい」というご相談をいただきました。

移転やバージョンアップの予定があるなら、同じタイミングでマルチサイトを分離すれば作業を一度で済ませられます。

子サイトを別の会社やサーバーに渡す

事業の売却・分社化や、グループ会社のサイトを別の制作会社に移管する場合、子サイトだけを切り出して独立したWordPressにする必要があります。マルチサイトのままでは、データベースやユーザー情報が他のサイトと混在しているため、丸ごと渡すと他サイトのユーザー情報まで渡ってしまいます。

このケースでは、後述する「ユーザー情報の整理」が特に重要です。渡す側のサイトには、そのサイトに関わるユーザーだけを残すようにします。

マルチサイトのままでよいケースとの見分け方

「このままでもよいのでは？」と迷う場合は、次の3点で判断します。すべて「はい」ならマルチサイトを続ける価値があり、ひとつでも「いいえ」ならシングルサイト化を検討しましょう。

• 全サイトを同じ担当者が管理し、今後も子サイトを増やす予定がある
• 必要なプラグインがすべてマルチサイトで問題なく動いている
• 全サイトを同じサーバーで運用し続ける

WordPress公式ドキュメントも、サイト同士が「データやユーザーを共有する」ような使い方ではマルチサイトが最適ではない場合があると説明しています（Before You Create A Network）。

なお、「マルチドメイン」は1つのサーバー契約で複数のドメインを使うサーバー側の機能で、WordPressのマルチサイトとは別物です。サイトを分離したあとも同じサーバーで運用したい場合は、「1つのサーバーで複数サイトを管理する方法」もご覧ください。

===

「うちはシングルサイトに戻すべき？マルチサイトのままでいい？」と迷っている方へ。

子サイトの数や使っているプラグイン、今後の運用予定を伺ったうえで、サイト引越し屋さんのエンジニアが分離の要否と進め方をご提案します。お気軽にご相談ください。
>>無料ご相談窓口はこちらをクリック

シングルサイトへ移行する2つの方法

マルチサイトをやめる方法は、大きく分けて「新しいWordPressに必要なサイトを切り出す」か「今のWordPressのままマルチサイトの設定を外す」かの2つです。

どちらが向いているかは、残すサイトがメインサイトか子サイトかでほぼ決まります。

方法① 新しいシングルサイトにサイトを切り出す

新しく通常のWordPressを用意し、そこへ残したいサイトのデータを移す方法です。元のマルチサイトには手を加えないため、切り替える直前まで本番サイトをそのまま動かしながら検証でき、失敗してもすぐに戻せます。

データの移し方は2通りあります。管理画面の「ツール＞エクスポート」で書き出したXMLを取り込む方法は手軽ですが、移るのは投稿・固定ページ・コメントなどのコンテンツだけで、テーマ設定やウィジェット、プラグインの設定はすべて作り直しになります。

設定ごとそのまま移したい場合は、データベースの該当テーブルを直接移す方法を選びます（次章で解説）。子サイトを残す場合や、移転と同時に分離する場合はこちらが基本です。

方法② 今のWordPressでマルチサイトの設定を外す

今のWordPressをそのまま使い、不要な子サイトを削除してから、wp-config.phpと.htaccessのマルチサイト用の設定を外し、ネットワーク用のテーブルを削除する方法です。メインサイトのデータはもともと通常のWordPressと同じテーブルに入っているため、データの移動はほとんどありません。

ただし、この方法で残せるのはメインサイト（サイトIDが1のサイト）だけです。また、本番環境を直接変更するため、作業中はサイトが不安定になりやすく、事前に同じ環境を複製して手順を通しておくことが前提です。

どちらを選ぶかの判断基準

残したいサイトと、サーバーを変えるかどうかで選びます。

実務では、メインサイトだけを残す場合でも、本番と別に検証環境を用意して事前に手順を通してから本番へ反映します。弊社が「検証環境での事前検証」を作業工程に必ず入れているのはこのためです。

子サイトをシングルサイトとして切り出す手順

方法①で設定ごと子サイトを切り出す場合、要になるのは「テーブル」「ユーザー」「画像の場所」「URL」の4つです。どれか1つでも抜けると、画像が表示されない・ログインできないといった不具合になります。

通常のWordPressの引越し手順そのものは「WordPress引越し方法5選」にまとめているので、ここではマルチサイト特有の部分に絞って解説します。

① サイトIDを確認し、wp_N_のテーブルを書き出す

マルチサイトでは、メインサイトのデータは「wp_posts」のような番号なしのテーブルに、子サイトのデータは「wp_2_posts」のようにサイトID付きのテーブルに保存されます。

サイトIDは「ネットワーク管理＞サイト」で対象サイトの編集画面を開くと、URL末尾の「id=」で確認できます。

書き出すのは、そのIDが付いたテーブルすべてです。標準のテーブル（posts、postmeta、options、terms、commentsなど）に加え、フォームやSEO系のプラグインが作った独自テーブルも同じ接頭辞で並んでいるので、取りこぼさないようにします。

取り込む側では接頭辞を「wp_N_」から「wp_」にそろえます。phpMyAdminの基本操作は「phpMyAdminの使い方」を参考にしてください。

② 共有されているユーザー情報を切り分ける

マルチサイトの落とし穴がユーザーです。ユーザー情報（wp_users・wp_usermeta）はサイトごとに分かれておらず、全サイトで1組を共有しています。そのため子サイトのテーブルを移しただけでは、新しいサイトに誰もログインできません。

対応としては、その子サイトに権限を持つユーザーだけを、IDを変えずに移します。IDが変わると記事の投稿者との対応が崩れるためです。

さらに、権限情報のキー名も書き換えます。usermetaの「wp_N_capabilities」「wp_N_user_level」を「wp_capabilities」「wp_user_level」へ、optionsの「wp_N_user_roles」を「wp_user_roles」へそろえます。

ここを忘れると、ログインはできても「このページにアクセスする権限がありません」と表示され、管理画面に入れなくなるので注意してください。。

③ 画像をuploads/sites/N/から移し、パスを置換する

子サイトの画像は「wp-content/uploads/sites/N/年/月/」に保存されています。シングルサイトでは「wp-content/uploads/年/月/」が標準なので、フォルダを移したうえで、データベース内の「uploads/sites/N/」を「uploads/」に置換します。

古いマルチサイトでは「wp-content/blogs.dir/N/files/」に保存されている場合もあるため、実際のフォルダを確認してから置換元を決めます。

置換には、シリアライズされたデータを壊さないツールを使います。SQLのREPLACEで一括置換すると、文字数情報がずれてウィジェットやテーマ設定が消えるので注意してください。

WP-CLIのsearch-replaceであればシリアライズデータを正しく扱えるため安全に近いすることができます。作業の際は、まず「–dry-run」で件数を確認してから実行しましょう。

wp search-replace 'wp-content/uploads/sites/2/' 'wp-content/uploads/' --dry-run
wp search-replace 'wp-content/uploads/sites/2/' 'wp-content/uploads/'

④ URLとパーマリンクを変えずに切り替える

検索評価や外部からのリンクを守るため、分離後も記事のURLは変えないのが原則です。サブドメイン型なら、新しいWordPressをそのサブドメインで立ち上げ、DNSを切り替えればURLを維持できます。サブディレクトリ型で「/blog/子サイト名/」のようなURLをそのまま使う場合は、設置するディレクトリと.htaccessの書き方に工夫が必要です。

切り替え前には、旧サイトの主要URLを一覧にして、新環境で同じURLが開けるかを確認します。特にサブディレクトリ型のメインサイトでは、投稿のURLに「/blog/」が自動で付く仕様があるため、解除後にパーマリンクが変わってしまうことがあります。どうしてもURLが変わる場合は、旧URLから新URLへ301リダイレクトを設定します。

＝＝＝

「ユーザー権限の書き換えや画像パスの置換、URLの維持まで自分で進めるのは不安…」という方は、マルチサイトの解除作業ごとサイト引越し屋さんにお任せください。

>>無料ご相談窓口はこちらをクリック

今のWordPressでマルチサイトを解除する手順

方法②でメインサイトだけを残す場合の手順です。順番が大切で、特に「プラグインのネットワーク有効化の解除」と「管理者権限の確認」をwp-config.phpの編集より前に済ませないと、解除した瞬間に機能が止まったり、管理画面に入れなくなったりします。

① 検証環境を用意し、ファイルとデータベースをバックアップする

本番と同じ環境を複製し、以下の手順を一度通してから本番に反映します。WordPress公式ドキュメントのほうでも、ネットワークを作る前にwp-config.phpと.htaccessを含めてバックアップするよう求めています（Create A Network）。

解除するときも同じファイルを触るため、元に戻せる状態を作ってから始めます。

② 不要な子サイトを削除する

「ネットワーク管理＞サイト」から、メインサイト以外を削除します。WP-CLIなら「wp site delete サイトID」で削除できます。削除するとそのサイトのテーブルは消え、元には戻せません。

将来必要になる可能性が少しでもあるなら、削除前にその子サイトだけのバックアップ（wp_N_のテーブルとuploads/sites/N/）を取っておきます。

③ プラグインのネットワーク有効化を解除し、管理者権限を確認する

ネットワーク全体で有効化したプラグインの情報は、ネットワーク用のテーブル（wp_sitemeta）に保存されています。そのまま解除すると、セキュリティやキャッシュなどのプラグインが、気づかないうちに停止した状態になります。

事前に「ネットワーク管理＞プラグイン」で有効化されているものを控え、ネットワークでの無効化→メインサイトでの有効化に切り替えておきます。

あわせて、作業するユーザーがメインサイトで「管理者」権限を持っているかを確認します。特権管理者は、サイトごとの権限が設定されていなくても全サイトを操作できるため、解除したとたんに「権限がありません」となることがあります。

「ユーザー」画面で自分の権限グループが「管理者」になっていれば問題ありません。

④ wp-config.phpからマルチサイトの定数を外す

wp-config.phpには、マルチサイト化したときに追加した次のような行があります。これらを削除するか、「WP_ALLOW_MULTISITE」をfalseにして残りを削除します。値は環境ごとに異なります。

define( 'WP_ALLOW_MULTISITE', true );
define( 'MULTISITE', true );
define( 'SUBDOMAIN_INSTALL', false );
define( 'DOMAIN_CURRENT_SITE', 'example.com' );
define( 'PATH_CURRENT_SITE', '/' );
define( 'SITE_ID_CURRENT_SITE', 1 );
define( 'BLOG_ID_CURRENT_SITE', 1 );

ドメインマッピング用の「SUNRISE」や、Cookie関連の定数が追加されている場合もあるため、前後の行もあわせて確認します。

⑤ .htaccessを通常のWordPress用に戻す

.htaccessの「# BEGIN WordPress Multisite」などマルチサイト用のルールを、通常のWordPress用のルールに置き換えます。ドメイン直下に設置している場合の例です。

# BEGIN WordPress
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress

「/blog/」などのディレクトリにWordPressを設置している場合は、RewriteBaseと最後のRewriteRuleをそのディレクトリに合わせます。置き換えたあと、管理画面の「設定＞パーマリンク」で変更せずに「変更を保存」を押すと、リライトルールが再生成されます。

⑥ ネットワーク用のテーブルと不要なユーザーを整理する

動作を確認できたら、マルチサイト専用のテーブル（wp_blogs、wp_blogmeta、wp_blog_versions、wp_registration_log、wp_signups、wp_site、wp_sitemeta）を削除します。

解説記事によっては「wp_blogmeta」が抜けていますが、WordPress 5.1以降に作られた、または更新されたマルチサイトには存在するため、あわせて確認します。

また、削除した子サイトにだけ所属していたユーザーは、解除後もwp_usersに残ります。不要なアカウントを残すと不正ログインの入口になりうるため、メインサイトで権限を持たないユーザーを確認して削除します。最後に主要ページ、画像、フォーム、管理画面が正しく動くかを確認したら完了です。

＝＝＝

「実際に依頼するかは分からないけど、まずは相談に乗って欲しい」
そんな時ほどサイト引越し屋さんへご連絡ください！

>>無料ご相談窓口はこちらをクリック

作業前に決めておく確認事項チェックリスト

マルチサイトの解除は、作業そのものよりも「何を残し、何を捨てるか」を先に決めておくことが重要です。弊社がお見積りの段階で必ず確認している項目を、そのままチェックリストにしました。

特に忘れがちなのが「子サイトの画像」です。子サイトは使っていなくても、メインサイトの記事から子サイトの画像URLを直接貼っているケースがあります。削除前にメインサイトのデータベースを「uploads/sites/」で検索し、参照がないか確かめておくと安心です。

作業期間とサイト停止時間の目安

メインサイトだけを残して子サイトを削除する場合、弊社ではログイン情報などがすべてそろってから1〜2週間を作業期間の目安にしています。そのうち実際にサイトを止めるのは本番反映のときだけで、メンテナンス表示を出す時間は念のため1〜2時間程度を見込んでいます。

工程は次の流れです。

1. 現行環境の調査（サイト構成、プラグイン、画像の参照関係）
2. ファイルおよびデータベースのバックアップ
3. 検証環境での事前検証
4. 記事・画像の移行と、既存URL・パーマリンクを維持するための調整
5. 子サイトの削除とマルチサイト設定の解除（ここでメンテナンス表示）
6. 主要ページ、画像、フォーム、管理画面の動作確認

子サイトをそれぞれ独立したWordPressとして残す場合や、サーバー移転も同時に行う場合は、上記がサイト数分必要になり、ドメイン（DNS）の切り替えも加わるため、期間も費用も増えます。AWSなどのクラウド環境では、レンタルサーバーより事前調査に時間がかかる点も見込んでおきましょう。

また、解除直後は問題なくても、更新頻度の低いページや管理画面の一部であとから不具合が見つかることがあります。弊社では作業後2週間を目安に検収期間を設け、その間に見つかった不具合に対応しています。自社で作業する場合も、元のバックアップは少なくともその期間は残しておきましょう。

サイト引越し屋さんの対応事例

マルチサイトの解除・分離について、弊社に寄せられたご相談と、それぞれの判断を紹介します。

事例① ブログの子サイトを削除し、メインだけをシングルサイト化

デザイン事業を営む方から、「/blog/」で運用しているマルチサイトのうち、使っていない子サイトを削除し、メインサイトだけのシングルサイトにしたいというご相談をいただきました。条件は「今のURL（パーマリンク）を変えないこと」です。

お客様からは「使いたいプラグインがマルチサイトに対応していなくて邪魔をしている。このままでもよいと思うか」というご質問もあり、子サイトを使っていない以上、シングルサイト化をおすすめしました。

ご提案したのは、現行環境の調査、バックアップ、検証環境での事前検証、記事・画像の移行とURL維持の調整、子サイト削除とマルチサイト解除、動作確認という工程です。

期間は1〜2週間、停止時間は1〜2時間を想定し、あわせて「削除する子サイトのバックアップを取るか」「子サイトの画像を残すか」の2点を確認させていただきました。

事例② AWSのサブドメイン型マルチサイトを2つのWordPressに分離

AWS上で、コーポレートサイトとサブドメインのサービスサイトを1つのマルチサイトで運用していた企業の事例です。

古いPHP・WordPressの環境から最新の環境へ移るにあたり、弊社は「①マルチサイトのまま移行」と「②マルチサイトを廃止してサイトごとに分離」の2案を提示しました。②は管理の自由度が高まる一方、サーバーが2台になり運用コストが増える可能性があります。

お客様は②を選ばれ、弊社では「本番用のサーバー2台へそれぞれデータを移し、URLをそのままに調整してからDNSを切り替える」工程をご案内しました。

テスト環境については費用を抑えたいとのご意向もありましたが、クラウド環境の分離はレンタルサーバーよりリスクが高いため、検証環境を用意して一括で進めることを推奨しています。

事例③ 「マルチドメイン」と「マルチサイト」の取り違えを整理

制作会社から、別々に管理している複数のサイトを「マルチドメインで一元管理したい」というご相談をいただいた際には、まず「ドメインやサーバーをまとめたいのか」「WordPress自体を1つにまとめたい（マルチサイト化）のか」を確認しました。

前者ならサイトは独立したまま管理をまとめられ、後者とは作業内容がまったく異なります。「管理を楽にしたい」という目的であれば、必ずしもマルチサイトは必要ありません。

まとめ

WordPressマルチサイトをシングルサイトへ移行する方法は、新しいWordPressにサイトを切り出す方法と、今のWordPressでマルチサイトの設定を外す方法の2つです。メインサイトだけを残すなら後者、子サイトを残す場合やサーバーも変える場合は前者が基本です。

どちらの方法でも、共有されたユーザー情報の整理、uploads/sites/N/の画像パス、プラグインのネットワーク有効化、URLの維持がつまずきやすいポイントです。

作業前に「何を残し、何を削除するか」を決め、検証環境で手順を通してから本番へ反映すれば、サイトの停止は1〜2時間程度に抑えられます。

サイト引越し屋さんでは、マルチサイトの解除・子サイトの切り出し・サーバー移転を、現在のURLを維持したまま代行しています。「このまま続けるべきか」という段階からでも、お気軽にご相談ください。