インデックス関連の技術的な問題を診断する方法

Search Console のページのインデックス登録レポートを使った切り分けの手順です。何から直すか、URL 検査で原因をどう確かめるか、どこで手を止めてよいかを説明します。

インデックスの問題は、レポート上の合計数ではなく、自分に必要なページから診断します。まず重要な URL の一覧を作り、そのうちインデックスに登録されていないものとその理由を調べます。そのうえで、深刻度の高い原因から順に対処します。順番は、サーバーエラーとアクセスエラー、意図しないブロック、canonical の競合、エラーに近いページ、そして最後に Google があえてインデックスに登録しなかったページです。各修正は URL 検査のライブテストで確認してから、Google に検証をリクエストしてください。

このプレイブックは、インデックス登録の基礎で説明しているステータスを理解していることを前提としています。

ステップ 1: 重要な URL の一覧を作る

ページのインデックス登録レポートは、パラメータ付きの URL、古いアドレス、公開するつもりのなかったページも含め、Google が把握しているすべての URL を数えます。そのため「インデックス未登録」の数が多いのは普通のことで、Google も、すべての URL をインデックスに登録すべきではないと明言しています(ページのインデックス登録レポート)。まず、自分で作った一覧から始めましょう。

トラフィックを獲得しているページ: 検索パフォーマンス → ページ で、過去 3 か月の上位 50〜100 件。
収益につながるページ: 商品、料金、サービス、店舗・拠点のページ。トラフィックの多寡は問いません。
新しいページ: 過去 90 日以内に公開したすべてのページ。
サイトマップ: インデックスに登録したい canonical URL だけを過不足なく掲載しているはずです。ページのインデックス登録レポートはサイトマップで絞り込め、そのサイトマップの URL のうちいくつが登録されているかを確認できます。また、サイトマップレポートでは、各サイトマップからその URL のインデックス登録状況へ移動できます。

ステップ 2: インデックスに登録されていない URL を見つける

一覧が短ければ、URL 検査 で 1 件ずつ調べます。長い場合は、ページのインデックス登録レポートをサイトマップで絞り込み、理由ごとに、重要な URL が例に含まれていないかを確認していきます。各 URL について、理由とその「ソース」を記録してください。Google の目安として、修正できるのは一般にソースが「ウェブサイト」と表示されている問題だけです。

ステップ 3: 原因を順番に潰していく

原因は次の順で修正します。上位の原因が下位の原因を隠していることがあり、また、最初の項目ほど一度に多くのページへ影響するためです。

順序	ステータス	最初に確認すること	一般的な対処
1	サーバーエラー(5xx)	Google がクロールした時刻のサーバーログとホスティングの稼働状況	容量不足やクラッシュを解消します。5xx が繰り返されると、Google のクロール頻度も下がります
2	リダイレクトエラー	その URL のリダイレクトチェーン全体	最終的な URL へ 1 回のリダイレクトで到達させ、ループを解消します
3	認証要求(401)によりブロック、アクセス禁止(403)、その他の 4xx	ログイン画面、ファイアウォール、ボット対策のルール	公開ページには Googlebot がアクセスできるようにします
4	'noindex' タグにより除外	ページの robots メタタグと `X-Robots-Tag` ヘッダー	検索結果に表示したいページから noindex を外します
5	robots.txt によりブロック	該当する robots.txt のルール	クロールさせたいページに対するルールを削除します
6	重複しています。ユーザーにより、canonical として選択されていません	canonical タグ、リダイレクト、サイトマップ、内部リンクがそれぞれどの URL を指しているか	すべてのシグナルを同じ URL に揃えます
7	soft 404	Googlebot が取得したときにページが何を表示するか	存在しないページは本物の 404 に、実在するページは本物のコンテンツを表示します
8	クロール済み - インデックス未登録	他のページや競合サイトにはない価値がそのページにあるか	ページを改善するか、より強力なページに統合します
9	検出 - インデックス未登録	クロール済みのページからリンクされているか	クロール済みのページからリンクします。非常に大規模なサイトでは、クロールの管理も行います

URL 検査で 1 つの URL を診断する

一覧にある重要な URL ごとに、同じ 5 つの確認を行います(URL 検査ツール)。

判定と理由を読む。 「URL は Google に認識されていません」と表示された場合、Google はそのアドレスをまだ見つけていません。この場合の課題は検出です。Google がすでにクロールしているページからリンクし、サイトマップにも載せましょう。
canonical を比較する。 Google が選択した canonical がユーザーが指定したものと異なる場合、Google はこの URL の代わりに別の URL をインデックスに登録しています。何かを変更する前に、まずその別の URL を確認してください。
クロールを確認する。 前回のクロール日時、スマートフォン用と PC 用のどちらでクロールされたか、クロールが許可されていたか、ページの取得に成功したかを確認します。注意点として、robots.txt でクロールがブロックされている場合、「インデックス登録は許可されていますか?」は常に「はい」と表示されます。Google は取得を許可されていないページの noindex を確認できないためです。
公開 URL をテストする。 既定の表示は、最後にインデックスに登録されたバージョンの内容で、古い場合があります。ライブテストはそのときのページを取得し、レンダリング結果のスクリーンショットを表示します。ログインしたユーザーにしか表示されないコンテンツや、スクリプトの失敗で表示されないコンテンツを見つけるには、これが最も手早い方法です。
インデックス登録のリクエストは修正後にだけ行う。 リクエストには 1 日あたりの上限があり、Google は、同じ URL を繰り返しリクエストしても処理は早まらないとしています(Google にクロールをリクエストする)。

