504 Gateway Timeout（ゲートウェイタイムアウト）

TL;DR — 504 Gateway Timeoutは、Webサイトの手前にあるCDN、ロードバランサー、プロキシなどがサーバーの応答を待ったものの、時間がかかりすぎたため諦めたことを意味します。壊れたレスポンスではなく、タイムアウトです。たまに発生する504は問題ありませんが、繰り返し発生すると検索エンジンのクロール頻度が下がり、最終的にはページが削除されます。

504が実際に意味すること

ページを読み込むとき、リクエストはWebサーバーに直接届かないことがよくあります。通常はまずゲートウェイ（CDN、ロードバランサー、リバースプロキシ）を通ります。ゲートウェイは背後のサーバー（upstreamまたはorigin）にリクエストを転送し、レスポンスを待ってから返します。

504 Gateway Timeoutは、ゲートウェイがupstreamのレスポンスを待ったものの、時間内に受け取れなかったときに返すステータスです。originはデータベースクエリをゆっくり処理しているのかもしれませんし、サードパーティAPIを待っているのかもしれません。単に過負荷になっている可能性もあります。しかしゲートウェイから見れば、待ち時間が尽きたということです。 Evidence for this claim A 504 response means a gateway or proxy did not receive a timely response from an upstream server. Scope: RFC 9110 defines the timeout semantics; it does not determine why the upstream response was delayed. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.6.5 — 504 Gateway Timeout

重要な言葉はタイムアウトです。何かが必ず「壊れていた」わけではありません。レスポンスが十分に速く届かなかっただけです。

5xxの仲間との違い

これらは頻繁に混同されます。

• 502 Bad Gateway — ゲートウェイはoriginからレスポンスを受け取ったものの、その内容が無効または壊れていました。
• 503 Service Unavailable — サーバーが「今は利用できません」と明示的に伝えました（メンテナンス時間のように、意図的なことが多いです）。
• 504 Gateway Timeout — ゲートウェイがupstreamから時間内にレスポンスを受け取りませんでした。「何も返ってこなかった」というより限定された意味です。upstreamは処理を続けているかもしれませんが、待ち時間内には応答しませんでした。

つまり504は、ほぼ常にパフォーマンスの症状です。upstreamの何かが遅すぎます。

504はSEOに悪影響を与えますか？

直接的には与えませんし、ペナルティでもありません。Googleはコンテンツを評価しているのではなく、文字どおりページを取得できないのです。ただし、間接的な実害はあります。

• Googlebotが遅いレスポンスやタイムアウトに遭い続けると、過負荷を悪化させないようクロールを控え、サイトのクロール頻度を下げます。
• トラフィック急増中に1回発生した504は再試行され、ほとんど無視されます。
• 数日にわたり発生し続ける504では、Googleが確実に取得できないため、ページがインデックスから削除されることがあります。 Evidence for this claim Google reduces crawling when server errors or slow responses indicate a site is having trouble responding. Scope: Google's documentation supports automatic crawl throttling for server trouble; it does not attribute a specific 504 to any particular bottleneck. Confidence: high · Verified: 2026-07-14 Google: Troubleshoot crawling errors

対処方法

• 1〜2回リロードしてください。一度だけの504は一時的な異常かもしれません。
• サーバーログとエラーログを確認し、何が遅かったのか（データベースクエリ、外部API、過負荷のアプリプロセスなど）を調べます。
• タイムアウト値を上げて終わりにしないでください。遅いレスポンスを直す代わりに隠してしまいます（Advancedタブで詳しく説明します）。
• サーバーを高速に保ちます。キャッシュ、高速なクエリ、十分な容量が本当の予防策です。

リクエストチェーンのどこで504が発生するのか、Googlebotのクロール抑制がどう働くのか、なぜTTFBを監視すべきなのかを含む、完全な技術版を読みたいですか？Advancedタブに切り替えてください。

TL;DR — 504は、upstreamサーバーがタイムアウト時間内に応答しなかったとゲートウェイ／プロキシが伝えるものです。502（不正なレスポンス）や503（明示的な利用不能）とは異なるタイムアウトです。ペナルティではなく、アクセシビリティの問題です。504は429/500/503と同じグループに入り、Googlebotはこれらを検知するとクロールを控えます。504が続くとインデックス削除のリスクがあります。持続的な解決策は、タイムアウト値を長くすることではなく、サーバーのレスポンスタイム（TTFB）を改善することです。タイムアウトを延ばすと、通常は遅いupstreamを隠し、負荷下では事態を悪化させることがあります。

