言語

クローリング

検索エンジンがウェブを発見して取得する仕組みを解説。GooglebotとBingbot、URLの発見、クロールのスケジューリング、レンダリング、インデックス登録やランキングとの違いを網羅します。

初回公開：2026年6月22日 · 最終更新：2026年8月22日 · 上級者向け
AI執筆者：AI v2
このページには証拠シグナルが1件あります

クローリングは検索の最初の段階（クロール→インデックス登録→検索結果への表示）です。GooglebotやBingbotがURLを発見してページを取得し、その後のレンダリング、インデックス登録、ランキングを可能にします。検索に表示されるために必要ですが、ランキング要因ではなく、インデックス登録やレンダリングとも別の処理です。大半のサイトでクロールバジェットの管理は不要です。問題が起きたときはサーバーログが実態を示します。

要点 — クローリングは検索の3段階（クロール→インデックス登録→表示）の最初です。 ボットはプル（リンクとサイトマップ）とプッシュ（IndexNow、Indexing API）でURLを発見し、 サーバーの状態に応じて調整されるアルゴリズム上の予定に従って取得します。JavaScriptのレンダリングは別工程です。 クロールはランキングに必要ですがランキングシグナルではなく、インデックス登録とも異なります。 大半のサイトでクロールバジェット管理は不要で、実際の挙動はログで確認します。

クローリングは3段階の最初

クローリングは3段階の最初です。順位が付くには、ページが各段階を通過する必要があります。 出典： /technical-seo/how-search-works/crawling/

左から右へ3段階が並びます。クロールではボットがURLを発見してページを取得します。インデックス登録では検索エンジンがページを処理し、対象情報を保存します。表示またはランキングでは、検索語に最も合う候補を並べます。クロール段階が強調され、すべてのページが各段階へ進めるわけではないと注記されています。

© Patrick Stox LLC · CC BY 4.0 ·

Googleはこの流れを明言しています。“Google Search works in three stages, and not all pages make it through each stage” (翻訳) Google検索は3段階で機能し、すべてのページが各段階を通過するわけではありません。 — クロール、インデックス登録、検索結果への表示です。 この主張の根拠 Google describes Search as three stages: crawling, indexing, and serving results. 対象範囲： Google Search's documented processing model; it does not guarantee that a page reaches every stage. 信頼度： 高 · 検証日： Google Search Central: In-depth guide to how Google Search works 技術SEOでは「すべてのページが通過するわけではない」点が重要です。クロールされてもインデックス登録されないページや、登録されても検索結果に出ないページがあります。この3段階を分けて考えることが最も有用な基本モデルです。

実際にクロールするもの

「Googlebot」は1つのプログラムのように聞こえますが、実際は違います。私の*How Search Works* では、デスクトップ、モバイル、画像、ニュース、動画、広告など、用途別クローラー群を動かす1 000超のシステムとして説明しています。リクエストの多くはMountain Viewから発生し、すべてが同じクロールバジェット枠を使います。そのため、画像やパラメータURLの暴走が本来のコンテンツ向けクロールを圧迫することがあります。

現在は検索エンジンだけではありません。Cloudflare Radarデータを分析した*新しいウェブクローラーの実態* では、検索エンジンのボットが依然最多ですが、AIボットは明確な2位で、数年以内に追い越す勢いです。ログに登場する顔ぶれは変わっています。

クローラーがURLを発見する方法

発見にはプルとプッシュがあり、Googleは全体を「URL discovery」と呼びます。 出典： /technical-seo/how-search-works/crawling/

2つの発見経路が1つのクロール待ち行列へ入ります。プル型にはリンクの追跡とサイトマップがあります。プッシュ型には、一般ページではGoogleが参加しないBingやYandexなど向けのIndexNow、JobPostingとBroadcastEvent向けのGoogle Indexing API、サイトマップのlastmod、RSS、WebSubによる変更通知があります。

© Patrick Stox LLC · CC BY 4.0 ·

発見にはプルとプッシュがあります。

  • プル — リンク。 Google: “Other pages are discovered when Google extracts a link from a known page to a new page.” (翻訳) Googleが既知のページから新しいページへのリンクを抽出すると、別のページが発見されます。 孤立ページ（どこからもリンクされていないページ）が見つかりにくい理由です。
  • プル — サイトマップ。 “Still other pages are discovered when you submit a list of pages (a sitemap) for Google to crawl.” (翻訳) クロール対象のページ一覧（サイトマップ）をGoogleへ送信することでも、別のページが発見されます。
  • プッシュ — 変更通知。 再クロールを待たず、変更を検索エンジンへ伝えます。IndexNow（Bing、Yandexなど。Googleは一般ページには利用しません）と、GoogleのIndexing API（公式にはJobPostingとBroadcastEventページのみ）が該当します。サイトマップのlastmod、RSS、WebSubもプッシュ手段です。

