「その他の 4xx が原因でブロック」の意味と修正方法 | SEOcrawl AI
「その他の 4xx が原因でブロック」の意味と修正方法
2026年7月2日
Search Console を開くと、そこに表示されています。 未登録：「その他の 4xx が原因でブロックされました」。 ステータスコードもなければ、対象のファイルも、明らかな原因も示されていません。
このガイドでは、どのエラーがこのラベルを引き起こすのか、その背後にある本当のステータスコードをどう見つけるのか、そして各原因をどう修正するのかを、 ほとんどの解説記事が飛ばしている診断ステップも含めて 正確に説明します。このレポートが Search Console 全体のなかでどこに位置づけられるかは、 Google Search Console 完全ガイド をご覧ください。
「その他の 4xx が原因でブロック」の本当の意味
「その他の 4xx が原因でブロックされました」とは、 Googlebot が URL をリクエストし、Search Console が独自のカテゴリに切り分けていない 4xx（クライアント側）レスポンスを受け取った ことを意味します。
Google はページを取得できなかったため、インデックスに登録しません。このような場合、URL は正常なステータスを返すようになるまで検索結果に表示されません。
ここでポイントとなるのが「その他」という言葉です。Search Console は、最も一般的な 3 つの 4xx コードについてはすでに専用のラベルを用意しています。
- ›401 →「不正なリクエストが原因でブロックされました（401）」。
- ›403 →「アクセス禁止が原因でブロックされました（403）」。
- ›404 →「 見つかりませんでした（404）」。
したがって「その他の 4xx」は、 4xx の範囲に含まれるそれ以外すべてを包括するカテゴリ になります。400、405、408、410、429 などのコードです。メッセージが曖昧なのは、Google は 4xx が起きたことは分かっていても、それが自分たちがラベル付けしているものではないからです。
この エラーを引き起こす 4xx ステータスコード
これらが このラベルの下に最も頻繁に該当するコード です。何かを修正する前に、サーバーが実際にどれを返しているのかを特定する必要があります。
| コード | 名称 | 典型的なきっかけ |
|---|---|---|
| 400 | Bad Request | 形式が不正な URL、無効な文字、破損したリクエスト |
| 405 | Method Not Allowed | サーバーがリクエストメソッドを拒否（例：そのパスで GET が無効） |
| 406 | Not Acceptable | コンテンツネゴシエーションの不一致 |
| 408 | Request Timeout | サーバーが所定の時間内に応答できないほど遅い |
| 410 | Gone | ページが恒久的に削除された（下記の注記を参照） |
| 411 / 412 / 421 / 422 | 各種 | 長さ／前提条件／誤送信／処理不能なリクエストの問題 |
| 429 | Too Many Requests | レート制限（大規模なサイトや厳重に保護されたサイトで非常によくある原因） |
| 451 | Unavailable for Legal Reasons | 地域／法的なブロック |
| 418 | I'm a teapot | RFC で定義されたジョークのステータス（まれだが、一部の環境がときどき実際に返す本物のコード） |
410（Gone）に関する注記： ページを意図的に恒久的に削除したのであれば、410 は 正しい レスポンスであり、「修正」すべきではありません。それが本当にインデックスに登録したいページでないことだけ確認してください。
Googlebot に対して 4xx エラーが発生する原因
ほとんどのケースは、次の 5 つの原因のいずれかにたどり着きます。
- ›セキュリティルールと WAF。 Cloudflare、Sucuri、AWS WAF などのファイアウォールが、Googlebot を脅威と誤認して 403 を返したり、リクエストをブロックしたりすることがあります。WordPress のセキュリティプラグインも同様の動作をすることがあります。
- ›レート制限（429）。 サーバーは、短時間にリクエストが多すぎると判断すると 429 を返します。Google は繰り返しレート制限を受けるページをインデックスに登録しません。
- ›サーバーまたは CDN の設定。 CDN のルール、.htaccess のディレクティブ、あるいはテンプレートの変更によって、ブラウザでは問題なく表示される URL で 4xx が返されるようになることがあります。
- ›形式が不正な URL（400）。 400 は、サーバーがリクエストを理解できなかったことを意味します。多くの場合、誤った URL 構造や不正なパラメータが原因です。これはファセットナビゲーションやセッション／トラッキングパラメータでよく発生します。
- ›ファイル権限。 ディレクトリ権限を厳しく設定しすぎている場合（例：755 ではなく 700）、403 が発生することがあります。
役立つ手がかりとして、これらは リクエストの行われ方 に結びついたクライアント側のレスポンスであるため、自分のブラウザでは同じエラーが表示されないことがよくあります。まさにこれが、このレポートが不透明に感じられる理由です。
Google が遭遇した正確な 4xx ステータスコードの見つけ方
Search Console は、あるページが影響を受けていることは教えてくれますが、どの 4xx コードを返したかは教えてくれません。 それは自分で見つける必要があります。 次の手順を順に進めましょう。
- ›影響を受けている URL を一覧表示する。 Search Console で インデックス作成 → ページ に移動し、「ページがインデックスに登録されなかった理由」までスクロールして、「その他の 4xx が原因でブロックされました」をクリックすると、完全な一覧が表示されます。これらはページ セクション → 未登録タブの下にあります。
- ›URL を検査する。 URL をクリックし、URL 検査ツールで 公開 URL をテスト をクリックします。Googlebot が実際に見たもの、HTTP レスポンスやリダイレクトを含めて正確に表示されます。
- ›Googlebot として取得する。 このエラーはユーザーエージェント固有であることが多いため、Googlebot ユーザーエージェントで再現します。Chrome DevTools でネットワーク条件タブを開き、「ブラウザのデフォルトを使用」のチェックを外して「Googlebot Smartphone」を選択し、再読み込みしてステータスコードを確認します。ターミナルから
curl -A "Googlebot" -I https://yoururlを実行することもできます。 - ›サーバーログを確認する。 ログには、サーバーが Google の IP に返した本当のステータスコードが記録されています。DevTools とブラウザが食い違う場合、これが真実の拠りどころです。
- ›本当に Googlebot かどうかを確認する。 WAF がブロックしている場合は、アクセスを広げる前に、リクエスト元の IP が本当に Google のものかどうかを確認しましょう。そうすれば、なりすましボットに扉を開くことはありません。
各 4xx エラーの修正方法（コード別）
コードが分かれば、修正方法はそこから導けます。
| 4xx コード | 考えられる原因 | 修正方法 |
|---|---|---|
| 403 | WAF またはファイアウォールが Googlebot をブロック | 検証済みの Googlebot を許可リストに追加するか、それを捕捉しているルールを調整する。原因がそれならファイル権限を修正する。 |
| 429 | レート制限 | 検証済みの検索ボット向けにレート制限を引き上げるか調整し、プラグインや CDN がクロールを抑制していないか確認する。 |
| 400 | 形式が不正な URL | URL 構造を修正し、無効なパラメータの組み合わせの生成を止め、パラメータ付き URL を正規化する。 |
| 405 / 406 / 408 | サーバールール、コンテンツネゴシエーション、またはタイムアウト | 対象のパスについて、サーバー側のルール、コンテンツネゴシエーション、またはタイムアウトの挙動を修正する。 |
| 410（消滅すべきでない） | 誤って削除されたページ | ページを復元するか、価値と被リンクがある場合は最も近い相当ページへ 301 リダイレクト する。 |
| 404 / 410（意図的） | URL が本当に存在しない | そのままにしておく。これらは修正すべきエラーではない。量が多い場合は robots.txt でクロールの無駄を防ぐ。 |
Search Console で 4xx の修正を検証する方法
根本原因を修正したら、「その他の 4xx が原因でブロックされました」レポートに戻り、 修正を検証 をクリックします。
Google は影響を受けた URL を再クロールします。修正済み URL の再クロールには、クロールバジェットにもよりますが、通常は数日から数週間かかります。
Google が各 URL を再試行するにつれてレポートは更新されるため、 最近行った修正はすぐには反映されません。 検証に頼る前に、各ページが 200 を返すようになったことを確認できるよう、URL 検査ツールを手元に置いておきましょう。
SEOcrawl AI で 4xx の影響を受けた URL を大規模に見つける
Search Console は問題を表示しますが、 URL を 1 つずつ検査させられます。 SEOcrawl AI は Search Console のカバレッジデータを取り込み、サイト全体のインデックス登録状態を可視化するため、URL を 1 つずつクリックする代わりに、影響を受けた URL を一括で見つけられます。
当社の MCP サーバー を使えば、 インデックス カバレッジの全内訳を状態別に読み取り、クロール済みページをステータスコードでフィルタリング（例：404 を返すものすべて）することが、Claude や ChatGPT から直接行えます。さらに、ルール・手動・MCP 経由でタグ付けも可能です。これをスケジュールされたクロールやアラートと組み合わせて、 4xx URL の急増を、順位に響く前に捉えましょう。
よくある質問
4xx エラーとは何を意味しますか？
4xx エラーとは クライアント側の HTTP ステータス で、リクエスト自体を実行できなかったことを意味します。ページが見つからない、アクセスが拒否された、リクエストの形式が不正、あるいはサーバーがレート制限をかけている、といった状況です。
4xx ファミリーには、400（不正なリクエスト）、403（アクセス禁止）、404（見つからない）、410（消滅）、429（リクエスト過多）などが含まれます。 SEO の観点では、インデックスに登録したいページで発生した 4xx はすべて問題です。 Google がコンテンツを取得してランク付けできなくなるからです。
4xx エラーは SEO に悪いですか？
インデックスに載せたいページで発生する場合は悪影響があります。4xx を返すページはクロールできないため、 インデックスにも登録されずランク付けもされず、本来得られたはずのトラフィックを失います。
大規模になると、 広範な 4xx エラーはクロールバジェットを浪費し、サイトの管理が不十分であるというシグナルにもなり得ます。 本当に存在しない URL に対する意図的な 404 や 410 は正常であり、問題となるのは公開されているべきページで返される 4xx レスポンスです。
SEO における 4xx エラーとは何ですか？
SEO の観点では、4xx エラーとは 検索エンジンが URL にアクセスできなくなるクライアント側のレスポンスすべて を指します。最も重要なのは、404（リンク切れや削除済みのページ）、403（多くはファイアウォールによるアクセスブロック）、そして 400・429・410 のような「その他の 4xx が原因でブロック」の背後にあるコードです。
Google がどの 4xx に遭遇したかを調べるには？
Search Console はコードを明示しないため、自分で調べましょう。対象の URL を URL 検査ツールで開き、 公開 URL をテスト を実行してレスポンスを確認するか、Googlebot ユーザーエージェントでページを取得します（Chrome DevTools のネットワーク条件パネル、または curl -A "Googlebot" -I [url] を使用）。
サーバーログには、サーバーが Google に返した確定的なステータスコードが記録されます。多数の URL に対して一度に行うには、SEOcrawl AI を使って クロール済みページをステータスコードで一括フィルタリング できます。