Domain 1 / 225

Google 検索はクロール → インデックス → ランキングの 3 段階で動く

検索基礎の要点

Google 検索はクロール → インデックス → 検索結果の 3 段階で動き、すべてのページが全段階を通過するわけではない。robots.txt はクロール制御、noindex はインデックス制御。canonical はヒントで、強制統合したいなら 301 リダイレクトが確実

なぜこれを学ぶか

検索エンジンの 3 段階はすべての SEO トラブルの切り分けに使う共通フレーム。ここを押さえずに施策を打つと、「robots.txt で消したのに検索結果に出続ける」「canonical を打ったのに統合されない」「インデックス済みなのに検索に出ない」のような症状の原因が突き止められず、対処が場当たりになる。

Web 担当・SEO コンサルが最初の 1 時間で身につけるべき土台。

学ばないと起きること

よくある事故	被害
新規ページが「インデックス登録済み」なのに検索結果に出ない	クエリ関連性 / 品質不足 / serve 段階のブロックが原因なのに、クロール側を疑い続けて時間を浪費する
CSR の初期 HTML が空	Googlebot が主コンテンツを認識できず、数週間〜数ヶ月インデックス遅延が続く
Disallow と noindex の併用順序を間違える	クローラーが noindex 指示を読みに来られず、インデックスから永久に消えない
クロール障害（5xx 連発・robots.txt 取得失敗）に気づかない	サイト全体の評価が下がり、流入が静かに減る
コアアップデートで順位が下がった時、3 段階のどこが原因か切り分けできない	「コンテンツが悪い」と決めつけて全面リライトするが、実は serve 段階の関連性問題で逆効果

学ぶメリット

「クロール / インデックス / serve」のどこで止まっているかを 1 分で切り分けられるようになる
Search Console のレポートが何を意味しているか自分で読み解けるようになる
商談で「インデックス登録 ≠ 検索結果に出る」を即答できれば、SEO 担当としての解像度が高いことを示せる
AI クローラー（GPTBot / ClaudeBot など）への対応も同じフレームで判断できる

仕組み

Google 検索の 3 段階

段階	何が起きるか	主な制御手段
1. クロール	Googlebot が URL を発見しページを取得する	robots.txt / サイトマップ / 内部リンク
2. インデックス登録	コンテンツを解析し、重複統合（canonical 選定）してインデックスに格納	canonical / noindex / 重複コンテンツ整理
3. 検索結果の提供	クエリに応じて関連性の高い順に結果を返す	コンテンツ品質 / 被リンク / E-E-A-T

Google は公式に「すべてのページが 3 段階を通過するわけではない」と明言している。途中で止まる「クロール拒否 / インデックス未登録 / 検索結果に出ない」のどこに該当するかを切り分けるのが SEO 担当者の最初の仕事。

1. クロール（Crawling）

Google は中央管理されたページ一覧を持っていない。新規ページや更新ページを発見するため、Googlebot が常時 Web を巡回している。 URL を発見する経路は 3 つ。

すでに知っているページからの内部リンク
ハブページ（カテゴリページ）から新規記事へのリンク
サイトマップ送信

Googlebot は最新の Chrome でレンダリングし、JavaScript も実行する。CSR でも基本的にはコンテンツを把握できるが、レンダリング処理は重く、すべてのページが即時にインデックスされるわけではない。

クロール失敗の主な原因。

原因	Google の挙動
サーバーが 5xx エラーを返し続ける	クロール頻度を下げて「速度を落とせ」のサインと解釈する
robots.txt の Disallow に該当	クロールしない
ログインや会員制ゲートでアクセス不可	クロールしない
ネットワーク・DNS エラー	クロール失敗として記録

2. インデックス登録（Indexing）

クロール済みページを解析し、内容が酷似する複数 URL をクラスタリングする。そのクラスター内から Google が「これが代表」と判断した 1 ページが canonical として選ばれ、検索結果に出る。それ以外は alternate（代替バージョン）として、モバイル端末や特定クエリで切り替わって表示されることがある。

インデックスに入らない代表的な原因。

コンテンツ品質が低い（薄い、独自性なし、自動生成のコピー）
robots meta の noindex
レンダリング困難な構成（重い CSR、初期表示で空 HTML）
サイト全体の評価が低く、Google が積極的にインデックスする価値を認めない

3. 検索結果の提供（Serving）

クエリ内容、ユーザーの言語・国・デバイスなど数百の要因で順位を決定する。 Search Console で「インデックス登録済み」と出ているページが検索結果に出ないこともあり、その場合の原因は次の 3 つ。

クエリと内容の関連性が低い
コンテンツ品質が低い（E-E-A-T 不足、独自情報なし）
robots meta が serve を阻害（後から noindex を入れた直後など）

キー概念

robots.txt は「クロール制御」、noindex は「インデックス制御」

混同されやすいので、目的別に使い分ける。

目的	使う制御	効果
Googlebot にページを取得させない	robots.txt の Disallow	クロールを止める。ただし URL は他経由で発見されるので、検索結果に「説明なし URL」だけ出る場合あり
検索結果から確実に消す	meta robots `noindex` または `X-Robots-Tag`	クロールはされるが、検索結果には出ない

「インデックスから消したいから robots.txt で Disallow した」は典型的な失敗パターン。 Disallow するとクローラーが noindex 指示を読みに来られず、結果としてインデックスから消えない。

canonical は重複の正規 URL を Google に伝える

同一・類似コンテンツが複数 URL にある場合、検索エンジンに「これが代表」と伝えるタグ。