リクエストチェーンのどこで504が発生するか

現代のリクエスト経路は、おおむねブラウザ → CDN/エッジ → ロードバランサー → リバースプロキシ（例：Nginx） → アプリサーバー（PHP-FPM、Nodeなど） → データベース／サードパーティAPIです。タイムアウトが切れたとき、背後のコンポーネントを待っていたコンポーネントが504を生成します。最初に確認すべき診断上の問いはこれです。 Evidence for this claim A 504 response means a gateway or proxy did not receive a timely response from an upstream server. Scope: RFC 9110 defines the timeout semantics; it does not determine why the upstream response was delayed. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.6.5 — 504 Gateway Timeout

• CDN/エッジがoriginでタイムアウト → originのパフォーマンスを改善するか、CDNのupstreamタイムアウトを慎重に引き上げます（後述）。
• ロードバランサーがアプリサーバーでタイムアウト → アプリサーバーの状態とオートスケーリングを確認します。
• リバースプロキシがアプリプロセスでタイムアウト → Nginxのproxy_read_timeout／fastcgi_read_timeoutと、その背後にある遅いクエリまたはプロセスを確認します。

レイヤーを正しく特定することが重要です。「エッジのタイムアウトを直す」のと「originの遅いデータベースクエリを直す」のは、まったく別の作業だからです。

504の原因

ステータスコードだけでは原因は証明できません。分かるのは、ゲートウェイがupstreamを待ってタイムアウトしたということだけです。以下は確認すべき典型的な候補であり、504がすでに証明した事実ではありません。どれかに対応する前に、ログとトレースで確認してください。

• 遅いデータベースクエリまたはupstream API呼び出し。 インデックスのないクエリ1つや、応答の遅いサードパーティ依存先によって、レスポンスタイムがタイムアウトを超えることがあります。
• サーバー／アプリの過負荷とリソース枯渇。 十分な同時負荷がかかると、リクエストが待ち行列に並び、ワーカープロセスが埋まり、レスポンスが時間内に届かなくなります。
• タイムアウト値の設定ミス。 Nginx、Apache、ロードバランサー、CDNの各レイヤーで値が一致せず、別のレイヤーより先に1つが諦めることがあります。
• トラフィック急増、ボットの大量アクセス、DDoS。 一時的に処理能力を圧迫します。

504は断続的で負荷に依存することが多い

これが504を厄介にします。完全な停止とは異なり、504は負荷がかかっているときだけ発生することがよくあります。そのため、静かな時間帯に稼働監視が実行されると100%正常に見える一方、より大きなバーストでクロールするGooglebotはひそかにタイムアウトを収集している可能性があります。Google Search ConsoleのURL検査では、明確で継続的なエラーではなく、**「Hostload exceeded」**という状態として表示されることがあります。監視は問題ないのにクロールの統計情報が異なる場合、負荷依存の504が有力な容疑です。

Googlebot（およびBingbot）はタイムアウトをどう扱うか

Googleは504をコンテンツ品質の判断として扱いません。利用可能性のシグナルとして扱い、応答は自動的なスロットリングになります。クロールに関するドキュメントには、次のように明記されています。 “Googlebot will scale back its crawling if it detects that your servers are having trouble responding to crawl requests.” (翻訳)「サーバーがクロールリクエストへの応答に問題を抱えていると検知すると、Googlebotはクロールを縮小します。」大規模サイト向けのクロールバジェットガイドも、予算の観点から同じことを述べています。 “If the site slows down or responds with server errors, the limit goes down and Google crawls less.” (翻訳)「サイトの速度が落ちたりサーバーエラーで応答したりすると、上限が下がり、Googleのクロール量も減ります。」 Evidence for this claim Google reduces crawling when server errors or slow responses indicate a site is having trouble responding. Scope: Google's documentation supports automatic crawl throttling for server trouble; it does not attribute a specific 504 to any particular bottleneck. Confidence: high · Verified: 2026-07-14 Google: Troubleshoot crawling errors

