Playwright を使って WooCommerce 商品スクレイパーを構築する方法

Scrapeless Agent Browser は WooCommerce ストアフロント向けに Playwright 自動化を実行し、Scrapeless Residential Proxies は店舗価格が場所によって変動する場合に、市場別のネットワークルーティングをサポートします。

質問に答える WooCommerce のサーフェスを選ぶ

WooCommerce 商品スクレイパーは、カタログソースを使って商品を発見し、レンダリングされたストアフロントが重要なときに Playwright でインタラクティブなオファーを確認します。自分が運営している、または収集が許可されているストアでは、公開カタログのフィールドとフィルターについて WooCommerce Store API Products リソース を確認してください。Products リソースには、公開済みおよびパスワード保護された商品がどのように表現されるかと、商品バリエーションのレコードがデフォルトの商品コレクションとどのように異なるかが記載されています。

必要なフィールドをすべて提供する承認済みカタログフィードがある場合はそれを使用します。テーマや拡張機能が、インタラクション後に表示価格、在庫メッセージ、バリアント選択を変更する場合は、ブラウザが適しています。各フィールドの出所を明確に保ってください。Store API の amount と表示される商品価格が、一方がベース値でもう一方がストア定義の表示調整を含む場合、異なる用途に使われることがあります。

このアプローチは、カタログ QA、選択済み公開オファーのモニタリング、変数商品が意図した情報を表示しているかの確認、マーチャンダイジングレビュー用のスクリーンショット収集に有効です。スクレイピング前に、チームがどのような出力を期待しているかを定義してください。価格選択のテストに適したフィクスチャは、マーケティングフィールドを省略しても、バリエーションのワークフローを代表できる場合があります。

前提条件とインストール

Node.js と Playwright、および Chromium ランタイムを使用します。Playwright パッケージとその Chromium バイナリをインストールするか、利用可能な互換 Chromium 実行ファイルを使用します。自分が運営または収集の許可を得ているストアと、シンプル商品、変数商品、利用不可の組み合わせを含むサンプルが必要です。以下の例は、WooCommerce テーマにセレクタを適合させる前に実行できるよう、安定した属性を持つ制御フィクスチャを使用しています。

リモート実行には Agent Browser Playwright クイックスタート を使用し、ドキュメントに従って Scrapeless アカウントと API キーを設定します。認証情報はターゲット URL やログに含めないようにします。ローカルでテストする例は既存の Playwright ページを受け取ります。リモート実行では、クラウドセッションから到達可能で、合意されたロケーションや市場設定を満たす認可済みターゲットも必要です。

ステップ 1. 商品を発見しソース ID を保持する

承認された sitemap、ストアフロントのナビゲーション、ストアフィード、またはドキュメント化されたカタログソースから各ターゲットを発見します。可能であればストアのネームスペースと商品 ID を保持します。重複排除のためにカノニカルなルートと、訪問に使った元のルートを保存します。 URL Standard は相対リンクがどのように解決されるかを定義しています。検証したいストアフロント状態を識別する変数クエリパラメータやルートコンポーネントは保持してください。

カタログのページネーションは、商品抽出とは別に扱います。各探索実行について、使用したフィルターとカーソルまたはページを記録します。耐久性のある ID を使って結果の重複を排除し、明確な上限と完了ルールを設定します。これにより、リスティングページが商品詳細ページと混同されるのを防ぎ、あるカテゴリから商品が減ったように見える場合でも、チームに監査証跡を提供できます。

ステップ 2. テーマがバリエーションをどのように確定するかを特定する

バリエーションの取得は、オプションコントロールと、その最終状態を確定させるシグナルの特定から始まります。ラベルと入力の挙動を調査してください。テーマはネイティブセレクト、スウォッチ、カスタムボタンなどを使用しているかもしれません。コレクターが組み合わせを選択したとき、その組み合わせに紐づいたバリエーション識別子、解決済みの在庫状態、または表示金額を監視します。セールバナーや関連商品が金額を提供しないよう、抽出範囲を商品詳細エリアに限定します。

次の Playwright 関数は、制御された WooCommerce スタイルの商品フィクスチャを読み込みます。テスト ID と readiness 属性はそのフィクスチャの一部です。実際の WooCommerce サイトでは、既知のテーマに合わせてセレクタを調整するか、ストアチームに安定した readiness マーカーを公開してもらってください。この例では、選択された青いマグカップに対する非同期の価格変更をテストします。

