SSD Nodes Learn Hosting plans →
ガイド Matt Connor著者 Matt Connor

Search Consoleの「サーバーエラー（5xx）」をVPSのログで突き止めて直す

Search Consoleに「サーバーエラー（5xx）」が出たら、VPSのアクセスログでGooglebotが実際に受け取った応答を確かめます。本物のGooglebotの見分け方と、レート制限、fail2ban、PHP-FPM、OOM、デプロイ時の再起動という自分で招きやすい原因を順に調べます。

Search Console の「サーバーエラー（5xx）」は何を意味するか

Search Console の「サーバーエラー（5xx）」は、Googlebot がその URL を取りに来たとき、あなたのサーバーが 500 番台のステータスコードを返したという記録です。VPS（仮想専用サーバー）なら、そのリクエストはあなたのアクセスログに残っています。Google が実際に何を受け取ったかを、推測ではなくログで確かめられます。

共用サーバーでは、このログが見られないことがよくあります。VPS ではすべてが手元にあります。そして原因の多くは、Google 側ではなく自分の設定の中にあります。レート制限、fail2ban、AI クローラー向けのブロック、PHP-FPM のワーカー不足、メモリ不足による強制終了、デプロイ時の再起動です。以下、Google の説明、レポートの読み方、ログとの突き合わせ、原因ごとの確認方法の順に進めます。

Google は 5xx をどう扱うと書いているか

Google 検索セントラルの HTTP エラーとネットワークエラーに関するドキュメント（2026年10月2日に確認）には、次のように書かれています。

5xx および 429 のサーバーエラーは、Google のクローラに対して一時的にクロールのペースを落とすように促します。
Google 検索の場合、すでにインデックスに登録されている URL はインデックスに保持されますが、最終的には削除されます。
Google 検索の場合、Google のインデックス登録パイプラインは、繰り返してサーバーエラーを返す URL をインデックスから削除します。

何日続くと削除されるのか、何回で「繰り返して」になるのかは、このドキュメントには書かれていません。ネット上で見かける日数は Google の公式な数字ではないので、それを前提に計画しないでください。分かっているのは二つです。エラーが続けばクロールが遅くなること、そしてエラーが続く URL はいずれインデックスから消えることです。

英語版には、クロール速度の低下は、サーバーエラーを返す個別の URL の数に比例する、とも書かれています。エラーを返す URL が多いほど、サイト全体のクロールが遅くなります。新しい記事が検索に出るまでの時間も延びます。

同じドキュメントは、429（Too Many Requests）をサーバーが過負荷だという合図として扱い、サーバーエラーに数えると書いています。そのため「503 ではなく 429 を返せば安全」という考えは成り立ちません。

レポートのどこを見ればよいか

Search Console の左メニューで「インデックス作成」の「ページ」を開きます。これが「ページのインデックス登録」レポートです。下にある「ページがインデックスに登録されなかった理由」の表に、「サーバーエラー（5xx）」の行があります。行をクリックすると、該当する URL の例と、それぞれを最後にクロールした日付が並びます。

この日付が次の作業の手がかりです。ログのどの範囲を探すかが、これで決まります。レポートはリアルタイムではないため、表示された時点ではすでに直っていることもよくあります。

合わせて、次の二つの画面も見ます。

  • 「URL 検査」: URL を一つ入力し、「公開 URL をテスト」を押すと、Google がいまその URL を取得できるかを試せます。いま正常に取得できるなら、問題は過去に起きた一時的なものです。
  • 「設定」の「クロールの統計情報」: 「ホストのステータス」に「robots.txt の取得」「DNS の解決」「サーバー接続」が並びます。レスポンス別の内訳には「サーバーエラー（5XX）」があります。サイト全体で、いつ、どれだけ失敗したかが分かります。