<link rel="canonical" href="https://example.com/article" />

頻出する重複ケース。

HTTPS と HTTP、www あり / なし
URL パラメータ（?utm_source=...、?color=red など）
AMP / モバイル別 URL
ページネーション（?page=2 系）
商品カラー違いページ

canonical は Google に対する「ヒント」であり、別ページを正規と判定されることもある。強制的に統合したい場合は 301 リダイレクトの方が確実。

リダイレクトのステータスコード

ステータス	意味	リンクシグナル	主な用途
301	Moved Permanently	ほぼ完全に転送	サイト統合、URL 構造変更（恒久的）
302	Found	元 URL の評価を維持	一時的な切り替え、A/B テスト
307	Temporary Redirect	302 の HTTP/1.1 後継	メソッドを変えずに一時転送
308	Permanent Redirect	301 の HTTP/1.1 後継	メソッドを変えずに恒久転送

URL を恒久的に変える場合は 301（または 308）が基本。

よくある誤解

よくある誤解	実際のところ	出典
robots.txt で Disallow すれば検索結果から消える	クロールは止まるが、被リンク経由で URL は発見される。検索結果に「説明なし URL」として出ることがある	robots.txt の概要
canonical で優先順位を上げられる	canonical は重複の正規化用。順位を上げる効果はない	URL の正規化
302 でも SEO 的には 301 と同じ	302 は一時的扱いで、元 URL の評価が維持される。恒久転送には 301 を使う	301 リダイレクト
Search Console で「インデックス登録済み」なら必ず検索結果に出る	出ない場合あり。クエリ関連性が低い、品質が低い、noindex 等が原因	Google 検索の仕組み
Googlebot は JavaScript を実行できない	最新の Chrome でレンダリング・JS 実行する。ただし重い CSR は処理遅延の原因	JavaScript SEO の基本
Google にお金を払えばクロール頻度や順位を上げられる	公式に否定。Google Ads は検索ランキングに影響しない	Google 検索の仕組み
Disallow と noindex を併用すれば確実に消える	NG。Disallow するとクローラーが noindex を読み取れない。先に noindex でインデックスを外し、その後 Disallow するのが正しい順序	noindex の使い方

実務での適用

新規サイト立ち上げ時のチェックリスト

robots.txt が Disallow: /（全拒否）のままになっていないか
サイトマップを Search Console に送信したか
www / 非 www / HTTPS の正規化を 301 と canonical で揃えたか
ステージング環境を noindex で守っているか（robots.txt の Disallow だけだと URL が漏れる）
内部リンクが孤立ページ（オーファンページ）を作っていないか
CSR のページで初期表示の HTML が空になっていないか

トラブル別の対処（3 段階で切り分け）

症状	どの段階で止まっているか	確認すべきこと
公開したページがいつまで経っても検索に出ない	クロール / インデックス / serve のいずれか	Search Console の URL 検査ツールで現在の状態を確認
検索結果に古い URL が出続ける	インデックス	301 が正しく設定されているか／ canonical が新 URL を指しているか
想定外の URL が検索結果に出ている	インデックス（重複統合の誤判定）	URL 検査で Google が選んだ canonical を確認、内部リンクと内容差分を見直す
急に表示回数が落ちた	serve	コアアップデート期間か／ robots.txt や noindex を誤って導入していないか
Search Console で「robots.txt によりブロック」が増えた	クロール	直近の robots.txt 変更がないか／ CDN や WAF が Googlebot を遮断していないか

公式ソース

自己テスト

Q1. robots.txt で Disallow した URL は検索結果から確実に消えるか？

消えない。robots.txt はクロールを止めるだけで、URL は被リンク経由で発見されることがある。検索結果に「説明なし URL」として出る場合があり、確実に消したいときは meta robots の noindex を使う

Q2. canonical タグの正しい用途は？

重複・類似コンテンツの中から「正規 URL」を Google に伝えるためのヒント。順位を上げる効果はなく、Google が別ページを正規と判定することもある。強制的に統合したい場合は 301 リダイレクトの方が確実

Q3. URL を恒久的に変えたい時、301 と 302 のどちらを使うか？

301（Moved Permanently）。リンクシグナルがほぼ完全に新 URL に転送される。 302 は一時的な切り替え扱いになり、元 URL の評価が維持されるので、恒久的な URL 変更には不向き

Q4. Search Console で「インデックス登録済み」と表示されたページは、必ず検索結果に出るか？

出ないこともある。クエリとの関連性が低い／コンテンツ品質が低い／後から noindex を入れた、などが原因。インデックス登録 ≠ 検索結果に出ること、を切り分けて考える必要がある

Q5. Googlebot は JavaScript を実行できるか？

実行できる。最新の Chrome を使って JavaScript を含めてレンダリングする。ただし重い CSR は処理遅延の原因になり、初期 HTML に主要コンテンツがない構成はインデックス遅延を招くことがある

Q6. Disallow と noindex を一緒に書けば確実にインデックスから消えるか？

NG。Disallow するとクローラーが noindex 指示を読みに来られないため、インデックスが残ったままになる。正しい順序は「先に noindex でインデックスを外し、その後 Disallow を追加」

Q7. Google にお金を払えばクロール頻度や順位を上げられるか？

できない。Google が公式に否定している。Google Ads は検索結果ページの広告枠に表示されるが、オーガニック検索のランキングには影響しない

これらの内容を採点付きで挑戦したい場合は、本ドメインのプロ試験で 5 問形式で確認できる。