async function readWooProduct(page, targetUrl, selections) {
  const response = await page.goto(targetUrl, { waitUntil: 'domcontentloaded' });
  if (!response?.ok()) throw new Error('Product navigation failed');

  const product = page.getByTestId('product-detail');
  const title = await product.getByRole('heading', { level: 1 }).innerText();
  for (const [label, value] of Object.entries(selections)) {
    await product.getByRole('combobox', { name: label }).selectOption(value);
  }

  const expected = JSON.stringify(selections);
  await page.waitForFunction(options => {
    const node = document.querySelector('[data-testid="resolved-offer"]');
    if (!node || node.dataset.state !== 'ready') return false;
    const selected = JSON.parse(node.dataset.options || '{}');
    return Object.entries(JSON.parse(options))
      .every(([name, value]) => selected[name] === value);
  }, expected, { timeout: 5000 });

  return product.getByTestId('resolved-offer').evaluate((node, heading) => ({
    title: heading,
    url: location.href,
    variantId: node.dataset.variantId,
    options: JSON.parse(node.dataset.options),
    priceText: node.querySelector('[data-testid="price"]')?.textContent.trim() || null,
    currency: node.dataset.currency || null,
    availability: node.dataset.availability || 'unknown'
  }), title);
}

制御フィクスチャは白のオプションから開始し、青のオプションを variation 11 に解決し、表示金額は $21.00 です。ローカルテストでは、そのバリエーションと金額を一緒に検証します。シンプル商品では、アダプタ契約がその形を定義している場合、空の選択と、その商品固有の ID を持つ ready なオファーを使用できます。バリエーションが利用不可のときは、その明示的な在庫メッセージを取得し、契約で許可されている場合は金額が存在しないことも認めます。

ステップ 3. コンテキストとともに価格を解釈する

価格フィールドは、表示販売価格と取り消し線付きのリスト価格、レンジとを区別すべきです。正規化前の生の金額と通貨を保持してください。 価格と在庫状況には Offer 語彙を使用する 正規化されたフィールドに名前を付けるときに注意してください。税金、手数料、送料、プロモーションが重要であれば、現在の画面がそれらをどのように含んでいるかを文書化します。市場ごとにそれらを暗黙のうちに混在させることは避けてください。

利用できないバリアントも依然として有用なカタログ上の観測です。その明示的な状態と選択された組み合わせを保存してください。未解決のバリアント状態には別の結果を与え、空の価格がゼロとして解釈されないようにします。空のセレクタは、アクティブなテーマ、サポートされていない組み合わせ、またはページに到達できなかったことが原因である可能性があります。在庫ラベルを割り当てる前に、周辺の証拠を確認してください。

金額の正規化には、承認された単一の信頼できる情報源を使用します。Store API を使用する場合は、その金額を付随する通貨情報とともに解釈します。画面表示を使用する場合は、サイトの既知のロケールと金額タイプに従って解析します。少数のサンプルについて両者を比較し、意図的な違いを記録します。これにより、カタログフィードを更新せずに表示フィールドだけを変更するストアプラグインを検出できます。

ステップ 4. 適切なマーケットでブラウザを実行する

使用する Scrapeless Agent Browser は、ジョブに管理されたブラウザセッションが必要な場合であり、 managed web automation solution は、ストアフロントのポートフォリオ全体でインタラクティブなワークフローを計画する際に使用します。 Playwright proxy setup guide は、ルーティングがブラウザ設定にどのように適合するかを説明しています。認可されたロケーション特定の取得を行うには、 Residential Proxies を選択し、ナビゲーション後に通貨、ロケール、配送コンテキストを確認してください。

ストアセレクタで設定されたマーケットは、Cookie または URL に保存される場合があります。各独立したマーケットテストは、想定するセッションポリシーから開始します。金額を受け入れる前に、レンダリングされたマーケットが一致していることを確認します。実際のブラウザ時間と転送量はテンプレートごとに保持し、 Scrapeless pricingと比較できるようにします。 price monitoring proxy solution は、地域ごとに一貫した観測が必要な収集に役立ちます。

コレクターが返すもの

有用な WooCommerce レコードには、ストア、商品またはバリエーション ID、選択された属性、最終 URL、生の表示価格、通貨、明示的な在庫状況、および観測時刻が含まれます。ソース、収集バージョン、単純商品パスと可変商品パスのどちらを使用したかを記録します。不完全な出力は明確な理由とともに保存し、検証済みのオファーイベントとは分離します。これにより、価格設定や QA の利用者は、URL には到達したもののページを検証できなかったコレクターと、完全な観測とを確実に区別できます。

既知の 1 つの製品ファミリーを中心にアダプタを構築する

検証可能で、表示価格が分かっているバリエーションを持つストアから始めます。商品リスト、単純商品、可変商品の各パスを個別に試し、その後、保存された行をレンダリングされたストアフロントと比較します。各フィールドと結果を説明できるようになってから、市場とソーステンプレートを追加してください。