クローリング
検索エンジンがウェブを発見して取得する仕組みを解説。GooglebotとBingbot、URLの発見、クロールのスケジューリング、レンダリング、インデックス登録やランキングとの違いを網羅します。
言語
このページには証拠シグナルが1件あります
- リンクされたソースデータgooglebot.json
クローリングは検索の最初の段階(クロール→インデックス登録→検索結果への表示)です。GooglebotやBingbotがURLを発見してページを取得し、その後のレンダリング、インデックス登録、ランキングを可能にします。検索に表示されるために必要ですが、ランキング要因ではなく、インデックス登録やレンダリングとも別の処理です。大半のサイトでクロールバジェットの管理は不要です。問題が起きたときはサーバーログが実態を示します。
要点 — クローリングとは、検索エンジンがページを発見して取得する仕組みです。 Googlebot(Google)やBingbot(Bing)などのボットはリンクをたどり、サイトマップを読み取って URLを発見し、その内容を取得します。検索結果に表示されるには、まずクロールされる必要があります。 ただし、頻繁にクロールされても順位が上がるわけではありません。
クローリングとは
検索エンジンは、人間と同じようにウェブを閲覧するわけではありません。クローラー、ボット、 スパイダーと呼ばれる自動プログラムを送り出し、ページを訪問して内容を取得し、リンクをたどって 別のページを見つけます。GoogleのクローラーはGooglebot、BingのクローラーはBingbotです。
処理は次の3段階で進むと考えると分かりやすいでしょう。
- クロール — ボットがURLを発見し、ページを取得します。
- インデックス登録 — 検索エンジンがページを処理し、検索結果に表示できる情報のデータベースへ保存します。
- 検索結果への表示(ランキング) — 検索が行われると、インデックスから最適な候補を選び、順序付けします。
クローリングは最初の段階です。クロールされなければインデックス登録できず、インデックス登録されなければ順位も付きません。つまり重要な入口ではありますが、点数を競う指標ではありません。
クローラーがページを見つける方法
主な方法は2つです。
- リンクをたどる。 ボットはページをクロールすると、その中のリンクを取得し、リンク先URLを次のクロール候補に加えます。新しいページの発見には適切な内部リンクが重要です。
- サイトマップ。 XMLサイトマップはサイトのURL一覧を検索エンジンへ直接渡すもので、すべてをリンクだけから発見する必要をなくします。
ページの変更を検索エンジンへ能動的に知らせる「プッシュ」方式もあります。詳しくは後述しますが、通常はリンクとサイトマップが大半の役割を担います。
検索エンジンがサイトをクロールしやすくする方法
- 重要なページへ、ほかのページ(特にホームページや主要ナビゲーション)からリンクします。
- Google Search ConsoleとBing Webmaster ToolsでXMLサイトマップを送信します。
- 発見してほしいページを誤って遮断しないよう、
robots.txtを確認します。 - サーバーを高速で安定した状態に保ちます。遅延やエラーが続くと、ボットはクロールを減らします。
よくある最大の誤解
クロールとランキングは同じではありません。 クロール頻度が上がっても検索順位は上がりません。また、robots.txtでページをブロックしてもGoogleから削除されません。 Googleが内容を読めなくなるだけです。 Evidence for this claim robots.txt controls crawler access and is not a reliable way to keep a URL out of Google. Scope: Google Search behavior for URLs blocked by robots.txt; blocked URLs may still be indexed when discovered elsewhere. Confidence: high · Verified: Google Search Central: Introduction to robots.txt ページを削除したいなら、クロールを許可したうえでnoindexを付けます(このブロック実験についてはAdvanced版で説明します)。
クロールのスケジューラー、取得上限、クロール・インデックス登録・ランキングの違いを詳しく知りたい場合は、Advancedタブへ切り替えてください。
要点 — クローリングは検索の3段階(クロール→インデックス登録→表示)の最初です。 ボットはプル(リンクとサイトマップ)とプッシュ(IndexNow、Indexing API)でURLを発見し、 サーバーの状態に応じて調整されるアルゴリズム上の予定に従って取得します。JavaScriptのレンダリングは別工程です。 クロールはランキングに必要ですがランキングシグナルではなく、インデックス登録とも異なります。 大半のサイトでクロールバジェット管理は不要で、実際の挙動はログで確認します。
クローリングは3段階の最初
Three stages run left to right. Crawl: a bot discovers a URL and downloads the page. Index: the engine processes the page and stores eligible information. Serve or rank: the best indexed matches are ordered for a query. The Crawl stage is highlighted, and a note says not every page advances through every stage.
© 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段階で機能し、すべてのページが各段階を通過するわけではありません。 — クロール、インデックス登録、検索結果への表示です。 Evidence for this claim Google describes Search as three stages: crawling, indexing, and serving results. Scope: Google Search's documented processing model; it does not guarantee that a page reaches every stage. Confidence: high · Verified: 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を発見する方法
Two discovery routes feed one crawl queue. Pull discovery includes following links and sitemaps. Push discovery includes IndexNow for Bing, Yandex, and other participating engines but not Google for general pages; the Google Indexing API for JobPosting and BroadcastEvent pages; and change notifications through sitemap lastmod, RSS, and 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のクローラーは条件付きリクエストとキャッシュを使います。レンダリング用リソースの正確なキャッシュ期間は公表されていないため、コード変更の反映期間を固定値で想定せず、多少の遅れを見込みます。
レンダリングはクロールではない
ここは頻繁に混同されます。“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へアクセスできるかを伝えます。 Evidence for this claim robots.txt controls crawler access and is not a reliable way to keep a URL out of Google. Scope: Google Search behavior for URLs blocked by robots.txt; blocked URLs may still be indexed when discovered elsewhere. Confidence: high · Verified: 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+ある規模から重要になります(クロールバジェットとクロール頻度を参照)。
Evidence for this claim Sites without many rapidly changing pages, or whose new pages are crawled the day they are published, generally do not need crawl-budget management. Scope: large websites Confidence: high · Verified: 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を参照してください。
AI要約
Advanced版の要点をまとめます。
- クローリングは検索の第1段階(クロール→インデックス登録→表示)。ランキングに必要ですがランキングシグナルではなく、インデックス登録やレンダリングとも別です。
- 発見はプル+プッシュ。 リンクとサイトマップがプル、IndexNowとIndexing APIがプッシュです。
- 取得はアルゴリズムで調整。 Googleが対象・頻度・件数を決め、
5xxや429で減速します。2026年時点の上限はURLあたり約2 MB、PDFは64 MBです。 - レンダリングは別工程。 状態を持たないChromeでJSを実行し、リソースをキャッシュしますが期間は公表されていません。
- クロール ≠ インデックス登録。 robotsで遮断してもリンク経由で登録され得ます。削除はクロールを許可して
noindexを使います。 - クロールバジェットは容量+需要で、大半のサイトでは管理不要です。
- ログで診断し、バジェットを浪費するスパイダートラップを監視します。AIボットの比率も増えています。
公式ドキュメント
検索エンジンが公開している一次資料です。
- Google検索の仕組みに関する詳細ガイド — クロール→インデックス登録→表示、URL発見、スケジューラー。
- クロールとインデックス登録 — robots、サイトマップ、正規化、クロール制御。
- robots.txtの概要 — できることとできないこと。
- クロールバジェットの最適化 — 容量+需要と対象サイト。
- Googleクローラーとフェッチャーの概要 — ユーザーエージェントと公開IP範囲。
- Inside Googlebot(2026年3月) — 現在のバイト上限と構造。
- Googlebotと15 MB(2022年) — 旧上限との比較。
- Crawling Decemberシリーズ(2024年) — Googlebot、HTTPキャッシュ、ファセット、CDN。
Bing / Microsoft
- bingbot Series: Maximizing Crawl Efficiency — Bingによるクローリングと効率指針の定義。
- Bing Webmaster Tools — Crawl Control — Bingbotの速度と時間帯を設定。
- IndexNow / indexnow.org — 変更URLを即時通知するプッシュ方式。
出典からの引用
GoogleとBingの公式発言です。各リンクは出典ページの該当箇所へ移動します。
Google — クローリングの仕組み
- “Google Search works in three stages, and not all pages make it through each stage.” (翻訳) Google検索は3段階で機能し、すべてのページが各段階を通過するわけではありません。 — Google Search Centralドキュメント。 引用箇所へ
- “Other pages are discovered when Google extracts a link from a known page to a new page… Still other pages are discovered when you submit a list of pages (a sitemap) for Google to crawl. This process is called ‘URL discovery’.” (翻訳) 既知のページから新しいページへのリンクを抽出した場合や、クロール対象のサイトマップを送信した場合にページが発見されます。この処理をURL discoveryと呼びます。 引用箇所へ
- “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. This mechanism is based on the responses of the site (for example, HTTP 500 errors mean ‘slow down’).” (翻訳) サイトへ過剰な負荷をかけないよう高速すぎるクロールを避けます。この仕組みはサイトの応答に基づき、HTTP 500は減速の合図です。 引用箇所へ
- “During the crawl, Google renders the page and runs any JavaScript it finds using a recent version of Chrome.” (翻訳) クロール中、Googleは新しいバージョンのChromeでページをレンダリングし、見つかったJavaScriptを実行します。 引用箇所へ
Google — robots.txtとクロールバジェット
- “A robots.txt file tells search engine crawlers which URLs the crawler can access on your site.” (翻訳) robots.txtファイルは、クローラーがサイト上のどのURLへアクセスできるかを伝えます。 — Google Search Centralドキュメント。 引用箇所へ
- “Taking crawl capacity and crawl demand together, Google defines a site’s crawl budget as the set of URLs that Google can and wants to crawl.” (翻訳) クロール容量と需要を合わせ、Googleはサイトのクロールバジェットを「Googleがクロールでき、かつクロールしたいURLの集合」と定義します。 引用箇所へ
- “If your site doesn’t have a large number of pages that change rapidly, or if your pages seem to be crawled the same day that they are published, you don’t need to read this guide.” (翻訳) 急速に変化するページが大量になく、公開当日にクロールされているなら、このガイドを読む必要はありません。 引用箇所へ
Gary Illyes(Google)(Search Engine LandがGoogleの2017年記事を逐語転載した内容)
- クロール頻度の上限は*“the number of simultaneous parallel connections Googlebot may use to crawl the site, as well as the time it has to wait between the fetches.”* (翻訳) Googlebotがサイトのクロールに使える同時接続数と、取得の間に待つ時間。 です。クロール需要は人気度と情報の古さで決まります。 解説を読む
Fabrice Canel(Microsoft Bing)
- “Crawling is the process by which bingbot discovers new and updated documents or content to be added to Bing’s searchable index.” (翻訳) クローリングとは、BingbotがBingの検索可能なインデックスへ追加する新規または更新済みの文書やコンテンツを発見する処理です。 引用箇所へ
- “Our crawl efficiency north star is to crawl a URL only when the content has been added (URL not crawled before), updated (fresh on-page context or useful outbound links).” (翻訳) クロール効率の指針は、コンテンツが追加されたとき、またはページ内容や有用な外部リンクが更新されたときだけURLをクロールすることです。 引用箇所へ
クロール健全性チェックリスト
検索エンジンが重要なページを発見・取得できるかを素早く確認します。
- 重要ページがクロール可能な場所からリンクされ、孤立していない。
-
robots.txtがインデックス登録したいページを遮断せず、内部検索など価値の低い領域は遮断している。 - XMLサイトマップをGoogle Search ConsoleとBing Webmaster Toolsへ送信し、正規で登録可能なURLと正確な
lastmodだけを載せている。 - サーバー応答が高速で安定し、
5xxやタイムアウトが少ない。 - インデックス削除に
robots.txtを使わず、クロールを許可してnoindexを使っている。 - カレンダー、ファセット、セッションIDなどのスパイダートラップがない。
- GSCのクロール統計で応答コード急増と平均応答時間を確認した。
- サーバーログで無駄なクロールと未到達の重要URLを確認した。
- JS依存コンテンツへ、クリック専用ではなく実際の
<a href>リンクで到達できる。
基本となる考え方
1. 処理の流れ — クロール→レンダリング→インデックス登録→表示。 各段階はフィルターです。ページの成果が出ないときは、変更前に失敗段階を特定します。クロール、レンダリング、インデックス登録、検索語への表示のどこで止まっているかを確認します。
2. 3つの「同じではない」。 次を分ければ混乱の多くが解消します。
- クロール ≠ インデックス登録(遮断ページもリンク経由で登録され得る)
- クロール ≠ ランキング(頻度はランキングシグナルではない)
- クロール ≠ レンダリング(JSは別のキャッシュ可能な工程で実行)
3. 発見=プル+プッシュ。
プルはリンクとサイトマップ、プッシュはIndexNow、Indexing API、lastmodです。ページが見つからないなら、どの経路が運ぶべきか、そもそもリンクがあるかを確認します。
4. クロールバジェット=容量+需要。 容量はサーバーが処理できる量、需要は人気度と情報の古さです。Googleに「もっと」クロールさせるより、トラップ、重複、不要なパラメータなどの無駄を除くほうが実効バジェットを増やせます。
5. ページ削除の判断規則。
検索から消すならクロールを許可+noindex。領域全体をボットに巡回させず、登録も気にしないなら**robots.txtでdisallow**。インデックス削除目的でdisallowを使わないでください。
クロール制御の早見表
各制御が実際に行うこと
| 制御 | クロールを止める? | インデックス登録を止める? | 用途 |
|---|---|---|---|
robots.txtのdisallow | はい | いいえ | 価値の低いURL領域からボットを除外 |
noindex(meta/header) | いいえ(クロール可能である必要) | はい | インデックスからページを削除 |
rel=canonical | いいえ | 統合するが強制ではない | 優先する重複ページを示す |
リンクのnofollow | 追跡を抑制 | いいえ | リンク先を推奨しない/追跡を抑える |
rel="sponsored" / rel="ugc" | ヒント | いいえ | 有料・広告、ユーザー生成リンクを識別 |
5xx / 503 / 429 | 一時的に減速 | いいえ | Googlebotへの短期的な減速合図 |
ボットが重視するステータスコード
200— 正常に取得。301/308— 恒久リダイレクト(統合)。404/410— 消滅。時間とともにインデックスから削除(410がやや速い)。429/500/503— 減速/後で再試行。継続するとクロールが減る。
早わかり
- Googlebotの取得上限: URLあたり約2 MB(PDFは64 MB)。超過分は切り捨て。
- GSCの手動クロール頻度スライダー: 2024年1月に廃止。現在はサーバーシグナルを使用。
- Bingの相当機能: Bing Webmaster ToolsのCrawl Control。
- IndexNow: Bing、Yandexなどで利用し、Googleは不参加。Indexing APIはGoogleのJobPostingとBroadcastEventのみ。
ボットが本物のGooglebotか確認する
Googlebotを名乗る通信は多数あります。逆引きと正引きDNSで確認してください。偽のユーザーエージェントが多く、Googleは近道を用意していません。
同じ確認を手作業で行う方法です。
macOS / Linux
# 1) Reverse DNS the IP from your logs — it should end in googlebot.com or google.com
host 66.249.66.1
# → 1.66.249.66.in-addr.arpa domain name pointer crawl-66-249-66-1.googlebot.com
# 2) Forward DNS that hostname back — it must resolve to the same IP
host crawl-66-249-66-1.googlebot.com
# → crawl-66-249-66-1.googlebot.com has address 66.249.66.1Windows
nslookup 66.249.66.1
nslookup crawl-66-249-66-1.googlebot.com逆引き結果がGoogleのドメインで終わらない場合や、正引き結果が元のIPと一致しない場合はGooglebotではありません。Googleの公開IP範囲(googlebot.json)との照合もできます。
安全なrobots.txtの出発点
User-agent: *
Disallow: /search # internal search result pages
Disallow: /*?*sort= # sort-order parameter spaces
Allow: /
Sitemap: https://example.com/sitemap.xml覚えておく点: Disallowが止めるのはクロールであり、インデックス登録ではありません。検索結果からページを削除する目的には使わないでください。
クローリングの確認と管理に使うツール
- Google Search Console — クロール統計レポート — リクエスト推移、応答コード、平均応答時間、ファイル種別、Googlebot種別を確認できます。
- Bing Webmaster Tools — クロール情報、Crawl Control、Site Scan。
- サーバーログ分析 — 実態を示します。Screaming Frog Log File Analyser、BigQuery、ログ基盤などを利用します。
- クローラー/サイト監査 — Ahrefs Site AuditやScreaming Frog SEO Spiderで巡回を再現し、深度、リダイレクト、遮断URL、トラップを検出します。
- Ahrefs Webmaster Tools — 確認済みサイト向けの無料クロールと監査。
- URL検査(GSC) — 単一URLのクロール、レンダリング、インデックス登録状態を確認します。
時間をかける価値のある資料
私の関連記事
- 技術SEO初心者ガイド — 技術SEO全体におけるクロール。
- 上位2ページをrobots.txtでブロックした実験 — クロールと順位の実験。
- robots.txtで遮断されてもインデックス登録される理由 — 遮断ページも登録される理由。
- robots.txtとSEOの完全ガイド。
- JavaScript SEOの問題とベストプラクティス — レンダリング側の解説。
- 新しいウェブクローラー:AIボットが検索ボットへ迫る。
私の講演
- How Search Works (SlideShare)— クロール、レンダリング、インデックス登録、ランキングの解説。常設の注意書き: “This is my understanding of systems… not going to be 100% complete or accurate.” (翻訳) これは私なりのシステム理解であり、100%完全または正確とは限りません。
その他の資料
- r/TechSEO — クロール/インデックス診断のコミュニティ。
- GoogleのCrawling December シリーズ — 公式の集中解説。
- Googleによるウェブ担当者向けクロールバジェット解説 — Gary Illyesの記事の逐語転載。
- Googlebotのクロールバジェット解説 — 容量と需要モデルの平易な説明。
- Googlebotのバイト上限とクロール構造 — 2026年更新の2 MB、PDF 64 MB、切り捨て動作。
- Bingbotの発見・クロール・抽出・インデックス登録 — Bing側の処理。
- Googlebotのファイルサイズ上限 — 上限超過時の切り捨てを解説。
ポッドキャスト
- サーチ・オフ・ザ・レコード(Google検索広報チーム)— Googlebotがウェブをクロールする仕組み。Gary IllyesとMartin Splittが、統合クロール基盤、HTTP/1.1とHTTP/2、条件付きリクエスト、バイト上限などGooglebotの過去・現在・未来を語ります。聴く
動画
- Google Search Central(YouTube)— How Google Search Worksシリーズと、JavaScript SEOを含むMartin Splittのクロール/レンダリング解説。チャンネル
引用に使える統計
- AIボットが検索ボットへ迫っています。 Cloudflare Radar分析では検索エンジンクローラーが最多ですが、AIボットは明確な2位で、数年以内に追い越す勢いです。出典
- Bingは毎日数百億件の、過去に見たことのない正規化URLを発見します。検索エンジンが積極的に絞り込む規模を示します(Fabrice Canel、Microsoft Bing、2022年)。解説
- 約1億4千万サイトが最も遮断するクローラー — Xibeijia Guanとのrobots.txt遮断率調査。出典
- 上限はURLあたり約2 MB(PDFは64 MB)— 2026年3月時点のGooglebot取得上限(従来は15 MB)。出典
理解度チェック:クローリング
検索エンジンがページを発見・取得する仕組みについての5問です。回答を選び、結果を確認してください。
変更履歴
2026年8月22日に更新。
編集概要と記録された変更の詳細。変更の詳細
-
変更の詳細な注記は現在英語でのみ提供されています。
完全な比較は利用できません — この改訂の以前のスナップショットがアーカイブされていません。
2026年8月10日に更新。
編集概要と記録された変更の詳細。変更の詳細
-
変更の詳細な注記は現在英語でのみ提供されています。
-
変更の詳細な注記は現在英語でのみ提供されています。
完全な比較は利用できません — この改訂の以前のスナップショットがアーカイブされていません。
2026年7月17日に更新。
編集概要と記録された変更の詳細。変更の詳細
-
変更の詳細な注記は現在英語でのみ提供されています。
-
変更の詳細な注記は現在英語でのみ提供されています。
-
変更の詳細な注記は現在英語でのみ提供されています。
完全な比較は利用できません — この改訂の以前のスナップショットがアーカイブされていません。