Google のヘルプは、この項目の対処として、サーバーの処理能力の確認や、ファイアウォールや DDoS（分散型サービス妨害）対策が Googlebot を誤って止めていないかの確認を挙げています。VPS では、そのどれもが自分で確認できます。

アクセスログで Googlebot が受け取った応答を確かめる

Ubuntu 24.04 の nginx は、標準の combined 形式で /var/log/nginx/access.log に記録します。この形式では、空白で区切った 9 番目の項目がステータスコードです。古いログは logrotate によって access.log.1 や access.log.2.gz に移され、圧縮されます。zgrep は圧縮済みのファイルも普通のファイルもそのまま読めるので、まとめて検索できます。

まず、Googlebot を名乗るリクエストがどのステータスを受け取ったかを数えます。

sudo zgrep -h 'Googlebot' /var/log/nginx/access.log* |
  awk '{print $9}' | sort | uniq -c | sort -rn

500 番台が含まれていれば、その行を見ます。表示するのは IP アドレス、時刻、パス、ステータスです。

sudo zgrep -h 'Googlebot' /var/log/nginx/access.log* |
  awk '$9 ~ /^5/ {print $1, $4, $7, $9}'

Search Console に出ていた URL を一つずつ確かめるときは、パスで絞ります。/blog/example-post/ は、あなたの URL のパス部分に置き換えてください。

sudo zgrep -h '"GET /blog/example-post/ ' /var/log/nginx/access.log*

時刻を比べるときは注意が必要です。多くの VPS イメージはタイムゾーンが UTC（協定世界時）なので、ログの時刻は日本時間より 9 時間遅れて見えます。サーバーの設定は timedatectl で確認できます。

結果は、おおむね次の四つのどれかになります。

  • 5xx が記録されている。 nginx か、その奥のアプリケーションがエラーを返しました。同じ時刻の /var/log/nginx/error.log を見ます。
  • 同じ URL に、後の日付で 200 が記録されている。 エラーは一時的なものでした。原因は残っているかもしれないので、エラーの時刻を手がかりに以下の節を確認します。
  • その時刻の行が一つもない。 リクエストが nginx まで届いていません。ファイアウォールや fail2ban が接続を落としているか、ログの保存期間より前の出来事です。
  • CDN（コンテンツ配信ネットワーク）を前に置いている。 Googlebot が話している相手は CDN です。CDN がオリジンサーバーに接続できずに返したエラーは、あなたのアクセスログには残りません。CDN 側のログを確認してください。

nginx 自身がエラーの理由を書くのは error.log です。上流（PHP-FPM やアプリケーション）との通信の失敗と、レート制限の発動を一度に拾います。

sudo grep -E 'upstream|limiting requests' /var/log/nginx/error.log

ログの検索はここまでです。以下の節では、見つかった行が何を意味するかを原因ごとに説明します。

そのアクセスは本物の Googlebot か

ユーザーエージェント（UA、リクエストが名乗るクライアント名）は誰でも自由に書けます。Googlebot を名乗るリクエストが、実際には別のスクレイパーであることは珍しくありません。Search Console に出るのは Google 自身のクロールの結果だけなので、偽物が受け取った 5xx はこのレポートと関係がありません。逆に、本物の Googlebot の IP アドレスを fail2ban が遮断しているなら、それは直すべき問題です。

Google のドキュメントは、DNS を使った確認手順を示しています。まず、ログにある IP アドレスから名前を引きます。これを逆引きといいます。

host 66.249.66.1

返ってきた名前が googlebot.com、google.com、googleusercontent.com のどれかで終わることを確認します。通常の Googlebot なら、crawl-***-***-***-***.googlebot.com という形の名前になります。次に、逆引きで得た名前から IP アドレスを引きます。これを正引きといいます。

host crawl-66-249-66-1.googlebot.com

正引きの結果が、ログにあった元の IP アドレスと同じなら本物です。逆引きだけでは足りません。逆引きの名前は IP アドレスの持ち主が自由に設定できるので、名前から同じ IP アドレスに戻ることまで確かめる必要があります。host: command not found と出るなら、sudo apt install bind9-host で入ります。

