本文へ移動
リライトレーダーRewrite Radar
メニュー

公開

「未承認のリクエスト(401)」「アクセス禁止(403)」はGooglebotが締め出された状態

どちらもGooglebotが玄関で断られ、中身が読まれていない状態です。公式は403について「Googlebot は認証情報を提供しないため、サーバーは間違ってこのエラーを返しています」と書き、4xxはすでに登録されているURLを削除するとも明記。自分のブラウザで開ける理由と、個人ブログの4典型を整理しました。

この記事のまとめ

「未承認のリクエスト(401)が原因でブロックされました」と「アクセス禁止(403)が原因でブロックされました」は、どちらもGooglebotが玄関で止められて、中身を一度も読めなかった状態です。公式ヘルプは401を「このページへのアクセスには認証が必要なため、Googlebot のアクセスがブロックされています」と説明し、403については「Googlebot は認証情報を提供しないため、サーバーは間違ってこのエラーを返しています」と書いています。

記事の中身は判定に関与していません。HTTPステータスの公式ドキュメントは「Google は、4xx ステータス コードを返す URL のコンテンツを使用しません」とし、「すでにインデックスに登録されている URL が 4xx ステータス コードを返すと、その URL はインデックスから削除されます」とも明記しています。だからリライトでは消えず、すでに検索結果に出ていたURLなら、放っておくとそこからも消えます。

自分のブラウザで普通に開けるのは、締め出しの条件が「誰が来たか」で変わるからです。個人ブログでよくあるのは会員限定の設定・公開前の環境に残ったパスワード・セキュリティ側の誤検知・海外からのアクセスの遮断で、この記事ではこの4つに整理しました(網羅ではありません)。意図してそうしているなら直す必要はありません。

記事ではなく認証・防御設定を確認する
図は左右にスクロールして読めます。

サーチコンソールの「ページ」を開いたら、見たことのない数字が並んだ行にURLが入っていた。「未承認のリクエスト(401)が原因でブロックされました」か、「アクセス禁止(403)が原因でブロックされました」です。

この2つは、意味を推測しづらい行です。しかも困るのは、そのURLを自分のブラウザに貼ると普通に表示されることです。見えているのに「ブロックされました」と言われるので、Googleの誤りだと思ってしまいます。

結論を先に書きます。どちらも、Googlebotがそのページを取りに行って、玄関で断られた状態です。断ったのはGoogleではなく、あなたのサイト側のサーバーです。だから記事の中身は一切関係がなく、書き直しても消えません。

直すかどうかの分かれ目は1つだけです。そのURLを検索結果に出したいのかどうか。会員限定ページや公開前の環境なら、閉じたままで正しい状態です。

次に直す記事を自分のデータで調べる

Search ConsoleのZIPを読み込むと、候補の判定と1記事分の診断カードを無料で確認できます。登録は不要です。ZIPが無い場合は、診断カードの見本を確認できます。

この2つの行は何を言っているのか

まず公式ヘルプの説明文を、両方とも全文で並べます。短いので、ここを読むのがいちばん早いです。

未承認のリクエスト(401)が原因でブロックされました
このページへのアクセスには認証が必要なため、Googlebot のアクセスがブロックされています(401 レスポンス)。Googlebot がこのページをインデックスに登録できるようにするには、認証機能を使ったページの保護を削除するか、Googlebot からのアクセスであることを確認して、ページへのアクセスを許可します。シークレット モードでこのページにアクセスすると、このエラーを確認できます。
— Google公式ヘルプ「ページ インデックス登録レポート」
アクセス禁止(403)が原因でブロックされました
HTTP 403 は、ユーザー エージェントが認証情報を提供したものの、アクセス権が付与されなかったことを意味します。しかし、Googlebot は認証情報を提供しないため、サーバーは間違ってこのエラーを返しています。このページはインデックスに登録されません。Googlebot がこのページをインデックスに登録するようにするには、ログインしていないユーザーを承認するか、Googlebot のリクエストを認証なしで明示的に許可する必要があります(ただし、Googlebot からのアクセスであることを確認する必要があります)。
— Google公式ヘルプ

