「その他の 4xx が原因でブロック」の意味と修正方法

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 の影響を受けたすべての URL を 1 か所で見つける。 Search Console を URL ごとにクリックしていく代わりに、SEOcrawl AI はインデックス カバレッジの全内訳を表示し、クロール済みページを Claude や ChatGPT から直接ステータスコードでフィルタリングできます。SEOcrawl AI をお試しください。
よくある質問
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 を使ってクロール済みページをステータスコードで一括フィルタリングできます。
著者: David Kaufmann

私はこの10年以上、SEOに完全に夢中になって過ごしてきました。正直なところ、他の生き方は考えられません。
私のキャリアが新たな次元に到達したのは、Chess.com でシニアSEOスペシャリストとして働いたときでした。Chess.com はインターネット全体で最も訪問数の多い上位100サイトの1つです。数百万ページ、数十言語、そして最も競争の激しい SERPs の1つという規模で仕事をした経験は、どんなコースや資格でも得られないことを教えてくれました。あの経験は、本当に優れたSEOとは何かという私の視点を一変させ、それ以降に私が築いてきたすべての土台となりました。
その経験から、私は SEO Alive を創業しました。オーガニック成長に本気で取り組むブランドのためのエージェンシーです。私たちは dashboards や月次レポートを売るためにここにいるのではありません。本当に成果を動かす戦略を構築するためにここにいます。クラシカルなSEOの最良の部分と、Generative Engine Optimization (GEO) というエキサイティングな新しい世界を組み合わせ、あなたのブランドが Google の青いリンクだけでなく、ChatGPT、Perplexity、Google AI Overviews が毎日何百万人もの人々に届けている AI 生成の回答の中にも確実に表示されるようにします。
そして、この両方の世界をきちんと扱えるツールが見つからなかったので、自分で作りました。それが SEOcrawl です。rankings、テクニカル監査、backlinks モニタリング、crawl ヘルス、そして AI ブランド可視性トラッキングを1つの場所に統合した、エンタープライズ向けのSEOインテリジェンスプラットフォームです。まさに、ずっと存在してほしいと願っていたプラットフォームです。
この著者の他のコンテンツをご覧ください

