言語

401 Unauthorized（認証が必要）

HTTP 401 Unauthorizedの意味、403 Forbiddenとの違い、Googleが認証で保護されたページをどう扱うか、そしてSEOへの影響を解説します。

初回公開：2026年6月28日 · 最終更新：2026年8月22日 · Advanced
言語
AI執筆者：AI v2
このページには証拠シグナルが1件あります

401 Unauthorizedは、有効な認証情報がないためリクエストが拒否されたことを意味します。サーバーはログインを求めています。認証情報を送ったもののアクセスを拒否される403 Forbiddenとは異なりますが、インデックスについてGoogleは同じように扱います。Googlebotは認証情報を送らないため、401ページのコンテンツはGoogleにとって実質的に存在せず、インデックスされません。すでにインデックスされていたURLも時間とともに外れます。ステージングサイトや会員エリアをゲートする401は自動的に悪いものではなく、正しい用途です。ランキングさせたいページに当たった場合だけ問題で、一般的な神話とは異なりサイト全体のクロールレートには影響しません。

TL;DR — 401 Unauthorizedは、リクエストに有効な認証情報がないことを意味するクライアントエラーです（RFC 9110 §15.5.2。RFC 7235に取って代わりました）。送信したものの拒否された認証情報も含み、まったく送信されなかった場合だけではありません。準拠した401は、想定するスキームを示すWWW-Authenticateヘッダーも送ります。認証チャレンジを必要としない、または認証情報と無関係なこともある403とは異なります。しかしGoogleは、429を除くすべての4xxをインデックス上は同じように扱います。コンテンツは「doesn’t exist」 (翻訳)「存在しない」ため、インデックスされず、以前インデックスされていたURLは時間とともに外れます。通常のGooglebotは認証情報を送らないため、Google自身の言葉では、Googlebotへの403は通常サーバーの設定ミスです。401/403はサイト全体のクロールレートに影響しません（広く繰り返される神話です）が、4xxを返し続ける個別URLは時間とともにクロール頻度が下がります。401は本当に非公開のコンテンツを制限する、Googleも認める正しい方法です。インデックスさせたいページに当たった場合だけ問題です。ペイウォールには、すべてを401にするのではなく、認められた方法があります。

401の正体

401 Unauthorizedはクライアントエラーのレスポンスです。MDNの定義が、技術的には最も明快です。

「The HTTP 401 Unauthorized client error response status code indicates that a request was not successful because it lacks valid authentication credentials for the requested resource. This status code is sent with an HTTP WWW-Authenticate response header that contains information on the authentication scheme the server expects the client to include to make the request successfully.」 (翻訳)「HTTPの401 Unauthorizedクライアントエラーレスポンスステータスコードは、要求されたリソースに有効な認証情報がないため、リクエストが成功しなかったことを示します。このステータスコードは、クライアントがリクエストを成功させるために含めるべき認証スキームの情報を持つHTTP WWW-Authenticateレスポンスヘッダーとともに送られます。」

Evidence for this claim A 401 response means the request lacks valid authentication credentials and the response must include a WWW-Authenticate challenge. Scope: RFC 9110 defines the status semantics and required challenge header; it does not prescribe a site's authentication product or login flow. Confidence: high · Verified: IETF: RFC 9110 §15.5.2 — 401 Unauthorized

ここから2点を取り出せます。1つ目は「authentication」、つまりリクエスターが自分の身元を証明していないことです。通常は認証情報の欠落、無効、期限切れを意味しますが、送信した認証情報が拒否された後にも401は返ります。実際にリクエストを確認せず、「認証ヘッダーがまったくない」と決めつけないでください。2つ目は、仕様に準拠した401にはWWW-Authenticateヘッダーが必ず付くことです。古いRFC 7235に取って代わったRFC 9110 §15.5.2に基づき、クライアントが想定されるスキーム（HTTP Basic Auth、Bearerトークン、セッションCookieフローなど）を伝えます。401をデバッグするなら、そのヘッダーが存在するか、どのスキームを示すかを最初に調べてください。 Evidence for this claim A 401 response means the request lacks valid authentication credentials and the response must include a WWW-Authenticate challenge. Scope: RFC 9110 defines the status semantics and required challenge header; it does not prescribe a site's authentication product or login flow. Confidence: high · Verified: IETF: RFC 9110 §15.5.2 — 401 Unauthorized

私のstatus-codes guide では、401を「the client hasn’t identified or verified itself when needed.」 (翻訳)「必要なときにクライアントが自分を識別または検証していない」とまとめています。それがすべての核心です。まだ誰も自分が誰かを示していません。