共通しているのは「Googlebotが入れなかった」という一点です。違うのは、公式がその状況をどう位置づけているかです。

行公式の説明文が言っていること設計どおりでも出るか
未承認のリクエスト(401)「このページへのアクセスには認証が必要なため」ブロックされている出る。認証をかけていれば、そう返るのが正しい
アクセス禁止(403)Googlebotは認証情報を出さないので「サーバーは間違ってこのエラーを返しています」出る。ただし公式は「間違って」と書いている(403の定義とGooglebotの挙動のずれを指した言い方)

⚠️ 403の「間違って」を「403は全部あなたの設定ミスだ」と読み替えないでください。ここで公式が言っているのは、403という番号の本来の意味(認証情報を出したが権限が無かった)と、Googlebotの振る舞い(そもそも認証情報を出さない)がずれているという指摘です。結果として何が起きるかは401と同じで、そのページはインデックスに登録されません。

⚠️ もう1つ、確認手順について補足します。 2026年9月10日にページ インデックス登録レポートの日本語ヘルプの本文を取得して全文を検索したところ、「シークレット モードでこのページにアクセスすると、このエラーを確認できます」という一文が付いていたのは401の説明文だけで、403の説明文には付いていませんでした。確認したのはこの1ページの本文だけです。なぜこの差が効いてくるのかは、後で書きます。

なぜ、自分では開けるのにGooglebotは締め出されるのか

締め出しは、サーバーがレスポンスを返す瞬間に決まっているからです。これが分かると、これから挙げる3つが全部同じ1点から出ていることが見えます。

① Googlebotは、認証情報を持たない客である

Googlebotは認証情報を出しません。公式ヘルプが403の説明文で「Googlebot は認証情報を提供しないため」と書いているのが、そのまま根拠です。

つまり「ログインすれば読める」ページは、Googleにとって読めないページです。自分が管理画面にログインした状態でそのURLを開けば、当然中身が表示されます。そこで見えている画面は、Googlebotが見ている画面ではありません。

公式は、この状態を意図してつくる手段としても案内しています。Googlebotのドキュメントには、ブロックの方法を選ぶ場面でこう書かれています。

クローラーとユーザーによるページへのアクセスを完全にブロックする場合はパスワード保護などの他の方法を使用してください。
— Google公式「Googlebot」

会員限定ページが401や403になっているのは、この案内どおりに動いている状態です。そこは直す場所ではありません。

② 判定はレスポンスの時点で終わっていて、中身は読まれない

4xxが返った時点で、そのURLの中身はGoogleの処理に渡りません。HTTPステータスコードの公式ドキュメントは、4xx全体についてこう書いています。

Google は、4xx ステータス コードを返す URL のコンテンツを使用しません。以前は使用されていた URL が 4xx ステータス コードを返すようになった場合、Google のシステムは徐々にその URL の使用を停止します。Google 検索の場合、Google は 4xx ステータス コードを返す URL をインデックスに登録しません。また、すでにインデックスに登録されている URL が 4xx ステータス コードを返すと、その URL はインデックスから削除されます。
— Google公式「HTTP ステータス コードが Google のクローラーに及ぼす影響」

ここから2つのことが出ます。1つは記事をリライトしてもこの行は消えないこと。読まれていないものを書き直しても、返るレスポンスは変わりません。 もう1つはすでに検索結果に出ていたURLがこうなった場合、放置すると消えることです。後者は時間の問題なので、先に確認してください。

③ 締め出す条件は「誰が来たか」で変わるので、自分の画面では再現しない

ここが、この行のいちばん厄介なところです。401や403を返すかどうかは、リクエストの中身を見て決まります。そして、あなたのブラウザとGooglebotではリクエストの中身が違います。

