WordPress のログイン画面で、正しいユーザー名とパスワードを入れたのに「Cookie がブロックされている」というエラーが出てログインできないことがあります。このエラーは、WordPress がログインに使う Cookie をブラウザーとやり取りできなかったときに表示されます。ブラウザーの設定より、サイト側の設定（https の混在、COOKIE_DOMAIN、余計な出力、キャッシュ）が原因になっていることが多いエラーです。
この記事の内容は WordPress 6.9 のソースコードと、テスト環境での再現で確認しています（2026年10月時点）。
エラーは2種類ある
日本語の管理画面では、次のどちらかが表示されます。どちらが出ているかで、調べる場所が変わります。
| 表示される文言（冒頭） | 意味 | 主な原因 |
|---|---|---|
| Cookie がブロックされているか、お使いのブラウザーで未対応のようです | ログイン画面を開いたときに渡したテスト用の Cookie が、ログイン送信時に戻ってこなかった | http と https の混在、COOKIE_DOMAIN の誤り、ログイン画面のキャッシュ、ブラウザーの設定 |
| 予期しない出力により Cookie がブロックされました | Cookie を送る前に、PHP が画面に何かを出力してしまった | ファイル先頭の BOM や空白、表示された PHP の警告 |
エラーが出る仕組み
wp-login.php を開くと、WordPress は wordpress_test_cookie という名前のテスト用 Cookie をブラウザーに渡します。ユーザー名とパスワードを送信したとき、この Cookie がリクエストに含まれていなければ、「ブロックされているか、未対応」のエラーになります。
Cookie はレスポンスのヘッダーで送られるため、その前に HTML や空白が1文字でも出力されると、PHP は Cookie を送れません。この場合は「予期しない出力」のエラーになります。
手順1: ブラウザー側を切り分ける
まず、サイト側の問題かどうかを確かめます。
- シークレットウィンドウや別のブラウザーでログインしてみる
- サイトを移転した後や URL を変えた後なら、そのサイトの Cookie を削除してから試す
- ブラウザーの設定で、そのサイトの Cookie をブロックしていないか確認する
どのブラウザーでも同じエラーが出るなら、サイト側に原因があります。手順2以降に進みます。
手順2: ログイン画面のヘッダーを確かめる
サーバーにログインできる環境か手元のパソコンで、curl を使ってログイン画面のレスポンスヘッダーを見ます。
curl -sI https://example.com/wp-login.php正常なら、次のような Set-Cookie の行があります（https のサイトでは secure も付きます）。
Set-Cookie: wordpress_test_cookie=WP%20Cookie%20check; path=/; secure; HttpOnly結果の見方は次のとおりです。
| 見えたもの | 考えられる原因 | 進む手順 |
|---|---|---|
Set-Cookie の行がない |
ログイン画面がキャッシュから返されている | 手順5 |
domain= が付いていて、アクセスしたホスト名と合わない |
COOKIE_DOMAIN の誤り |
手順4 |
secure が付いているのに、http の URL でアクセスしている |
http と https の混在 | 手順3 |
| ヘッダーは正常 | ブラウザーやプラグインの影響、または予期しない出力 | 手順1、手順6、手順7 |
手順3: http と https を統一する
https のサイトでは、テスト用の Cookie に secure が付きます。secure 付きの Cookie は、ブラウザーが http の接続では受け取りません。そのため、http:// の URL でログイン画面を開くと、Cookie が保存されずにエラーになります。
WordPress に登録されている URL を確認します。
wp option get siteurl
wp option get home2つが https:// で、ホスト名（www の有無を含む）がそろっているかを確かめます。違っていれば、正しい URL に直します。
wp option update siteurl 'https://example.com'
wp option update home 'https://example.com'WP-CLI が使えない場合は、「設定」→「一般」の「WordPress アドレス (URL)」と「サイトアドレス (URL)」で確認できます。あわせて、サーバーやレンタルサーバーの設定で、http へのアクセスを https に転送しておきます。
手順4: wp-config.php の Cookie の定義を見直す
wp-config.php に Cookie 関連の定数を書いていないか確かめます。
grep -n "COOKIE" wp-config.php1つのサイトだけを動かしている場合、COOKIE_DOMAIN・COOKIEPATH・SITECOOKIEPATH・ADMIN_COOKIE_PATH を定義する必要はありません。 定義しなければ、WordPress は COOKIE_DOMAIN を空にし、パスは「設定」→「一般」の URL から決めます。
よくある誤りは次のとおりです。
COOKIE_DOMAINにアクセスしているホスト名と違う値を入れている: たとえばwww.example.comを指定したのにexample.comでアクセスすると、ブラウザーはその Cookie を受け取りません。不要なら定義を削除します- 同じ定数を2回定義している: PHP 8 では「Constant COOKIE_DOMAIN already defined」という警告になります。警告が画面に表示される設定だと、それが「予期しない出力」になり、手順6のエラーにつながります。片方を削除します
ADMIN_COOKIE_PATHを/にしている: 本来はwp-adminのパスになる値です。理由がなければ定義を削除しますwp-config.phpの中でLOGGED_IN_COOKIEなどの Cookie 名の定数を参照している: これらはwp-config.phpを読み込んだ後に WordPress が定義する定数なので、wp-config.phpの中ではまだ存在せず、PHP 8 では Error で止まります
マルチサイトで独自ドメインのサイトにログインできない場合
マルチサイトで、サブサイトに独自ドメインを割り当てていて Cookie のエラーが出る場合は、WordPress の公式ドキュメント（Advanced Administration Handbook のドメインマッピングの項）が、ネットワーク用の設定の後に次の1行を加える方法を案内しています。
<?php
define( 'COOKIE_DOMAIN', $_SERVER['HTTP_HOST'] );この行は、ほかに COOKIE_DOMAIN の定義がない状態で1回だけ書きます。1つのサイトだけの環境には加えません。
手順5: ログイン画面をキャッシュから外す
ページキャッシュのプラグイン、サーバーのキャッシュ機能、CDN が wp-login.php をキャッシュしていると、保存済みの HTML だけが返され、テスト用の Cookie を渡す Set-Cookie が付きません。手順2の結果で Set-Cookie がない場合は、キャッシュの設定で wp-login.php と /wp-admin/ をキャッシュの対象から外し、キャッシュを削除します。
CDN を使っている場合は、curl -sI の結果にキャッシュの状態を示すヘッダー（Cloudflare なら cf-cache-status）が出ます。ログイン画面で HIT になっていれば、CDN のキャッシュルールを見直します。
手順6: 「予期しない出力」の原因を探す
「予期しない出力により Cookie がブロックされました」のときは、ヘッダーより前に何かが出力されています。よくある原因は次の3つです。
wp-config.php、テーマのfunctions.php、プラグインのファイルの先頭に BOM（文字コードの印）や空白・改行がある- ファイル末尾の
?>の後ろに空白や改行がある - PHP の警告や注意が画面に表示されている
BOM があるファイルは、サーバーで次のコマンドを実行すると一覧にできます（WordPress のフォルダーで実行）。
grep -rl $'^\xEF\xBB\xBF' --include='*.php' wp-config.php wp-content/見つかったファイルは、エディターで「BOM なしの UTF-8」で保存し直します。
どのファイルが出力しているかは、デバッグログでわかります。wp-config.php の「編集が必要なのはここまでです」の行より上に、次の3行を加えます（同じ定数がすでにあれば、そちらの値を変えます）。
<?php
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );ログインを試した後、wp-content/debug.log に次のような行が残ります。output started at の後ろが、出力を始めたファイルと行番号です。
PHP Warning: Cannot modify header information - headers already sent by (output started at /var/www/html/wp-content/mu-plugins/example.php:1) in /var/www/html/wp-login.php on line 531原因を直したら、3行を削除するか WP_DEBUG を false に戻し、debug.log も削除します。debug.log は外から見える場所にあるため、残したままにしないでください。
なお、PHP の output_buffering が有効なサーバーでは、少量の出力ならエラーにならないことがあります。サーバーを移した途端にこのエラーが出始めた場合は、もともとあった BOM や空白が表に出た可能性があります。
手順7: プラグインの影響を確かめる
セキュリティ系やログイン画面を変えるプラグインが、Cookie やリダイレクトに影響していることがあります。有効なプラグインを記録してから、いったんすべて無効にして確かめます。
wp plugin list --status=active --field=name > active-plugins.txt
wp plugin deactivate --allログインできるようになったら、記録したプラグインを1つずつ有効に戻して、原因を特定します。次の例の akismet の部分を、active-plugins.txt に書かれたスラッグに替えて実行します。
wp plugin activate akismetすべて戻すときは、wp plugin activate $(cat active-plugins.txt) で元の状態に戻せます。WP-CLI が使えない場合は、FTP などで wp-content/plugins のフォルダー名を一時的に変えると、すべてのプラグインが無効になります。
エラーは出ないがログイン画面に戻される場合
エラーは表示されず、ログインしても管理画面に入れずにログイン画面へ戻される、またはリダイレクトが繰り返される場合は、別の原因が考えられます。ロードバランサーや CDN が https を受けて、WordPress には http で転送している構成では、WordPress が https の接続だと判断できません。公式ドキュメントの HTTPS の項では、この構成でリダイレクトが繰り返される場合の対処として、wp-config.php で転送元の情報から https を判定する方法が案内されています。
<?php
if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && false !== strpos( $_SERVER['HTTP_X_FORWARDED_PROTO'], 'https' ) ) {
$_SERVER['HTTPS'] = 'on';
}X-Forwarded-Proto ヘッダーを付けるのはプロキシ側なので、プロキシがこのヘッダーを送っていることを確かめてから使います。
まとめ
- 「ブロックされているか、未対応」はテスト用 Cookie が戻らない、「予期しない出力」は Cookie の前に出力がある、という違いがある
curl -sIでログイン画面のSet-Cookieを見ると、原因の見当がつくsiteurlとhomeを https とホスト名でそろえ、http から https へ転送する- 1つのサイトだけなら
COOKIE_DOMAINなどの定義は不要。二重定義やwp-config.php内でのLOGGED_IN_COOKIEの参照は削除する - ログイン画面はキャッシュの対象から外す
- 「予期しない出力」は BOM・空白・表示された警告を、
debug.logのoutput started atで探す