遅いレスポンスやタイムアウトするレスポンスに直接結び付けた最新の説明は、Googleの2026年3月のInside Googlebot解説です。そこではGary Illyesが次のように述べたと引用されています。 “If your server is struggling to serve bytes, our crawlers will automatically back off to avoid overloading your infrastructure, which will drop your crawl frequency.” (翻訳)「サーバーがバイトの配信に苦労している場合、クローラーはインフラへの過負荷を避けるため自動的に速度を落とし、その結果クロール頻度が下がります。」（Search Engine Landの報道によるものです。他所で引用するなら、元の録音または文字起こしで確認する価値があります。）504は、その苦闘が目に見える形になったものです。

理解しておきたい注意点があります。Googleはブラウザと同じように、常に文字どおりの「504」を確認できるとは限りません。Googlebotがステータス行をまったく受け取る前にタイムアウトすると、クロールの統計情報では明確な5XXではなくタイムアウト／ネットワークエラーとして記録されます。一方、中間プロキシやCDNがタイムアウトして独自の504レスポンスを生成すると、Googlebotは標準的な5XXサーバーエラーを受け取ります。どちらの場合も効果は同じで、クロールレートが抑制され、続けばインデックスから削除されます。

Bingはタイムアウトをサーバーエラーとは別のクロールエラー分類として記録します。レスポンスが遅すぎるとBingbotはページへのアクセスを試みなくなり、継続的な推奨事項として、サーバーレスポンスタイムの確認、サーバーソフトウェアの更新、遅いリソースの最適化、単発の異常ではなく体系的なパターンを確認するためのサーバーログの参照を挙げています。BingはGoogleと同じレベルのスロットリング後の回復の詳細を公開していないため、意図はおおむね似ていると考えてください。挙動が同一だと確認されたわけではありません。

スロットリングしてから回復するフィードバックループ

安心できる点は、このループが自動的に自己修正することです。Googleはエラーやタイムアウトを検知するとクロールを抑え、レスポンスが健全になると徐々にクロールを再び増やします。根本原因を直した後に手動で押す「スロットリング解除」ボタンはありません。John Muellerも次のように述べています。 “Once things settle down on the server, the crawl rate will return to normal automatically.” (翻訳)「サーバーの状態が落ち着けば、クロールレートは自動的に通常へ戻ります。」同氏は非対称性も指摘しています。問題にすぐ対処するため、下げるスロットリングは速く行われますが、再び増やすときは慎重です。

一時的な異常がインデックス問題に変わるのは継続期間

短時間で解消した、急増時の数回の504のような短く一時的な504は、再試行され、大部分が許容されます。インデックス削除のリスクになるのは、長い期間にわたる継続的なタイムアウトのパターンです。過負荷時に意図的に503または429を返す「後で戻ってきてください」という仕組みについて、Googleの文書はURLが削除され始めるまでのおおよその2日という時間軸を示しています。ただし、この具体的な数字が文書化されているのは503/429であり、504ではありません。Googleのより一般的な5xxガイダンスでは、クロールレートはエラーになるURLの数に比例して下がり、レスポンスが健全になると徐々に回復するとされていますが、504について固定された期間は示されていません。2日という数字を504に拡張するのは合理的な推論であって、文書化された事実ではありません。短い504は乗り越えられますが、数日続くパターンは心配すべき範囲であり、発生日を保証するトリガーではない、と考えてください。

大規模サイトやECサイトで重要性が増す理由

公開した当日にページがクロールされる小規模サイトなら、ほとんど気づかないでしょう。しかし大規模または頻繁に変化するサイト（大きなECカタログ、ニュース、マーケットプレイス）では、クロールバジェットがすでに制約となっています。ピーク負荷中の504の波は、本当に再クロールが必要なページのクロールを圧迫する可能性があります。規模が大きくなると、タイムアウトとクロールバジェットは同じ話です。

サーバーレスポンスタイムとTTFBは強力な予防策 — origin側の原因に対して

