Skip to main content
Crawl は URL を Firecrawl に送信し、到達可能なすべてのサブページを再帰的に検出してスクレイピングします。サイトマップ、JavaScript レンダリング、レート制限を自動的に処理し、各ページについてクリーンな Markdown または構造化データを返します。
  • サイトマップとリンクの再帰的なたどりによってページを検出
  • パスのフィルタリング、深さ制限、サブドメインや外部リンクの制御をサポート
  • ポーリング、WebSocket、または Webhook で結果を返す
クロールがスクレイピングする各ページは、スクレイピングと同じパイプラインを通ります。そのため、スクレイピングが 1 ページに対してできることは、クロールが到達するすべてのページに対しても実行できます。Capabilities では、その内容、各機能がどこで実行されるか、APIキーが必要かどうかを一覧しています。

Playground で試す

インタラクティブな Playground でクロールをテストできます。コードは不要です。

インストール

基本的な使い方

開始 URL を指定して POST /v2/crawl を呼び出し、クロールジョブを送信します。このエンドポイントは、結果をポーリングするために使用するジョブ ID を返します。
クロールされたページ 1 件ごとに 1 クレジットを消費します。デフォルトのクロール limit は 10,000 ページです。開始前に、クロールエンドポイントは残りのクレジットで limit をカバーできるか確認し、不足している場合は 402 (Payment Required) エラーを返します。これを避けるには、意図したクロール規模に合わせて、limit: 100 のようにより小さい limit を設定してください。特定のオプションには追加クレジットが必要です。JSONモードはページごとに追加で 4 クレジット、PDF 解析は PDF のページごとに 1 クレジットを消費します。

スクレイピングのオプション

/scrape エンドポイント のすべてのオプションは、scrapeOptions (JS) / scrape_options (Python) を使ってクロールでも利用できます。これらは、クローラーがスクレイピングするすべてのページに適用されます (フォーマット、プロキシ、キャッシュ、アクション、ロケーション、タグを含む) 。

クロールステータスの確認

ジョブ ID を使用してクロールのステータスをポーリングし、結果を取得します。
ジョブの結果は、完了後24時間は API 経由で取得できます。この期間を過ぎても、activity logs からクロール履歴と結果を参照できます。
クロール結果の data 配列に含まれているページは、対象サイトが 404 のような HTTP エラーを返した場合でも、Firecrawl がスクレイピングに成功したページです。metadata.statusCode フィールドには、対象サイトから返された HTTP ステータスコードが含まれます。Firecrawl 自体がスクレイピングに失敗したページ (ネットワークエラー、タイムアウト、robots.txt によるブロックなど) を取得するには、専用の Get Crawl Errors エンドポイント (GET /crawl/{id}/errors) を使用してください。

レスポンスの処理

レスポンスはクロールのステータスによって異なります。未完了のレスポンス、またはサイズが10MBを超える大きなレスポンスの場合は、next URLパラメータが付与されます。次の10MBのデータを取得するには、このURLにリクエストしてください。next パラメータがない場合は、クロールデータの終端を示します。
skipnext のパラメータが関係するのは、API を直接呼び出す場合のみです。 SDK を使用している場合は、ページネーションは自動的に処理され、すべての 結果が一度に返されます。

SDK メソッド

SDK で crawl を使う方法は 2 通りあります。

クロールして待つ

crawl メソッドはクロールの完了を待機し、完全なレスポンスを返します。ページネーションを自動処理します。ほとんどのユースケースで推奨されます。
レスポンスには、クロールのステータスと収集された全データが含まれます:

開始して後で確認

startCrawl / start_crawl メソッドは即時にクロール ID を返します。その後、ステータスを手動でポーリングして確認します。これは、長時間のクロールや独自のポーリングロジックに有用です。
最初のレスポンスではジョブ ID が返されます:

WebSocket によるリアルタイム結果

watcher メソッドでは、ページのクロール中にリアルタイムで更新を受け取れます。クロールを開始し、その後イベントを購読することで、データを即座に処理できます。

Webhooks

クロールの進行に合わせてリアルタイム通知を受け取れるよう、webhook を設定できます。これにより、クロール全体の完了を待たずに、スクレイプされたページを随時処理できます。
cURL

イベントタイプ

ペイロード

Webhook シグネチャの検証

Firecrawl からのすべての webhook リクエストには、HMAC-SHA256 シグネチャを含む X-Firecrawl-Signature ヘッダーが含まれます。Webhook が正当で改ざんされていないことを確認するために、必ずこのシグネチャを検証してください。
  1. アカウント設定の Advanced タブ から webhook secret を取得する
  2. X-Firecrawl-Signature ヘッダーからシグネチャを取得する
  3. 取得した secret を使い、生のリクエストボディに対して HMAC-SHA256 を計算する
  4. タイミング攻撃耐性のある関数を使って、計算結果とヘッダーのシグネチャを比較する
