診断ではなくステータスから始める
ページ インデックス作成レポートには、真の技術的問題と予想される除外事項の両方が含まれています。 robots.txt ルール、noindex ディレクティブ、認証要件、または応答の失敗により、インデックス作成が妨げられる場合があります。重複ステータスと正規ステータスは意図したとおりに機能する可能性があります。また、発見された URL は単にまだクロールされていない可能性があります。
最も誤解を招きやすい状態は、「クロール済み - 現在インデックスに登録されていません」です。これにより、Google がページを取得しましたが、その時点ではインデックスに追加しなかったことがわかります。 Googleは、ページは後でインデックスに登録される場合とされない場合があり、このステータスだからといって再送信する必要はないと明言しています。
本当にエラーであるステータス
これらはあなたの側で保存を妨げた何かを示します。Googleは各ステータスの発生源を、自分で直せる場合はウェブサイト、原因が向こう側にある場合はGoogleと分類します。根本のレスポンスを正すことが、対処のすべてです。
| ステータス | 意味 | 発生源 |
|---|---|---|
| サーバーエラー（5xx） | サーバーが500番台のエラーを返した | |
| リダイレクトエラー | リダイレクトの連鎖が循環または失敗した | ウェブサイト |
| robots.txt によりブロック | robots.txtが取得の許可を与えなかった | ウェブサイト |
| 「noindex」タグによって除外 | ページがnoindexディレクティブを返した | ウェブサイト |
| ソフト404 | 「見つかりません」の内容をコード200で返した | ウェブサイト |
| 不正なリクエストによりブロック（401） | ページが認証情報を要求した | ウェブサイト |
| 見つかりませんでした（404） | URLが404を返した | ウェブサイト |
| アクセス拒否によりブロック（403） | サーバーが403を返した | ウェブサイト |
| その他の4xxによりブロック | それ以外の4xxレスポンス | ウェブサイト |
このうち二つは自ら招いた例が多いため、とくに注意する価値があります。ソフト404とは、丁寧な「ここには何もありません」というページをステータス200で返している状態です。検索エンジンには不在ではなく「取得成功かつ内容が薄い」と映るので、404か410で事実を伝えてください。また公開するつもりのページに401や403が出ている場合、たいていはステージング用のルールかファイアウォールが本番へ紛れ込んでいます。
エラーに見えて、エラーではないステータス
無駄な作業を最も多く生むのがこちらです。いずれもGoogleが自らの判断を報告しているだけであって、あなたが持ち込んだ不具合ではありません。これらを追いかけることは、本当の問題に必要な注意力を食い潰します。
| ステータス | 実際の意味 |
|---|---|
| 代替ページ（適切なcanonicalタグあり） | 統合が意図どおりに機能している |
| 重複しています。ユーザーにより選択された正規ページがありません | canonicalを宣言しなかったのでGoogleが選んだ |
| 重複。Googleにより、ユーザー指定とは異なるページが選択されました | 宣言したが、Googleが同意しなかった |
| リダイレクトエラーのあるページ | 非正規URLが設計どおりリダイレクトしている |
| 検出 – インデックス未登録 | 存在は把握しているが、まだ取得していない |
| クロール済み – インデックス未登録 | 取得し、評価し、脇に置いた |
二つの重複ステータスは区別する価値があります。「ユーザーにより選択された正規ページがありません」は、canonicalを一度も宣言せずGoogleが代わりに選んだ状態です。ほぼ無害ですが、自分で下せる判断を明け渡していることになります。「ユーザー指定とは異なるページが選択されました」は、宣言したうえで覆されたということであり、あなたが指名したページを検索エンジンは主たるものと見ていないという合図です。
「クロール済み – インデックス未登録」を正直に読む
このステータスは、Google がページをクロールしたものの、その時点ではインデックス登録しなかったことを意味します。原因が 1 つに決まるわけではなく、URL 検査のライブテストでも将来のインデックス登録を確実に予測することはできません。レポートに書かれていない技術エラーを決めつけるべきではありません。
テンプレート型サイトでは、類似・重複の度合い、canonical シグナル、内部リンク、各ページが類似ページにはない情報を追加しているかを確認すると有効です。これは診断の観点であり、このステータスの URL がすべて品質基準を下回ったという意味ではありません。
- URL検査ツールを開き、200を返すこと、自己参照canonicalであること、本文がレンダリングされることを確認する。
- 最も近い3つの兄弟ページと比較する。差し替え値を入れ替えて同等のページになるなら、検索エンジンにも同じように見えている。
- 説明的なアンカーテキストで内部リンクされているか、それともサイトマップにしか存在しないかを確かめる。
- このページが答えていて、どの兄弟も答えていないことは何かを問う。答えがなければ、それこそが所見である。
- その答えが存在するようページを変更し、そのうえでインデックス登録をリクエストする——この順序で。
「検出 – インデックス未登録」は別のシグナル
こちらはURLの存在は知られているが取得されていない状態です。小規模サイトなら通常は一時的な状態にすぎません。規模が大きい場合、これはGoogleが名指しする、真のクロールバジェット制約の最も明確な症状です。URLが多すぎ、需要が少なすぎて、順番が回ってこないのです。
URLの大きな割合がここに留まっているなら、生産的な仕事は個別のページを再送信することではなく、検索エンジンに検討を求める低価値URLの数を減らすことです。重複を統合し、消えたものには正しい404を返し、リダイレクトの連鎖を短くする、といった作業です。
症状ではなくレポートを片付ける
レポートは原因別に並ぶため、上から件数順に処理したくなります。それを我慢してください。「リダイレクトエラーのあるページ」の1000件はたいてい機能しているリダイレクト設計ですが、「ソフト404」の40件は実在のページに影響する本物の欠陥です。
- まずエラー表にあるものをすべて直す——曖昧さがなく機械的に対処できる。
- 情報系のステータスは脇に置く。ただし件数が意図と矛盾する場合、たとえば設計した覚えのないcanonical統合が出ている場合は別。
- 「クロール済み – インデックス未登録」は技術的な課題ではなく、編集上の積み残しとして扱う。
- 再検証は、根本のレスポンスかコンテンツが実際に変わってからにする。