見ている条件あなたのブラウザGooglebot
ログイン状態(Cookie)ログイン済みのことが多い持たない(公式いわく「認証情報を提供しない」)
User-Agent普通のブラウザGooglebotと名乗る
アクセス元のIP日本の自宅や職場大部分が米国(公式の記述。後述)

3つとも違います。だから「自分が開けるかどうか」は、Googlebotが開けるかどうかの証明になりません。401の説明文に付いていた「シークレット モードでこのページにアクセスする」は、このうちの1つ目だけを揃える手順です。シークレットモードで消えるのはログイン状態だけで、User-Agentもアクセス元のIPも自分のままです。だから、User-AgentやIPを見て弾いている403は、シークレットモードでは再現しません。

⚠️ この段落の3行の表と、シークレットモードで揃うのが1つだけだという説明は、公式が一覧としてまとめているものではありません。上に引いた公式の各記述(認証情報を提供しない・アクセス元IPの分布・401の確認手順)から、この記事で組み立てたものです。

個人ブログで起きる4つの典型

①②③を踏まえると、原因の候補はそれほど多くありません。よくある形を4つに分けます。どれも「これで確定」ではなく、確認の入口です。

ア. 会員限定・パスワード保護の設定

よくある形で、そして直す必要がいちばん少ない形です。会員向けの記事や有料コンテンツを、プラグインやテーマの機能で閉じている場合、Googlebotに401か403が返ることがあります(ログイン案内のページを200で返す実装もあり、その場合はこの行には入りません)。401なら、それは設計どおりの動きです。403も閉じる意図どおりの結果ですが、番号の使い方としては公式が「間違って」と書いている状態です。

判断は「そのURLを検索結果に出したいか」だけです。出さなくてよいなら、この行はそのままで構いません。ただし、閉じるつもりのないページまで巻き込まれていないかは見てください。会員向けの設定が、カテゴリ単位やテンプレート単位で効いていることがあります。

イ. 公開前の環境に残ったパスワード

公開前にBasic認証をかけて作業し、そのまま公開した場合です。認証が残っていれば、訪問者にもGooglebotにも401が返ります。この形は、サイト全体または特定のディレクトリがまとめてこの行に入るのが特徴です。

テスト用のサブドメインや別ディレクトリを、サーチコンソールの同じプロパティで見ている場合も同じ行に出ます。並んでいるURLのドメインとパスを先に読んでください。「出すつもりのなかったURL」なら、閉じたままで正しい状態です。

ウ. セキュリティ側の設定による誤検知

ここが403で多い形です。セキュリティ関連のプラグインやサーバー側のファイアウォールには、怪しいUser-Agentからのアクセスを遮断する設定を持つものがあります。そして、Googlebotを名乗る偽物は実際に多いというのが公式の説明です。

Googlebot をブロックする前に、他のクローラーが Googlebot の HTTP user-agent リクエスト ヘッダーを使用して Googlebot になりすましていることがよくある点に注意してください。
— Google公式「Googlebot」

偽物が多いので、名前で弾く設定には理由があります。問題は、その網に本物まで掛かることです。本物と偽物を名前だけで見分けることはできないので、公式は別の確認方法を用意しています(後述します)。

プラグインの名前や既定値をここで断定はしません。この記事では個別のプラグインを検証していないので、「そういう設定を持つものがある」という以上のことは書けません。使っているセキュリティ系の設定画面で、User-Agentやボットの遮断に関する項目を見てください。

エ. 海外からのアクセスの遮断

日本語のブログだから海外のIPアドレスはまとめて遮断する、という設定を入れている場合です。Googleのクローラーがどこから来るかは、公式が書いています。

Google からのトラフィックは大部分が米国の IP アドレスからですが、サイトが米国からのリクエストをブロックしていることが検出された場合は、他の国の IP アドレスからクロールを試みることがあります。
— Google公式「Google のクローラーとフェッチャー(ユーザー エージェント)の概要」

大部分が米国から来ます。だから米国のIPを弾く設定は、そのままGooglebotを弾く設定になりえます。