401と403 Forbidden：重要な違い

ここは多くの人が曖昧になるため、はっきりさせます。一言で言うと：

  • 401＝「Who are you?」 (翻訳)「あなたは誰ですか？」。認証情報がないか無効なので、認証して再試行する。
  • 403＝「I know who you are, but no.」 (翻訳)「あなたが誰かは分かっているが、だめだ」。リクエストは理解されたが、認証情報にかかわらずアクセスが拒否される。

MDNも同じように説明しています。

「A 401 Unauthorized is similar to the 403 Forbidden response, except that a 403 is returned when a request contains valid credentials, but the client does not have permissions to perform a certain action.」 (翻訳)「401 Unauthorizedは403 Forbiddenレスポンスに似ています。ただし403は、リクエストに有効な認証情報が含まれていても、クライアントに特定の操作を行う権限がない場合に返されます。」

私のガイドでも同じ対比をしています。401は「the client hasn’t identified or verified itself when needed」 (翻訳)「必要なときにクライアントが自分を識別または検証していない」、403は「the client is known but doesn’t have access rights」 (翻訳)「クライアントは識別されているがアクセス権がない」です。Authenticationとauthorizationの違いです。

この一言は信頼できる短縮表現ですが、コードやWAFルールで2つを選ぶ必要があるなら、より明確なプロトコル上のテストがあります。401にはWWW-Authenticateチャレンジが必要です。RFC 9110はMUSTと定めています。一方403には不要です。403の拒否は、認証情報と無関係な理由（IPブロック、権限ルール、レート制限ポリシー）でも起こるためです。そのため「認証情報が存在したか」だけでは区別できません。401は、ない認証情報だけでなく、拒否された認証情報の後にも返ります。返すコードを決めるなら、「認証チャレンジを出すのか（401）、単に拒否するのか（403）」と考えてください。

ここに見落としやすいSEO上のひねりがあります。これはGoogle自身が403について述べている点です。通常のGooglebotは決して認証情報を送りません。 そのため、特にGooglebotへ配信した403は、Google自身の言葉ではサーバーが誤っている状態です。

「HTTP 403 means that the user agent provided credentials, but was not granted access. However, Googlebot never provides credentials, so your server is returning this error incorrectly. The page will not be indexed.」 (翻訳)「HTTP 403は、ユーザーエージェントが認証情報を提供したものの、アクセスを許可されなかったことを意味します。しかしGooglebotは認証情報を決して提供しないため、サーバーはこのエラーを誤って返しています。ページはインデックスされません。」

これは有用な診断です。Googlebotへの401は意図的な場合があります（ページが設計上ゲートされている）。Googlebotへの403は通常設定ミスを示します。Googlebotは認証情報を送らないため、「認証情報が拒否された」レスポンスを発生させるものがないはずです。Googlebotが到達すべきページで403が出るなら、まずCDN、WAF、サーバー設定を疑ってください（ここで説明しているのはGoogleの一般的なクローラーです。Googleは特殊用途のクローラーやユーザー起点のフェッチャーを別カテゴリーとして文書化し、それぞれ異なる挙動を持つため、「決して認証情報を送らない」ルールをすべてのGoogleプロダクト連携に一般化しないでください）。

401 Unauthorized403 Forbidden
意味認証情報がない／無効 — 「あなたは誰？」理解したがアクセス拒否 — 「分かったが、だめ」
必須ヘッダーWWW-Authenticate（RFC 9110）必須なし
典型的なトリガーログインウォール、期限切れトークン、Basic Auth、セッションタイムアウト権限ルール、IP／地域ブロック、WAFルール、ディレクトリ制限
Googlebotに対して意図的な場合がある（ページがゲートされている）通常はサーバー設定ミス（Googlebotは認証情報を送らない）
インデックス結果インデックスされない。時間とともに外れるインデックスされない。時間とともに外れる

最後の行が要点です。インデックスに関して、Googleは両者を同じように扱います。

Googleは401ページをどう扱うか

GoogleのHTTP status codes doc は、4xxファミリーについて率直に説明しています。