Google はクローラーの IP アドレス範囲も JSON で公開しています。通常の Googlebot の範囲は common-crawlers.json です。次のコマンドは、その JSON を取得し、指定した IP アドレスが範囲に入るかを表示します。Python 3 は Ubuntu 24.04 に最初から入っています。

python3 - 66.249.66.1 <<'EOF'
import ipaddress, json, sys, urllib.request
url = 'https://developers.google.com/static/crawling/ipranges/common-crawlers.json'
data = json.load(urllib.request.urlopen(url))
ip = ipaddress.ip_address(sys.argv[1])
nets = [ipaddress.ip_network(p.get('ipv4Prefix') or p.get('ipv6Prefix')) for p in data['prefixes']]
print('in common-crawlers.json' if any(ip in n for n in nets) else 'NOT in common-crawlers.json')
EOF

範囲は変わることがあります。そのため、ファイアウォールの設定に固定で書き写すより、確認のたびに取得する方が安全です。

レート制限が Googlebot に 503 を返していないか

nginx の limit_req は、制限を超えたリクエストに 503 を返します。limit_req_status の初期値が 503 だからです。Googlebot は短い時間に多くの URL を取りに来ることがあります。そのため、人間の閲覧を想定した厳しい制限にかかりやすくなります。

発動すると、error.log に次のような行が残ります。

limiting requests, excess: 20.500 by zone "perip", client: 66.249.66.1, server: example.com, request: "GET /blog/ HTTP/1.1"

client の IP アドレスが本物の Googlebot なら、これが 5xx の原因です。対処は、制限をサイト全体ではなく、ログインページのように負荷が高く攻撃されやすいパスにだけかけることです。

# http ブロック
limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s;

# server ブロック: サイト全体ではなく、ログインだけに制限をかける
location = /wp-login.php {
    limit_req zone=perip burst=10 nodelay;
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
}

limit_req_status 429; に変えても解決しません。前の節のとおり、Google は 429 もサーバーエラーとして扱うためです。設定を変えたら、構文を確認してから読み込み直します。

sudo nginx -t && sudo systemctl reload nginx

nginx -t が syntax is ok と test is successful を表示した場合だけ、reload が実行されます。

fail2ban や WAF が Googlebot を締め出していないか

fail2ban は、ログの中の失敗パターンを数え、しきい値を超えた IP アドレスをファイアウォールで遮断します。SSH だけを守っているなら、Googlebot には関係ありません。nginx のログを読むジェイル（jail、fail2ban の監視ルールの単位）を有効にしていると、事情が変わります。たとえば nginx-limit-req ジェイルは、前の節の limiting requests の行を数えて IP アドレスを遮断します。レート制限で 503 を受け取った Googlebot が、次は接続そのものを拒否されるわけです。

遮断されたリクエストは nginx に届きません。そのため、アクセスログには何も残りません。fail2ban 側のログを見ます。

sudo fail2ban-client status
sudo zgrep -h ' Ban ' /var/log/fail2ban.log*

Ban の後ろの IP アドレスを、前の節の方法で一つずつ確かめます。本物の Googlebot なら、まず解除します。

sudo fail2ban-client set nginx-limit-req unbanip 66.249.66.1

解除だけでは、同じことがまた起きます。直すべきはジェイルのしきい値か、ジェイルが数えているレート制限そのものです。jail.local の ignoreip には CIDR 表記の範囲も書けますが、Google の範囲は変わるため、書き写した範囲はいずれ古くなります。ジェイルの設計は Ubuntu 24.04 で fail2ban を設定する手順 にまとめてあります。

WAF（Web アプリケーションファイアウォール）や、VPS 事業者の DDoS 対策も同じ問題を起こします。これらは事業者の管理画面で動くため、サーバーのログには何も出ません。アクセスログに行がない時間帯があるなら、管理画面の遮断記録も確認してください。

