ヘッドレスコマースストアの動的商品ページをスクレイピングする方法

Scrapeless Agent Browser は、管理されたブラウザーセッションで JavaScript 製のストアフロントをレンダリングし、Scrapeless Residential Proxies は、認可された地域別キャプチャのためのロケーションターゲットアクセスをサポートします。

どのサーフェスがオファーを所有しているかを特定する

ヘッドレスコマースのストアフロントは、ショッピングインターフェースとバックエンドのコマースサービスを分離しているため、商品情報は初期 HTML、アプリケーション状態、レスポンス、およびレンダリングされたページに現れることがあります。収集で答えたい具体的な問いに対応するソースを選んでください。ストアが自分向けに文書化された API やフィードを提供している場合、カタログのアイデンティティにはそれで十分なことがあります。市場やバリアントを選択した後に購入者が見る価格が必要な場合は、レンダリングされた状態も検証します。

初期 HTML と実際のブラウザーセッションを並べて確認します。あるページはサーバー側で商品タイトルとデフォルト金額を送り、その後コントロールをハイドレートして選択されたバリアントのオファーを表示します。別のページは、選択されたオファーをサーバー側でレンダリングし、ブラウザーはバリアント変更のみに使うことがあります。 Hydrogen の商品バリアント選択 は、あるフレームワークがバリアント対応のストアフロントルートとデータをどのように利用するかを説明しています。特定の実装を想定する前に、対象のストアを検証してください。

収集契約では、商品ファミリー、バリアント、市場を分けて考えます。 ProductGroup 語彙 は、グループとそれに属するバリアントを区別します。カノニカルな商品 URL は、選択されたバリアントがクエリパラメータや状態変更として存在していても、ファミリーを識別できます。既知の場合はカノニカルなグルーピング URL と、キャプチャ中に観測された実際の URL の両方を保存します。

前提条件とインストール

Playwright パッケージと Chromium を備えた Node.js プロジェクトを使用します。Playwright の Chromium ランタイムをインストールするか、既存の互換ブラウザーを構成します。承認済みのストアフロントか、分離されたテストフィクスチャを選びます。金額が変わる 1 つのバリアント、利用不可のオプション 1 つ、通貨が異なる市場 1 つを含めてください。リモート実行には Scrapeless アカウントと、文書化された Agent Browser 接続設定が必要です。

承認済みストアフロントでデベロッパーツールを使用し、読み込み、コントロール、リクエストを調査します。収集対象が商品データなのか、購入者向けオファーの証拠なのかを確認します。自分向けに文書化されたインターフェースをサイトが提供している場合は、適切なアクセス権を取得し、その範囲を順守してください。デベロッパーツールに現れるリクエストは、安定したインターフェースを確立するものでも、それを独立して収集する許可を与えるものでもありません。

ステップ 1. 商品と選択市場を発見する

許可されたカタログソースまたは既知の商品 URL から開始し、観測したい市場コンテキストを記録します。通常のナビゲーションに従い、最終的なルートをキャプチャします。特に初期ルートがリダイレクトされる場合は、レンダリングされた市場または通貨インジケーターを探します。ロケールと市場を独立して公開しているストアでは、両方を記録します。商品タイトルの言語だけでは、通貨や配送地域を確立するには不十分です。

この URL Standard は、ブラウザーが URL を解決およびシリアライズする際に使用するコンポーネントを説明しています。ストアの挙動に従ってそれらのコンポーネントを扱ってください。トラッキングパラメータはアイデンティティには無関係な場合がありますが、実際のバリアント選択用のクエリパラメータは証拠として重要です。ルートを正規化する前に、その有無でページをテストしてください。

ステップ 2. バリアントレスポンスを相関させ UI を検証する

オファーレスポンスは、意図したインタラクションと状態に対応している場合にのみ有用です。アクションの前にリスナーを登録し、想定されるオリジンとリクエスト形状を一致させ、選択されたバリアントと市場を検証します。そのうえで、期待される値がレンダリングされたオファーに確定されるまで待機します。すべての非同期更新が完了したことのシグナルとして、汎用的な待機時間に頼るのは避けてください。

次の例は、ボタンクリック後にオファーレスポンスを返し、商品パネルを更新する制御されたストアフロントフィクスチャに対して実行されます。パス、セレクター、ペイロードフィールドはフィクスチャ固有です。対象ストアで検証できるインターフェースやページコントロールにのみ適合させてください。GraphQL ベースの統合では、承認済みのオペレーション名と、その関連入力変数が、共有エンドポイントが複数のリクエストを処理する場合のレスポンス識別に使えます。