Googleは全体を*“URL discovery.”* (翻訳) URLの発見。 と呼びます。

クローラーがページを取得する仕組み

  • 予定はアルゴリズムで決まります。 “Googlebot uses an algorithmic process to determine which sites to crawl, how often, and how many pages to fetch from each site.” (翻訳) Googlebotは、クロールするサイト、頻度、各サイトから取得するページ数をアルゴリズムで決定します。 影響を与えることはできますが、直接設定はできません。
  • クロールはサーバーへ配慮します。 “they try not to crawl the site too fast to avoid overloading it… HTTP 500 errors mean ‘slow down.’” (翻訳) サイトへ過剰な負荷をかけないよう高速すぎるクロールを避け、HTTP 500エラーを「速度を落とせ」という合図として扱います。 一時的に遅くするなら503や429を返すとGooglebotは数日程度ペースを落とします。
  • バイト上限があります。 2026年3月のGoogle Inside Googlebot更新によると、GooglebotはURLあたり約2 MB（従来の15 MBから縮小）、PDFは64 MBまで取得します。超過分は拒否ではなく切り捨てとなり、取得済み部分だけがインデックス登録へ渡されます。
  • キャッシュで再取得コストを抑えます。 Googleのクローラーは条件付きリクエストとキャッシュを使います。レンダリング用リソースの正確なキャッシュ期間は公表されていないため、コード変更の反映期間を固定値で想定せず、多少の遅れを見込みます。
この主張の根拠 Googlebot algorithmically determines which sites to crawl, how often to crawl them, and how many pages to fetch. 対象範囲： web 信頼度： 高 · 検証日： In-Depth Guide to How Google Search Works

レンダリングはクロールではない

ここは頻繁に混同されます。“During the crawl, Google renders the page and runs any JavaScript it finds using a recent version of Chrome.” (翻訳) クロール中、Googleは新しいバージョンのChromeを使ってページをレンダリングし、見つかったJavaScriptを実行します。 レンダリングはHTML取得とは別工程です。Web Rendering Serviceは状態を保持せず、読み込みごとにストレージとCookieを消去し、権限要求を拒否し、Service Workerも拒否します。クリック後や実際の<a href>ではないJSナビゲーションでしか現れないコンテンツは、発見やレンダリングに問題が起きやすくなります。詳しくはJavaScript SEO を参照してください。

クロール、インデックス登録、ランキングの違い

このページで最も重要な区別は次のとおりです。

  • クロール ≠ ランキング。 検索結果に出るには必要ですが、ランキングシグナルではありません。クロール頻度が上がっても順位は上がらず、クロールバジェットは効率の問題です。
  • クロール ≠ インデックス登録。 robots.txtでブロックしたページでも、ほかのページからリンクされていればインデックス登録されることがあります。Googleは内容やnoindexを確認できません。Indexed, though blocked by robots.txt で述べたように、“crawling and indexing are two different things.” (翻訳) クロールとインデックス登録は別のものです。 ページを削除するには、クロールを許可してnoindexを追加します。

私はブロックの影響を*上位2ページをrobots.txtでブロックした実験* で直接検証しました。結果は、“We lost a position here or there and all of the featured snippets for the pages… I expected a lot more impact, but the world didn’t end.” (翻訳) 所々で順位を1つ失い、対象ページの強調スニペットをすべて失いました。もっと大きな影響を予想していましたが、世界が終わるほどではありませんでした。 でした。結論は変わりません。“Don’t block pages you want indexed. It hurts. Not as bad as you might think it does — but it still hurts.” (翻訳) インデックス登録してほしいページをブロックしないでください。想像ほど深刻ではなくても、悪影響はあります。

クロールを制御する方法

  • **robots.txt**はインデックス登録ではなくクロールを制御します。“A robots.txt file tells search engine crawlers which URLs the crawler can access on your site.” (翻訳) robots.txtファイルは、クローラーがサイト上のどのURLへアクセスできるかを伝えます。 この主張の根拠 robots.txt controls crawler access and is not a reliable way to keep a URL out of Google. 対象範囲： Google Search behavior for URLs blocked by robots.txt; blocked URLs may still be indexed when discovered elsewhere. 信頼度： 高 · 検証日： Google Search Central: Introduction to robots.txt 価値の低い領域からボットを遠ざけるために使い、インデックス削除には使いません。
  • サイト構造と内部リンクはページの深さと発見可能性を左右します（クロール深度を参照）。
  • クロール頻度の制御。 Googleは2024年初頭にSearch Consoleの手動スライダーを廃止し、サーバー応答と低い自動下限を使っています。Bing Webmaster Toolsには手動のCrawl Controlがあります（クロール頻度を参照）。

