WordPressマルチサイト（ネットワーク）は、1つのWordPressで複数のサイトを動かす機能です。設定が wp-config.php、.htaccess（またはnginxの設定）、データベースの3か所にまたがるため、どれか1つが合っていないだけで、サブサイトが404になる、ログインできない、といった症状が出ます。この記事では、症状ごとに原因を絞り込み、公式ドキュメントに沿って直す手順を説明します。
作業の前に、wp-config.php・.htaccess の控えと、データベースのバックアップを取ってください。WP-CLIが使える場合は wp db export で保存できます。
症状から原因の見当をつける
| 症状 | まず疑う場所 |
|---|---|
| メインサイトは表示されるが、サブサイトのページや管理画面が404になる | 書き換えルール（.htaccess・nginx）、Apacheの mod_rewrite・AllowOverride |
| サブドメイン型で、サブサイトにアクセスするとサーバーのエラーやブラウザのエラーになる | DNS（ワイルドカードレコード）、バーチャルホスト、SSL証明書 |
| ネットワーク作成後にログインできない、ログイン画面に戻される | ブラウザのCookie、wp-config.php に残ったCookie関連の定数、URLの不一致 |
| 「データベース接続確立エラー」やテーブルが見つからない旨のエラー | wp-config.php の定数、wp_site・wp_blogs テーブル |
| ネットワーク有効化したプラグインが、一部のサイトで正しく動かない | プラグイン側のマルチサイト対応 |
| サブサイトに、別のサイトの投稿や設定が表示される | 自作コードの switch_to_blog() の戻し忘れ |
現在の設定を確認する
WP-CLIで、マルチサイトとして認識されているか、サイト一覧がどうなっているかを確認します。
# マルチサイトとして動いているか
wp eval 'echo is_multisite() ? "multisite: ON" : "multisite: OFF", PHP_EOL;'
# 登録されているサイトの一覧と状態
wp site list --fields=blog_id,url,public,archived,spam,deleted
# サブドメイン型かどうか
wp eval 'var_dump( is_subdomain_install() );'WP-CLIが使えない場合は、wp-config.php を開いて次の定数を確認します。
wp-config.php の定数を正しく書く
マルチサイトの有効化は2段階です。まず wp-config.php の「/* That's all, stop editing! Happy publishing. */」の行より上に次の1行を加えると、管理画面の「ツール」に「ネットワークの設置」が現れます。
/* Multisite */
define( 'WP_ALLOW_MULTISITE', true );「ネットワークの設置」画面でネットワークを作成すると、その環境用の定数が表示されます。それを、先ほどの行の直後に貼り付けます。サブディレクトリ型では次のような内容になります（表示された内容を優先してください）。
define( 'MULTISITE', true );
define( 'SUBDOMAIN_INSTALL', false ); // サブディレクトリ型は false、サブドメイン型は true
define( 'DOMAIN_CURRENT_SITE', 'example.com' );
define( 'PATH_CURRENT_SITE', '/' );
define( 'SITE_ID_CURRENT_SITE', 1 );
define( 'BLOG_ID_CURRENT_SITE', 1 );確認するポイントは次のとおりです。
DOMAIN_CURRENT_SITEはhttps://を付けず、ドメインだけを書く。wwwの有無もデータベースの登録と合わせる- 定数が
require_once ABSPATH . 'wp-settings.php';の行より下に書かれていると効かない。公式ドキュメントでも、その行より後にあるコードは「stop editing」の行より上へ移すよう案内されています SUBDOMAIN_INSTALLは、ネットワーク作成時に選んだ型と一致させる。途中で型を変えるのは、データベースのURLも変わるため簡単ではありません
サブサイトが404になる場合：書き換えルールを確認する
サブサイトのURLをWordPressに振り分ける書き換えルールが足りないと、メインサイトだけが表示され、サブサイトが404になります。シングルサイト用の .htaccess のまま、というのがよくある原因です。
Apache（.htaccess）
「ネットワーク管理」→「設定」→「ネットワーク設定」の画面に、その環境向けのルールが表示されます。既存の WordPress 用の行を、表示されたルールに置き換えます。公式ドキュメントに載っているWordPress 3.5以降のサブディレクトリ型のルールは次のとおりです。
# BEGIN WordPress Multisite
# Using subfolder network type: https://wordpress.org/documentation/article/htaccess/#multisite
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
# add a trailing slash to /wp-admin
RewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L]
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]
RewriteRule . index.php [L]
# END WordPress Multisiteサブドメイン型では、パスの先頭にサイト名が付かないため、次のように短くなります。
# BEGIN WordPress Multisite
# Using subdomain network type: https://wordpress.org/documentation/article/htaccess/#multisite
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
# add a trailing slash to /wp-admin
RewriteRule ^wp-admin$ wp-admin/ [R=301,L]
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule ^(wp-(content|admin|includes).*) $1 [L]
RewriteRule ^(.*\.php)$ $1 [L]
RewriteRule . index.php [L]
# END WordPress Multisiteルールが正しいのに404が続く場合は、Apache側で .htaccess が読まれていない可能性があります。自分で管理しているUbuntuのサーバーなら、mod_rewrite を有効にし、サイト設定の AllowOverride None を AllowOverride All に変えてApacheを再起動します。
sudo a2enmod rewrite
sudo systemctl restart apache2Apacheのエラーログに FollowSymLinks や SymLinksIfOwnerMatch が無効なため RewriteRule が禁止されている、という記録がある場合は、.htaccess の先頭に Options FollowSymlinks が必要な環境です。レンタルサーバーでは、これらの設定を利用者が変えられないことがあるので、サーバー会社のマニュアルを確認してください（2026年10月時点）。
nginx
nginxは .htaccess を読まないため、同じ働きのルールをサーバー設定に書きます。公式ドキュメントのサブディレクトリ型の例では、server ブロックの中に次のルールを置きます。
if (!-e $request_filename) {
rewrite /wp-admin$ $scheme://$host$request_uri/ permanent;
rewrite ^(/[^/]+)?(/wp-.*) $2 last;
rewrite ^(/[^/]+)?(/.*\.php) $2 last;
}サブドメイン型では、このブロックは不要で、server_name example.com *.example.com; のように、サブドメインも同じ server ブロックで受けるようにします。変更後は sudo nginx -t で構文を確かめてから再読み込みします。
サブドメイン型でサブサイトに届かない場合：DNSと証明書
サブドメイン型では、site2.example.com のようなアクセスが、WordPressの入ったサーバーまで届く必要があります。
- DNSにワイルドカードのレコード（
*.example.com）か、サブドメインごとのレコードがある - Webサーバーが、サブドメインへのリクエストもWordPressのディレクトリで受けている
- SSL証明書がサブドメインにも対応している（ワイルドカード証明書や、サブドメインを含む証明書）
ここが足りないとWordPressまで届かないため、表示はWordPressの画面ではなく、サーバーやブラウザのエラーになります。WordPressの画面（「サイトが存在しません」など）が出ているなら、サーバーまでは届いています。その場合の対処は マルチサイトで「サイトが存在しません」と表示される場合の対処法 を参照してください。
なお、公式ドキュメントでは、WordPressのアドレスが localhost やIPアドレスの場合はサブドメイン型を選べないこと、:80・:443 以外のポート番号を含むアドレスではネットワークを作成できないことが案内されています。
ログインできない場合：Cookieの定数とURLを確認する
ネットワークを作成した直後は、ログインし直す必要があります。ログイン画面に戻される場合は、まずブラウザのキャッシュとCookieを削除して試します。
それでも直らない場合は、wp-config.php にCookie関連の定数を自分で書いていないか確認します。マルチサイトでは、WordPressがネットワークの設定から COOKIEPATH・SITECOOKIEPATH・ADMIN_COOKIE_PATH を自動で決め、サブドメイン型では COOKIE_DOMAIN も「. ＋ネットワークのドメイン」に設定します。これらは「定義されていなければ設定する」作りなので、wp-config.php で先に別の値を定義すると、自動の設定が使われません。たとえばサブドメイン型で COOKIE_DOMAIN を空文字にすると、サブドメインをまたいだログインの共有が崩れます。
// 次のような行が残っていたら、意図して書いたものでない限り削除して試す
// define( 'COOKIE_DOMAIN', '' );
// define( 'COOKIEPATH', '/' );
// define( 'SITECOOKIEPATH', '/' );
// define( 'ADMIN_COOKIE_PATH', '/' );あわせて、「設定」→「一般」のWordPressアドレス（URL）とサイトアドレス（URL）が、http/https や www の有無まで含めて一致しているかを確認します。公式ドキュメントでも、www を使う場合は両方のアドレスを同じにするよう案内されています。移転やドメイン変更の後なら、データベースの wp_site・wp_blogs のドメインが古いまま残っていることがあります。手順は マルチサイトのドメイン変更後に起きるエラーの対処法 にまとめています。
データベースのエラーが出る場合：ネットワーク用テーブルを確認する
公式のトラブルシューティングでは、ネットワーク用のテーブルが欠けている、または wp_site・wp_blogs が空になっているとネットワークが動かない、と説明されています。次のテーブルがあるかを確認します（接頭辞が wp_ 以外なら読み替えてください）。
SHOW TABLES LIKE 'wp\_blog%';
SHOW TABLES LIKE 'wp\_site%';
SHOW TABLES LIKE 'wp\_signups';
SHOW TABLES LIKE 'wp\_registration\_log';
SELECT * FROM wp_site;
SELECT blog_id, site_id, domain, path FROM wp_blogs;必要なテーブルは wp_blogs・wp_blogmeta・wp_site・wp_sitemeta・wp_signups・wp_registration_log などです。データベースのユーザーに十分な権限がない、データベースのホスト名が移転で変わった、といった原因もあり得るので、wp-config.php の接続情報も確認します。
ネットワーク有効化したプラグインが一部のサイトで動かない場合
「ネットワーク管理」→「プラグイン」で「ネットワークで有効化」したプラグインは、全サイトで読み込まれます。サイトごとの状態はWP-CLIで確認できます。
# サブサイトから見たプラグインの状態（active-network ならネットワーク有効化）
wp plugin list --url=https://example.com/site2/
# ネットワーク全体で有効化されているプラグインの一覧
wp plugin list --status=active-networkネットワーク有効化しても、プラグインの初期設定（独自テーブルの作成や初期値の保存など）がメインサイトでしか行われず、ほかのサイトで動かないことがあります。これはプラグイン側のマルチサイト対応の問題なので、プラグインの説明やサポートで、マルチサイトでの使い方（ネットワーク有効化と、サイトごとの有効化のどちらを想定しているか）を確認してください。ネットワーク有効化をやめて、必要なサイトだけで有効化すると動く場合もあります。
別のサイトのデータが表示される場合：switch_to_blog() の戻し忘れ
テーマや自作プラグインで、ほかのサイトのデータを読むために switch_to_blog() を使っている場合、restore_current_blog() で元に戻さないと、以降の処理が切り替え先のサイトのまま実行されます。切り替えるたびに、対になる restore_current_blog() を呼びます。
<?php
/**
* 指定したサイトの最新投稿を取得する。
*/
function my_get_posts_from_site( int $blog_id, int $count = 5 ): array {
if ( ! is_multisite() ) {
return array();
}
switch_to_blog( $blog_id );
$posts = get_posts(
array(
'posts_per_page' => $count,
'post_status' => 'publish',
)
);
restore_current_blog(); // 切り替えたら元に戻す
return $posts;
}途中で return する分岐があると戻し忘れが起きやすいので、上の例のように、切り替えから戻すまでの間で関数を抜けない書き方にします。ネットワーク全体で共有する設定値は、switch_to_blog() を使わず get_site_option()・update_site_option() で読み書きできます。
修正後の確認
- メインサイトとサブサイトのトップページ、記事ページ、管理画面をそれぞれ開く
- ログアウトしてからログインし直し、サブサイトの管理画面へ移動できるかを確かめる
wp site listで、すべてのサイトのURLが想定どおりになっているかを確認する- 修正前に控えた
wp-config.php・.htaccessとの差分を見て、意図しない変更が残っていないかを確かめる
マルチサイトを新しく作る場合の手順は WordPressマルチサイトの設定方法 で説明しています。
まとめ
- マルチサイトの設定は
wp-config.php・書き換えルール・データベースの3か所にまたがる。症状から、どこが合っていないかを先に見当づける - サブサイトの404は、マルチサイト用の書き換えルールの不足が多い。「ネットワーク設定」画面に表示されるルールに置き換え、Apacheでは
mod_rewriteとAllowOverrideも確認する - サブドメイン型では、ワイルドカードDNS、バーチャルホスト、証明書がそろっている必要がある
- ログインの不具合は、Cookieの削除、自分で書いたCookie定数の削除、アドレスの一致を順に確認する
- プラグインの不具合はマルチサイト対応を確認し、自作コードでは
switch_to_blog()とrestore_current_blog()を対にする