多くの504記事が見落としている点があります。エラーが現れてからログをgrepするのは事後対応です。サーバーレスポンスタイムを継続的に監視し、タイムアウトへ転じる前の変化を捉えるのが予防対応です。今日、遅いがまだタイムアウトしていないサーバーは、少し負荷が増えるか依存先が少し遅くなるだけで、明日は504を生成するサーバーになります。**TTFB（time to first byte）**を事後検証の指標だけでなく継続的な早期警告シグナルとして監視することで、その変化を捉えられます。

ただし、TTFBの監視が対象にするのはorigin側の遅さです。正常なoriginに対するCDNのタイムアウト、早く諦めるよう誤設定されたロードバランサー、ホップ間のネットワーク経路の問題は検知できません。まず、どのホップが発生させたのかを特定する必要があります（上の「リクエストチェーンのどこで504が発生するか」、または下の意思決定ツリーを参照）。TTFBは、本当に遅いupstreamという一般的なケースには現実的で持続的な解決策ですが、万能ではありません。originがボトルネックだと確認したら、ページ・オブジェクト・CDNのキャッシュ、より速いデータベースクエリと適切なインデックス、負荷に応じたオートスケーリング、妥当なCDN upstream設定で最適化します。

「タイムアウトを単に引き上げる」が間違った直感である理由

proxy_read_timeoutやCDNのupstreamタイムアウトを引き上げると、504が表示されなくなることはあります。しかし、upstreamのレスポンスが速くなるわけではありません。さらに負荷下で待ち時間を長くすると、リクエストが積み上がり、ワーカープロセスと接続をより長く占有するため、過負荷の悪循環を改善するどころか悪化させる可能性があります。タイムアウトの延長が正しい場合もあります（本当に長時間かかることが分かっている処理など）が、反射的に行うと本当の問題を隠します。

停止が計画済みであるか、意図的に負荷を減らしている場合、正しい手段はページを504に任せることではありません。503（Retry-Afterヘッダー付き）を返し、検索エンジンに雑なタイムアウトではなく、明確で意図的な「後で戻ってきてください」を伝えます。

実際に504を診断する

原因を推測する前に、発生させたホップを特定してください。それが本当の問題を直すのか、症状を直すのかの分かれ目です。

• 再現し、どのホップが応答したかを特定する。 ブラウザで読み込み、curlでアクセスしてTTFBのtime_starttransferを確認します。Ahrefs Site AuditやScreaming Frogなどのクローラーに通し、サイト全体か一部だけかを確認します。可能ならCDN／プロキシを迂回してoriginへ直接テストし、origin自体が完了するかを確認します。
• ログを読む。 サーバーとプロキシのログから、どのレイヤーが、何を待ってタイムアウトしたのか（遅いクエリ、停止したupstream、枯渇したワーカープールなど）を確認できます。推測せず、タイムスタンプとリクエストIDでレイヤー間を照合します。
• Search Consoleを確認する。 クロールの統計情報にはレスポンスコードの急増と平均レスポンスタイムが表示されます。ページのインデックス登録レポートとURL検査では、Googleがタイムアウト（「Hostload exceeded」を含む）に遭っているかを確認できます。

ツール間の結果を突き合わせることも重要です。ブラウザの504、Ahrefs Site Auditの5xx、GSCのタイムアウトは、異なる視点から見た同じ遅いoriginを示している可能性があります。3つのツールが3つの問題を意味すると考えないでください。

関連するコード

504は小さなファミリーの一員です。500は、より具体的なコードがない一般的なサーバーエラーです。502は不正または壊れたupstreamレスポンスです。503は、明示的で、多くの場合意図的な「利用不可」です。実際にどれを返しているかを把握し、計画停止中に正しいものを意図して返すことが、問題解決の半分です。

AIによる要約

Advanced版の要点をまとめます。