ただし、条件付きの続きがあります。公式の一文は「サイトが米国からのリクエストをブロックしていることが検出された場合は、他の国の IP アドレスからクロールを試みることがあります」と続いています(上の引用の後半です)。だから「海外IPを遮断したら必ずクロールされなくなる」という話ではありません。検出された場合に、試みることがある。書かれているのはそこまでです。遮断の設定に心当たりがあるなら、確認する価値がある、というところまでにしてください。

直す記事と作業内容を決める

Search ConsoleのZIPを読み込むと、候補の判定と1記事分の診断カードを無料で確認できます。登録は不要です。ZIPが無い場合は、診断カードの見本を確認できます。

すでに検索結果に出ていたURLはどうなるのか

ここだけは、放置の判断をする前に読んでください。さきほど引いたHTTPステータスの公式ドキュメントは、「すでにインデックスに登録されている URL が 4xx ステータス コードを返すと、その URL はインデックスから削除されます」と書いています。

レポート側にも、同じ現象が別の角度から書かれています。

該当するエラーの増加が見られないのにインデックス登録済みページの総数が減少している場合、robots.txt、noindex、ログイン要求によって既存のページへのアクセスをブロックしている可能性があります。
— Google公式ヘルプ

「ログイン要求」が、既存の登録が減る原因として名指しされています。だから、これまで検索から人が来ていたURLがこの行に入っているなら、そこは急ぐ側です。逆に、もともと閉じていたURLしか入っていないなら、急ぐ理由はありません。

なお、この行に入ったからといってGooglebotがすぐ来なくなるわけではありません。同じヘルプはこう書いています。

既知の URL から少しの間 4XX エラーが返されても、一時的なエラーである場合に備えて、Google は既知の URL をすべてクロールし続けます。URL がクロールされなくなるのは、URL から noindex ディレクティブが返される場合のみです。
— Google公式ヘルプ

直せば、次に取りに来たときに読まれます。ただし、この点について見た2ページ(ページ インデックス登録レポートのヘルプとHTTPステータス コードのドキュメント)には、消えた登録が戻るとも戻らないとも書かれていません。

⚠️ 401や403をクロールを減らす目的で使うのはやめてください。公式ドキュメントに「クロール頻度を制限する目的で 401 および 403 のステータス コードを使用しないでください」と書かれています。 なお同じ欄には「4xx ステータス コード(429 を除く)はクロール頻度に影響しません」と「クロール頻度は徐々に低下します」が並んでいて、この2文の関係はそのページに書かれていません。 この2文の読み合わせは404の行の記事にあるので、ここでは踏み込みません。

似た行との違いを1行ずつ

同じレポートには、似て見えて止まっている工程が違う行が並んでいます。混ぜないための対比だけ置いて、詳しい扱いはそれぞれの記事に譲ります。

行Googlebotは取りに行ったか詳しくは
401 / 403行ったが、玄関で断られたこの記事
見つかりませんでした(404)行ったが、そのURLは無いと返ってきた「見つかりませんでした(404)」は消した覚えがなくても出る、直すのは自分が案内しているURLだけ
URL が robots.txt によってブロックされていますそもそも行っていない「robots.txtによりブロックされました」は取りに行かなかったという報告です
サーバーエラー(5xx)行ったが、正常な応答の代わりに500番台のエラーが返ってきた「サーバーエラー(5xx)」はサーバーが応答を返せなかった記録、記事を直しても消えない
URL に noindex が指定されています行って読んだうえで、指示に従った「noindexタグによって除外されました」は正常、直すのは意図と違うときだけ

5xxとの差だけ、ここで補足します。同じ公式ドキュメントは5xxについて「すでにインデックスに登録されている URL はインデックスに保持されますが、最終的には削除されます」と書いており、4xxの「インデックスから削除されます」とは扱いが違います。5xxの原因の探し方と直し方は上の記事の領分なので、ここでは踏み込みません。