「Google doesn’t use the content from URLs that return 4xx status codes. If a URL was previously used but is now returning 4xx status code, Google systems will stop using the URL over time. In the case of Google Search, Google doesn’t index URLs that return a 4xx status code, and URLs that are already indexed and return a 4xx status code are removed from the index.」 (翻訳)「Googleは4xxステータスコードを返すURLのコンテンツを使いません。URLが以前使われていたものの、現在4xxステータスコードを返している場合、Googleのシステムは時間とともにそのURLの利用を停止します。Google検索では、4xxステータスコードを返すURLはインデックスされず、すでにインデックスされていて4xxステータスコードを返すURLはインデックスから削除されます。」 Evidence for this claim Google does not index 4xx URLs and removes already-indexed 4xx URLs over time. Scope: Google's crawler documentation supports the Search indexing outcome for 401 responses; it does not address access decisions for private users. Confidence: high · Verified: Google: How HTTP status codes affect Google's crawlers

そして401は、このファミリーの中で特別扱いされません。文書の表では、401 (unauthorized) and 403 (forbidden) が別の行にあり、説明は1つを共有しています。

「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のクローラーは、次の処理システムにコンテンツが存在しないと伝えます。」

つまり、結果は降格ではなく二値です。401のページは「ランキングが下がる」のではなく、そもそもインデックスされないか、以前インデックスされていた場合は完全に削除されます。部分的なペナルティはありません。これは私のガイドにある基本的な主張4xxs will cause pages to drop from the index とも一致します。この記事はその401特化の深掘りです。

タイミングには注意が必要です。削除は最初の不正な取得で起きるのではなく、「over time」 (翻訳)「時間とともに」起きます。Googleの文書も段階的なプロセスとして説明しており、クロールシステムは歴史的に、URLが本当に消えたと扱う前に短期間のエラーを許容すると説明されてきました。

クロールレートの神話：401はクロールを遅くしない

これは、良い記事を書いている人でも多くつまずく点なので、正確に述べます。401（または403）はGoogleのクロールレートを下げません。 Googleは直接こう述べています。

「Don’t use 401 and 403 status codes for limiting the crawl rate. The 4xx status codes, except 429, have no effect on crawl rate.」 (翻訳)「クロールレートの制限に401や403ステータスコードを使わないでください。429を除く4xxステータスコードは、クロールレートに影響しません。」

これは、401の背後にページを置くと「クロールバジェットを節約する」「クロールバジェットを浪費する」という助言が見つかるため重要です。どちらの説明も誤りです。Googlebotに後退を求めるのは429だけであり、503のような5xx系シグナルも同様です。401はスロットルではなく、インデックスに対して「コンテンツが存在しない」と伝えるシグナルです。クロールを一時的に遅くしたいなら、429/503です（401/403ではありません）。

ここで、混同しやすい2つの主張の範囲を分けておきます。「クロールレートに影響しない」は、サイト全体のクロールレートについてです。一方、Googleは4xxを返し続ける個別URLの再クロール頻度が時間とともに下がると述べています。これは別の範囲です。サイト全体のクロールバジェットは抑制されませんが、GoogleがそのURLの優先度を下げるため、401を続けるURLはチェック頻度が下がります。

もう1つ知っておくべき特殊例があります。通常のページの401と、/robots.txt自体の401は同じ扱いではありません。/robots.txtが429以外の4xx（401を含む）を返すと、Googleはrobots.txtが存在しないかのように扱います。そのファイルによるクロール制限はないと判断するのであって、サイト全体に到達できないとはみなしません。/robots.txtを非公開ページと同じ認証ウォールの背後に置かないでください。

401は常に問題か？ いいえ。

401は、公開したいページで意図せず返された場合だけバグです。ページが本当に非公開なら、401は検索から除外するための正しい方法であり、Googleも推奨しています。John MuellerはSearch Engine Journalが伝えた発言で、理想的な方法は通常のユーザーがコンテンツを見られないサーバー側認証であり、「that would include GoogleBot」 (翻訳)「それにはGoogleBotも含まれる」と明確に述べています。（Search Engine Journal が2019年のGoogleハングアウトから伝えた内容。断片を逐語検証した引用ではなく、正確に言い換えられた担当者発言として扱ってください。）

サーバー側認証（401を生成するもの）は、非公開コンテンツを隠すために彼が推奨する仕組みです。robots.txtより優先されるのは、ボットに外に出てほしいと頼むだけでなく、実際にアクセスをブロックできるからです。

判断の枠組みは簡単です。

  • 401のままにするべき： ステージング環境、会員限定エリア、内部ツール、本当に非公開なもの。設計どおりに動いています。修正しないでください。
  • 修正が必要： 公開され、インデックス可能なページが誤って401を返している場合。CDN／WAFの誤検知、残ったBasic Auth、期限切れのトークン、プラグイン／ミドルウェアの競合などが原因です。