クロール効率とクロールバジェット

両検索エンジンとも、クロールを効率の問題として捉えています。Gary IllyesはGoogle側をクロール頻度の上限＋クロール需要（人気度と情報の古さ）と説明します。BingのFabrice Canelは、“crawl efficiency north star … to crawl a URL only when the content has been added … updated.” (翻訳) クロール効率の指針は、コンテンツが追加または更新された場合にのみURLをクロールすることです。 と表現しています。

安心できる点は、大半のサイトで心配する必要がないことです。Googleは、ページ数が多く急速に変化するサイトでなく、公開当日にクロールされるなら、“you don’t need to read this guide.” (翻訳) このガイドを読む必要はありません。 と明記しています。週に変化するページが1M+、または日に10k+ある規模から重要になります（クロールバジェットとクロール頻度を参照）。

この主張の根拠 Sites without many rapidly changing pages, or whose new pages are crawled the day they are published, generally do not need crawl-budget management. 対象範囲： large websites 信頼度： 高 · 検証日： Optimize your crawl budget

クロールに問題があるときの確認方法

修正に着手する前に、どの段階が壊れているかを特定します。段階ごとに症状も対処法も異なります。

  • まったく発見されない場合。 ページへのリンクがなく、サイトマップにもありません。内部リンクとサイトマップを修正し、クロール深度とクロール頻度を確認します。

  • 発見済みだが取得されない場合。 サーバーエラー、タイムアウト、robots.txtの遮断を確認します。GSCのクロール統計とログを調べ、クロールバジェットとクロール頻度を参照します。

  • 取得されたがレンダリングが誤る場合。 クリックやJS専用ナビゲーションに依存している、またはWRSがタイムアウトしています。JavaScript SEOで固有の失敗を確認します。

  • 取得・レンダリング済みでも登録されない場合。 インデックス側の別の判断です。クロール問題として扱わず、インデックス登録ハブを参照します。

  • ログファイル分析が事実を示します。実際にボットが訪れたURL、頻度、ステータスコードを確認でき、無駄なクロールや未到達ページを見つける最良の方法です。

  • スパイダートラップは、カレンダー、ファセットナビゲーション、セッションID、相対リンクの増殖などで無限のURL空間を作り、不要なURLにクロールバジェットを消費します。

次に読む項目：クローリングのトピック群

このハブが全体地図です。以下の各項目には詳しい解説があります。

クロール効率 — 量と頻度

  • クロールバジェット — 容量と需要、無駄になる要因、管理が必要なサイト。
  • クロール頻度 — ボットの取得速度、GSCのスライダー廃止理由、現在の加速・減速方法。
  • 再クロール頻度 — 人気度、情報の古さ、正確なlastmodなど、再訪を早める要因。
  • クロール深度 — クリック深度と巡回深度の違い、重要ページをホームページ近くに置く理由。

クローラーを知る — ページを取得している主体

  • クローラー — ウェブクローラー（ボット、スパイダー）と、取得→解析→追跡の処理。
  • ユーザーエージェント — ボットを名乗る文字列とrobots.txtのトークン、文字列だけを信用できない理由。
  • Googlebot — SmartphoneとDesktop、レンダリング、検証方法。
  • Bingbot — Microsoftのクローラー、Googleとの違い、Bing以外の利用先。
  • AIクローラー — 学習、AI検索、ユーザー起動型の取得ボットと制御方法。

クロール問題の診断

  • ログファイル分析 — 本物のボットを確認し、クロール内容を読み取る方法。
  • スパイダートラップ（クローラートラップ） — 無限のURLを生むパターンと修正方法。

上記の各項目はこのハブ配下の詳しい解説で、サイドバーからも開けます。

外部リンクの属性指定もクロールに関連するページ内制御です。リンクをクロールするかではなく、Googleにどう扱わせるかを示します。nofollow（当初の包括的な指定で、現在はヒント）と、有料・広告リンクやユーザー生成リンク向けのrel=sponsoredとrel=ugcがあります。3つともページ内metaタグの項目です。

最初に発見されることは関連しますが別の段階です。内部リンク、各種サイトマップ、プッシュ方式のIndexNowとGoogle Indexing APIによるURL発見は、**Discovery**ハブで扱います。全体像はHow Search Worksを参照してください。

専門家メモを追加

専門家の引用を固定

新しい人物ですか？まず、 /admin/experts/ → 専門家の引用を固定 から未登録プロフィールを作成してください。