401 Unauthorized（未認証）

TL;DR — “Blocked due to unauthorized request (401)” (翻訳)「未認証リクエストによるブロック（401）」は、Googlebotがページを読もうとしてログインを求められたことを意味します。Googlebotにはサイトのパスワードがないため、処理を諦め、そのページはインデックス登録できません。Googleに載せたいページなら、本来ないはずのログイン壁（残ったログイン保護、ステージングサイトのパスワード、誤ってGoogleをブロックするセキュリティルール）が原因です。非公開にするページなら正常で、直す必要はありません。

このステータスの意味

このレポートラベルは、GoogleがURLに対するHTTP 401認証レスポンスを受け取ったことを意味します。 Evidence for this claim The Page Indexing report identifies URLs where Google encountered an authorization request. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: Page indexing report Googleは、429以外の4xxレスポンスが継続すると、インデックス登録では利用できないコンテンツとして扱います。 Evidence for this claim Google treats 4xx responses other than 429 as if the content does not exist for indexing. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: HTTP status codes

Google Search Consoleのページのインデックス登録レポートで、“Blocked due to unauthorized request (401)” (翻訳)「未認証リクエストによるブロック（401）」と表示されるのは、GooglebotがURLをクロールし、サーバーがHTTP 401（「認証が必要」）を返したという意味です。つまり「見るにはログインが必要」ということです。 Evidence for this claim Google's Blocked due to unauthorized request (401) Page indexing reason means the page was blocked to Googlebot by an authorization request returning HTTP 401. Scope: verified Search Console properties Confidence: high · Verified: 2026-07-16 Page indexing report

Googlebotにはサイトのユーザー名やパスワードがなく、今後も提供されません。ページがログインを要求すると、Googlebotは中に入れず、コンテンツを読めず、ページをインデックス登録できません。以前はGoogleに登録されていたページが401を返し始めた場合、やがて検索結果から削除されます。

問題なのか

そのページをGoogleに表示したいかどうかで決まります。

• インデックス登録したい → 問題です。本来公開されるべきページの前にログイン壁があります。何がゲートになっているかを見つけ、開放する必要があります。
• 非公開／ステージングページである → 問題ありません。401は非公開領域をGoogleから遠ざける適切な方法であり、このレポートの行を消すためだけにゲートを弱めるべきではありません。確認するのは、そのURLをこのSearch Consoleプロパティへリンク、サイトマップ掲載、送信する必要が本当にあるかだけです。

「でも、そのページは自分のブラウザーでは表示できる」

もっとも多い混乱です。ブラウザーでURLを開くと表示できるのに、なぜGoogleはブロックされたと言うのでしょうか。あなたはログイン済み（またはオフィスのIPが許可リストにある）で、Googlebotはそうではないからです。あなたが見ているのはゲートの先で、Googlebotが当たっているのはゲートです。Googleが見る状態を確認するには、匿名の訪問者としてページをテストします。方法はAdvancedタブで説明します。

よくある原因

• ステージングまたはテストサイトに残ったパスワード。
• 本来公開すべきセクションにログイン保護を誤って残している。
• セキュリティツールまたはCDN（Cloudflareなど）がGooglebotを誤ってブロックしている。
• 会員限定など、意図してゲートを置いたコンテンツの本当のログイン壁。

詳しい診断手順、401と403の違い、正しい修正方法を知りたい場合は、Advancedタブへ切り替えてください。

TL;DR — “Blocked due to unauthorized request (401)” (翻訳)「未認証リクエストによるブロック（401）」は、GooglebotがHTTP 401（Unauthorized）を受け取った、つまり通過できない認証ゲートに当たったという意味です。Googleは認証情報を提供しないため、コンテンツは見えず、ページはインデックス登録されません。以前登録されたURLが401を返し続けると、時間の経過とともに削除されます。401と403の正確な違いはRFC 9110にあります。401はリクエストに有効な資格情報がない（送信されていない、または送信されたものを拒否された）状態、403はサーバーがリクエストを理解したうえで拒否した状態です。Googleはインデックス登録では429を除くすべての4xxを同じように扱いますが、原因と修正はページの種類で変わります。誤ってゲートされた公開ページは認証要件を削除し、ボットセキュリティに誤ブロックされた公開ページは偽装可能なユーザーエージェントではなくIP／逆引きDNSで確認したGooglebotを許可し、本当に非公開またはステージングのページは認証を維持し、登録可能な購読コンテンツには一律401ではなくGoogleのペイウォール構造化データを使います。「ブラウザーでは表示できる」は罠です。あなたは認証済みで、Googlebotはそうではありません。クロール速度の制限に401／403を使わず、ボットとして（URL InspectionのLive Testとcurl -Iで）診断します。WWW-Authenticateヘッダーがない場合、それはレスポンスが不正または不完全だという意味であり、WAFが原因だとは限りません。Live TestとValidate Fixが確認するのはアクセスであってインデックス登録ではなく、公開された再試行間隔もありません。

Googleが実際に伝えていること

