429 Too Many Requests（RFC 6585）は、ユーザーが一定時間内に送ったリクエストが多すぎることを示します。レスポンスでは状況を説明する必要があり、クライアントが再試行できるようになるまでの秒数または日時を示す Retry-After ヘッダーを含めることもできます。キャッシュは 429 レスポンスを保存してはいけません。
レート制限は、IP アドレス、ユーザー、API キー、エンドポイントごとに適用できます。多くの API は、残りの利用可能量を示すために、X-RateLimit-Limit や X-RateLimit-Remaining などのヘッダーや、IETF で標準化が進められている RateLimit ヘッダーフィールドも送信します。
行儀のよいクライアントは、すぐに再試行するのではなく、Retry-After で示された時間だけ待つか、再試行の間隔を指数関数的に延ばします。TrueURL 自身の API も、短時間に非常に多くのチェックを実行すると、Retry-After 付きの 429 を返します。
レスポンス例
HTTP/1.1 429 Too Many Requests
Date: Fri, 06 Nov 2026 10:15:32 GMT
Retry-After: 120
Content-Type: application/json
Content-Length: 81
{"error":"rate_limited","message":"Too many requests. Try again in 120 seconds."}SEO とリダイレクトチェック
Google は 429 を、5xx エラーと同様に、サーバーが過負荷であることを示すシグナルとして扱います。Googlebot はクロールの頻度を下げ、429 を返し続ける URL は最終的にインデックスから削除されることがあります。緊急時にクロールを減らす方法としては、短期間だけ 429 や 503 を返すことが推奨されていますが、1〜2 日を超えて返し続けるのは推奨されていません。
通常の運用時に、レート制限やボット対策が正規のクローラーに影響しないようにしてください。リダイレクトチェックで 429 が返った場合は、チェック対象がチェッカーにレート制限をかけています。しばらく待ってから、もう一度チェックしてください。
よくある原因と主な用途
- API クライアントが、利用枠やバースト制限を超えた場合。
- ログインフォームが、同じ IP アドレスからの繰り返しの試行をブロックしている場合。
- クローラー、監視ツール、一括チェッカーによって、CDN や WAF のレート制限ルールが発動した場合。
- 多くのユーザーが 1 つの IP アドレスを共有しており（社内ネットワーク、携帯キャリア）、IP アドレスごとの制限にまとめて達した場合。