シグネチャを最初に検証せずに webhook を処理してはいけません。X-Firecrawl-Signature ヘッダーには、sha256=abc123def456... という形式でシグネチャが含まれています。
JavaScript と Python による完全な実装例については、Webhook セキュリティのドキュメント を参照してください。詳細なイベントペイロード、ペイロード構造、高度な設定、トラブルシューティングを含む包括的な webhook ドキュメントについては、Webhooks ドキュメント を参照してください。

実行と結果の集計

クロールが完了したことは、すべてのページに到達できたことを意味しません。このセクションでは、crawl endpoint が実行について現在報告する内容 — カウンター、ページングの規約、失敗の記録、スコープの上限 — を説明します。これをもとに、その実行結果が次のアクションを判断できるだけの完全性を備えているかを、ご自身で見極められます。ただし、これらの記録はいずれも完全性を保証するものではありません。

ステータスカウンターの読み方

Get Crawl Status (GET /v2/crawl/{id}) のレスポンスには、その実行状況を表すカウンターが必ず含まれます。
完了したクロールで completed == total になっていても、発見されたすべてのページが成功したという意味ではありませんtotal は完了・実行中・キュー待ち・バックログのページを合計し、失敗したページを除外するため、終了状態のクロールでは activequeuedbacklog が必ずゼロになります。そのため、ページが失敗したかどうかに関係なく2つのカウンターは一致します。ステータスカウンターでは失敗の有無を判断できません。失敗したページを列挙できるのは Get Crawl Errors だけです。
data 配列には、Firecrawl が正常にスクレイピングできたページのみが含まれます。試行したものの結果が得られなかったページは data に含まれないため、後述の Get Crawl Errors から確認してください。

結果のページング

レスポンスの上限は10MBです。レスポンスが切り詰められた場合、next に次のページの結果を取得するためのURLが入ります。 next は単に「まだデータが残っている」ことを示すものではありません。statuscompleted 以外のときにも常に返されるため、failedcancelled で終了したクロールでも、残りの結果が存在しないのに next のURLが返ることがあります。next がないことをループの終了条件にしないでください。失敗またはキャンセルされたクロールでは、next が消えることはありません。 終了判定に使うのはステータスフィールドです。実行を最後まで読み取るには、次の手順に従います。
  1. statuscompletedfailedcancelled のいずれかになるまで GET /v2/crawl/{id} をポーリングします。
  2. next が存在し、かつ 直前のページが空でない data 配列を返している間は、next をたどって残りの結果を収集します。
  3. next がなくなったとき、またはページが新しいドキュメントを返さなくなったときに停止します。
公式SDKsはこのページングを自動的に処理し、すべての結果をまとめて返します。

失敗したページとブロックされたページ

Get Crawl Errors (GET /v2/crawl/{id}/errors) は、data に含まれなかったページを記録します。返されるのは2つの配列です:
  • errors — 失敗した scrape job で、それぞれ idurlerror (error message) 、失敗時刻の timestamp を持ちます。これらはネットワークエラーや timeout など、Firecrawl 自体がスクレイピングに失敗したページです。意図的にスキップされた外部サイトのホームページへのリンクも、エラーコード EXTERNAL_LINK としてここに報告されます。
  • robotsBlocked — アクセスを試みたものの、サイトの robots.txt によってブロックされたURLです。
このリストは、すべての失敗を漏れなく列挙することを保証するものではありません。一部の内部的な失敗クラスは、現在レスポンスを構築する前に errors から除外されています。あくまで Firecrawl が報告する失敗の記録であり、他に問題が起きていないことの証明ではない点に注意してください。上記のエラーコード (EXTERNAL_LINK) は現時点でもエラーオブジェクトとして返されますが、公開されている GET /crawl/{id}/errors の schema にはまだ含まれておらず、APIリファレンスの更新待ちです。
対象サイトが404などのHTTPエラーを返したページは、クロールエラーではありません。Firecrawl はスクレイピングに成功しているため、そのページは data に含まれ、サイトのステータスコードが metadata.statusCode に入ります。

クローラーが到達できる範囲

到達範囲は設定した scope パラメータによって決まります。詳細は 設定リファレンスCrawl エンドポイントリファレンス を参照してください:
  • デフォルトでは子ページのみ。 クロールは、指定した URL の子ではないサブリンクを無視します。兄弟パスや親パスをたどるには crawlEntireDomain、サブドメインには allowSubdomains、ドメイン外へのリンクをたどるには allowExternalLinks を使用します。
  • includePaths / excludePaths は URL のパス名に対して正規表現パターンとして照合されます。完全な URL やクエリパラメータは対象外です。クエリ文字列を含む完全な URL に対して照合したい場合は regexOnFullURL: true を設定します。開始 URL も includePaths と照合されるため、一致しない場合はクロール結果が 0 ページになることがあります。
  • sitemap モード。 デフォルトの sitemap: "include" では、URL は sitemap と再帰的なリンク探索の両方から取得されます。"skip" は HTML のリンクのみを使用するため、PDF や深い階層のページなど sitemap にしかないページは取得できません。"only" は sitemap と開始 URL をクロールし、HTML からのリンク探索は行いません。
  • maxDiscoveryDepth は、ルートからたどるリンク探索のホップ数の上限です。最大深度のページ自体はスクレイピングされますが、そこで見つかったリンクはたどりません。
  • limit はページ数の上限で、デフォルトは 10000 です。
  • ignoreQueryParameters は、クエリパラメータのみが異なる同一パスの再スクレイピングを回避します。
  • robots.txt は尊重されます (ignoreRobotsTxt を有効にした場合を除く。Enterprise のみ) 。
