WordPressサイトで「429 Too Many Requests」と表示されたら、最初に再読み込みや保存、ログイン、API実行の連打を止めてください。429は、一定時間内の要求が多すぎると判定され、レート制限が働いた状態です。
制限した場所は、CDNやWAF、レンタルサーバー、セキュリティプラグイン、WordPress REST APIの手前、連携先の外部サービスなど複数あります。自分が操作しすぎた場合だけでなく、自動処理、共有IP、誤設定、ボットや攻撃が原因になることもあります。
発行元を確認する前に、WAF・CDN・セキュリティ機能を全面停止しないでください。防御を外すと、実際の大量アクセスやログイン攻撃をそのままWordPressへ通し、503など別の障害へ広げるおそれがあります。
この記事では、`Retry-After`、エラー画面、URL、時刻、応答元を記録し、429を返した場所だけを最小範囲で直す順番を解説します。
先に結論：429エラーは8段階で確認する
| 順番 | 確認すること | 目的 |
|---|---|---|
| 1 | 手動の連打と自動再試行を止める | 制限時間の延長と負荷増加を防ぐ |
| 2 | 画面・URL・時刻・操作を記録する | 制限ログへつなぐ |
| 3 | `Retry-After`とエラー本文を確認する | 再試行の目安と提供元を知る |
| 4 | 公開画面・管理画面・保存・外部連携を分ける | 制限された経路を絞る |
| 5 | CDN・WAF・ホスト・プラグイン・APIのログを見る | 429の発行元を特定する |
| 6 | 正当な通信と大量・不正通信を分ける | 防御を維持して誤検知だけ直す |
| 7 | 対象ルールや実行頻度を最小範囲で調整する | 原因を追える状態で復旧する |
| 8 | HTTP 200、重要機能、ログを再確認する | 解除しすぎと再発を見逃さない |
`Retry-After`がある場合は、指定された時刻または秒数まで待ちます。ない場合は、エラー本文やサービス管理画面の案内を優先し、短時間の連続確認を避けます。「必ず5分待てば直る」のような固定時間はありません。
429 Too Many Requestsとは？
RFC 6585の429 Too Many Requestsは、利用者が一定時間内に多すぎる要求を送った状態を示します。応答には理由を説明する内容と、再試行までの時間を示す`Retry-After`が含まれる場合があります。
ただし、何を一人の利用者として数えるか、何回で制限するかは仕様で一律に決まっていません。IPアドレスだけでなく、ログイン利用者、APIトークン、Cookie、URL、サーバー群などを単位にする実装があります。そのため、別回線で開けたからといって原因がIPだけだとは断定できません。
429はWordPress本体だけが返すエラーではありません。ブラウザがアクセスした自サイトのCDNやWAFが返す場合も、WordPressプラグインが呼び出した外部APIから返る場合もあります。失敗した要求の送信先ドメインを確認することが重要です。
429・403・503の違い
| 表示 | 意味 | 最初の行動 |
|---|---|---|
| 429 Too Many Requests | 一定時間内の要求が基準を超えた | 連打を止め、Retry-Afterと制限ログを確認 |
| 403 Forbidden | 要求は理解されたが処理を拒否された | WAF、権限、IP・アクセス制限を確認 |
| 503 Service Unavailable | 過負荷やメンテナンスで現在は処理できない | 障害情報、発行元、負荷、メンテナンスを確認 |
403は要求回数の超過とは限らず、待つだけでは直らない場合があります。詳しくはWordPressの403 Forbiddenを安全に直す確認順を確認してください。サイト全体が過負荷で503を返しているなら、WordPress 503 Service Unavailableの直し方が対象です。
429と503はどちらも`Retry-After`を返す場合があります。最終判断は番号だけでなく、応答本文、ヘッダー、発生範囲、同時刻のログを合わせて行います。
最初の10分で行う安全な初動
1．連打と自動再試行を止める
F5、ログイン、保存、更新、キャッシュ削除、API同期を繰り返すと、新しい要求がカウントされ、制限が続く場合があります。ブラウザ操作だけでなく、バックアップ、監視、在庫同期、投稿自動化、外部ツールの再試行も一度止めます。
2．証拠を保存する
エラー画面全体、完全なURL、発生時刻とタイムゾーン、直前の操作、毎回か断続的かを記録します。確認できる場合は、HTTP 429、`Retry-After`、`Server`、`Cf-Ray`などの識別ID、応答本文も保存します。
識別IDがあるだけで発行元を断定しません。たとえばCloudflareの`Cf-Ray`はCloudflareを通った要求に付きますが、それだけでCloudflareのレート制限が429を生成した証拠にはなりません。セキュリティイベントや配信元ログまで照合します。
3．どの操作だけ失敗するかを分ける
待機後、トップページ、別の記事、`wp-admin`、問題の操作を一度ずつ比較します。公開画面は正常で記事保存だけ失敗するなら、ブロックエディターが送るREST API要求やセキュリティ規則が候補です。保存エラーの切り分けは「正しいJSONレスポンスではありません」の直し方も参考になります。
ログインだけで出るなら、ログインパスを対象にしたCDN・WAF・ホスト・セキュリティプラグインの規則を確認します。管理画面へ入れない場合の安全な入口はWordPress管理画面にログインできないときの確認順にまとめています。
429を返している場所を特定する
| 症状・手がかり | 優先して見る場所 | 確認内容 |
|---|---|---|
| CloudflareのError 1015や制限画面 | Cloudflare Security Events | 時刻、Ray ID、作用したルール、Path、Action |
| 公開ページやwp-adminが429 | CDN、ホストWAF、Webサーバー、プラグイン | 同時刻の制限ログ、URL、要求元、回数 |
| 特定操作だけ429 | ブラウザのNetworkとREST API | 失敗したRequest URL、応答元、Retry-After |
| 同期・SEO・バックアップ機能だけ429 | 連携先の外部API | 送信先ドメイン、クォータ、利用量、障害情報 |
| 自分または同じ回線だけ429 | IP・認証・Cookie単位の制限 | 制限条件と同一IPの要求数 |
| アクセス急増時に全体で429 | CDN・WAF・ホストの防御と容量 | 正当流入、ボット、攻撃、サーバー負荷 |
CloudflareのSecurity Events公式資料では、実際に作用した製品やルール、送信元IP、ユーザーエージェント、パスなどを確認できます。時刻やRay IDで絞り、Rate limitingのルールが本当に作用したかを確認します。
外部APIから429が返っている場合、自サイトのWAFを変更しても直りません。ブラウザやプラグインのログで送信先ホストを確認し、そのサービスの管理画面、クォータ、応答ヘッダー、公式障害情報を調べます。
原因別の安全な直し方
1．Cloudflare・CDN・WAFのレート制限
セキュリティイベントで、対象ルール、URL、カウント条件、しきい値、期間、ブロック時間を確認します。正当な利用者だけが誤検知されていると確認できた場合に限り、対象パスや条件、しきい値を必要最小限調整します。
WAFの全面停止や全IPの許可は避けます。ログイン、XML-RPC、REST APIなど攻撃を受けやすい場所の防御を外すと、WordPressへ大量要求が届きます。基本防御の考え方はWordPressセキュリティの基本を確認してください。
2．レンタルサーバー・Webサーバー側の制限
ホストのWAF、アクセスログ、レート制限ログで、対象パス、要求元、要求回数、ブロック理由を確認します。共有サーバーで設定を見られない場合は、時刻、URL、429画面、ヘッダー、識別IDを添えてサポートへ問い合わせます。
正当なアクセスが契約上限を継続的に超える場合も、上限だけを上げる前にキャッシュ、重い処理、ボット、アクセス集中を確認します。上流の防御だけ緩めると、今度はサーバーが過負荷になり503を返すことがあります。
3．セキュリティ・ログイン制限プラグイン
プラグインのブロック履歴、Live Traffic、監査ログなどで、429の発生時刻と対象URLを確認します。原因プラグインが特定できた場合だけ、設定を調整するか、一つずつ停止して再現を確認します。
プラグインによって制限時のステータスコードや解除方法は違います。429だから特定製品だと決めつけず、削除ではなく元に戻せる方法を選びます。作業前にはWordPressのバックアップを安全に取る手順で復元手段を確認してください。
4．REST API・インポート・自動化の要求過多
同時実行数と実行頻度を下げ、`Retry-After`を尊重し、待機時間を段階的に増やす再試行へ変更します。無限再試行や、複数ツールから同じ同期を動かす設定を止めます。処理済みか不明な更新要求は、結果を照合してから再送します。
WordPress REST API公式のPaginationを使い、大量データを小分けに取得します。必要な項目だけなら`_fields`パラメータで応答量を減らせます。
REST APIを全面停止するのは避けます。WordPress公式FAQは、REST API停止で管理画面機能が壊れるため無効化を推奨していません。問題のエンドポイント、利用者、認証、頻度を限定して対処します。
5．外部APIのクォータ・レート制限
翻訳、画像、SEO、SNS、メール、決済、在庫などの外部サービスが429を返す場合は、相手側の利用量、契約クォータ、リセット時刻、障害情報を確認します。待機、処理の分散、正式な上限変更の順に検討し、自サイト側のCDNやキャッシュを無関係に変更しません。
6．ボット・攻撃・正当なアクセス急増
実際の攻撃や悪性ボットなら、制限を解除せず、防御を維持します。正当な訪問者、検索クローラー、監視、自社API、悪性ボットをログで分け、対象の狭いルールを使います。
正常なアクセスでも頻繁に上限へ達するなら、WordPressが重い原因と改善順で処理負荷を確認し、キャッシュ設定の基本に沿って配信元への要求を減らします。
Google検索への影響と復旧後の確認
Google Search Centralのクロールエラー資料では、サーバー過負荷時にGooglebotへ429または503を一時的に返すとクロールが減速し、数日以上続けるとURLがインデックスから外れる可能性があると案内しています。
短時間の429だけで検索順位が下がったとは断定できません。ただし、サイト全体や重要URLで長時間繰り返す場合は、復旧後に主要URLがHTTP 200を返すこと、Search Consoleのページ登録状況とクロール統計が戻ることを確認します。クロール制限の代わりに403や404を返さないでください。
- トップページ、記事、管理画面がHTTP 200で安定して開く
- ログイン、記事保存、画像アップロード、予約投稿が一度ずつ成功する
- REST APIと外部連携が適切な間隔で成功する
- `Retry-After`後も429が再発していない
- 変更したルール以外のWAF・CDN防御が有効である
- 正当な利用者だけを広く遮断していない
- サーバー負荷とエラー率が通常範囲へ戻った
- 自動処理に無限再試行や重複ジョブがない
429対応でやってはいけないこと
- F5、保存、ログイン、API実行を繰り返す
- `Retry-After`を無視して自動再試行する
- WAF、CDN、セキュリティプラグインを全面停止したままにする
- ログを確認せず全IP、全ボット、広いパスを許可する
- 429を正常な200、403、404へ見せかける
- REST APIを全面停止する
- プラグインを一括削除し、複数設定を同時に変える
- 権限を777にする、無関係な`.htaccess`を編集する
- キャッシュ全削除を繰り返して解除を試す
- 攻撃や容量不足を確認せず上限だけを引き上げる
安全な対処は、発行元と作用した条件をログで確定し、必要な範囲だけを一つ変更することです。
429を繰り返さないための予防
- CDN・WAF・ホストの429件数と対象URLを定期確認する
- 正当なピークと攻撃時の要求数を分けてしきい値を見直す
- APIクォータの使用率とリセット時刻を監視する
- 自動処理へ同時実行数、間隔、最大再試行回数を設定する
- バックアップ、同期、クロール、集計の実行時刻を分散する
- ログイン、REST API、公開ページで同じ制限を使い回さない
- 設定変更日、元の値、理由、検証結果を記録する
- 解除後に防御を戻したことまで運用記録へ残す
制限は厳しすぎると正当な利用を止め、緩すぎるとWordPressの負荷と攻撃リスクを増やします。平常時のアクセス量と、ログイン・保存・APIなど経路ごとの利用実態を基準に調整します。
サポートへ伝える情報
- 429が出た正確なURLまたは外部APIの送信先
- 発生時刻とタイムゾーン
- エラー画面、応答本文、Retry-After
- Server、Cf-Ray、リクエストID
- 公開画面、wp-admin、ログイン、保存、同期のどこで出るか
- 同じ回線・利用者・APIトークンだけか
- 直前に変更したWAF、プラグイン、自動処理
- 同時刻の要求数と伏せ字済みログ
- 実施済みの確認と結果
「429を解除してください」だけでなく、「14時10分、`wp-admin`のログインだけで発生。Retry-Afterは60、Ray IDあり。Security Eventsでは特定ルールが対象。公開ページは正常」のように伝えると、解除すべき場所を絞りやすくなります。
よくある質問
何分待てばよいですか？
`Retry-After`があれば、その指定を優先します。ない場合はエラー本文、サービス管理画面、提供元の案内に従います。待機時間はルールごとに違うため、固定の分数は断定できません。
Retry-Afterがなくても429ですか？
はい。`Retry-After`は付く場合があるヘッダーで、必須ではありません。429本文、識別ID、制限ログを確認してください。
429はハッキングされた印ですか？
429だけでは断定できません。正当な連打、自動処理、共有IP、誤ったしきい値、ボット、攻撃のいずれでも起こります。要求元、対象URL、回数、ユーザーエージェントをログで確認します。
キャッシュを削除すれば直りますか？
通常は、429を返した場所の待機または制限設定の確認が先です。キャッシュ削除はレート制限カウンターの解除とは限らず、繰り返すと配信元への要求を増やす場合があります。
自分だけ429が出ることはありますか？
あります。IP、ログイン利用者、Cookie、APIトークンなどの単位で制限される場合があります。ただし、自分だけという状況だけでIP制限と決めず、実際のカウント条件を確認します。
外部APIの429ならサイト全体の障害ですか？
必ずしもそうではありません。特定プラグインの同期や投稿だけ失敗し、公開ページは正常な場合があります。送信先ドメインと外部サービスのクォータを確認します。
まとめ
WordPressの429 Too Many Requestsは、一定時間内の要求が多すぎると判定され、どこかのレート制限が働いた状態です。まず連打と自動再試行を止め、`Retry-After`、画面、URL、時刻、応答元を記録します。
WAFやセキュリティを全面停止せず、実際に作用したルールまたは要求元だけを最小範囲で直すことが安全な復旧方法です。自分でログを確認できない場合は、記録した情報をサーバー会社、CDN、プラグインまたは外部サービスの提供元へ渡してください。