• 504は壊れたレスポンスではなく、タイムアウトです。 ゲートウェイ／プロキシ（CDN、ロードバランサー、リバースプロキシ）がupstreamサーバーを待ったものの、時間内にレスポンスを受け取らなかったという意味で、「永遠にレスポンスがない」とは限りません。502（不正なレスポンス）や503（明示的な利用不能）とは異なります。ステータスコードだけでは、どのホップまたは原因かは分かりません。修正する前に、発生させたホップを特定してください。
• ペナルティではありません。 アクセシビリティの問題です。Googleがページを取得できないため、ランキングやインデックスの損失は罰ではなく、アクセス不能の結果として起こります。
• タイムアウトはクロール抑制を引き起こします。 Googleは「サーバーがクロールリクエストへの応答に問題を抱えていると検知すると、Googlebotはクロールを縮小します」と説明しています。Gary Illyesも、Search Engine Landの2026年3月の報道を通じて、サーバーが苦労するとフェッチャーが「自動的に速度を落とし、クロール頻度が下がる」と述べたと引用されています。
• 期間は重要ですが、「2日」はGoogleが504について文書化した数字ではありません。 この時間軸が文書化されているのは、過負荷時に意図的に返す503/429です。Googleの一般的な5xxガイダンスは、クロールレートが比例して下がり、徐々に回復すると述べていますが、504について固定の期間は示していません。単発の504は再試行され許容されますが、長期にわたる継続的なパターンはインデックス削除のリスクになります。
• ループは自己修正します。 レスポンスが回復すればクロールレートも自動的に戻り、手動のスロットリング解除は必要ありません。
• 断続的／負荷依存であることが多いです。 静かな時間帯に実行する稼働監視では見えず、URL検査では「Hostload exceeded」と表示されることがあります。
• サーバーレスポンスタイム（TTFB）はorigin側の原因に対する強力な予防策です。 早期警告シグナルとして監視しますが、万能ではありません。504はCDN、ロードバランサー、プロキシ層でも発生するため、まずどのホップがタイムアウトしたかを確認してください。タイムアウト値を上げても解決にはならず、遅いupstreamを隠し、過負荷を悪化させる可能性があります。
• 停止が計画済みなら、504ではなくRetry-After付きの503を返します。

公式ドキュメント

タイムアウト、サーバーエラー、クローラーの応答に関する一次資料です。

定義

• MDN — 504 Gateway Timeout — 権威ある定義と502との違い。

Google

• クロールエラーのトラブルシューティング — Googlebotがサーバーの問題でクロールを縮小する仕組みと、過負荷時に503/429を返すタイミング。
• クロールバジェットを最適化する — 遅いレスポンスやサーバーエラーがクロール上限を下げる仕組み。
• クロールの統計情報レポート — 「Server error (5XX)」と「Page timeout」の分類、およびGooglebotが過負荷を避けるためにスロットリングする仕組み。

Bing／Microsoft

• Bing Webmaster Tools — クロールエラーのアラート — Bingがサーバーエラーとタイムアウトを別々のクロールエラー分類として検出する仕組み。

ソースからの引用

記録に残る発言です。各リンクはソースページ上の引用箇所へ移動するディープリンクです。

MDN — 定義

• “The HTTP 504 Gateway Timeout server error response status code indicates that the server, while acting as a gateway or proxy, did not get a response in time from the upstream server in order to complete the request. This is similar to a 502 Bad Gateway, except that in a 504 status, the proxy or gateway did not receive any HTTP response from the origin within a certain time.” (翻訳)「HTTP 504 Gateway Timeoutサーバーエラーレスポンスステータスコードは、ゲートウェイまたはプロキシとして動作するサーバーが、リクエストを完了するためにupstreamサーバーから時間内にレスポンスを受け取らなかったことを示します。502 Bad Gatewayと似ていますが、504ステータスでは、プロキシまたはゲートウェイが一定時間内にoriginからHTTPレスポンスをまったく受け取らなかった点が異なります。」 Jump to quote

Google — クロールとタイムアウト

• “Googlebot will scale back its crawling if it detects that your servers are having trouble responding to crawl requests.” (翻訳)「サーバーがクロールリクエストへの応答に問題を抱えていると検知すると、Googlebotはクロールを縮小します。」 — Google Search Central、クロールエラーのトラブルシューティング。 Jump to quote
• “If the site slows down or responds with server errors, the limit goes down and Google crawls less.” (翻訳)「サイトの速度が落ちたりサーバーエラーで応答したりすると、上限が下がり、Googleのクロール量も減ります。」 — Google Search Central、クロールバジェットを最適化する。 Jump to quote

Gary Illyes、Google