ページのインデックス登録ラベルは、Googleが観測したレスポンスを示すだけで、どの認証、CDN、アプリケーションルールが生成したかは特定しません。 Evidence for this claim The Page Indexing report identifies URLs where Google encountered an authorization request. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: Page indexing report 基礎にあるインデックス登録の挙動は、Googleが文書化している4xxレスポンスの扱いから決まります。 Evidence for this claim Google treats 4xx responses other than 429 as if the content does not exist for indexing. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: HTTP status codes

ステータスはサーバーのレスポンスコードから直接来ます。GooglebotはURLを要求し、HTTP 401、「Unauthorized」ステータスを受け取りました。ページは認証ゲート（HTTP Basic Auth、ログイン壁、アクセス制御ルール）の背後にあります。Google自身のページのインデックス登録レポートの定義でも、認証要求によってGooglebotがブロックされ、登録したい場合は認証要件を削除するか、身元を確認してGooglebotを通す必要があると説明されています。

私のHTTPステータスコードとSEOへの影響では、401を「必要なときにクライアントが自身を識別または確認していない状態」と説明しています。これは便利なメンタルモデルですが、プロトコル全体の定義ではありません。RFC 9110の正確なルールでは、401はリソースに対する有効な認証資格情報がないことを意味し、サーバーが資格情報を拒否した場合にも返されます。したがって401は、Googlebot（またはブラウザー）が何も送らなかったことを必ずしも意味しません。提示されたものが有効でなかったということです。いずれにしてもGooglebotには提示できる資格情報がなく、ゲートを通過できないという実務上の結果は同じです。

Googleは401をどう扱うか

ページをインデックス登録したいなら、良い結果にはなりません。GoogleのHTTPステータス文書は、429を除くすべての4xxエラーを同じように扱い、クローラーが次の処理システムへ「コンテンツは存在しない」と伝えると明記しています。つまり401は、Googleに「ここには何もない」と伝えるのと同じです。結果は次のとおりです。

• ページはインデックス登録されません。 Googleはコンテンツを見ていないため、登録するものがありません。
• 以前登録されていたページは削除されます。 401固有ではなく、4xx全体の挙動です。私のAhrefsのHTTPステータスコード解説でも、4xxはページをインデックスから落とすと説明しています。Googleが登録済みのページで401が返ると、クロールを繰り返すうちにURLは検索結果から外れます。
• クロールを制限しません。 Googleはクロール速度を制限するために401や403を使わないよう明記しています。429を除く4xxにはクロール速度への効果がないため、401を「速度を落とす」手段にはできません。その用途には503／429を使います。

ここで、具体的な再試行間隔を示すことはしません。Googleは時間をおいて再クロールしますが、「Googlebotは401をN日ごとに再試行する」という保証されたスケジュールを文書化していません。存在しない数字を作るのは避けます。再クロールは「いつか戻ってくる」と考え、ストップウォッチのように扱わないでください。

401と403、その他の4xx — 重要な違い

多くの解説が曖昧にする区別であり、ここに実務上の価値があります。インデックス登録では、Googleは401と403を同じように扱います（429を除く4xxのルール）。しかしコードの意味が違うため、原因と修正は異なります。

• 401 UnauthorizedはRFC 9110の定義では、対象リソースに対する有効な認証資格情報がない状態です。資格情報をまったく送らなかった場合と、送ったものをサーバーが拒否した場合の2つがあります。適合する401レスポンスには、少なくとも1つのチャレンジを示すWWW-Authenticateヘッダーが必要です。私の短い定義である「必要なときにクライアントが自身を識別または確認していない」は、よくあるケースの略語として使えますが、完全なルールではありません。
• 403 Forbiddenは同じRFCで、サーバーがリクエストを理解したが実行を拒否した状態です。資格情報は理由の1つになり得ますが、仕様は「資格情報とは無関係な理由で拒否されることもある」と明記しています。したがって403が常に「クライアントは認証済みだが権限がない」という意味とは限りません。Googleのページのインデックス登録レポートで、資格情報を送らないGooglebotへの403が出る場合は、設定ミスのファイアウォール、WAF、ボットルールが原因であることが多いです。その場合の兄弟ステータスは**Blocked due to access forbidden (403)**です。

トリアージでは、401 ≒「認証ゲートを解除し忘れた」（ステージングサイトや残ったHTTP認証）、403 ≒「セキュリティルールがGooglebotを誤ってブロックしている」という近道が役立ちます。インデックス登録の結果は同じでも根本原因は違います。ただし、どちらもプロトコルの境界そのものではありません。判断表はCheat Sheetsタブにあります。

これが表示される理由 — よくある原因

本当にインデックス登録したいページで401が返る場合、ほとんどは次のいずれかです。