maxConcurrency のデフォルトは、プランによって決まるチームの concurrency 上限です — Rate limits を参照してください。

実行ごとに結果が異なる場合

同じ設定で実行しても、クロール結果は実行ごとに異なる場合があります。ページは並行してスクレイピングされるため、リンクが検出される順序はネットワークのタイミングや、どのページの読み込みが先に完了するかに左右されます。そのため、深さの境界付近ではサイト内の異なる分岐が異なる程度まで探索されることがあり、特に maxDiscoveryDepth の値が大きい場合に顕著です。 実行の再現性を高めるには:
  • maxConcurrency1 に設定します。設定リファレンスに記載のとおり、maxConcurrency は「最大同時スクレイピング数」であり、同時に処理中となるリクエスト数の上限を定めます。これによりタイミング依存の処理の入れ替わりは減りますが、実行ごとの差異が完全になくなるわけではありません。サイトマップの検出はこの上限の対象外でキューに入れられ、ネストされたサイトマップは独立したジョブとして取得され、返される data 配列は検出順ではなく完了時刻順に並びます。delay を設定した場合も同時実行数は 1 に強制されます。
  • サイトに包括的なサイトマップがある場合は sitemap: "only" を使用し、URL の集合をリンク検出ではなくサイトマップから取得するようにします。

クロールの完了を知る方法

ポーリングを行わない場合は、webhook イベントから同じ情報を得られます。crawl.page はページのスクレイピングが成功するたびに発火し、crawl.completed (または crawl.failed) は実行の終了時に発火します。ジョブの結果は完了後 24 時間 API から取得できます。それ以降はアクティビティログで確認してください。

設定リファレンス

クロールジョブの送信時に指定できる全パラメータ:

重要な詳細

デフォルトでは、crawl は指定した URL の配下にないサブリンクを無視します。たとえば、website.com/blogs/ をクロールした場合、website.com/other-parent/blog-1 は返されません。兄弟パスや親パスも含めるには、crawlEntireDomain パラメータを使用します。website.com のクロール時に blog.website.com のようなサブドメインも対象にするには、allowSubdomains パラメータを使用します。
  • サイトマップによる検出: デフォルトでは、クローラーは URL を検出するためにウェブサイトのサイトマップを含めます (sitemap: "include") 。sitemap: "skip" を設定すると、ルート URL から HTML リンクを通じて到達できるページのみが検出されます。HTML から直接リンクされていない PDF などのアセットや、サイトマップには記載されていても深い階層にあるページは見逃されます。最大限の網羅性を得るには、デフォルト設定のままにしてください。
  • クレジット使用量: クロールした各ページにつき 1 クレジットかかります。JSONモードではページごとに 4 クレジットが追加され、PDF の解析には PDF 1 ページごとに 1 クレジットかかります。
  • 結果の有効期限: ジョブの結果は、完了後 24 時間は API 経由で利用できます。その後は、アクティビティログで結果を確認してください。
  • クロールエラー: data 配列には、Firecrawl が正常にスクレイピングしたページが含まれます。ネットワークエラー、タイムアウト、または robots.txt によるブロックで失敗したページを取得するには、Get Crawl Errors エンドポイントを使用します。
  • 外部リンク: allowExternalLinks: true を指定すると、クローラーはドメイン外を指すリンクをたどり、リンク先の各ページを 1 回スクレイピングします。ただし、その外部ページで見つかったリンクをさらにクロールすることはありません。無関係なサイト全体を取り込むことを避けるため、外部サイトのホームページ (パスのないルート URL。例: https://example.com/) へのリンクは意図的にスキップされます。これらは Get Crawl Errors にコード EXTERNAL_LINK として表示されます。リダイレクトは宛先までたどられます。これには正規 URL に解決されるリンク (たとえば http → httpswww バリアント) も含まれるため、外部ホームページに到達するリダイレクトのみがスキップされます。
  • 非決定的な結果: 同じ設定で実行しても、クロール結果は実行ごとに異なる場合があります。これは、ページが並行してスクレイピングされ、リンクの検出順序がネットワークのタイミングに左右されるためです。何が変動するのか、また実行の再現性を高める方法については、実行と結果の集計を参照してください。
Firecrawl APIキーが必要な AI エージェントですか? 自動オンボーディング手順については、firecrawl.dev/agent-onboarding/SKILL.md を参照してください。