同じ表には「他の 4xx の問題が原因で、URL がブロックされました」という行もあります。公式が書いているのは「ここで説明されていないタイプの 4xx の問題」までで、番号は挙がっていません。401でも403でも404でもない4xxの置き場所だ、というのは、私がそこから読み取ったものです。読み方は「他の 4xx の問題が原因で、URL がブロックされました」は何番のエラー?公式は番号を書いておらず、確かめるのはサーバー側にまとめました。

なお、サイトマップの送信で出る「robots.txt にアクセスできません」は、robots.txtというファイル自体へのレスポンスの話で、この記事とは別物です。そちらはサイトマップの「robots.txt にアクセスできません」はサーバー側の問題ですにまとめています。

インデックスされない原因の全体像と、どこから切り分けるかはインデックスされない原因は2系統に分かれる、確認できるものから潰すの領分です。この記事は401と403の2行だけを扱います。

決めることは3つ

順番に決めれば、やることは自動的に決まります。

1. 並んでいるURLを、出したいURLと出さなくてよいURLに分ける

これが最初です。会員限定ページ、公開前の環境、管理画面まわりのURLしか入っていないなら、そこで終わりです。 公式ヘルプは、「インデックス登録に関する問題の原因」の「未登録」のまとまりを、こう説明しています(2026年9月13日に本文を取得して見出しの階層を調べたところ、h2「インデックス登録に関する問題の原因」→ h3「未登録」の下に、401と403の項目が置かれていました)。

ページはインデックスに登録されていませんが、必ずしもエラーによるものではありません。具体的な説明を読んで、対処する必要があるエラーかどうかを確認してください。
— Google公式ヘルプ

同じヘルプには「「未登録」は、必ずしも URL にとって不適切な状態であるとは限りません」とも書かれています。件数を0にする作業ではありません。

2. 出したいURLがあるなら、締め出しているのは「認証」か「フィルタ」か

認証なら、自分で入れた覚えがあるはずです。会員限定の設定、公開前のBasic認証、有料エリアの保護。どれも設定画面にたどり着けます。

フィルタは、入れた覚えが無いことがあります。セキュリティ系の設定や、サーバー会社側の防御機能、海外IPの遮断。見分け方は、③の段落で書いたとおり「自分の画面で再現するかどうか」です。シークレットモードで開いて401や403が出るなら認証側、普通に見えてしまうならフィルタ側の可能性が高くなります。

3. そのURLは、これまで検索結果に出ていたか

出ていたなら急ぎます。401や403も4xxなので、すでに登録されていたURLがこれを返すと、その登録は削除されると公式が書いているからです。もともと出ていなかったURLなら、落ち着いて直して構いません。

⚠️ 同じ4xxでも404は「直す/直さない」の線の引き方が違います。公式が404について修正をすすめている範囲は、同じページ インデックス登録レポートのヘルプのトラブルシューティング節にある「一般的に、自分自身にリンクしているか、サイトマップに記載している 404 エラーのみを修正することをおすすめします」で、レポートの項目説明だけでは切れません。 ただし「すでに登録されていたURLが4xxを返すと削除される」は404にも同じく効くので、公開しているつもりのページが404を返している事故は、あちらでも先に直す扱いです。404の行の読み方は「見つかりませんでした(404)」は消した覚えがなくても出る、直すのは自分が案内しているURLだけの領分です。

取れる手は4つ

公式が401と403の説明文の中で挙げている手と、閉じたままにする手を合わせると4つになります。

  • 閉じたままにする。検索結果に出さなくてよいURLなら、これが正解です。 公式も「クローラーとユーザーによるページへのアクセスを完全にブロックする場合はパスワード保護などの他の方法を使用してください」と書いています
  • 保護そのものを外す。401の説明文にある「認証機能を使ったページの保護を削除する」です。 公開前の環境に残っていたBasic認証は、たいていこれで片付きます
  • ログインしていない訪問者にも見せる。403の説明文にある「ログインしていないユーザーを承認する」です。 会員限定を解く判断になるので、事業の判断とセットになります
  • Googlebotだけ通す。401の説明文の「Googlebot からのアクセスであることを確認して、ページへのアクセスを許可」、 403の説明文の「Googlebot のリクエストを認証なしで明示的に許可する」がこれです。ただし公式は、どちらにも「Googlebot からのアクセスであることを確認」という条件を付けています