• Basic Authの背後にあるステージングまたは開発サイト。 ステージング環境をパスワードで保護するのは正しい判断ですが、内部リンク、サイトマップ、漏れた参照などからGoogleがURLを発見し、401を報告している可能性があります。ステージングURLを本当に公開すべきでないなら、これは期待どおりです（意図した401の節を参照してください）。
• 公開セクションに残ったHTTP認証。 .htpasswdルール、「近日公開」プラグイン、メンテナンスモードのゲートが、本来公開するディレクトリに残っています。
• WAF／CDN／IP許可リストがGooglebotをブロック。 Cloudflare、Akamai、Sucuri、地域またはIPの許可リストがGooglebotのIPに401（または403）を返し、人間には正常にページを返すケースです。テストしている人が許可されたIPから来ているため、「全員に正常」と見えます。
• 登録したい購読またはペイウォールコンテンツのログイン壁。 一律401ではGooglebotが完全に締め出されます。修正はゲートを弱めることではなく、Googleがサポートするペイウォール構造化データです（4つ目の分岐を参照してください）。

ブラウザーではなくボットとして診断する

ここで最大の罠は「自分では動く」です。あなたは認証済み、IPが許可リストにある、またはブラウザーにセッションCookieがあるので当然動きます。Googlebotにはそのどれもありません。 ボットとして診断します。

• URL Inspection → Live Test（GSC）。 Googlebotが受け取る実際のレスポンスを確認する最も近い方法です。対象URLで実行し、認証が原因で取得できなければ、401が実在し再現することを確認できます。

• 未認証の状態からcurl -Iを実行する。 Cookieも資格情報も付けず、ステータス行を確認します。

  curl -I https://www.example.com/page/
  # Look for:  HTTP/1.1 401 Unauthorized
  # and a WWW-Authenticate: header confirming an auth gate

セッションも認証も送らないcurlが401を返し、ブラウザーが200を返すなら、その差が問題です。ブラウザーは認証済みで、Googlebotはそうではありません。RFC 9110に適合する401にはWWW-Authenticateヘッダーが必要で、存在すれば本当の認証チャレンジだと確認できます。ただしない場合も答えが決まるわけではありません。レスポンスが不正または不完全だという意味であり、どの層が生成したかは分かりません。ヘッダーがないだけで「WAFに違いない」と決めつけないでください。

• IPスコープか確認する。 自分のマシンのcurlが200を返し、GSCのLive Testが失敗するなら、送信元IPまたはリクエストルーティングに紐づくルールの手がかりです。WAFと断定する前に、エッジ／CDNログ、オリジンログ、アプリケーション層、IDプロバイダーを比較してください。curl -IのHEADリクエストはGETと違うルーティングやキャッシュになることがあるため、匿名GETでも照合します。

ページの種類で修正を分ける — 4つの分岐

修正は1つではなく4つあります。間違った方法を選ぶと、守るはずのコンテンツを公開するか、登録可能なページをゲートのままにします。設定に触れる前に、URLを次のいずれかに分類してください。

1. 本当に非公開またはステージングのコンテンツ → 認証を維持する。 URLを公開すべきでないなら、401は意図どおりに動作しています。サーバー側認証は、Googlebotを含む全員からコンテンツを隠す、Googleが推奨する正当な方法です。John Muellerもステージングサイトについて、IP、Cookie、通常のサーバー認証でサイトを隠し、通常のユーザー（Googlebotも含む）がコンテンツを見られないようにするのが正しいと説明しています。このレポートの行を消すためだけに、非公開コンテンツを守るゲートへGooglebotを許可しないでください。ここで直すのはアクセスではなく発見性です。URLがこのSearch Consoleプロパティにリンク、サイトマップ掲載、送信されていないことを確認し、認証は維持します。

2. 公開ページを誤ってゲートしている → 認証要件を削除する。 ページをインデックス登録すべきで、ゲートが残ったBasic Auth、ログイン壁、メンテナンスモードのプラグインなら、そのパスだけ無効にします。匿名リクエストが200を返すようになれば、Googlebotにもページが開きます。

3. ボットセキュリティが公開ページを誤ってブロック → 確認済みGooglebotを許可する。 WAF、CDN、IP許可リストが、公開したいページでGooglebotを拒否しているなら、文字どおりのユーザーエージェントではなく、IP／逆引きDNSで確認したGooglebotを許可します。ユーザーエージェントは誰でも偽装できます。Googleの推奨手順は、公開IP範囲または逆引き後の正引きDNSでクローラーを確認し、確認できたリクエストだけをゲートの先へ通すことです。セキュリティルール全体を削除するのではなく、確認済みの例外を作ります。誤検知自体を直すには次の手順を取ります。

• Googlebotに401／403を返しているルールを特定する（Cloudflare Firewall Events、Akamai／Sucuriログ、または自分のエッジ／オリジン／アプリケーションログ）。
• 保護を一括で無効にせず、Googleの確認済みIP範囲（またはボットカテゴリ）を許可リストに追加する。
• Googleが取得できるまで、URL InspectionのLive Testで再テストする。

4. 登録したい購読またはペイウォールコンテンツ → 一律401を使わない。 登録または購読が必要なページを検索で発見可能にしたいなら、原因にかかわらず硬い401は不適切です。Googlebotは取得できないからです。代わりに、Googleがサポートするペイウォール実装を使います。適切なペイウォールコンテンツ構造化データ（isAccessibleForFree、hasPartと関連プロパティ）を付けてページを提供し、ページ全体を開放せずに無料プレビュー部分をGoogleがインデックス登録できるようにします。これはマークアップとサーバーレスポンスの変更であり、認証ゲートを変更するものではありません。

