製品ページをスクレイピングする際、200応答は有用なデータを保証するものではありません。なぜなら、重要な情報はしばしばJavaScript経由でロードされるからです。重要な質問は「どのスクレイパーか？」ではなく、「データはどこにあるか？」です。多くの場合、eコマースページはクライアントサイドレンダリングを使用し、バックエンドAPI呼び出しを通じてデータを取得します。良い出発点は、DevToolsでネットワークリクエストを検査し、製品詳細を含むJSON応答を探すことです。大まかなワークフローには、ページを手動でロードし、Fetch/XHRでネットワークリクエストをフィルタリングし、既知の製品データを応答本文で検索し、リクエストをcURLとしてコピーし、次にヘッダーを最小化して必須のヘッダーを見つけることが含まれます。一部のサイトでは直接cURL呼び出しが可能ですが、他のサイトではセッションクッキー、ジオヘッダー、またはCSRFトークンが必要です。Shopifyストアはしばしば容易です。なぜなら、多くが/products.jsonを通じてカタログを公開しており、製品タイトル、バリアント、価格、画像URLを提供しているからです。この方法はHTMLを解析するよりも高速で堅牢であり、テーマの変更によるCSSセレクタの失敗を回避します。しかし、一部のShopifyストアはこのエンドポイントをブロックしたり、公開されるデータを制限したりします。直接的なJSONエンドポイントが利用できない場合、またはトークン生成にJavaScriptが必要な場合は、Playwrightのようなヘッドレスブラウザでページをレンダリングする必要があります。PlaywrightはAPI応答をキャプチャしたり、JavaScript実行後にDOMからデータを抽出したりできます。このアプローチは遅く、タイムアウト、CAPTCHA、およびリージョン推論のような問題の管理が必要です。フルブラウザ自動化は、クリックと永続的なセッションを必要とするログイン保護された価格、ウィッシュリスト、またはチェックアウトプロセスのようなインタラクティブな状態のために予約されています。しかし、これは最もリソースを消費し、ジョブの遅延、CAPTCHAリスクの増加、およびブラウザフィンガープリントのような問題が発生しやすいです。決定木は、公開JSONエンドポイントを優先し、次に内部API呼び出し、続いてヘッドレスブラウザレンダリング、最後にフルブラウザ自動化を優先します。必要不可欠でない限り、フルブラウザ自動化から始めるのは避け、なぜならそれは大規模になると高価で不安定になるからです。