AI クローラーのブロックが Googlebot まで止めていないか

AI の学習用クローラーを止めるために、UA で拒否するルールを書くことがあります。このとき google という文字列で拒否すると、Googlebot も止まります。Google-Extended は robots.txt で使うトークンで、独自の UA を名乗って来るクローラーではありません。Google のクロールは既存の Google の UA のまま行われるため、UA で Google-Extended だけを狙うことはできないのです。

ルールが 403 を返すなら、Search Console では別の理由として表示されます。しかし 503 や 429 を返すルールなら、ここで調べている「サーバーエラー（5xx）」に入ります。444 で接続を閉じるルールの場合、nginx は応答を何も返さないので、Googlebot から見ればサーバーが正常に応答しなかったことになります。

自分の nginx 設定の中で、UA を使っている箇所を一覧にします。

sudo grep -rn 'http_user_agent' /etc/nginx/

正規表現が bot や google のように広すぎないかを確認します。名前を一つずつ並べ、robots.txt と組み合わせるやり方は AI クローラーを自分のサーバーでブロックする方法 で説明しています。

PHP-FPM のワーカーが足りていないか

PHP-FPM は、pm.max_children で決めた数のワーカーでリクエストを処理します。全員が使用中になると、新しいリクエストは空きを待つ列に並びます。待ち時間が nginx の fastcgi_read_timeout（初期値 60 秒）を超えると、nginx は 504 を返します。待つ列もあふれると、nginx は接続に失敗して 502 を返します。Googlebot がまとめてページを取りに来るのは、小さなプールを埋めるのにちょうどよい負荷です。

PHP-FPM はワーカーが上限に達したとき、自分のログに次の警告を書きます。

WARNING: [pool www] server reached pm.max_children setting (5), consider raising it
sudo zgrep -h 'max_children' /var/log/php8.3-fpm.log*

nginx の error.log では、次のような行になります。

upstream timed out (110: Connection timed out) while reading response header from upstream
connect() to unix:/run/php/php8.3-fpm.sock failed (11: Resource temporarily unavailable) while connecting to upstream

これらの時刻が Googlebot の 5xx と重なるなら、原因はプールの大きさです。ただし、pm.max_children をただ増やすのは危険です。ワーカー一つ一つがメモリを使うため、増やしすぎると次の節の問題に変わります。メモリから上限を計算する方法は 小さな VPS での PHP-FPM プールの決め方 を参照してください。

メモリ不足でプロセスが強制終了されていないか

メモリが尽きると、Linux カーネルの OOM killer（Out Of Memory killer）がプロセスを一つ選んで強制終了します。メモリを多く使っているプロセスが選ばれやすいので、MySQL や PHP-FPM のワーカーがよく対象になります。データベースが落ちれば、アプリケーションは 500 を返します。PHP-FPM が落ちれば、nginx は上流に接続できず 502 を返します。

カーネルのログで確認します。

sudo journalctl -k | grep -iE 'out of memory|oom-kill'

Out of memory: Killed process で始まる行があれば、メモリ不足でプロセスが終了させられています。括弧の中が終了したプロセスの名前です。時刻を Googlebot の 5xx と比べます。

対処は、メモリの使用量を減らすか、メモリを増やすかです。具体的には、pm.max_children を実際のメモリに合わせて下げる、使っていないサービスを止める、スワップを用意する、プランを上げる、のどれかになります。free -h で、いまの使用量とスワップの有無を確認できます。

デプロイや再起動のたびにエラーを返していないか

sudo systemctl restart php8.3-fpm は、ワーカーをすべて止めてから起動し直します。止まっている間に届いたリクエストは失敗し、nginx は 502 を返します。数秒の出来事でも、その数秒に Googlebot が来れば記録に残ります。