修正を確認し、期待値を正しく置く

ページを実際に開放し、curl／Live Testで未認証リクエストが200を返すことを確認したら、それぞれの手順が何を証明するかを正確に分けます。

• Live Testが確認するのはアクセスであり、インデックス登録ではない。 GoogleのURL Inspection文書では、Live TestはGoogle-InspectionToolが現在ページへアクセスして解析できるかだけを確認すると説明されています。ページがインデックスに入り検索結果に表示される保証ではありません。Live Testに合格したということはゲートが開いたという意味であり、その後の結果を約束しません。
• Validate Fixは任意で、必須ではない。 GoogleはValidate Fixをクリックしたかどうかにかかわらず、再クロールしたページの件数を更新します。実際の修正を自分で追跡するときに使い、非公開のままにするURLには使わないでください。検証操作自体が再インデックスを速めるとも考えないでください。
• 即時の再インデックス登録を期待しない。 再クロールと再登録には時間がかかり、公開された再試行間隔はありません。実際の登録状態と検索パフォーマンスは、レポートのステータスとは別に確認します。Live TestもValidate Fixもcanonical選択や検索表示を保証しません。
• 最後に、401はペナルティや手動対策ではありません。クロールアクセスのステータスです。他のページのランキングを損なったりサイトを「ブラックリスト」に入れたりするのではなく、ゲートされたページをインデックスから外しているだけです。

これはどこに位置付けられるか

これはページのインデックス登録レポートにあるHTTPステータスの1つです。兄弟にはBlocked due to access forbidden (403)、その他の4xx／404ステータス、5xxサーバーエラーステータスがあります。レポート自体と「ページがインデックス登録されない理由」表の読み方は、Googleのページのインデックス登録ドキュメントを参照してください。Googlebotが取得し、ステータスコードが何を意味するかという仕組みは、ここで扱ったとおりです。

AI要約

Advanced版の要点を圧縮します。

• 何を意味するか。 GSCのページのインデックス登録ステータスで、GooglebotがHTTP **401（Unauthorized）**を受け取った状態です。通過できない認証ゲートであり、Googleは資格情報を提供しないためコンテンツを見られません。
• Googleの処理。 ページは登録されず、以前登録されたURLが401を返すと時間の経過とともに削除されます。429を除くすべての4xxは同じように扱われ、「コンテンツは存在しない」と伝えられます。4xxにはクロール速度への効果がないため、Googlebotを遅くするために401／403を使わないでください。
• 401と403の正確な違い。 RFC 9110では、401は有効な資格情報がない（送信されていない、または拒否された）状態、403はサーバーがリクエストを理解したうえで拒否した状態です。常に資格情報が原因とは限りません。「401＝認証ゲート、403＝セキュリティルールがGooglebotを誤ってブロック」という整理はトリアージの近道であり、プロトコル全体の定義ではありません。
• よくある原因（登録したいページの場合）。Basic Authの背後にあるステージングサイト、公開セクションに残ったHTTP認証、Googlebotを除外するWAF／CDN／IP許可リスト、登録したい購読／ペイウォールコンテンツのログイン壁です。
• 「自分では表示できる」は罠。 あなたは認証済みまたはIP許可リストにあり、Googlebotはそうではありません。Cookieも認証も付けず、URL InspectionのLive Testとcurl -Iでボットとして診断します。適合する401ではWWW-Authenticateヘッダーが本当の認証ゲートを示します。ない場合はレスポンスが不正なだけで、WAFが原因だとは限りません。エッジ、オリジン、アプリケーション、IDプロバイダーのログを確認します。
• 一律の修正ではなく、ページの種類で直す。 公開ページを誤ってゲート → 認証要件を削除。ボットセキュリティが公開ページを誤ってブロック → ルール全体を無効にせず、偽装可能なユーザーエージェントではなくIP／逆引きDNSで確認したGooglebotを許可。本当に非公開／ステージング → 認証を維持し、このレポートを消すためだけに開放せず、サイトマップ／リンク／プロパティへの誤った登録だけを整理。登録可能な購読／ペイウォール → 一律401ではなくGoogleのペイウォール構造化データを使います。
• 過剰な約束をせず確認して待つ。 Live Testが確認するのは現在のアクセスだけで、インデックス登録ではありません。Validate Fixは任意で、Googleは次の再クロールで件数を更新します。再登録には時間がかかり、公開された再試行間隔はなく、どちらの手順も登録、canonical選択、検索表示を保証しません。401はペナルティではありません。

公式ドキュメント

検索エンジンによる一次資料です。

Google

• ページのインデックス登録レポート — レポート本体と「Blocked due to unauthorized request (401)」ステータスの定義、403の兄弟ステータス、その他のHTTPステータス。
• HTTPステータスコード、ネットワークエラー、DNSエラーがGoogle検索に与える影響 — Googlebotの401処理、429を除く4xxの扱い、クロール速度の制限に401／403を使わないというルール。
• Googlebotとその他のGoogleクローラーの確認 — ユーザーエージェントではなく、IP／逆引きDNSでGooglebotを確認して許可リストに入れる推奨手順。
• GooglebotのIP範囲（googlebot.json） — WAF／CDNを通すための公開IP範囲。

