WordPressマルチサイトの「No site defined on this host」エラーを修正する

エラーの内容

WordPress マルチサイトを設定し、新しいサイトを追加してアクセスしようとすると、サイトの代わりに以下のメッセージが表示されます：

No site defined on this host! If you are the owner of this site, please check Debugging WordPress for further assistance.

これはサブドメインインストール（site1.example.com）とサブディレクトリインストール（example.com/site1）の両方で発生します。WordPress はリクエストされたホストに対して wp_blogs テーブルを検索しましたが、一致するレコードが見つからずに処理を中断しました。ブラウザのドメインとデータベースのドメインが一致していないことが原因です。

主な原因

• ブラウザで指定したドメインが wp_blogs や wp_site に保存されている値と一致していない。
• wp-config.php にマルチサイトに必要な定数が存在しないか、誤ったドメインを指している。
• あるドメインでサイトを追加した後にドメインを変更したが、データベースには古いドメインが残っている。
• 移行時にデータベースをコピーしたが、URL の更新手順を省略した。
• サブドメイン用のワイルドカード DNS がサーバーに正しく解決されていない。

修正方法 1 — wp-config.php の定数を確認する

wp-config.php を開き、以下の行が存在し正しく設定されていることを確認してください：

define( 'MULTISITE', true );
define( 'SUBDOMAIN_INSTALL', true ); // false for subdirectory
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 はアクセスするドメインと完全に一致している必要があります。メインサイトが www を使用している場合を除き、www プレフィックスは付けないでください。www.example.com にアクセスしているにもかかわらず定数が example.com になっている場合、すべてのサブドメインの検索が静かに失敗します。このような単純なタイプミスが、驚くほど多くのサポートチケットの原因となっています。

修正方法 2 — データベースのレコードを確認する

MySQL にログインし、2 つの重要なテーブルを確認します：

-- Check the network (site) record
SELECT * FROM wp_site;

-- Check individual blog records
SELECT blog_id, domain, path, archived, deleted FROM wp_blogs;

domain カラムの値とブラウザでリクエストしているドメインを比較してください。移行後の不一致は通常このような状態になっています：

-- Database says:
domain = 'site1.old-domain.com'

-- But you're visiting:
https://site1.new-domain.com

対象を絞った UPDATE で修正します：

-- Update the network root
UPDATE wp_site SET domain = 'new-domain.com' WHERE id = 1;

-- Update the main blog
UPDATE wp_blogs SET domain = 'new-domain.com' WHERE blog_id = 1;

-- Update a specific sub-site (blog_id = 2 here)
UPDATE wp_blogs SET domain = 'site1.new-domain.com' WHERE blog_id = 2;

これだけで終わりではありません。各サイトには独自のオプションテーブルがあるため、そちらも確認してください：

-- Main site options
SELECT option_name, option_value FROM wp_options
WHERE option_name IN ('siteurl', 'home');

-- Sub-site with blog_id = 2 (table prefix = wp_2_)
SELECT option_name, option_value FROM wp_2_options
WHERE option_name IN ('siteurl', 'home');

古い URL が見つかった場合はそちらも更新してください。

修正方法 3 — サブドメインインストール用のワイルドカード DNS

サブドメインのマルチサイトにはワイルドカード DNS レコードが必要です。これがないと、site1.example.com はサーバーに到達できず、WordPress はリクエスト自体を受け取れないため、ルーティングの処理も行われません。

DNS プロバイダーで以下のレコードを追加してください：

Type:  A
Name:  *
Value: YOUR_SERVER_IP
TTL:   3600

数分待って伝播したら、以下のコマンドで確認します：

dig site1.example.com +short
# Should return your server IP

ローカルでテストする場合は、DNS の伝播を待つ代わりに /etc/hosts に手動でエントリを追加してください：

127.0.0.1  example.com
127.0.0.1  site1.example.com
127.0.0.1  site2.example.com

修正方法 4 — Web サーバーの設定

Nginx

server_name でワイルドカードサブドメインを受け付ける必要があります。よくある間違いはルートドメインのみを指定することです：

server {
    listen 80;
    server_name example.com *.example.com;

    root /var/www/html;
    index index.php;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ \.php$ {
        fastcgi_pass unix:/run/php/php8.1-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;
    }
}

変更後はリロードしてください：sudo nginx -t && sudo systemctl reload nginx

Apache

ServerAlias でサブドメインをカバーし、mod_rewrite が有効になっていることを確認してください：

<VirtualHost *:80>
    ServerName example.com
    ServerAlias *.example.com
    DocumentRoot /var/www/html

    <Directory /var/www/html>
        AllowOverride All
        Require all granted
    </Directory>
</VirtualHost>

また、.htaccess にマルチサイト用のリライトルールが含まれているか確認してください。WordPress はネットワーク設定時にこれらを自動生成します。削除されている場合は、パーマリンク設定を再保存するか、ネットワーク設定画面から直接取得して手動で貼り付けてください。

修正方法 5 — 移行またはドメイン変更後の対処

別のサーバーから移行した場合や、ドメインを変更した場合は、テーブルを手作業で一つずつ修正するのではなく、WP-CLI の一括検索・置換を使用してください：

# Dry run first — always
wp search-replace 'old-domain.com' 'new-domain.com' --network --dry-run

# Apply when the output looks right
wp search-replace 'old-domain.com' 'new-domain.com' --network

# Clear all caches
wp cache flush --network

--network フラグを使用すると、wp_2_options、wp_3_options など、すべてのサイトテーブルに対して置換が実行されます。20 サイトのネットワークでは、このコマンド 1 つで 40 以上の手動クエリを置き換えることができます。

動作確認

修正を適用したら、完了と判断する前に実際に正常に動作しているか確認してください：

# 1. Check WordPress can see all sites
wp site list --fields=blog_id,url,public,archived

# 2. Curl the sub-site directly — bypasses browser cache
curl -I http://site1.example.com
# Expect: HTTP/1.1 200 OK (or 301 redirect to HTTPS)

# 3. Confirm DB records look right
wp db query "SELECT blog_id, domain, path FROM wp_blogs;"

# 4. Scan PHP error log for anything still broken
tail -f /var/log/php/error.log

予防策

• 移行前：wp site list で全サイトの URL をスナップショットしておく — 移行後に何を更新すべきかが明確になります。
• ドメイン変更後：ユーザーが 404 エラーを報告し始める前に、サイト公開前の段階で wp search-replace --network を実行してください。
• ワイルドカード SSL：HTTPS 環境では、ルートドメインだけでなく *.example.com をカバーする証明書が必要です。ルートドメインのみの証明書ではすべてのサブサイトが機能しなくなります。
• ステージング環境：独自の DOMAIN_CURRENT_SITE を持つ専用の wp-config.php を用意してください。そうすることで、本番データベースのダンプをインポートしてもステージング環境が静かに壊れることがなくなります。