4つ目を選ぶなら、名乗りを信じてはいけません。さきほど引いたとおり、Googlebotを名乗る偽物は多いというのが公式の説明です。確認の方法も公式に用意されています。

手動: 1 回限りのルックアップでは、コマンドライン ツールを使用します。ほとんどの場合、この方法で十分です。
自動: 大規模なルックアップでは、自動ソリューションを使用して、公開されている Google の IP アドレスのリストとクローラーの IP アドレスを照合します。
— Google公式「Google のクローラーとフェッチャーからのリクエストを確認する」

手動のほうは、アクセスログに残っているIPを逆引きして名前を出し、その名前が googlebot.com / google.com / googleusercontent.com のいずれかであることを確かめ、さらにその名前を引き直して同じIPに戻るかを見る手順です。ドメイン名の確認を飛ばすと、自前のDNSで往復を一致させた偽物を通してしまいます。公式は一般的なクローラーの名前の形として「crawl-***-***-***-***.googlebot.com」または「geo-crawl-***-***-***-***.geo.googlebot.com」を挙げています。設定の詳細はサーバーやプラグインごとに違うので、この記事では手順までは書きません。

⚠️ 逆に「もう検索結果から消したい」という理由で401や403を選ぶのはおすすめしません。削除の意図で返す信号としては404・410・301・noindexがあり、選び方が別にあります。その使い分けは記事の削除で404と410どちらを返すか、301・noindexとの使い分けの領分なので、この記事では信号の選び方を議論しません。

直したあと、どう確かめるか

公式ヘルプは、まさにこの状況をFAQに立てています。「自分ではページを表示できるのに、Google にページが認識されないのはなぜですか?」という項目です。

URL 検査ツールを使用して、Google が公開中のページを認識できるかどうかを確認します。認識できない場合は、理由が説明されているはずです。認識できる場合、問題の原因は、最後のクロール以降にアクセスエラーが修正されたためだと考えられます。URL 検査ツールを使用してライブページのクロールを実行し、インデックス登録をリクエストしてください。
— Google公式ヘルプ

自分のブラウザで開くのではなく、Google側から取りに行かせて結果を見る、ということです。①②③で書いたとおり、自分のブラウザはGooglebotと条件が違うので、ここは道具を変える必要があります。直した直後に見るのは「公開 URL をテスト」のほうです。最初に出る結果は前回クロール時の情報なので、設定を直した後でも古い表示のままになります。

URL検査の操作と、出た表示ごとに次の一手がどう変わるかはサーチコンソールでインデックスを確認する方法、URL検査の表示ごとに次の一手が違うにまとめています。この記事では表示の一覧までは書きません。

レポート側の「修正を検証」については、公式が所要時間と注意を書いています。「検証は通常 2 週間ほどで完了しますが、それより長くかかる場合もあります」とあり、そのうえで「ウェブサイトに関する問題によっては、修正して検証することに常に意味があるとは限りません」とも書かれています。閉じたままにすると決めたURLについては、検証を回す必要はありません。

片付いた後にやること

401と403の行を読み終えると、多くの場合「閉じたままでよいURLだった」で終わります。そのとき残るのは、すでに検索結果に出ているページのほうをどうするかという問題です。

ここから先は、インデックスの話ではなく順位とクリックの話になります。使う道具も変わります。選択肢としては、たとえば次のような分かれ方をします。

  • サーチコンソールの検索パフォーマンスをそのまま見る。 追加の道具は要りませんが、表示回数・クリック数・掲載順位を自分で見比べる手間がかかります
  • Looker Studioなどにつないで表を作る。 自由に加工できますが、作るまでの設定が要ります
  • スプレッドシートにCSVを落として並べ替える。 誰でもできますが、毎月同じ手順を踏むことになります
  • リライト候補の抽出に特化したツールを使う。 判断は速くなりますが、道具ごとに前提と得意分野が違います