Bing／Microsoft

• Bing Webmaster Toolsヘルプ — Bingには同一のステータス文字列はありませんが、401／403を返すURLは同様にアクセス不能として扱われ、インデックス登録されません。bingbotも匿名でページへ到達できる必要があり、同じ許可リスト修正のために確認済みIP範囲と逆引きDNS確認を公開しています。

ソースからの引用

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

Google — 401ステータスの意味（ページのインデックス登録レポート）

• “The page was blocked to Googlebot by a request for authorization (401 response). If you do want Googlebot to be able to index this page, either remove authorization requirements for this page, or else allow Googlebot to access your pages by verifying its identity.” (翻訳)「認証要求（401レスポンス）によってGooglebotがページをブロックされました。Googlebotにこのページをインデックス登録させたい場合は、ページの認証要件を削除するか、身元を確認してGooglebotがページへアクセスできるようにしてください」 — Google Search Consoleヘルプ、ページのインデックス登録レポート。 引用箇所へ

Google — Googlebotが401をどう扱うか（HTTPステータスコード文書）

• “All 4xx errors, except 429, are treated the same: Google crawlers inform the next processing system that the content doesn’t exist.” (翻訳)「429を除くすべての4xxエラーは同じように扱われます。Googleのクローラーは次の処理システムへ、コンテンツは存在しないと伝えます」 — Google Search Central文書。 引用箇所へ
• “Don’t use 401 and 403 status codes for limiting the crawl rate.” (翻訳)「クロール速度を制限するために401と403のステータスコードを使わないでください」 引用箇所へ

Patrick Stox — 401／403の定義と4xxがインデックスに与える影響

• “The client hasn’t identified or verified itself when needed.” (翻訳)「必要なときにクライアントが自身を識別または確認していません」（401）。 — Patrick Stox、HTTPステータスコードとSEOへの影響、Ahrefs。 引用箇所へ
• “The client is known but doesn’t have access rights.” (翻訳)「クライアントは認識されていますが、アクセス権がありません」（403）。 引用箇所へ
• “4xxs will cause pages to drop from the index.” (翻訳)「4xxはページをインデックスから削除させます」。 引用箇所へ

John Mueller、Google — サーバー側認証でサイトをゲートする方法

• “Ideally, what you would want to do is provide some kind of server side authentication on the server so that normal users when they go there would get blocked from being able to see the content; that would include GoogleBot.” (翻訳)「理想的には、サーバー側で何らかのサーバー側認証を提供し、通常のユーザーがそこへ行ったときにコンテンツを見られないようブロックすることです。そこにはGoogleBotも含まれます」 （Webmaster Hangout、2019年9月25日。Search Engine Journal経由で伝えられたもの。） 報道を読む

401の診断と修正チェックリスト

GSCで「Blocked due to unauthorized request (401)」が表示されたときに実行します。

• まず意図を決める — このURLを本当にインデックス登録したいか。完全に非公開／ステージングなら401は正しいので最後の項目へ進む。登録したい購読／ペイウォールなら認証削除の手順を飛ばし、ペイウォール構造化データを使う。
• ボットとして再現する — URLでURL Inspection → Live Testを実行し、認証エラーを確認する（ログイン済みブラウザーを信用しない）。
• Cookie／資格情報なしでcurl -I — **401**が返ることとWWW-Authenticateヘッダーを確認する。ブラウザーが200でここが401なら、それが問題。ヘッダーがあれば本当の認証ゲートで、なければレスポンスが不正という意味であり、生成層までは分からない。
• ゲートを特定する — エッジ／CDN、オリジン、アプリケーション、IDログを確認し、Basic Auth（.htpasswd）、メンテナンス／「近日公開」プラグイン、ログイン壁、WAF／CDN／IP許可リストのどれかを絞る。
• WAF／CDNなら — Googleをブロックしているファイアウォールイベントのルールを確認し、保護全体を無効にせず確認済みGooglebotのIP範囲を許可する。
• 正しい方法で修正する — 誤ってゲートされた公開ページの認証要件を削除する、またはボットセキュリティの誤検知なら、偽装可能なユーザーエージェントではなくIP／逆引きDNSで確認したGooglebotを許可する。本当に非公開のゲートへGooglebotを通さない。
• 再テストする — 未認証のcurl -Iが**200**を返し、URL InspectionのLive Testが取得できることを確認する。
• Validate Fix（任意） — ページのインデックス登録レポートで実行し、サンプルURLを再検査する。Googleは次の再クロールで件数を更新するため、Live Testの合格はアクセスを示すだけで登録を示さない。
• 期待値を置く — 再クロール／再登録には時間がかかり、保証された再試行間隔も検索表示の保証もない。ペナルティではない。
• 意図したゲートなら — ステージング／非公開URLがこのプロパティに属さないことを確認し、リンクや送信を止め、ゲートを維持する。

401と403、その他の4xx — チートシート