async function readMarketVariant(page, targetUrl, variant, market) {
  await page.goto(targetUrl, { waitUntil: 'domcontentloaded' });
  await page.getByTestId('product-ready').waitFor({ state: 'visible' });

  // Register the response listener before selecting the variant.
  const data = page.waitForResponse(response => {
    const url = new URL(response.url());
    return url.origin === new URL(targetUrl).origin &&
      url.pathname === '/fixture/offer' &&
      url.searchParams.get('variant') === variant &&
      url.searchParams.get('market') === market &&
      response.request().method() === 'GET' && response.ok();
  }, { timeout: 5000 });
  await Promise.all([
    data,
    page.getByRole('button', { name: variant, exact: true }).click()
  ]);

  const offer = await (await data).json();
  const panel = page.getByTestId('rendered-offer');
  await panel.getByText(offer.display, { exact: true }).waitFor();
  const visible = await panel.evaluate(node => ({
    variant: node.dataset.variant,
    market: node.dataset.market,
    currency: node.dataset.currency,
    display: node.querySelector('[data-testid="amount"]').textContent.trim()
  }));
  if (offer.variant !== variant || offer.market !== market ||
      visible.variant !== variant || visible.market !== market ||
      visible.currency !== offer.currency || visible.display !== offer.display) {
    throw new Error('Offer response and rendered state disagree');
  }
  return { url: page.url(), ...visible, observedAt: new Date().toISOString() };
}

このフィクスチャでは Olive を選択し、市場 GB 向けの GBP オファーを受信し、表示された £74.00 を検証します。レンダリングされた市場やバリアントがレスポンスと異なる場合は失敗します。実際のストアフロントでは、必要なデータがすでに提供またはプリフェッチされている場合などに、新たなリクエストを発行せずにハイドレートされることがあります。その場合、決して発生しないイベントを期待するのではなく、選択されたオファーを識別できる、検証済みのレンダリング状態チェックを選びます。

ステップ 3. 商品価格、在庫、条件付きオファーを解釈する

この Offer 語彙 価格、通貨、在庫状況に関する用語を提供します。生の金額と正規化された金額は別々のフィールドにし、セール価格、通常価格、会員価格が存在する場合はそれぞれを区別して保持します。ヘッドレスのストアフロントでは、場所が判明してから初めて送料や税金のメッセージを表示する場合があります。データコントラクトが期待するコンポーネントを定義し、検証されるまで条件付きの金額は比較可能な現金価格ビューから外しておきましょう。

見えている金額が同じままでも、あるオプションから別のオプションへ移動するときには、選択されたバリアントを確認してください。2つのバリアントが同じ価格である場合があり、テキストの変化だけを待つ方法は信頼できません。状態マーカーやその他の識別証拠を調べます。この例では、表示金額が確定した後に、レスポンスとパネルの両方の識別子を確認しています。自分で運営するストアでは、安定した単一の収集条件が必要な場合に、バージョン管理された準備完了マーカーを公開してください。

在庫状況とナビゲーション成功を分けて扱います。有効なブラウザレスポンスであっても、売り切れ商品、利用できないバリアント、リダイレクト、あるいはストアフロント障害メッセージを表示することがあります。結果をカテゴリ別に保存して、金額が空であることが誤った最低価格アラートにならないようにします。意図的に完全なオファーのレンダリングに失敗するフィクスチャケースを用意し、下流のパイプラインがそれらを承認済み比較から除外し続けることを確認してください。

ステップ4. ブラウザとプロキシの責任分担を決める

使用 Scrapeless Agent Browser は、Playwright がストアフロントを実行し、そのコントロールと対話する必要がある場合に使用します。 動的ウェブサイト向け Agent Browser ソリューション はブラウザベースのワークフローを対象としています。 Residential Proxies は、許可された観測に特定のネットワークロケーションが必要な場合に使用します。 プロキシによる価格監視ソリューション は、同一カタログについて市場をまたいだ繰り返し比較が必要な場面に関連します。ブラウザはページを実行し、プロキシはネットワーク経路を提供します。市場での受容性は収集ロジックに属します。

この Playwright guide for Shopify variant data は、抽出前に正しいソースを選ぶ別の例を示しています。実際のワークロードは、ブラウザセッションがどれくらい開いたままになるか、各地域でどれだけのネットワーク転送量を消費するかを測定した後に Scrapeless pricing を使って見積もります。挙動の似たページをグループ化し、複雑なインタラクティブテンプレートが、より単純な商品ページの見積りを歪めないようにします。

取得結果

レビュー可能なイベントには、ソースURL、商品またはバリアントキー、市場、通貨、表示金額、観測時刻、キャプチャソースが含まれます。ソースが在庫状況や販売者を表示しており、コントラクトがそれらを必要とする場合は追加してください。下流分析のための正規化表現と、キャプチャが承認された理由のコンパクトな記録を保持します。証拠には、選択されたオプション、関連するレスポンスフィールド、そしてユースケースが必要とする場合にはスコープされたスクリーンショットを含めることができます。

スケール前にストアフロントの状態を検証する

既知の商品を1つ選び、初期HTML、承認済み構造化データ、レンダリングされたオファーを比較します。正確な選択操作を自動化し、その操作後に何が変化するかを記録します。コレクターが、要求されたオファーとデフォルト、事前フェッチ、地域不一致の状態を区別できるようになったら、対象範囲を広げてください。