検索パフォーマンスのどこを見るかはサーチコンソールでリライト記事をどう選ぶ?迷わない判定基準と手順に、索引には入っているのに表示回数が0のままという場合はサーチコンソールで表示回数が0のとき、表示されない原因を3つに切り分けるに書いています。

よくある質問

「未承認のリクエスト(401)が原因でブロックされました」とはどういう意味ですか

そのページを見るのに認証が必要な状態になっていて、Googlebotが入れなかった、という意味です。公式ヘルプは「このページへのアクセスには認証が必要なため、Googlebot のアクセスがブロックされています(401 レスポンス)」と説明しています。記事の中身への評価ではありません。

「アクセス禁止(403)が原因でブロックされました」とはどういう意味ですか

サーバーが「権限が無い」と答えて、Googlebotを追い返した状態です。公式ヘルプは「HTTP 403 は、ユーザー エージェントが認証情報を提供したものの、アクセス権が付与されなかったことを意味します。しかし、Googlebot は認証情報を提供しないため、サーバーは間違ってこのエラーを返しています」と書いています。そのうえで「このページはインデックスに登録されません」と続きます。

ブラウザでは普通に開けます。Googleの誤りではないですか

誤りとは限りません。401や403を返すかどうかは、リクエストの中身を見て決まるからです。あなたのブラウザはログイン済みのCookieを持ち、日本のIPから、普通のUser-Agentで来ています。 Googlebotは認証情報を持たず、公式いわく「Google からのトラフィックは大部分が米国の IP アドレスから」(部分引用です)来て、Googlebotと名乗ります。条件が違う以上、返るものが違っても矛盾しません。Google側から取りに行かせて確かめるには、URL検査を使ってください。

会員限定ページなので401のままで構いません。放置していいですか

構いません。公式ヘルプは「未登録」のまとまりを「ページはインデックスに登録されていませんが、必ずしもエラーによるものではありません」と説明しており、Googlebotのドキュメントも「クローラーとユーザーによるページへのアクセスを完全にブロックする場合はパスワード保護などの他の方法を使用してください」と案内しています。確認するのは、閉じるつもりのなかったURLが混ざっていないかどうかだけです。

これまで検索に出ていたページが401や403になりました。どうなりますか

そのままだと、インデックスから削除されると公式は書いています。HTTPステータス コードの公式ドキュメントは「すでにインデックスに登録されている URL が 4xx ステータス コードを返すと、その URL はインデックスから削除されます」としています。ここは急いで直す側です。ただしこの点について見た2ページ(ページ インデックス登録レポートのヘルプとHTTPステータス コードのドキュメント)には、直したあとに元の順位へ戻るとは書かれていません。

Googlebotだけ通す設定にすれば解決しますか

公式が挙げている手ですが、条件が付いています。401の説明文は「Googlebot からのアクセスであることを確認して、ページへのアクセスを許可します」、 403の説明文は「Googlebot のリクエストを認証なしで明示的に許可する必要があります(ただし、Googlebot からのアクセスであることを確認する必要があります)」です。User-Agentの名乗りだけで通すと、Googlebotを騙る相手にも同じ扉を開けることになります。確認の手順は公式の「Google のクローラーとフェッチャーからのリクエストを確認する」にあります。

「URL が robots.txt によってブロックされています」とは何が違いますか

取りに行ったかどうかが違います。401と403は、Googlebotが実際にリクエストを送って、サーバーに断られた記録です。 robots.txtのほうは、そもそもリクエストを送らなかったという報告です。だから確認する場所も直す場所も別になります。詳しくは「robots.txtによりブロックされました」は取りに行かなかったという報告ですをご覧ください。

記事をリライトすれば消えますか