各コードの実際の意味（および典型的な原因）

Googleがインデックス登録でどう扱うか

修正方法の対応表

誤ってゲートされた公開ページに対する公式の2つの修正（Googleの文言）

1. ページの認証要件を削除する。
2. 身元を確認してGooglebotを通す — 偽装可能なユーザーエージェントではなく、IP／逆引きDNSで許可する。

本当に非公開／ステージングのコンテンツ（ゲートを維持）にも、登録可能なペイウォールコンテンツ（ゲートを開けずにペイウォールマークアップを使う）にも、この2つを適用しません。

メンタルモデル

1. ゲートとコンテンツを分ける。 401はコンテンツの問題ではありません。Googlebotはコンテンツまで到達していないため、問題はゲートにあります。ページを編集するのではなく、未認証のボットに対してゲートがどう応答するかを変えます。「ページは良いか」と「Googlebotはドアを通れるか」を常に分けて考えます。

2. すべては意図で決まる。 修正する前に、このURLをインデックス登録すべきかを決めます。登録すべきなら401は削除する設定ミスです。登録すべきでないなら401は意図どおりに動作しており、本当の問題はなぜそのURLがこのSearch Consoleプロパティに入っているかです。役割を果たしている401を直さないでください。

3. 自分ではなくボットとしてテストする。 「自分では動く」はここで最初に起きる判断ミスです。あなたにはセッション、Cookie、許可されたIPがあります。Googlebotにはありません。診断はそれらを取り除くところから始めます。資格情報なしのcurl -I、またはURL InspectionのLive Testを使います。

4. 401と403 — 結果は同じでもドアが違う。 インデックス登録では両方とも同じです（429を除く4xx）。RFCでは、401は有効な資格情報がない（送信されていない、または拒否された）、403はサーバーがリクエストを理解したうえで拒否した状態で、資格情報が理由の場合もそうでない場合もあります。「401＝自分で制御する認証ゲート、403＝誤動作するセキュリティルール」という整理は実務的な近道ですが、プロトコルの境界そのものではありません。ドアに向かって診断します。401なら認証／ステージング、403ならWAF／ファイアウォールを確認します。

5. ボットを確認し、名前を信用しない。 後で問題になるのは「Googlebotのユーザーエージェントを許可リストに入れる」修正です。その文字列は誰でも名乗れます。長く使える修正はIP／逆引きDNSによる身元確認です。Googlebotだと証明できるボットを許可し、そう名乗っているだけのボットは許可しません。

401を診断する：意図したゲートか設定ミスか

最初の分岐は技術ではなく意図です。設定に触れる前に、URLをインデックス登録すべきか決めます。本当の設定ミスだと分かったら、次に、解除し忘れたログイン壁か、Googlebotを誤ってブロックするWAF／CDNルールかを分けます。ツリーを進んでください。

401の件数を追う — 存在するかどうかだけではない

見るべき1つの数字は、ページのインデックス登録レポートで「未認証リクエストによるブロック（401）」の行に入っているURL数を時間の経過とともに追ったものです。行が存在するかだけではいけません。1回のスナップショットでは、問題を直しているのか、ゲートされたURLを増やしているのか分からないからです。

401バケットの件数を時間で追う

• 指標 — GSCのページのインデックス登録レポートで「未認証リクエストによるブロック（401）」に入っているURL数を週ごとに追います。
• 分かること — 修正が実際に効いたか、新しい401が増えていないか。認証要件を削除するか確認済みGooglebotを許可した後、直したURLの件数はゼロに近づくはずです。意図的にゲートしているURL（ステージング、非公開セクション）は横ばいでよく、増加するなら新しい非公開URLが誤ってこのプロパティにリンクまたはサイトマップ掲載されています。
• 取得方法 — GSCのページのインデックス登録レポートを401行で絞り、個別URLをURL Inspection → Live Testで確認して古いスナップショットではないことを確かめます。
• ベンチマーク／現実的な範囲 — 一律の目標はありません。意図的にゲートするページ数で決まります。正直な基準は、登録したいURLの401はゼロ、意図的に認証の背後に置くURLは増えず横ばいです。傾向を判断する前に、自分のベースライン件数を作ります。
• 頻度 — 修正直後は件数が安定するまで週次、その後は回帰チェックとして月次で確認します。

手順書：診断、修正、確認

401のワークフローは短い順序付きのループです。意図を確認し、ボットとしてブロックを再現する前に「修正」へ飛ばさないでください。

1. まず意図を決める。 このURLは本当にインデックス登録すべきですか。本当に非公開またはステージングなら、ここで止めます。401は正しく、次にするのはURLがこのプロパティへリンクまたはサイトマップ掲載されていないことの確認だけです。ゲートを弱めません。登録したい購読／ペイウォールコンテンツなら、認証ゲートに触れず、ペイウォール構造化データの修正へ進みます。

2. 自分ではなくボットとして再現する。 GSCでURL Inspection → Live Testを実行し、別途Cookieと資格情報なしでcurl -Iを送ります。curlが401を返し、ログイン済みブラウザーが200を返すなら、その差が問題です。あなたは認証済みまたはIP許可済みで、Googlebotはそうではありません。