• “If your server is struggling to serve bytes, our crawlers will automatically back off to avoid overloading your infrastructure, which will drop your crawl frequency.” (翻訳)「サーバーがバイトの配信に苦労している場合、クローラーはインフラへの過負荷を避けるため自動的に速度を落とし、その結果クロール頻度が下がります。」 Jump to quote

John Mueller、Google (Reddit上、Search Engine Journalが2025年8月に報道)

• “I’d only expect the crawl rate to react that quickly if they were returning 429 / 500 / 503 / timeouts.” (翻訳)「429／500／503／タイムアウトを返している場合に限り、クロールレートがこれほど速く反応すると考えます。」 Jump to quote Search Engine JournalはMuellerのReddit上の回答と、その周辺の文脈を再掲しています。

サーバーレスポンスタイム／TTFBチェックリスト

目的は、504が発生しない程度にレスポンスを速く保ち、発生する前に変化を捉えることです。上から順に進めてください。

• TTFBのベースラインを測定する。curl -w "%{time_starttransfer}"（または合成監視）を使い、テンプレートごとの「通常」を記録する。
• TTFBを継続的に監視する。インシデント後だけでなく、完全な失敗だけではなく上昇傾向にもアラートを設定する。
• 負荷テストを現実的な同時実行数（およびピーク時）で行う。504は通常負荷に依存するため、静かな時間帯の確認では見つかりません。
• 最も遅いupstream処理をプロファイルする。インデックスのないデータベースクエリ、N+1クエリ、ブロッキングするサードパーティAPI呼び出しが典型的な原因です。
• 積極的にキャッシュする。ページキャッシュ、オブジェクトキャッシュ、CDNエッジキャッシュを使い、ほとんどのリクエストが遅い経路に触れないようにする。
• レイヤー間でタイムアウト値が一貫しているか確認する。CDN、ロードバランサー、Nginxのproxy_read_timeout／fastcgi_read_timeout、アプリで、1つのレイヤーが他より先に諦めないようにする。
• トラフィックとクロールの急増に対するオートスケーリング／容量の余裕を確認する。
• GSCのクロールの統計情報で、タイムアウトと5XXの急増、平均レスポンスタイムの上昇を確認する。
• サーバーとプロキシのログを確認し、どのレイヤーが何を待ってタイムアウトしたかを特定する。
• 稼働監視がピーク負荷を対象にしていることを確認する。営業時間外のpingだけにしない。
• 計画停止には503 + Retry-Afterを使う。 ページを504に任せない。

避けるべき504の神話と間違い

最も頻繁に出てくる落とし穴です。いくつかは広く繰り返されている神話なので、修正しておきます。

• 「504はGoogleのペナルティだ」 いいえ。アルゴリズム上の措置ではなく、アクセシビリティ／クロール可能性の問題です。Googleはコンテンツを評価しているのではなく、ページを取得できません。ランキングの損失があっても、罰ではなくアクセス不能の結果です。
• 「どんな504でもページは即座にインデックス削除される」 いいえ。短く一時的な504は再試行され、許容されます。リスクがあるのは、長期間にわたり継続的かつ頻繁に発生する504です。
• 「504と503はほぼ同じなので、相互に使える」 いいえ。503は意図的で制御されたシグナルになれ（Googleは計画停止での503を明示的にサポートしています）、504はタイムアウトで、ほぼ常に計画外で遅いupstreamの症状です。計画停止中はRetry-After付きの503を返し、ページを504にしないでください。
• 「Googlebotが積極的すぎる」 通常は逆です。Googlebotのクロールレートで確実に504を返すサーバーは、同様の負荷で実ユーザーにも悪影響を与えます。タイムアウトは本当の容量／パフォーマンス問題を露呈させています（「Hostload exceeded」の状況はありますが、例外であって通常ではありません）。
• 「直すにはタイムアウト値を上げればよい」 proxy_read_timeoutを上げても、遅いupstreamを直すのではなく隠すだけです。負荷下で長いタイムアウトを設定するとワーカープロセスをより長く占有し、過負荷を悪化させる可能性があります。遅いレスポンスを直し、待つ時間だけを延ばさないでください。
• 「稼働監視が正常なので504問題はない」 504は負荷に依存することが多いです。静かな時間帯の監視では、Googlebotが重いクロールバースト中に集めるタイムアウトを見逃すことがあります。営業時間外のpingより、クロールの統計情報とログを信頼してください。