消えません。公式ドキュメントは「Google は、4xx ステータス コードを返す URL のコンテンツを使用しません」と書いています。中身が読まれていないので、中身を変えても返るレスポンスは変わりません。変えるのはサーバーやプラグインの設定のほうです。

まとめ

  • 401も403も、Googlebotが玄関で止められた状態。公式は401を「このページへのアクセスには認証が必要なため、Googlebot のアクセスがブロックされています」と説明し、403には「Googlebot は認証情報を提供しないため、サーバーは間違ってこのエラーを返しています」と書いている
  • 中身は読まれていないので、リライトでは消えない。公式は「Google は、4xx ステータス コードを返す URL のコンテンツを使用しません」としている
  • すでに登録されていたURLは、4xxを返すと削除されると公式が明記している。検索から人が来ていたURLが入っているなら、そこは急ぐ側
  • 自分のブラウザで開けることは、Googlebotが開ける根拠にならない。Cookie・User-Agent・アクセス元のIPが違う。シークレットモードで揃うのはログイン状態だけなので、フィルタ側の403は再現しないことがある
  • 個人ブログでよくあるのは、会員限定の設定・公開前の環境に残ったパスワード・セキュリティ側の誤検知・海外IPの遮断。この記事での整理であって、網羅ではない。公式は「Google からのトラフィックは大部分が米国の IP アドレスからですが、サイトが米国からのリクエストをブロックしていることが検出された場合は、他の国の IP アドレスからクロールを試みることがあります」と書いており、遮断すれば必ずクロールされなくなるとまでは書いていない
  • 閉じたままにするのは、公式が案内している選択肢。ステータス「未登録」は公式いわく「ページはインデックスに登録されていませんが、必ずしもエラーによるものではありません」で、件数を0にする作業ではない
  • Googlebotだけ通すなら、名乗りを信じないこと。公式は「Googlebot からのアクセスであることを確認」を条件に付けており、確認の方法も別ページに用意している

ここから先は、私が作ったツールの話です。

リライトレーダーは、この記事の「片付いた後にやること」で書いたすでに検索結果に出ているページの側を扱います。 Search Console のエクスポートをZIPのまま落として貼るだけで、掲載順位4.0〜20.5位・表示回数100回以上のページだけを拾い、改善余地スコアの大きい順に並べます。判定と候補3記事の改善余地スコアの確認、そのうち1記事分の診断カードまでは無料で、残りの診断カードが2,980円(税込)の買い切りです。月額課金や自動更新はありません。ログインも不要です。CSVファイルそのものはブラウザの外に出ません(送るのは、診断カードを出すときは選んだ1ページのURL・数値・入力したキーワード、「ページタイトルを取得する」を押したときは判定に出たページのURL最大10件です)。

⚠️ ただし、向かない人がいます。401や403を調べに来た人には、この時点では向きません。サーバーのレスポンスもクロールもインデックス登録も扱っていません。読むのは、すでに検索結果に出ているページの4つの数字だけです。 また、表示回数が2桁で止まっているサイトにも向きません。判定の条件が表示回数100回以上なので、対象になるページが1つも出ないからです。

Search ConsoleのZIPで無料判定する

Search ConsoleのZIPを読み込むと、候補の判定と1記事分の診断カードを無料で確認できます。登録は不要です。ZIPが無い場合は、診断カードの見本を確認できます。

この記事の内容をツールにしています

Search Console の「ページ」CSVを貼ると、改善余地のある記事を順番に出します。 判定とご自分の記事1件分の診断カードは無料です。ログイン不要。CSVファイルはアップロードせず、ブラウザ内で解析します。

リライトレーダーで無料診断する

関連する記事

この記事を書いた人

みやこし

ブログのリライトで「どの記事を直すか」を数字で決めるSEOライター向けツールを作っています。 掲載順位ごとの平均クリック率、AI Overviewによるクリック減の補正、タイトルの直し方など。

noteQiitaZenn

ブログの一覧に戻る