3. ゲートを特定する。 匿名レスポンスにWWW-Authenticateヘッダーがあるか確認します。適合する401にはヘッダーが必要なので、存在すれば本当の認証ゲート（Basic Auth、ログイン壁、メンテナンスモード）だと分かります。ない場合は原因が分かるのではなく、レスポンスが不正だという意味です。WAF／CDN／許可リストのルールだと結論する前に、エッジ／CDN、オリジン、アプリケーション、IDプロバイダーのログを照合します。

4. 原因に応じて直す。 誤って公開ページをゲートしているなら、そのパスの認証要件を削除します。WAF／CDNルールが公開ページを誤ってブロックしているなら、偽装可能なユーザーエージェントだけに頼らず、ファイアウォールでIPまたは逆引きDNSで確認したGooglebotを許可します。本当に非公開のコンテンツを守るゲートにはGooglebotを通しません。

5. 確認する。 同じ匿名のcurl -Iを再実行し、200が返ることを確認します。ページのインデックス登録レポートのValidate Fixは追跡用の任意操作です。Googleは次の再クロールで件数を更新します。URL InspectionのLive Testが確認するのもGoogle-InspectionToolが現在アクセスできることだけで、登録されることではありません。

6. 期待値を置いて止める。 再クロールと再登録には時間がかかり、公開された再試行間隔はありません。Live TestもValidate Fixもインデックス登録や検索表示を保証しないため、待っている間に同じURLを二度「修正」しないでください。数週間たってもGSCの401バケットが減らないなら、新しい原因を推測するのではなく、手順2へ戻ってボットとして再現します。

すぐ使えるAIプロンプト

生の診断出力から401の原因を分類するための、コピーして使えるプロンプトです。原因をすばやく絞る助けになりますが、変更前には必ず実際のサーバー／ファイアウォール設定で結論を確認してください。

curl出力から考えられる原因を分類する

I'm diagnosing a "Blocked due to unauthorized request (401)" status in Google
Search Console. Below is the raw output of an unauthenticated request to the
URL (curl -I, no cookies, no credentials). Based on this output alone,
classify the most likely cause as one of: (1) staging/dev site behind Basic
Auth, (2) accidental HTTP auth or maintenance-mode gate left on a public
section, (3) WAF/CDN/IP-allowlist blocking Googlebot, (4) a login wall on
content that's meant to be gated. Explain which specific header or detail in
the output pointed you to that answer, and tell me what's missing if you
can't tell for sure.

CURL OUTPUT:
[paste]

WAF／ファイアウォールのログ行から原因を分類する

I'm investigating why Googlebot is getting a 401 or 403 on a page I want
indexed. Below is a log line (or a few) from my WAF/CDN showing a blocked
request. Tell me whether this looks like a bot-identity rule (blocking by
user-agent or IP range), a rate-limit/challenge rule, or something else, and
what I'd need to allowlist — by IP range or reverse-DNS — to let verified
Googlebot through without disabling the rule entirely.

LOG LINE(S):
[paste]

出荷前に修正をサニティチェックする

I'm about to remove an authorization requirement from a URL that's currently
returning 401 to Googlebot, because I want it indexed. Here's a short
description of the current gate and what I'm about to change: [describe].
Point out anything I might be missing — e.g. whether this could accidentally
expose a section I meant to keep private, or whether I should allowlist
verified Googlebot instead of removing the auth requirement outright.

自分で確認：「未認証リクエストによるブロック（401）」

401の意味、403との違い、診断と修正方法についての5問です。それぞれ答えを選んでから確認してください。

匿名リクエストとして401を再現する

このチェックの目的はAdvancedタブと同じです。ブラウザーは認証済みですが、Googlebotはそうではありません。Cookieと資格情報を完全に外し、匿名クライアントが実際に受け取るものを確認します。

macOS / Linux

# Fetch headers only, with no cookies and no credentials
curl -sI https://www.example.com/page/
# Look for:
#   HTTP/1.1 401 Unauthorized
#   WWW-Authenticate: Basic realm="..."   <- confirms a real auth gate

Windows (PowerShell)