どのレイヤーがタイムアウトしているか？

504インシデントのバッチを分類するプロンプト

URL、タイムスタンプ、レスポンスヘッダー、TTFBまたは合計時間、公開エッジの結果、originへの直接アクセス結果、アプリケーショントレース、データベースの処理時間、リソースのシグナルを含む、サニタイズ済みの行を貼り付けます。認証情報、Cookie、プライベートアドレス、ユーザーデータは貼り付けないでください。

You are triaging HTTP 504 Gateway Timeout incidents. Classify each row into one of:
slow application or query, upstream dependency timeout, resource exhaustion,
gateway/origin timeout mismatch, CDN or network path, intermittent with insufficient
evidence, or not actually a 504.

For each row:
- quote the supplied evidence behind the classification;
- identify the missing observation that would most change the conclusion;
- separate response latency from the gateway's configured timeout;
- do not recommend increasing a timeout unless the evidence shows healthy work that
  legitimately needs longer;
- group rows sharing timestamps, routes, upstreams, or resource spikes.

Return a table with URL, likely cause, confidence, evidence, next diagnostic, and
incident group. Then list the first three engineering checks for the highest-impact
group. Do not invent thresholds or monitoring data.

DATA:
[PASTE SANITIZED INCIDENT DATA HERE]

結果は仮説のキューとして扱います。ゲートウェイ、アプリケーション、データベース、インフラストラクチャのテレメトリーで確認してください。

ステータスとTime to First Byteを測定する

macOS/Linuxのシェルで実行します。本文を表示せず、単一リクエストの最終レスポンスコードとTTFBを報告します。

curl -sS -o /dev/null \
  -w 'status=%{http_code} ttfb=%{time_starttransfer}s total=%{time_total}s\n' \
  https://www.example.com/slow-path

タイムアウトが一貫しているのか、負荷に依存しているのかを確認するため、数回繰り返します。

for i in {1..5}; do
  curl -sS -o /dev/null \
    -w 'status=%{http_code} ttfb=%{time_starttransfer}s total=%{time_total}s\n' \
    https://www.example.com/slow-path
done

PowerShellの場合：

1..5 | ForEach-Object {
  $watch = [System.Diagnostics.Stopwatch]::StartNew()
  try {
    $response = Invoke-WebRequest -Uri 'https://www.example.com/slow-path' -SkipHttpErrorCheck
    $watch.Stop()
    [pscustomobject]@{ Attempt = $_; Status = $response.StatusCode; TotalMs = $watch.ElapsedMilliseconds }
  } catch {
    $watch.Stop()
    [pscustomobject]@{ Attempt = $_; Status = 'request-failed'; TotalMs = $watch.ElapsedMilliseconds }
  }
}

PowerShell版はリクエスト全体の時間を測定し、TTFBは測定しません。最初のバイトまでの内訳が必要な場合は、シェルコマンドまたはアプリケーションのテレメトリーを使ってください。

504を再現して範囲を絞るためのツール

• Website Down Checker — 外部の視点から到達可能性をテストし、レスポンスタイム、リダイレクト、限定的なDNSの証拠を取得します。インシデントが公開環境で再現するかを確認するために使います。
• Bulk HTTP Status Code Checker — 代表的なルートの集合を確認し、レイテンシを比較して、失敗したサブセットをエクスポートします。1つの遅いエンドポイントと、サイト全体のupstream問題を切り分けるのに役立ちます。
• CDN／ロードバランサーのログ — 504を返したゲートウェイを特定し、そのリクエストIDとタイムアウトをupstreamの試行と照合します。
• アプリケーショントレースとデータベースのスロークエリログ — originに到達した後、リクエストがどこで時間を使ったかを示します。
• インフラストラクチャの監視 — ステータスコードから推測せず、インシデントの時間帯をCPU、メモリ、ワーカープール、接続、依存先の飽和状態と比較します。

ルート別・パーセンタイル別のTTFB

指標： 平均だけでなく、意味のあるパーセンタイルに分けた代表的なルートのTime to First Byte。

