TL;DR: クイック修正
ログインした直後に、たった一行のテキストによってアクセスを拒否されるのは非常にストレスが溜まるものです。現在ロックアウトされている場合は、アクセスを回復するために次の3つのステップを試してください。
- データベースの接頭辞を同期する:
wp-config.php内の$table_prefixがwp_usermetaテーブル内のキーと一致しているか確認します。 - .htaccess をリフレッシュする: カスタムサーバーのルールをバイパスするために、ファイル名を
.htaccess_oldに変更します。 - プラグインを無効化する: FTPまたはSSHを使用して、
wp-content/pluginsフォルダの名前を一時的にplugins_oldに変更します。
実際には何が起きているのか？
このエラーは、内部的な「403 Forbidden」メッセージだと考えてください。サーバーレベルのブロックとは異なり、ログイン自体は成功しているものの、リクエストしたページを表示するための適切な「権限（capabilities）」があなたのアカウントにないと WordPress 自体が判断しています。これはサイトの移転後に頻繁に発生し、ロックアウトの原因の約80%は設定ファイル内の一行の不一致に起因します。
主な原因は以下の通りです：
- データベースの接頭辞の不一致（サイト移転後の最大の原因）。
- Wordfence や Sucuri などのセキュリティプラグインによる特定の IP のブロック。
- WordPress が自身のコアファイルを読み取れなくなる、不適切なファイルパーミッション。
- PHP バージョンの不一致（特にホストが最近 PHP 8.x にアップデートした場合）。
ステップごとの修正方法
1. データベーステーブルの接頭辞を確認する
WordPress は、テーブルの接頭辞をキー名の一部として使用して、管理者の権限をデータベースに保存します。wp-config.php で接頭辞を wp_ から wp_secure_ に変更したものの、データベース内の行を更新しなかった場合、WordPress はあなたを権限のない「購読者」とみなします。
まず、wp-config.php を開き、次の行を探します。
$table_prefix = 'wp_custom_';
次に、phpMyAdmin を使用して wp_usermeta テーブルを確認します。meta_key カラムを見てください。接頭辞が wp_custom_ の場合、wp_custom_capabilities という名前のキーがあるはずです。もし wp_capabilities のままであれば、それが問題の原因です。これらを同期するために、次の SQL コマンドを実行します。
UPDATE `wp_custom_usermeta` SET `meta_key` = 'wp_custom_capabilities' WHERE `meta_key` = 'wp_capabilities';
UPDATE `wp_custom_usermeta` SET `meta_key` = 'wp_custom_user_level' WHERE `meta_key` = 'wp_user_level';
UPDATE `wp_custom_options` SET `option_name` = 'wp_custom_user_roles' WHERE `option_name` = 'wp_user_roles';
2. 正しいファイルパーミッションを設定する
不適切なパーミッションは重大なセキュリティリスクとなります。フォルダが 777 に設定されていると、ハッカーに門戸を広げているようなものです。逆に制限が厳しすぎると、ロックアウトされてしまいます。WordPress がスクリプトを適切に実行するには、非常に細かなバランスが必要です。
標準的なパーミッションは以下の通りです：
- フォルダ:
755（所有者は読み取り/書き込み/実行が可能、その他は読み取り/実行のみ）。 - ファイル:
644（所有者は読み取り/書き込みが可能、その他は読み取りのみ）。 - wp-config.php: 最大限のセキュリティを確保するために
600または640。
SSH 経由で次のコマンドを実行して、ディレクトリツリー全体を安全にリセットします。
find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;
私は通常、ToolCraft の Unix Permissions Calculator を使ってこれらの設定を視覚化しています。これにより、誤って一般ユーザーに書き込み権限を与えていないか確認できます。
3. .htaccess ファイルをリセットする
.htaccess ファイルのたった一つのタイプミスが、管理ダッシュボードを壊す可能性があります。セキュリティプラグインはここに何百行ものコードを追加することがあり、それがログインと競合することがあります。これをテストするには、現在のファイルを削除して、次のデフォルトの WordPress ブロックに置き換えます。
# BEGIN WordPress
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress
4. 緊急用管理ユーザーを作成する
ユーザーデータが修復不可能なほど破損している場合は、テーマを介して新しい管理者を挿入することで、データベースを完全にバイパスできます。次のスニペットをテーマの functions.php ファイルに貼り付けてください。
function temp_admin_account() {
$user = 'recovery_admin';
$pass = 'SecurePass!2024';
$email = 'admin@yoursite.com';
if ( !username_exists( $user ) ) {
$user_id = wp_create_user( $user, $pass, $email );
$user_obj = new WP_User( $user_id );
$user_obj->set_role( 'administrator' );
}
}
add_action('init','temp_admin_account');
サイトを一度更新し、これらの新しい認証情報でログインして、メインアカウントを修正してください。管理画面に戻れたら、このコードを削除するのを忘れないでください。
ロックアウトを防ぐために
再発を防ぐために、常に最新のバックアップを保持してください。データベースの接頭辞を変更したり、大規模なセキュリティスイートをインストールしたりする場合は、ステージング環境を使用することをお勧めします。最後に、年に2回はユーザーを監査して、バグのあるプラグインのアップデートによって「管理者」ロールからコア権限が剥奪されていないか確認してください。