reload を使うと中断が短くなります。nginx の reload は、古いワーカーが処理中のリクエストを終えてから入れ替わるため、接続が切れません。PHP-FPM も systemctl reload php8.3-fpm で設定を読み込み直せます。Docker で docker compose up -d を実行してコンテナを作り直す場合は、新しいコンテナが起動するまでの間、リバースプロキシの nginx が 502 を返します。上流の扱いは nginx のリバースプロキシ設定の読み方 で説明しています。

再起動の時刻と 5xx の時刻を並べて確認します。日付は Search Console に出ていたクロールの日付に合わせて変えてください。

sudo journalctl -u nginx -u php8.3-fpm --since "2026-09-28" --until "2026-09-29"

停止と起動の記録が 5xx の時刻と重なるなら、原因はデプロイの手順です。短時間の計画的なメンテナンスで 503 を返すこと自体は問題ありません。Google のドキュメントのとおり、クロールが一時的に遅くなるだけです。問題になるのは、それが長く続く場合や、気づかないうちに毎日起きている場合です。

直したあとにすること

原因を直したら、まず「URL 検査」の「公開 URL をテスト」で、レポートにあった URL をいくつか試します。正常に取得できることを確認してから、「サーバーエラー（5xx）」の詳細画面で「修正を検証」を押します。Google はその URL を順にクロールし直します。完了までの期間は決まっていません。途中で一つでもエラーを返すと、検証は失敗として記録されます。

Search Console は、問題が起きてから知らせるまでに時間がかかります。サイトの外から定期的にアクセスする監視を置けば、5xx が出た時点で気づけます。Uptime Kuma によるサイトの死活監視 なら、同じ VPS ではなく別の場所から確認するように置くのが基本です。同じ VPS が落ちれば、監視も一緒に止まるからです。

ログの集計も続けます。アクセスログの節にある一つ目のコマンドを週に一度実行すれば、Googlebot が受け取ったステータスの内訳が分かります。500 番台が 0 なら、レポートの「サーバーエラー（5xx）」もいずれ減っていきます。

FAQ

「サーバーエラー（5xx）」が出たら、すぐにインデックスから消えますか？

すぐには消えません。Google のドキュメントによると、5xx を受け取ったクローラーはまずクロールのペースを一時的に落とします。すでにインデックスに登録されている URL はしばらく保持されますが、サーバーエラーを繰り返して返す URL は最終的に削除されます。何日で削除されるかは公開されていないので、見つけたらすぐに原因を調べるのが安全です。

アクセスログに Googlebot の 5xx が見当たりません。なぜですか？

考えられる理由は主に四つです。リクエストが fail2ban やファイアウォール、事業者の DDoS 対策で遮断され、nginx に届いていない場合。CDN が前にあり、エラーを返したのが CDN の場合。ログの保存期間より前の出来事の場合。そして、ログの時刻が UTC で、日本時間の日付とずれて別の日を探している場合です。/var/log/fail2ban.log と CDN のログ、timedatectl のタイムゾーンを確認してください。

503 の代わりに 429 を返せば、サーバーエラー扱いになりませんか？

なりません。Google のドキュメントは、429 をサーバーが過負荷だという合図として扱い、サーバーエラーに数えると明記しています。5xx と同じように、クロールのペースが落ちます。Googlebot に 429 や 503 が返っているなら、ステータスを変えるのではなく、レート制限のかけ方を見直してください。

UA に Googlebot と書かれていれば、本物の Googlebot ですか？

いいえ。UA は誰でも自由に書けます。本物かどうかは、IP アドレスを host で逆引きして googlebot.com、google.com、googleusercontent.com のどれかで終わる名前が返り、その名前を正引きして元の IP アドレスに戻ることで確かめます。Google が公開している common-crawlers.json の IP アドレス範囲と照合する方法もあります。

#search-console#googlebot#http-errors#nginx#seo