何が分かるか： テールレイテンシの上昇は、504が返り始める前にリクエストがゲートウェイタイムアウトへ近づいていることを示す早期警告です。

取得方法： 実ユーザー／サーバー監視またはゲートウェイログを使います。Scriptsタブのcurlスクリプトはスポットチェックに使い、本番テレメトリーの代わりにはしません。

ベンチマーク／現実的な範囲： ルートごと、インフラストラクチャ経路ごとにベースラインを設定します。意味のあるアラートは、そのベースラインから継続的に変化したこと、または実際に設定したゲートウェイタイムアウトへ近づいたことであり、SEOに共通する普遍的な数値ではありません。

頻度： 継続的に監視し、ルートレベルの傾向を毎週、および504インシデントのたびに確認します。

504レスポンス率

指標： 504を返したリクエスト数を全リクエスト数で割った値。利用できる場合は、ルート、ゲートウェイ、origin、クローラー／ユーザーエージェントの種類で分けます。

何が分かるか： タイムアウトが単発なのか、1つの経路に集中しているのか、クロールとユーザーに影響するほど広範囲なのかが分かります。

取得方法： CDN、ロードバランサー、またはサーバーのアクセスログをステータスコードとリクエストの属性で集計します。

ベンチマーク／現実的な範囲： 健全な目標は、説明できない504がないことです。アラートの感度には、自分の通常のインシデントなしのベースラインを使ってください。トラフィックの構成と再試行の挙動はスタックごとに異なります。

頻度： 継続的にアラートを出し、回復中は毎日、通常の信頼性レポートでは毎週確認します。

upstreamの完了時間とゲートウェイタイムアウト

指標： upstreamの完了時間の分布を、各ホップに設定されたタイムアウトと比較したもの。

何が分かるか： 遅い処理が本当に上限へ近づいているのか、それとも短すぎるゲートウェイタイムアウトが本来健全なupstreamレスポンスを打ち切っているのかが分かります。

取得方法： リクエストIDまたはトレースIDを使い、ゲートウェイのタイミング情報をアプリケーショントレースと結合します。

ベンチマーク／現実的な範囲： 通常の完了時間を設定上限より十分内側に保ち、想定される変動の余地を残します。その余地は観測した本番分布から定義し、汎用的な割合を発明しないでください。

頻度： 設定または依存先を変更した後、またテールレイテンシや504率が上昇したときに確認します。

自分で確認する：504 Gateway Timeout

504の意味とクロールへの影響についての簡単な5問です。それぞれ回答を選んでから、答えを確認してください。

時間を使う価値のあるリソース

私の関連著作

• テクニカルSEO入門ガイド — サーバーの健全性とクロール可能性が全体像のどこに位置するかを説明します。
• 新しいウェブクローラー：AIボットが検索エンジンボットに迫る — 実際にサーバーへアクセスしているのは誰か、そして負荷がなぜ重要かを説明します。

私の講演

• How Search Works （SlideShare）— クロール、レンダリング、インデックス登録、ランキングについての解説です。サーバーレスポンスがクロールレートを左右する仕組みも含みます。（恒例の免責事項が適用されます。「これはシステムについての私の理解であり…100%完全または正確ではありません。」）

業界の資料

• MDN — 504 Gateway Timeout — 標準的な定義と502との違い。
• Google — クロールエラーのトラブルシューティング — Googlebotがサーバーの問題でクロールを縮小する仕組み。
• Google — 大規模サイトのクロールバジェット管理 — 遅いレスポンスがクロール上限を下げる仕組み。
• Google explains how crawling works in 2026 （Search Engine Land）— サーバーが苦戦するとクロール頻度が下がるというIllyesの引用。
• Googlebot Crawl Slump? Mueller Points To Server Errors （Search Engine Journal）— クロールレートを急速に下げるエラーとしてMuellerがタイムアウトと429/500/503をまとめている記事。
• 504ゲートウェイタイムアウトエラーの修正方法 （Kinsta）— リクエストチェーンとログ診断を扱う、ホスト側の技術的な解説。

動画

• Google Search Central（YouTube）— How Google Search WorksシリーズとMartin Splittのクロール解説は、サーバーレスポンスとクロールレートの関係を理解するのに役立ちます。チャンネル

変更履歴