対処が難しいステータスについての補足

robots.txt でブロックされていることと、インデックスから除外されていることは同じではありません。 robots.txt が制御するのはクロールであり、インデックス登録ではありません。他のページからリンクされているブロック済みの URL は、コンテンツなしでインデックスに登録される場合があります。ページを Google から除外したい場合は、クロールを許可したうえで、メタタグまたは X-Robots-Tag ヘッダーで noindex を指定します(インデックス登録のブロック)。除外が反映されるのは Google がそのページを再クロールしたときだけで、時間がかかることがある点にも注意してください。

canonical の競合は、たいてい自分で招いたものです。 Google は、リダイレクトと rel="canonical" を強いシグナル、サイトマップへの掲載を弱いシグナルとして扱い、HTTPS を優先します(重複した URL を統合する)。よくある競合は、canonical タグが 1 つの URL を指している一方で、ナビゲーション、サイトマップ、内部リンクがすべてバリエーション(末尾のスラッシュの有無、大文字、トラッキングパラメータ、http://)を使っているケースです。これらを揃えれば、たいていは次回のクロールで解消されます。

soft 404 には 2 種類あります。 1 つは、本当に存在しないページです。たとえば、200 を返す「商品が見つかりません」のテンプレートがこれにあたり、404 または 410 を返すようにします。もう 1 つは、実在するのに Google からは空に見えるページです。商品のないカテゴリや、スクリプトの失敗後にコンテンツが読み込まれるページがこれにあたり、Google に見えるコンテンツを用意する必要があります。ライブテストのスクリーンショットで確認できます。

「クロール済み - インデックス未登録」はエラーではなく、評価の結果です。 Google はページをクロールしたうえで、現時点ではインデックスに保持しないと判断しました。後でインデックスに登録される場合もあれば、されない場合もあります。そのページが何を加えているのか、率直に問い直してください。他のページの薄い焼き直し、投稿が 2 件しかないタグページ、他の 10 サイトが書いていることの繰り返しになっている記事が、典型的な該当例です。ページを明確に優れたもの、あるいは独自のものにするか、すでにそうなっているページに統合しましょう。

「検出 - インデックス未登録」は、多くの場合リンクの問題です。 Google はその URL を把握していますが、まだクロールしていません。ほとんどのサイトでは、Google がすでにクロールしているページからそのページへリンクし、サイトマップにも載せ続けることで解決します。Google のクロールバジェットに関するガイドが対象としているのは、もっと限られたサイトです。具体的には、週に一度程度更新される 100 万ページを超えるサイトや、毎日更新される 10,000 ページを超えるサイトです(クロールバジェットの管理)。該当する場合は、URL の総数を減らしてください。重複を統合し、取得させる必要のない URL はクロールをブロックし、削除したページには 404 または 410 を返し、クロールされ続ける soft 404 を修正します。

ステップ 4: 修正を検証する

ある理由に該当する URL をすべて修正したら、ページのインデックス登録レポートでその理由を開き、修正を検証 を 1 回だけ押します。Google はまず数件のサンプルページを確認し、問題が残っていれば検証はそこで止まります。問題がなければ、既知の影響を受けるすべての URL を再確認し、それぞれに合格か不合格かを付けます。Google によれば、検証には通常で最長 2 週間程度、場合によってはそれよりはるかに長くかかります。また、検証をリクエストしなくても、通常のクロール中に修正が検出されることがあります。

手を止めるタイミング

あるステータスの対象がインデックスに登録する必要のない URL(パラメータ付き、絞り込み表示、サイト内検索結果、古いリダイレクトなど)であれば、そのステータスを追いかけるのはやめましょう。また、ページを改善し、リンクを張り、再送信してから数か月たっても Google が登録しない場合も同様です。その段階で有効なのは、たいていインデックス登録を再リクエストすることではなく、より強力なページに統合してリダイレクトすることです。

AutoPSEO でできること

AutoPSEO は、ステップ 2 を常時のチェックに変えます。Index Tracker には任意の URL を最大 1,800 件登録でき、そのうち最大 200 件を URL Inspection API で毎日再検査します(検査日が古いものから順に、Google が定めるプロパティあたり 1 日 2,000 件の検査枠の範囲内で実行します)。また、過去 30 日間にインデックスから外れたページと、Google が 120 日間クロールしていないページにはマークが付きます。追跡中の URL がインデックスから外れたとき、または戻ったときには、Index flip アラートが Slack、Microsoft Teams、または Webhook に通知します(アラート)。URL 検査とサイトマップはアプリ内から利用でき、Bing のクロール問題では、同種の問題を Bing 側から確認できます。

新しいページについては、IndexNow が、更新された URL を Bing と IndexNow に対応するその他の検索エンジンに通知します。Google は IndexNow に参加していないため、Google に伝える手段は引き続きサイトマップと内部リンクです。コンテンツエンジンが作成した記事はお客様のサイトに配信され、他のページと同じようにサイトが公開してリンクします。サイトが IndexNow キーを宣言している場合、AutoPSEO は、公開または更新されたホスト上の各アドレスを IndexNow に通知し、IndexNow からの応答を記録します(配信)。