「ここでリクエストを送れば、順番が前に進むはずだ」。公開した記事が検索に出てこないとき、Search Consoleの「インデックス登録をリクエスト」というボタンを前に、そう考える担当者の方は多いはずです。申請という言葉とボタンが並んだ画面を見れば、送った分だけ順番が繰り上がると受け取るのが自然でしょう。
しかし、オウンドメディアの記事制作と公開後の順位の動きを追い続けてきた弊社の立場から言えるのは、クロールの申請でできるのは発見の依頼までで、登録の可否は動かせないという点です。リクエストを繰り返し送っているのに検索結果に出てこないという相談は、原因がまったく別の場所にあります。
本記事では、Googleクローラーの仕組みから、巡回を申請する3つの方法、巡回状況の確認手順、そして申請しても登録されないときに見る場所まで、記事制作の現場の視点で順を追ってお伝えします。
- Googleクローラーがページを見つけて検索結果に載せるまでの4つの工程
- URL検査ツールとXMLサイトマップを使った巡回の申請手順
- 巡回されているかどうかを3つの角度から確認する方法
- 申請しても登録されないとき、技術と記事の中身のどちらから直すかの判断基準
- robots.txtとnoindexの使い分けと、併用してはいけない理由
Googleクローラーとは
Googleクローラー（Googlebot）は、Web上のページをリンクづたいにたどりながら、ページの内容を読み取ってGoogleのサーバーへ持ち帰るプログラムです。誰かが検索する前に、あらかじめWeb上の情報を集めて回る役割を担っています。
最初に押さえておきたいのは、クローラーが訪れることと、そのページが検索結果に表示されることが別の出来事だという点でしょう。ここを同じものとして捉えていると、後述する原因の切り分けで必ず迷います。
クロールからインデックスまでの4つの工程
Googleが1つのページを検索結果に載せるまでには、大きく4つの工程があります。
- クロール：クローラーがURLを訪問し、HTMLやCSS、画像などのファイルを取得する
- レンダリング：JavaScriptを実行し、ブラウザで見えるのと同じ状態にページを組み立てる
- インデックス：組み上がったページの内容を解析し、検索用のデータベースに登録する
- ランキング：検索された言葉に対して、登録済みのページの中から表示順を決める
この並びで見落とされがちなのが、3番目のインデックスが自動的な作業ではないという点です。クロールしたページのすべてが、インデックスに登録されるわけではありません。Googleは取得した内容を解析したうえで、検索結果に載せる価値があるかどうかを判断します。ここで見送られたページは、何度クロールを申請しても検索結果には現れません。
クロールとインデックスの違い
用語が混ざりやすいため、いったん整理します。クロールは「ページを取りに行く行為」、インデックスは「取ってきたページを検索用のデータベースへ登録する行為」を指します。図書館にたとえるなら、職員が本を集めて回るのがクロール、集めた本を目録に載せるのがインデックスです。書庫に本が届いていても、目録に載っていなければ利用者は見つけられません。
Googleがどのように情報を集め、整理しているかは公式に説明されています。有料でクロール頻度を上げる仕組みは用意されていない点も、あわせて明記されています。
関連記事：【2025年最新版】初心者でもできるSEOのやり方完全ガイド | 上位表示するための具体的な方法を徹底解説
知っておきたいGooglebotの種類
Googleのクローラーは1種類ではありません。用途ごとに複数のクローラーが動いており、robots.txtで制御する際にはユーザーエージェント名で指定します。代表的なものを並べます。
クローラー名 | 主な役割 |
|---|---|
Googlebot Smartphone | 検索順位の判断基準となるモバイル版ページの取得 |
Googlebot Desktop | パソコン向け表示の取得 |
Googlebot Image | 画像検索に使う画像の取得 |
Googlebot Video | 動画検索に使う動画の取得 |
Googlebot News | ニュース向けコンテンツの取得 |
Google-InspectionTool | URL検査ツールなど、検査系機能の実行 |
現在のGoogleはモバイルファーストインデックスを採用しているため、順位の判断に使われるのはスマートフォン版のページです。パソコン版に詳しい解説を載せながら、スマートフォン版では画面の都合で省略している、という構成にしている場合、省略した部分は評価の対象から外れます。レスポンシブデザインであれば基本的に同じHTMLが配信されるため、この問題は起きにくいでしょう。
※ クローラー名とユーザーエージェント文字列の正式な一覧は、Google公式のドキュメントで随時更新されています。
関連記事：E-E-A-Tとは？Googleの評価基準の基本概念
クローラーに巡回を申請する3つの方法
新しく公開したページや、内容を大きく書き換えたページは、放っておいてもいずれ発見されます。ただ、発見までの時間を短くしたい場面はあるでしょう。申請の手段は次の3つに整理できます。
| URL検査ツール | XMLサイトマップ | 内部リンクの整備 | |
|---|---|---|---|
| 対象の範囲 | 1ページずつ | サイト全体 | サイト全体 |
| 反映までの体感 | 数時間から数日 | 数日から数週間 | 継続的に効く |
| 1日あたりの上限 | あり | 実質なし | なし |
| 向いている場面 | 公開直後の重要ページ | ページ数の多いサイト | 恒常的な発見のされやすさ |
| 手間 | 都度の手作業 | 初回設定のみ | 設計と運用が必要 |
3つは対立する選択肢ではなく、役割が違います。URL検査ツールが緊急時の呼び出しだとすれば、内部リンクの整備は日常的な巡回路の敷設に当たります。
URL検査ツールからのリクエスト
1ページ単位で申請したいときに使う方法です。かつて「Fetch as Google」と呼ばれていた機能は、現在のSearch ConsoleではURL検査ツールに統合されています。
画面左上でプロパティを切り替え、申請したいURLが含まれるプロパティを選びます。
サイト内のURLを入力すると、そのページの登録状況の照会が始まります。
「URLがGoogleに登録されていません」と出た場合は、続けて申請へ進みます。すでに登録済みでも、内容を更新したときは再申請できます。
ボタンを押すと、優先クロールの待ち行列に追加されます。完了通知は届かないため、数日後に再度URL検査で状態を確かめます。
ここで注意したいのは、同じURLへ繰り返しリクエストを送っても順番は前に進まないことです。待ち行列に入るだけで、送信回数によって優先度が上がる仕組みにはなっていません。反応がないときに何度も押したくなりますが、その時間は次の章で扱う原因の切り分けに充てたほうが結果につながります。
XMLサイトマップの送信
サイト全体の地図をGoogleへ渡す方法です。WordPressであれば主要なSEOプラグインが自動生成しますし、多くのCMSにも同等の機能が備わっています。生成したファイルのURLを、Search Consoleの「サイトマップ」から送信します。
一度送信すれば、以降はGoogleが定期的に読みに来ます。ページを追加するたびに再送信する必要はありません。むしろ大切なのは中身の鮮度で、更新日時（lastmod）が実際の更新と食い違っていると、参考情報として扱われにくくなります。
内部リンクと被リンクによる発見
もっとも根本的な方法が、リンクで到達できる状態をつくることです。クローラーはリンクをたどって移動するため、どこからもリンクされていないページは、サイトマップに載っていても優先度が低いまま放置されがちになります。
新着記事を一覧ページやカテゴリページから必ず参照する、関連記事同士を本文中で結ぶ、パンくずリストで階層を明示する。地味な作業ですが、この経路が整っているサイトは、申請しなくても公開当日から翌日にはクロールされる状態になります。
関連記事：GoogleのSEOガイドラインとは？公式文書の読み分けと使い方
巡回されているかを確認する方法
申請の次は確認です。「来ているのか来ていないのか分からない」まま対策を打つと、直す場所を間違えます。確認は3つの角度から行います。
まずサイト全体の傾向を見るのが、Search Consoleの「設定」内にあるクロールの統計情報です。過去90日間のクロールリクエスト数、平均応答時間、ファイル形式ごとの内訳が確認できます。リクエスト数が右肩下がりに減っていれば、サイト側で何かが起きている合図と読みます。
次にページ単位です。URL検査ツールで対象URLを照会すると、「前回のクロール」として日時が表示されます。ここが数か月前で止まっているなら、そのページはGoogleにとって優先度の低い場所に置かれていると考えられます。
3つ目が、検索窓に「site:」と自社ドメインを入力する簡易チェックです。おおよその登録状況をつかむには手軽ですが、表示件数は概算のため、正確な数はSearch Consoleのページレポートで確認してください。
確認の順番は、全体（クロールの統計情報）から個別（URL検査ツール）へ。いきなり1ページだけを見ると、サイト全体で起きている問題を個別ページの問題と取り違えます。
クローラーが来ない原因の切り分け
ここからが実務の本題です。クローラーが来ない、あるいは来ても検索結果に出ないという状況は、原因が3つの層に分かれます。
Web担当者公開して2週間経つのに、記事が検索に出てきません。クロールの申請が足りないのでしょうか。
Writers-hub編集部
申請の回数はほとんど関係ありません。Search Consoleのページレポートを開いて、そのURLがどの状態になっているかを見てください。「検出 - インデックス未登録」なら発見までは済んでいる、「クロール済み - インデックス未登録」なら読み取りまで終わっている。どこで止まっているかで、直す場所がまるで変わります。
止まっている場所は、発見されていない、取得できない、登録されない、の3段階に分けて考えると整理できます。
技術的な障害でクロールが止まっている場合は、次のいずれかに該当していないかを確認します。
- robots.txtでクロールをブロックしたままになっている
- テスト環境から本番へ公開する際、noindexタグを外し忘れている
- サーバーが5xxエラーを返している、または応答が極端に遅い
- 会員機能などでページ全体が認証の内側に入っている
- 全ページのcanonicalがトップページを指すよう誤設定されている
- サイトマップに古いURLや404のURLが大量に残っている
とりわけ多いのが2番目の、公開時のnoindex外し忘れです。サイトをリニューアルした直後、まったく検索に出ないという相談の何割かは、この一行が残っていたことで説明がつきます。まずHTMLのソースを開き、head内にnoindexの記述がないかを確認してください。
申請しても登録されないときの見どころ
技術的な問題が見当たらないのに登録されない。この状態が、いちばん相談の多いパターンです。
ページレポートで「クロール済み - インデックス未登録」と表示されているなら、Googleはそのページを取得し、内容を読んだうえで、検索結果に載せない判断をしています。登録されない原因の多くは、発見の失敗ではなく中身の判断にあります。
では、何を見て判断されているのか。実務で当たることが多いのは次の3つです。
1つ目が、既存ページとの内容の重なりです。同じキーワードを狙った記事が自社内に複数あると、Googleは代表となる1ページを選び、残りを重複として扱います。この場合、新しく公開した記事が選ばれない限り、いつまでも登録されません。カテゴリ違いで書き分けたつもりが、読者から見れば同じ問いに答えている、というケースはよく起こります。
2つ目が、既存の検索結果に対して追加される情報がない状態です。上位10本を読めば分かる内容だけで構成された記事は、取得はされても登録の優先度が上がりません。ここは制作側の実感として言えることですが、独自の情報を1つ足すだけで状況が変わる例を何度も見ています。自社の実測値、実務での判断基準、担当者への取材メモ。何でも構いません。
3つ目が、サイト全体の評価です。個別ページに問題がなくても、低品質なページが大量にあるサイトでは、新規ページの登録が後回しになります。自動生成のタグページや、中身の薄い一覧ページが数千件あるなら、そちらの整理が先です。
「クロール済み - インデックス未登録」を技術で解こうとすると、時間だけが過ぎます。サイトマップの再送信もリクエストの再送も、この状態には効きません。読み手にとって何が増えるのかを、記事単位で見直してください。
ここまで読んで、直すべき場所が記事の中身の側にあると分かった方も多いのではないでしょうか。とはいえ、既存記事の重複を洗い出し、追加すべき情報を決め、書き直すところまでを通常業務と並行して進めるのは、なかなか手が回らない領域です。
登録されない記事が溜まったまま、次の記事を書き続けていませんか
公開済み記事のうちどれが重複と判断されているか、どのページから直せば登録が進むかを、Search Consoleの実データをもとに切り分けてご提案します。技術面と記事内容の両方から、優先順位を付けてお渡しします。
robots.txtとnoindexの使い分け
逆に、クローラーに来てほしくないページもあります。検索結果に出す必要のない管理画面、社内向けの資料置き場、パラメータ違いで無限に増える絞り込みページなどが該当します。
制御の手段は主に2つですが、効く工程がまったく違います。
それぞれの働き方を並べると、次のように整理できます。
手段 | 働く工程 | 効果 | 向いている場面 |
|---|---|---|---|
robots.txt | クロールの前 | ページを取得させない | サーバー負荷の軽減、大量の不要URLの遮断 |
noindexメタタグ | インデックスの段階 | 取得はされるが登録しない | 検索結果から確実に外したいページ |
ここで最も事故が多いのが、両方を同時に設定してしまうケースです。robots.txtでブロックしたページのnoindexは、読まれません。クローラーがページを取得できない以上、HTML内に書かれた指示は目に入らないためです。結果として、他サイトからリンクされていると、内容不明のままURLだけが検索結果に残ることがあります。
検索結果から確実に外したいなら、robots.txtの記述は外し、noindexだけを設定してクロールさせてください。除外が反映されたことを確認してから、必要に応じてrobots.txtでの遮断を検討します。順番が逆になると、いつまでも消えません。
なお、リンク先へ評価を渡したくないときに使うnofollowは、クロールやインデックスの可否とは別の指示です。混同すると意図しない設定になるため、目的を分けて考えてください。
クロールバジェットを気にすべき規模
クロールバジェットという言葉を目にして、自社サイトでも対策が必要かと考える方がいます。結論から言えば、多くのサイトには当てはまりません。
Googleが大規模サイト向けの案内で挙げている目安は、100万ページを超えていて内容が週1回程度更新される規模、または1万ページを超えていて内容が毎日大きく変わる規模です。数百ページから数千ページのコーポレートサイトやオウンドメディアであれば、公開したページが当日から数日でクロールされている限り、意識する必要はないでしょう。
それでもサーバーの応答速度は無関係ではありません。応答が遅いとGoogleはクロール速度を自動的に落とすため、表示速度の改善は結果としてクロールの効率にも働きます。
Googleクローラーのよくある質問
現場で受けることの多い質問をまとめます。
ページによって大きく異なります。更新頻度の高いトップページやカテゴリページは数日おき、長く更新のない下層ページは月単位になることもあります。実際の日時はURL検査ツールの「前回のクロール」で確認できるため、推測せず実データを見てください。
外部からのリンクが1本もない状態だと、発見の手がかりがありません。Search Consoleにプロパティを登録してサイトマップを送信したうえで、公式SNSや既存の自社サイトからURLを参照する経路をつくってください。数日で状況が変わることがほとんどです。
あります。ただしGoogleは応答時間の悪化を検知するとクロール速度を自動的に落とします。5xxエラーが続くとクロール自体が大きく減るため、サーバーの安定化は表示速度だけでなく登録のされやすさにも関わります。
レンダリング工程で実行されるため読み取られます。ただし取得からレンダリングまでに時間差が生じることがあり、主要な本文や見出しをJavaScriptに依存させると反映が遅れます。重要な情報は最初のHTMLに含めておくのが安全です。
4つの質問に共通しているのは、推測ではなく実データを見れば答えが出るという点です。Search Consoleに表示されている状態を起点にすれば、次に何をすべきかは自然と絞り込まれていきます。
技術面は問題ないはずなのに、検索流入が伸びないままですか
クロールやインデックスの状態、記事の内容、サイト構造のどこに原因があるのかを、実際のデータを見ながら切り分けます。今の運用体制のままでどこまで改善できるかも含めて、率直にお伝えします。
まとめ｜クローラーは呼ぶより読める状態で決まる
Googleクローラーへの巡回申請は、発見までの時間を縮める手段です。URL検査ツールとXMLサイトマップで入口をつくり、内部リンクで日常的な経路を保つ。ここまでが申請の役割になります。
そのうえで、登録されるかどうかを決めているのは記事の中身とサイト全体の状態です。「クロール済み - インデックス未登録」が並んでいるなら、リクエストの再送では動きません。既存ページとの重なりを解き、その記事にしかない情報を足すところから始めてください。
私たち合同会社Writers-hubは、数多くのオウンドメディアで記事制作と公開後の改善を手がけてきました。クロールの状態を確認するところから、どの記事をどう直すかの判断まで、実データをもとに伴走しています。手が回らない工程が出てきたときは、お声がけください。
