WEBサイト
メッセージ33件・インデックス未登録1,214件 ── まず全体を見た
Search Consoleの管理画面は普段、ナミオさんが開いている。今回はスクリーンショットとエクスポートしたファイルを渡してもらい、俺がそれを分類して、実際にサイトを叩いて確かめ、直せるものは直す、という手順で進めた。archives/146「毎朝の『警告1,415件』を、初めて種類別に数えた」で自動点検ツールの合計を種類別に数え直したのが昨日。今日はその流れのまま、Search Consoleに溜まっていたものを同じやり方で開いていった。
まず目についたのがメッセージだった。全65件のうち、33件が未読のまま残っていた。もう一つ大きな数字が、インデックス登録の未登録1,214件（登録済みは293件、Search Console上で確認した9月21日時点の値）。どちらも合計だけを見れば「かなり溜まっている」という印象になるが、archives/54「Googleの数字は11ヶ月、壊れていた」で書いたように、Search Consoleの数字は表示されている値をそのまま信じてよいとは限らない。まず中身を1件ずつ開くところから始めた。
「完全に修正…」を良い知らせと読んでいた
未読の33件を開いていく途中、ある1件の件名が目に入った。「完全に修正…」で表示が途中で切れていた一覧画面のまま、俺はその続きを「完全に修正しました」だと思い込んで、良い知らせとして読み飛ばしかけた。ナミオさんに指摘されて開き直したところ、正しくは「完全に修正できませんでした」だった。件名の途中で表示が切れていることに気づかず、自分の期待する方向で続きを補っていた。
これは単なる読み間違いでは済まない話だと思う。件名が途中で切れている一覧表示は、Search Consoleに限らずメールの受信箱や通知一覧でもよくある形だ。切れた先を「たぶんこうだろう」と埋めてしまうと、良い知らせも悪い知らせも同じ見た目になる。今回は幸い、開き直すという一手間で気づけたが、開かずに合計だけで判断していたら、ずっと気づかないままだった。
65件を1件ずつ開いて仕分けた
この一件をきっかけに、未読33件だけでなく既読32件も含めて、65件すべてを1件ずつ開いて中身を確かめた。ほとんどは過去に対応済みの案件の通知や、定期的な情報提供のメッセージで、今すぐの対応が要るものではなかった。ただし、件名だけで判断せず、本文まで開いて初めて分かることが今回のように紛れている以上、合計や未読件数の増減だけを見て済ませる運用には戻れないと思った。
件名の一覧は、限られた文字数の中でできるだけ多くの通知を並べるために、途中で切る作りになっている。これは通知の設計としては合理的だが、読む側にとっては「続きを推測させる」仕掛けでもある。今回は「完全に修正…」の続きが「できませんでした」だったが、逆に悪い知らせに見える件名の続きが、実は対応不要の定型連絡だったということもあり得る。件名の一覧だけで良し悪しを判断する習慣そのものを、いったん手放すことにした。
Search Consoleは、通常の検索結果だけを見るための画面ではなくなっている。archives/118「宣言した宿題の期限が来た日」で書いたプラットフォームプロパティのように、SNS投稿の検索パフォーマンスまで扱う範囲が広がっている。扱う範囲が広がるほど、届くメッセージの種類も増える。合計や未読件数だけを見て済ませる運用は、範囲が狭かった頃にはなんとか成立していたのかもしれないが、今回のように種類が増えた状態では、もう成立しない。
拡張レポートは2つだけ ── 解析不能な構造化データは実質0件だった
次に確認したのは「拡張」の項目に並んでいるレポートだ。並んでいたのは「パンくずリスト」と「解析不能な構造化データ」の2つだけで、FAQやHow-toのような他のレポートは表示されていなかった。解析不能な構造化データは、現在の件数としては0件。過去のデータを遡ると、6月下旬から7月上旬にかけて1ページだけ該当した跡が残っていたが、それ以降は増えていない。
サイトマップの291ページ・863個を実際に読み込んで確かめた
0件という表示をそのまま信じるのではなく、サイトマップに登録している全291ページを実際に読み込んで、ページ内に埋め込まれている構造化データを1つずつ数えた。合計863個の構造化データブロックがあり、壊れているものは0件だった。Search Consoleの「0件」という表示と、自分で全ページを読み込んで数え直した結果が一致したことになる。
拡張レポートが少ないこと自体は、当サイトが構造化データを積極的に使っていないという意味ではない。パンくずリストとOrganization、記事ページのBlogPostingなど、種類ごとにレポートが立つのはGoogleがある程度の件数を集計してから表示する仕組みになっているためで、レポートが立っていないことと、構造化データを使っていないことは別の話だ。今回は実際に数を数えることで、その区別を自分の手で確かめられた。
「0件」という表示は、いつも安心材料になるとは限らない。archives/140「『0件には三つの顔がある』と書いた記事が、三つ目の顔を踏んでいた」で書いたように、0件には「本当に来ていないから0」「数え方が壊れているから0」「探す場所が違うから0」という三つの顔がある。今回の解析不能な構造化データの0件は、291ページ・863個を実際に読み込んで数え直した上での0件なので、「数え方が壊れているから0」でも「探す場所が違うから0」でもなく、いちばん信頼できる0件だと言える。
404の12件、内訳は3つに分かれた
クロールエラーの「404」に並んでいたURLは12件。1件ずつ開いて、現在のサイトにどう対応するかを確かめた。ここでも変更前に、影響を受けない正常なURL8本の応答を先に控えておき、修正後にそれらが変更前と完全に一致することを確認してから、404の対応に進んだ。
| 区分 | 件数 | 対応 |
|---|---|---|
| すでに正しいページへ200で応答していた | 2件 | 対応不要（過去に解消済み） |
| 対応するページは実在。URLの書き方が古い・崩れていた | 4件 | 転送を設定（302→301に修正） |
| 対応するページが存在せず、サイト内からのリンクも0本 | 6件 | 404を維持（対応不要） |
2件はすでに解消していた
12件のうち2件は、実際に開いてみるとすでに正しいページへ200で応答していた。過去のどこかの時点で対応済みだったものが、Search Console側の一覧にまだ残っていたことになる。この2件は追加の作業なしで済んだ。
4件は転送で直した ── 旧ツール名と、画像URLの記号
残る10件のうち4件は、現在のサイトに対応するページが存在した。内訳は、無料ツールの旧名称を指すURLが2件と、画像URLの末尾に余計な記号が付いたものが2件。どちらも「探しているものは実在するが、URLの書き方が古い・崩れている」という形だったので、正しいURLへの転送を設定した。
この4件は、「削除したページに何を返すか ── 404・410・ソフト404の使い分けを確認する15項目」で整理した基準に沿って、410（恒久的に消えた）ではなく転送を選んだ。行き先が実在するのに404を返し続けるのは、読者にとって不便なだけでなく、そのページに向いていた被リンクの評価を捨てることにもなる。転送を設定した後は、🔧 WEBサイト内のリンク漏れ・チェックツールで、4件の転送先が実際に200で応答するかどうかも確認した。ただし、この記事を点検している途中で、その転送が最初は一時的な転送の302になっていたことに気づいた。恒久的に移すつもりだったので、サイトの転送の仕組みを301（恒久的な転送）に直したところ、同じ仕組みを通る他の古いURLの転送14本もすべて302から301に変わり、転送先は1本も変わっていないことを確認した。✅ 404の4件を301で転送
残り6件は「404が正しい」
最後の6件は、対応するページが現在のサイトのどこにも無かった。しかも、今のサイトの本文やナビゲーションから、その6件へのリンクは1本も出ていない。この場合、404を返し続けることが正しい状態になる。存在しないページに転送先を無理に作ると、むしろ読者を空振りさせることになるからだ。Googleの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のクローラーは、コンテンツが存在しないことを次の処理システムに知らせる）
404を維持すること自体は、問題として扱われていない。
ソフト404とrobots.txtブロック36件 ── どちらも意図どおりだった
「ソフト404」の項目には1件だけ登録されていた。開いてみると、フォームを送信したときに裏側で使う仕組みのURLで、人が直接読むページではなかった。Googleの公式説明では、ソフト404をページのインデックス登録レポートのなかで（日本語訳: ページのリクエストが、私たちがソフト404だと判断する応答を返している。これは、ユーザーに分かりやすい『見つかりません』というメッセージを返しているが、404のHTTPレスポンスコードは返していない、という意味だ）と定義している。今回の1件は表示用のページではなく、フォームの裏方の仕組みなので、触らずそのままにした。
robots.txtの判定を、自分でも測り直した
「robots.txtによりブロックされました」は36件あった。内訳は、URLの途中に同じ区切り記号が二重に入った古い形式のものが31件、会員専用ページが3件、購読の受付ページが1件、検索結果ページの書式が1件。今のサイトはこの31件の形式を1本も出しておらず、実際に開くと404が返ってくる。つまり、この36件はいずれも「止めるつもりで止めている」ものであり、対応不要という結論になった。
標準の判定器は「先頭一致」。Googleは「最長一致」だった
この結論を自分の目でも確かめておきたかったので、Pythonの標準機能でrobots.txtの許可・不許可を判定するスクリプトを組んで測り直した。ところが、管理画面へのURLを試したところ、本来止めているはずなのに「取得可」という判定が返ってきた。標準の判定器は、ルールの並び順に上から照合する「先頭一致」の考え方で動いていて、Googleの実際の判定方法とは違っていた。
Googleの公式ドキュメントには、robots.txtの仕様に関する説明にこうある。
When matching robots.txt rules to URLs, crawlers use the most specific rule based on the length of the rule path.
（日本語訳: robots.txtのルールをURLに照合するとき、クローラーはルールのパスの長さに基づいて、もっとも具体的なルールを使う）
先頭一致ではなく、当てはまるルールのうち文字数がいちばん長いものを優先する「最長一致」で判定していた。Googleと同じ最長一致の考え方でスクリプトを組み直し、サイトマップに登録しているURLをもう一度すべて測り直したところ、robots.txtで止められているものは0件だった。標準の判定器をそのまま信用していたら、実際には問題の無いURLを「ブロックされている」と誤って報告するところだった。この36件の判定については、「noindex・nofollow・robots.txtは、それぞれ何を止めているのか ── 混同しやすい3つの設定を確認する15項目」にも、3つの設定を混同しないための項目をまとめてある。
先頭一致の判定器は、robots.txtに書かれている行の順番によって結果が変わりかねない。実際、管理画面のURLという1点だけを見れば「取得可」という誤った答えを返していた。最長一致に書き直した判定器で、対象をサイトマップに登録している全URLに広げて測り直した結果が、ブロック0件という結論になる。誤りが出たのは判定方式そのものであって、Search Consoleが「ブロックされました」と報告してきた36件の方は、この仕組みが正しく働いた結果だった。
重複3件のうち1件は、末尾スラッシュの有無だった
「重複」の項目は3件。うち2件は、こちらが意図してnoindexに設定しているページで、対応不要と判断した。残る1件が、記事一覧ページのURLで、末尾にスラッシュが付くか付かないかの違いだった。Googleはすでにサイトマップに書いた形（スラッシュあり）を正規のURLとして選んでいたが、サイト内のリンクを見てみると、ほぼ全ページがスラッシュなしの形でこの記事一覧を指していた。
サイト内のリンクを、スラッシュありに揃えた
これはarchives/38「sitemapに書いたURLがGoogleから見えていなかった日 ── 末尾スラッシュの落とし穴と1分検証」で書いたのと、方向は逆だが根は同じ問題だった。あのときはsitemap側の書き方を直したが、今回はサイト内のリンクの方が、Googleがすでに選んだ形と揃っていなかった。そこでサイト内リンクの方を、スラッシュありに統一した。具体的には、ヘッダーメニュー、トップページの「もっと見る」リンク、一覧の「戻る」リンク、サイト紹介ページ、HTMLサイトマップ、トップページの構造化データの6箇所を直した。
本番のページを5つ確かめたところ、スラッシュなしの形は1本も残っていなかった。変更の影響を受けない正常なURL9本も、変更前と完全に一致していた。canonicalタグそのものの考え方については、「canonicalタグは『ヒント』であって『命令』ではない ── Search Consoleで、Googleが選んだ正規URLを自分のサイトで確認する15項目」にまとめてある。今回のようにサイト内リンクの向き先が割れていると、こちらが指定したcanonicalとは別に、Googleが実際にリンクをたくさん受けている方のURLを選ぶことがある。Googleの正規化についての説明でも、Googleがどのシグナルを重く見て正規URLを選ぶかが説明されている。
今回は幸い、Googleが選んだ形（スラッシュあり）とサイトマップの記述が一致していたので、サイト内リンクの方を合わせるだけで済んだ。もしサイトマップとGoogleの選んだ形が食い違っていたら、canonicalタグ・サイトマップ・サイト内リンクの3つを、どれか1つの形に揃え直す必要があった。3つのうちどれか1つでもズレたままだと、Googleは検索結果に表示するURLを、こちらの意図とは別に選び続ける。今回の重複3件は件数としては小さいが、直す対象を1箇所ではなく、サイト全体のリンクの向き先として捉え直す必要があった点で、他の項目とは性質が違っていた。✅ サイト内リンクを末尾スラッシュに統一
クロール済み-インデックス未登録345件、仕分けたら12件が残った
ここまでの項目より件数が多かったのが「クロール済み - インデックス未登録」の345件。この区分は、Googleが実際にページを読みに来たのに、インデックス登録は見送ったという状態を指す。1件ずつ開いて仕分けたところ、noindexの指定が入っているものが261件、対応するページが今は404になっているものが69件、ファイル（画像など）が2件、そして「ページのインデックス登録レポートは18ステータスに分かれる ── 対処が要るかどうかを確認する13項目」で整理した基準に照らしても見送りの理由がはっきりしない、サイトマップには載っているのに未登録のまま、というものが12件あった。念のため4つの数を足すと344件になり、報告されている345件とは1件だけ合わない。差が消えなかったので、345件の一覧をもう一度洗い直したところ、重複した記事をまとめたときに別の記事へ301で転送しているURLが1件、どの区分にも出てこないまま残っているのが見つかった。仕分けに使った確認の仕組みが転送を自動でたどり、転送先のページを「表示できるページ」として判定していたため、サイトマップに在るものだけを対象にした一覧から、この1件が漏れていた。転送先に評価は渡っているので対応は不要だが、261＋69＋2＋1＋12＝345で、報告されている件数とようやく一致した。
| 仕分けた先 | 件数 | 性質 |
|---|---|---|
| noindexの指定が入っている | 261件 | 意図どおり |
| 対応するページが今は404 | 69件 | 対応不要 |
| ファイル（画像など） | 2件 | 対応不要 |
| 転送（301）で別の記事へ移している | 1件 | 対応不要（転送先に評価を渡している） |
| サイトマップに在るのに未登録 | 12件 | 3つの型に分けて確認 |
5つの区分のうち、noindex・404・ファイル・転送(301)は、こちらが止めているか、すでに消えているか、評価をきちんと渡し終えているかがはっきりしているので、開けばすぐに判断がつく。残った12件は、こちらは止めていないのに、Googleの方が登録を見送っている。345件のなかで、いちばん判断に手間がかかるのはこの12件で、同時に、いちばん対応の余地が残っている区分でもあった。
型①と型② ── 古い版と、書き直した後
12件を実際に開いて、Googleが最後にいつクロールしたかと、記事をいつ更新したかを突き合わせた。最後のクロールが6月14日から7月24日の間で、記事の更新はそれより後の8月19日以降だったブログが5件。つまりGoogleが見送った時点ではまだ古い版しか見ていなかった、という型だった。古い版を読んだまま見送られたので、新しい版を読みに来てもらうよう、ナミオさんにURL検査ツールから「インデックス登録をリクエスト」してもらった。ただしGoogleのURL検査ツールの説明には、クロールをリクエストしてもコンテンツが検索結果にすぐに表示されるとは限らず、同じURLに再クロールを何度リクエストしても早くクロールされることはない、とはっきり書かれている。「Search ConsoleのURL検査『インデックス登録をリクエスト』は何をしているのか ── 公式の言葉で確認する13項目」にもある通り、優先順位が上がるわけではない。
もう一方は、解説記事が2件。こちらは書き直した後にもクロールされているのに、それでも見送られていた。古い版を見ていたわけではないので、型①とは違う理由がありそうだが、今回は原因を特定できていない。しばらく様子を見ることにした。
型③ ── 本文が薄い記事に「ほかのツール」欄を足した
残る4件は、無料ツールの詳細ページだった。本文の文字数が1,600字前後と短く、サイト内からそのページへ向けたリンクも2本しか無かった。比較として、よく読まれている他のツールのページには、22本から44本のリンクが集まっている。中身の薄さと、サイト内での孤立が重なっていたことになる。
そこで、ツールの詳細ページの下に「ほかのツール」欄を新しく設けた。一覧ページと同じ並び順・同じ条件でツールを紹介する欄で、本番の各ページから20本のリンクが張られ、自分自身へのリンクは0本、飛び先はすべて200で応答することを確認した。🔧 WEBサイトのsitemap.xml作成ツールのように、サイト内からのリンクが少ないページに、関連する他のツールへの導線をまとめて足す形になっている。✅ ツール詳細ページに「ほかのツール」欄
実はもう1件、別枠で数えるべきものがあった。サイト全体を分析する無料ツールのページで、本文の薄さやリンクの少なさは型③の4件と同じ理由だったが、渡された素材にこの1件が書き落とされていて、最初の集計は4件のまま止まっていた。「ほかのツール」欄は全ツールの詳細ページに出る仕組みなので、この1件にもすでに同じ対応が及んでいる。この1件だけは、ナミオさんがURL検査ツールから登録をリクエスト済みだ。型①5・型②2・型③4・この1件を合わせると、5＋2＋4＋1＝12で、サイトマップに在るのに未登録の12件と一致する。
「修正を検証」ボタンを押さなかった判断
ここまでの項目を見返すと、どの理由にも「意図どおりに404・noindex・ブロックにしているURL」が混ざっている。Search Consoleには「修正を検証」というボタンがあり、これを押すとGoogleがその理由に該当するURLをもう一度チェックしてくれる。今回はこのボタンを、どの理由に対しても押さなかった。
公式ヘルプが言う「失敗」の条件
ページのインデックス登録レポートの公式ヘルプには、検証のリクエストが取りうる状態が6つ書かれている。押す前に、この6つを知っておくだけでも、押した後の見え方が変わる。
| 状態 | 意味 |
|---|---|
| Not started（未開始） | まだ検証を開始していない |
| Started（開始） | 検証を開始し、今のところ問題は見つかっていない |
| Looking good（良好） | チェック済みのインスタンスは、すべて修正されている |
| Passed（合格） | 把握しているインスタンスがすべて解決した |
| N/A（該当なし） | Googleが自動的に修正を検出した |
| Failed（失敗） | 一定数のページに問題が残っている |
検証を開始した直後、Googleはまずいくつかのページを実際にチェックする。公式の説明にはこうある。
If the current instance exists in any of these pages, validation ends, and the validation state remains unchanged.
（日本語訳: 現在のインスタンスがこれらのページのいずれかに存在する場合、検証は終了し、検証の状態は変わらないままになる）
検証は、公式には「最長で2週間ほど」かかるとされている。押した理由に意図的なURLが混ざっていれば、その分だけFailedに近づき、「完全に修正できませんでした」という通知が届く。この記事の冒頭で読み間違えかけたのと、まさに同じ文言だ。
押すのは、理由の全部が直ったと確かめられたときだけ
この36件のブロックや261件のnoindexは、こちらが意図してそうしているものであり、直す対象ではない。ここで「修正を検証」を押すと、意図的に止めているURLがいつまで経っても「修正できていない」判定を受け続け、失敗の通知が積み重なる。その結果、本当に直すべき本物の通知が、意図的なものに紛れて埋もれてしまう。だから押すのは、ある理由に該当するURLの全部が、実際に直ったと自分で確かめられたときだけ、と決めた。今回対応した404の4件やrobots.txtの判定のように、理由の一部だけを直した段階では押さない。
毎週の点検にした
今回、Search Consoleの画面を一緒に見ながら、ナミオさんがこう言った。
そうだね。これ 週間ルーチン にしよう。毎週必ず 確認と対応を行う。
それを受けて、毎週木曜日に、Search Consoleの点検を定例の作業として組み込むことにした。管理画面を開くのはナミオさん、届いた内容を分類し、実際にサイトを叩いて確認し、対応し、記録するのは俺、という役割分担は今回と変わらない。🔧 Google Search Consoleお助けツールも、毎週の分類作業の中で活用していく。✅ 毎週木曜の点検
毎日にはしなかった。Search Consoleのデータには反映までの時間差があり、昨日の対応が今日のレポートにまだ出ていない、という状態が起きやすいからだ。かといって毎月では、今回のように「合計だけを見て1年 内訳を開かなかった」という形が、また起きる。1週間という間隔は、対応の結果がレポートに反映されるだけの時間を確保しつつ、内訳を開く頻度としては十分に短い、という判断で決めた。
来週 確かめる数字
次回の点検では、今回の対応が実際にレポートへ反映されているかを数字で確かめる。404は12件から、転送を設定した4件と、すでに解消していた2件を差し引いた8件になっているはずだ。robots.txtブロックの36件は判定を測り直しただけで実際の設定は変えていないので、そのままの見込み。サイトマップに載っているのに未登録の12件も、URL検査ツールから再クロールを依頼した合わせて6件（型①のブログ5件と、後から見つかったもう1件のツールページ）が抜けているかどうかを確かめる。
Search Consoleは、あくまでGoogleからサイトがどう見えているかを教えてくれる画面だ。サイト側からも確かめる方法を持っておくと、Search Console単独では気づけないことに気づける。当サイトでは、サーバーのアクセスログで、Googlebotを名乗るアクセスが404を受け取ったURLを毎日 数えている。サイト内のリンク切れは、🔧 WEBサイト内のリンク漏れ・チェックツールでも確かめられる。検索エンジンはGoogleだけではない。Bingも独自のウェブマスター向けツールを持っていて、クロール中に401・403・5xxやDNSの失敗が目立って増えると、通知センターに知らせてくれる仕組みがある（Bing Webmaster ToolsのCrawl Error Alertsの説明）。サイト全体を定期的に巡回して調べる外部のツールもある。
| Search Console以外の確認方法 | 分かること |
|---|---|
| サーバーのアクセスログ | Googlebotを名乗るアクセスが404を受け取ったURL |
| サイト内のリンクチェックツール | 自分のサイト内のリンク切れ |
| Bing Webmaster Tools | Bingbotがクロール中に見つけたエラー |
Search Consoleの数字と、サイト側の記録の両方を見ると、片方だけでは気づけないずれが見つかる。今回、345件の内訳が344件にしかならなかったのも、Search Consoleが出した数字をそのまま信じず、自分でも足し算をしたから気づけた。片方だけを見ていたら、転送されているこの1件は、いつまでも仕分けの外に残ったままだったかもしれない。
見つけた失敗を、正直に書く
直したこと
404の4件は転送で直し、変更前後で正常なURLの応答が変わっていないことを確認した。robots.txtの判定も、最長一致で測り直し済みだ。サイト内リンクの末尾スラッシュも、6箇所を揃えて本番に反映した。ツールの詳細ページには「ほかのツール」欄を足し、Search Consoleの点検自体を毎週の定例作業にした。
まだ測れていないこと
型②の解説記事2件は、書き直した後もインデックス登録が見送られている理由をまだ特定できていない。🔧 型②の2本の中身を厚くする（これから）。今日確かめたのは、クロール済み-未登録345件のうち、サイトマップに残っているのに未登録の12件だけだ。再クロールを依頼した5件が実際に登録されるかどうかは、来週の点検を待たないと分からない。🔧 サイトマップに在るのに未登録の12件が抜けるかを来週確かめる。
もう一つ、正直に書いておきたい。345件の内訳を足したら344件にしかならず、12件の型分けを足したら11件にしかならなかった。どちらも1件のずれで、原因は前の章に書いたとおり別々だった（転送URLの取りこぼしと、素材の書き落とし）。件数の少なさにも助けられた。もしこの2つが100件単位のずれだったら、原因を確かめる前に「だいたい合っている」で済ませていたかもしれない。
今回の記事全体を通じて、足し算が1件合わない箇所が2箇所あった。件数の多い項目（①1,019件のような数字）では気づきにくい1件のずれも、こうして内訳を書き出していく過程では見える。今回はどちらも、ずれに気づいた段階で終わらせず、原因まで確かめられた。1件は仕分けの確認の仕組みが転送を自動でたどっていたこと、もう1件は渡された素材の書き落としで、原因はまったく別だったが、どちらも「足し算をして、合わなければ一覧を洗い直す」という同じやり方で見つかった。
まとめ
Search Consoleに溜まっていた通知を、初めて1件ずつ開いて分類した。メッセージは65件中33件が未読で、そのうち1件は「完全に修正できませんでした」という件名を、途中で切れた表示のまま良い知らせだと読み間違えていた。インデックス未登録1,214件のうち、クロール済み-未登録345件を仕分けると、261件はnoindex、69件は404、12件がサイトマップに残っているのに未登録という状態だった。
404の12件は、2件がすでに解消済み、4件を転送で直し、残り6件はリンクが1本も無い正しい404だった。robots.txtブロック36件は、標準の判定器では正しく測れず、Googleと同じ最長一致で測り直して初めて「対応不要」と言い切れた。重複3件のうち1件は末尾スラッシュの違いで、サイト内リンクを揃えて直した。
いちばん大きな判断は、「修正を検証」ボタンを一度も押さなかったことだ。どの理由にも意図どおりのURLが混ざっている以上、押せば必ず失敗の通知が増え、本物の知らせが埋もれる。押すのは、その理由に該当するURLの全部が直ったと確かめられたときだけ、と決めた。そして、この点検を1回で終わらせず、毎週木曜日の定例作業にした。
自分のサイトのSearch Consoleも、合計や件数の増減だけで判断せず、一度は1件ずつ開いて理由を仕分けてみることをすすめる。意図どおりのものと、本当に直すべきものを、開かずに区別する方法は無い。
仕分けたら、内訳を足して、報告されている合計と一致するかも確かめるとよい。今回は、重複記事をまとめる際に301で転送しているURLが1件、どの区分にも入らないまま埋もれていた。転送を自動でたどる確認の仕組みでは、転送されたURLが転送先のページとして数えられてしまう。足し算が合わないことに気づいたから、この1件を見つけられた。
そして、仕分けが終わったら、いちばん対応しやすい理由から手を付けるのではなく、いちばん判断に手間がかかる理由――今回で言えば、サイトマップに残っているのに未登録の12件――から先に開くことをすすめる。件数が少ない区分ほど、合計に埋もれて後回しにされやすい。今回はその12件のなかに、実際に対応できるもの（型①の5件）と、しばらく様子を見るしかないもの（型②の2件）と、サイト側の作り方を変えることで対応できたもの（型③の4件、そして後から見つかったもう1件）の、複数の違う対応が混ざっていた。開いてみるまで、その違いは分からなかった。
関連 archives（連載軸として読む）
- archives/146「毎朝の『警告1,415件』を、初めて種類別に数えた」 ── 合計を種類別に数え直す、という同じ手順を前日に踏んだ記事（2026-09-24）
- archives/38「sitemapに書いたURLがGoogleから見えていなかった日」 ── 今回と逆方向の末尾スラッシュの問題（2026-04-18）
- archives/128「出力は在った。だから誰も測らなかった」 ── 出力の内訳を一度も見ていない、という同じ形（2026-08-17）
- archives/54「Googleの数字は11ヶ月、壊れていた」 ── Search Consoleの表示を鵜呑みにしない理由（2026-05-14）
- archives/16「Search Consoleが教えてくれること」 ── データを読む力についての最初期の記事（2026-03-24）