# -SkipHttpErrorCheck so PowerShell shows the 401 instead of throwing
Invoke-WebRequest -Uri "https://www.example.com/page/" -Method Head `
  -SkipHttpErrorCheck | Select-Object StatusCode, Headers
# Check the Headers output for WWW-Authenticate

これがWWW-Authenticateヘッダー付きの401を返すなら、本当の認証ゲート（Basic Auth、ログイン壁）だと確認できます。RFC 9110では適合する401にヘッダーが必要です。WWW-Authenticateヘッダーなしで401／403を返す場合、レスポンスが不正または不完全だという意味であり、どの層が生成したかは分かりません。ヘッダーがないだけでWAFやCDNと証明されるわけではありません。自分のネットワーク外からだけブロックされるなら、IPスコープのルールがWAF／CDN／IP許可リストの強い手がかりです。ファイアウォール／CDNログで確認し、別ネットワークから再テストするか、GooglebotとしてリクエストするGSCのURL Inspection Live Testを使います。

許可リストに入れる前に、本当にGooglebotか確認する

「Googlebot」と名乗るリクエストをWAFルールで通す前に、IPが本当にGoogleのものか確認します。ユーザーエージェント文字列を偽装したトラフィックは多数あります。

macOS / Linux

# 1) Reverse DNS the IP from your logs — must end in googlebot.com / google.com
host 66.249.66.1
# → ... domain name pointer crawl-66-249-66-1.googlebot.com

# 2) Forward DNS that hostname back — it must resolve to the same IP
host crawl-66-249-66-1.googlebot.com
# → crawl-66-249-66-1.googlebot.com has address 66.249.66.1

Windows

nslookup 66.249.66.1
nslookup crawl-66-249-66-1.googlebot.com

逆引きがGoogleのドメインで終わらない、または正引きが元のIPと一致しない場合は許可リストに入れないでください。本物のGooglebotではありません。Googleの公開範囲（googlebot.json）と照合することも、Googlebot Verifierで直接確認することもできます。ユーザーエージェント文字列だけでなく、確認済みの身元で許可します。

401を診断・修正するツール

• HTTP Status Checker — 対象URL（または一括）を貼り、ステータスコードと完全なレスポンスチェーンを確認し、認証ゲートに到達する前のリダイレクトを検出します。
• Googlebot Verifier — Googlebotを名乗るIPが本物か（公開IP範囲と逆引きDNSで確認）を調べてから、WAFまたはファイアウォールのルールを通します。
• Google Search Console — URL Inspection → Live Test — Googlebotが受け取る正確なレスポンスと、現在認証でブロックされているかを確認する最も近い手段です。
• curl -I — Cookieや資格情報なしでURLを要求し、WWW-Authenticateを含む生のステータス行とヘッダーを読む最速の方法です。
• WAF／CDNのファイアウォールイベントログ（Cloudflare、Akamai、Sucuriなど）— GooglebotのIP範囲に401／403を返している具体的なルールを見つけます。

修正が実際に効いたことを証明する

認証要件を削除するか、確認済みGooglebotを許可したら、「設定が変わった」ことと「Googleが実際にページへ到達できる」ことを分ける次のチェックを順番に実行します。

テスト1 — 匿名リクエストが200を返す

• 実行 — Cookieと資格情報なしで対象URLにcurl -Iを実行します（またはHTTP Status Checkerで確認）。
• 期待する結果 — ステータス行がHTTP/1.1 200 OKで、WWW-Authenticateヘッダーがありません。
• 失敗の読み方 — まだ401なら、そのパスの認証要件が実際には削除されていないか、間違ったURL／環境をテストしています。401ではなく403なら、別のゲートに置き換わっています。WAF／CDNルールを確認します。
• 監視期間 — 変更が有効になればサーバーはすぐ応答するため、即時です。
• ロールバック条件 — ゲートを削除して非公開にしたいコンテンツが露出したら、直ちに認証要件を戻し、代わりにIP／逆引きDNSで確認したGooglebotを許可します。

テスト2 — Googleが到達できることを確認する

• 実行 — Google Search Consoleで対象URLにURL Inspection → Test Live URLを実行します。
• 期待する結果 — Live Testが成功し、認証エラーなしでページ内容を表示します。Google-InspectionToolが現在アクセスして解析できることの確認であり、登録の保証ではありません。Googleの文書でも、Live Testはすべての登録条件をテストせず、合格してもインデックスへの掲載を保証しないと説明されています。
• 失敗の読み方 — 匿名curlが成功したのにLive Testが認証ブロックを報告するなら、一般的な認証ゲートではなく、GooglebotのIP範囲にだけ適用されるWAF／CDN許可リストの可能性を疑います。
• 監視期間 — 修正直後から数分です。
• ロールバック条件 — なし。読み取り専用のテストです。失敗するならロールバックせず、テスト1の失敗分岐へ戻ります。

テスト3 — ページのインデックス登録レポートから401が消える

• 実行 — ページのインデックス登録レポートで「未認証リクエストによるブロック（401）」の問題にValidate Fixを実行します（任意。Googleは次の再クロールでも件数を更新します）。その後数週間、401バケットの件数を追います（How to Measureタブを参照）。
• 期待する結果 — URLが401バケットから移動し、以前登録されていたなら時間をかけてインデックスへ戻ります。Validate FixもLive Testの合格も、インデックス登録、canonical選択、検索表示を保証しません。実際の登録状態と検索パフォーマンスを別に追跡します。
• 失敗の読み方 — 公開された再試行間隔はないため、検証が遅いことを新しい失敗と解釈しません。数週間たっても401バケットが減らなければ、テスト1を再実行して修正が残っているか確認します。再デプロイやCDNキャッシュがゲートをひそかに戻すことがあります。
• 監視期間 — 401バケットの件数を追いながら、数日から数週間です。
• ロールバック条件 — テスト1が再び失敗したときだけゲートを見直します。ページのインデックス登録レポートの反映タイミングを追いかけて変更を戻さないでください。

変更履歴