SEOへの影響と「自分には動く」罠

実際に起きる失敗は次のとおりです。

  • インデックスさせたいページが見えないままになる。 ゲートを外すまで続きます。
  • 以前ランキングしていたページが消える。 401を返し始めた場合です。
  • 「自分には動く」罠： テストしている人は認証済み、ログイン済み、または許可リストのIPにいます。クローラーは違います。401についてGoogleが示す方法は*「You can verify this error by visiting the page in incognito mode.」* (翻訳)「シークレットモードでページにアクセスすれば、このエラーを確認できます」です。さらに、curl -I https://example.com/page を使って未認証でテストするか、Search ConsoleのURL検査／ライブテストを使ってください。

実際のクローラーを通す必要がある場合は、ユーザーエージェント文字列を信頼せず、IP／逆引きDNSで確認してください。ユーザーエージェント文字列は簡単に偽装できるため、「Googlebot」という名前だけで許可リストに入れるのはセキュリティホールであり、修正ではありません。

ペイウォールや購読者限定コンテンツはどうするか

ゲート付きコンテンツをランキングさせたい場合、全員（Googlebotを含む）に一律401を返す以外の選択肢があります。Googleは、isAccessibleForFree構造化データ を使い、購読者／登録ユーザー向けコンテンツについてGoogle専用クローラーの識別情報にアクセスを許可する方法で、ペイウォールコンテンツのインデックスをサポートしています。このマークアップの目的は次のとおりです。

「This structured data helps Google differentiate paywalled content from the practice of cloaking, which violates spam policies.」 (翻訳)「この構造化データは、ペイウォールコンテンツと、スパムポリシーに違反するクローキング行為をGoogleが区別する助けになります。」

ここに組み込まれた警告があります。構造化データで開示せず、Googlebotにだけ完全なコンテンツをひそかに配信するのはクローキングであり、スパムポリシー上のリスクです。ゲート付きコンテンツをインデックスさせたいなら、静かなバイパスではなく、認められた方法（マークアップ＋クローラーアクセス）を使ってください。

望まない401を修正する方法

  1. 本当に望まない401か確認する。 このページは公開されるべきですか？ステージングや会員限定なら、修正するものはありません。
  2. 公開ページの認証要件を外す。 残ったBasic Auth（.htaccess／nginx）を取り除き、期限切れのトークンを修正し、プラグイン／ミドルウェアの競合を解消します。
  3. CDN／WAFを確認する。どの層が401を出したか、すでに分かっているとは考えない。 レスポンス（およびWWW-Authenticateヘッダー）はチャレンジが起きたことを示しますが、発生場所は示しません。アプリ、ID／認証プロキシ、CDNまたはWAFのボット管理ルール、オリジンサーバーは、どれも401を生成できます。エッジのボット管理ルールによる誤検知はよくある原因です。各層のログを調べ、許可リストに入れる前に逆引きDNSでGooglebotを確認してください。
  4. 確認済みクローラーをユーザーエージェントではなくIP／逆引きDNSで通す。
  5. 公開できるページをインデックスから外すために401を使わない。 代わりに、クロールを許可したままnoindexを使います。ログインウォールは本当に非公開であるべきコンテンツ用です。
  6. URL検査のライブテストで修正を検証する。 ただし合格は現在の取得の確認であり、保証ではありません。401修正後の再クロール、再インデックス、ランキング回復について、Googleは固定のタイムラインを約束していません。ライブテストの合格は、Googleのライブ取得が通ったことを示すだけです。スケジュールされたクロールやインデックスが追いつくまで時間を置き、即時の反転を期待せずPage Indexingレポートを再確認してください。

401のPage Indexingステータス「Blocked due to unauthorized request (401)」 (翻訳)「未認証リクエストのためブロック（401）」について、Google Search Consoleで診断、修正、検証する完全なワークフローは、専用の関連記事を参照してください。この記事はプロトコルと概念のレベルにとどめます。

Bing

Bingも機能上は同じです。Bingbotに401（または403）を返すURLはアクセス不能で、インデックスされません。BingbotもGooglebotと同じく未認証アクセスを必要とするため、許可リストにはユーザーエージェントではなく、公開されたIP範囲で確認します。

Try it live

This is a real endpoint on this site — not a simulation. Hit it from the button, open it in a new tab, or curl -i it from your terminal, and the server answers with the actual status code this article is about.

Open in new tab ↗

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.