運営しているサイトの検索流入がじわじわ落ち、Google Search Console を見ると「サーバー接続エラー」。ところがブラウザでは普通に表示される——この食い違いを、AI（Claude Code）と対話しながら1つずつ確認していった記録です。結論から言うと、残ったエラーの原因は完全には特定できませんでした。それでも、AI と対話することで自分だけでは見落としていた確認項目まで調べられた、という話をまとめます。同じように「サイトは見えているのに Search Console だけがエラーを出す」で困っている方の、確認項目の参考になればと思います。
Search Consoleだけが「サーバー接続エラー」を報告していた
きっかけは検索流入の落ち込みでした。Google Search Console を開くと、カバレッジや URL 検査で「サーバー接続エラー」と表示されている。一方で、ブラウザから自分のサイトを開くと、いつも通り普通に表示されます。
「見えているのにエラー」という状態は、原因の切り分けが難しい種類の不具合です。サーバーが完全に落ちているわけではなく、特定の条件や経路で失敗している可能性もあるため、順番に切り分ける必要があります。まずはこの食い違いの正体を突き止めることにしました。
最初に見つかった原因：放置していた古いWordPress
PHP8非対応で500エラーを出していた
調べていくと、サイトのルート（ドメイン直下）に、7〜8年前に設置した WordPress がそのまま残っていました。契約直後によく分からないまま作り、その後は使っていなかったものです。
この古い WordPress が現行の PHP（PHP8）に対応しておらず、アクセスのたびに PHP のフェイタルエラーで500を返していました。トップページの表示に使っている仕組みとは別系統だったため、普段ブラウザで見るぶんには気づけなかった、という構図です。
robots.txtが巻き添えになりクロールが止まっていた
さらに影響が大きかったのが robots.txt です。ルートの WordPress が500を返す状態になっていたことで、robots.txt も正常に返せなくなっていました。
Google はクロール前に robots.txt を取得しようとし、それが取得できないとドメイン全体のクロールを一時的に控えます。結果として、サイト全体が「クロールできない」状態になり、検索流入の低下につながっていました。
対処自体はシンプルで、FTP で壊れた WordPress 本体を別ディレクトリに退避しました。これで500エラーと robots.txt の異常は解消しました。
500を直しても検査ツールは変わらなかった
500 が止まったので直ったつもりでいたのですが、Search Console の「URL 検査（ライブテスト）」は、その直後もずっと「サーバー接続エラー」のままでした。ここから、よくある原因を1つずつ確認していく作業に入りました。
Claude Codeと進めた切り分けの手順
以下は、Claude Code と対話しながら順番に確認していった内容です。仮説を立てる、確認方法を決める、結果を見て次を決める、という流れを会話でそのまま回しました。
- 世界55拠点からの実測（check-host.net）：特定の地域・経路だけがブロックされている可能性を確認 → どの拠点からも正常応答が返り、地域ブロック説は棄却
- 接続元 IP の確認：ログに残っていたアクセス元を確認 → Google Cloud のシンガポールに関連するホスト名が返った（ただし、これだけで正規の Google クローラーと断定はできない）
- サーバー設定の総当たり：Xserver のサーバーパネルで、アクセス制限・アクセス拒否設定・AI クローラー遮断・WAF・国別アクセス制限の5項目を確認 → いずれも該当なし
- ログ保存の有効化：そもそもサーバーのログ保存設定が「残さない」になっていたため、1週間保存に変更
- ログの実測：30分以上の間隔をあけて3回ログをダウンロードし、該当時刻に1行も記録が残っていないことを確認
- 追加確認：IPv6 経由の応答、TLS 証明書、レスポンスヘッダーも確認 → 手がかりなし
結論：Google側に古い状態が残っていた可能性を疑った
robots.txt、WAF、IP ブロックといった定番の原因は、確認できる範囲では潰しました。それでもサーバー側のログには失敗の痕跡が一切残っていません。確認した範囲では、サーバー側に明確な原因は見つかりませんでした。
痕跡がないのに Search Console 側だけがエラーを表示し続けている状況から、Google 側に修正前の状態（過去に robots.txt を取得できなかった時期の情報）が残っていた可能性が有力だと考えました。ただし、これは確定した原因ではありません。時間経過とともに再クロールが進めば表示も更新されていく、という見立てです。
整理すると、古い WordPress による500エラーは解消できた一方、修正後も残った Search Console のエラーは原因を特定できず、Google 側に古い状態が残っていた可能性を疑っている、というのが今回の結論です。
念のため、Xserver のサポートへの問い合わせ文面も、実測したデータを添えて Claude Code が下書きし、こちらで内容を確認して送信しました。
よくある質問（FAQ）
Q. サイトはブラウザで見えているのに Search Console がサーバーエラーを出します。まず何を確認すべきですか?
A. ドメイン直下の robots.txt が正常に返るか（HTTP 200 か）を最初に確認するのがおすすめです。ルートに古い CMS やテスト用のプログラムが残っていて、そこが500を返していると robots.txt も巻き添えになります。
Q. サーバーのログを見れば原因は分かりますか?
A. ログ保存が有効になっていることが前提です。今回は保存設定が「残さない」になっており、まずそこを変更しました。エラー時刻にログが1行も無いという事実自体が、「サーバーは実際にはエラーを返していない」という切り分けの根拠になりました。
Q. 原因が特定できないまま終わっても意味はありますか?
A. 定番の原因を確認し切ったという記録が残るので、サポートへの問い合わせが具体的になりますし、再発時に確認範囲を絞れます。原因不明でも「ここまでは確認済み」と言える状態は無駄になりません。
まとめ
Google Search Console だけが「サーバー接続エラー」を報告し続けた件を、AI と一緒に確認していきました。発端は、放置していた古い WordPress が PHP8 非対応で500を返し、robots.txt を巻き添えにしてクロールを止めていたことでした。この500エラーは解消できた一方、修正後も残った検査ツールのエラーは原因を特定できず、地域ブロック・サーバー設定・ログ・証明書まで確認しても手がかりはなく、Google 側に古い状態が残っていた可能性を疑うにとどまりました。それでも、AI と対話しながらだと次に確認する項目が途切れず出てくるので、1人で調べるより広い範囲まで短時間で切り分けられました。
おまけ：無料キャンペーンのお知らせ
サイトの不具合とは別の話ですが、いま、都市伝説フルマンガ「家庭の解剖室 ―その『あなたのため』、わたしが解体します。―」を無料で公開しています。家庭でよく使われる「あなたのため」という言葉を題材にした一冊で、「解剖室」シリーズの3冊目です。シリーズものですが、どの巻からでも読めます。無料期間は2026年9月5日16:59まで、Kindle Unlimited でも読めます。ダウンロードはこちらからどうぞ。家庭の解剖室（Amazon）
