パース初心者の多くは、サイトのフル巡回から始めます：ホームページにアクセスし、すべてのリンクを収集し、それぞれに移動し、再度リンクを収集するという作業を何千回も繰り返します。これにより、プロキシや時間が消費され、しばしばブロックされてしまいます。もっと簡単で安価な方法があります：ほとんどの大規模サイト、Wildberries、Ozon、Avitoを含む、にはすでにすべてのページのマップであるsitemap.xmlが用意されています。これを見つけて、読み取り、余分なリクエストの代わりに使用する方法を見ていきましょう。
sitemap.xmlとは何か、パーサーにとっての重要性
Sitemap.xmlは、サイトがGoogleやYandexなどの検索エンジンのために自動的に作成するファイルです。そこには、サイトの所有者がインデックス化してほしいすべてのページが列挙されています：商品カード、カテゴリ、ブログ記事。基本的には、サイトが自動的に提供するURLのリストであり、手動でリンクをクリックしたり、ページネーションを操作したり、ナビゲーションのロジックを解読したりする必要はありません。
WildberriesやOzonで競合の価格を監視しているセラーにとって、これは一つの意味を持ちます：何千ものカテゴリやページを巡回する代わりに、sitemapに対して一回のリクエストで全商品カードのリストを取得できます。競合のコンテンツ分析のためにURLのデータベースを収集しているマーケターにとっては、手作業での作業時間を数時間節約できます。競合のランディングページをパースしてクリエイティブを分析しているアービトラージャーにとって、sitemapはサイトのすべてのページを一度に表示します。
重要な点：すべてのページがsitemapに含まれているわけではありません。フィルター付きのページ、期間限定のプロモーション、URLにパラメータがあるページは含まれないことがあります。したがって、sitemapは常にサイトの100%をカバーするわけではありませんが、通常はカタログや監視に必要な有用なページの80-95%をカバーしています。
フル巡回 vs sitemapファースト：コストの比較
アプローチの違いは、抽象的な「試行」ではなく、実際のリソース、つまりリクエストの数、プロキシトラフィックの消費、結果までの時間を考慮すると顕著です。以下は、50,000の商品カードのカタログ収集の例での比較です。
| パラメータ | サイトのフル巡回 | sitemapを通じたパース |
|---|---|---|
| URL収集のためのリクエスト数 | 15,000–20,000（カテゴリ、ページネーション、フィルター） | 50–300（sitemapファイルのみ） |
| URLリスト収集にかかる時間 | 4–8時間 | 15–30分 |
| IPブロックのリスク | ナビゲーションへのリクエスト量が多いため高い | リクエストが少ないため低い |
| プロキシトラフィックの負荷 | 高い、大規模なIPプールが必要 | 最小限、小さなプールで済む |
| パーサーのロジックの複雑さ | 高い、ナビゲーションを解析する必要がある | 低い、XML構造の解析 |
タイトルの「10倍安い」という数字は誇張ではありません。フル巡回がページリストを作成するために15,000〜20,000のリクエストを必要とし、sitemapが同じリストを50〜300のリクエストで提供する場合、プロキシトラフィックと時間の節約は桁違いになります。この時、商品カード自体は別途ダウンロードする必要がありますが、どのURLをダウンロードするかは明確であり、無駄なページ、重複、ゴミリンクにリソースを浪費することはありません。
任意のサイトでsitemap.xmlを見つける方法
最初で最も簡単な方法は、サイトのドメインに/sitemap.xmlを追加することです。たとえば、ブラウザでhttps://example.com/sitemap.xmlのようなアドレスを開いてみてください。これは、多くのサイト、特に人気のCMSを使用している多くのオンラインストアに対して機能します。
もしこのアドレスで何も見つからない場合は、robots.txtファイルを確認してください。これはほぼ常に/robots.txtの場所にあり、ほとんどの場合、Sitemap: https://example.com/sitemap_index.xmlという行が含まれています。これは、サイトが検索エンジンにマップの場所を知らせる公式な方法です。WildberriesやOzonのような大規模マーケットプレイスでは、サイトマップがしばしば数十のファイルに分割され、robots.txtを通じて指定されています。
三つ目のオプションは、Google Search Consoleのようなシステムでの言及を探すことです（自分のサイトにアクセスできる場合）や、すべてのsitemapファイルを自動的に見つける専門のスキャナーを使用することです。競合の他のサイトに対しては、通常、最初の二つの方法で十分です。robots.txtはほとんどの場合、外部の目から隠されることはなく、公開ファイルです。
アドバイス：
sitemapファイルの名前は常に標準的ではありません。sitemap_index.xml、sitemap-products.xml、product-sitemap.xmlなどのバリエーションが見られます。常にrobots.txtから始めてください。正確なパスを示してくれます。
マーケットプレイスのsitemap構造：インデックスとネストされたマップ
小規模なサイトでは通常、すべてのURLを含む1つのsitemap.xmlファイルがあります。しかし、Wildberries、Ozon、Avitoのような大規模なカタログでは、数百万のページがあり、そのようなボリュームの1つのXMLファイルは不便です。したがって、彼らは「sitemap index」と呼ばれるインデックスファイルを使用します。これは、カテゴリ、日付、または単に10,000〜50,000のURLのバッチに分割された数十または数百の個別のsitemapファイルを参照します。
構造は次のようになります：最初にメインインデックスファイルを開き、そこに子sitemapへのリンクのリストを見つけます。たとえば、sitemap-products-1.xml、sitemap-products-2.xmlなどです。次に、これらのファイルをそれぞれダウンロードし、そこから商品カードの最終URLを抽出します。これは二段階のプロセスですが、手動でサイトのナビゲーションを巡回するよりもはるかに速いです。
時には、子sitemapファイルがgzip形式（拡張子.xml.gz）で圧縮されていることがあります。これは、サーバー上のスペースを節約するための標準的な慣行です。スクリプトがファイルをダウンロードし、XMLの代わりに読み取れない文字が表示される場合、パースの前に内容を解凍する必要がある可能性が高いです。
sitemapからのURLのステップバイステップ抽出
既存のノーコードパースツールを使用している方のために、ほとんどの現代のマーケットプレイスカタログパーサーは、sitemapを自動的に読み取ることができます。サイトのルートURLを指定するだけで、ツールが自動的にrobots.txtを見つけ、sitemapインデックスを見つけ、すべての商品カードのリストを収集します。しかし、開発者と一緒に作業している場合や、小さなスクリプトを自分で書いている場合、ロジックはシンプルで、以下はPythonの例です：
import requests
import gzip
from io import BytesIO
from lxml import etree
def get_sitemap_urls(sitemap_url, proxies=None):
response = requests.get(sitemap_url, proxies=proxies, timeout=15)
content = response.content
# gzipを解凍する、ファイルが圧縮されている場合
if sitemap_url.endswith('.gz'):
content = gzip.decompress(content)
root = etree.fromstring(content)
namespace = {'ns': 'http://www.sitemaps.org/schemas/sitemap/0.9'}
# もしこれがsitemapインデックスであれば、子マップへのリンクを収集
sub_sitemaps = root.findall('.//ns:sitemap/ns:loc', namespace)
if sub_sitemaps:
all_urls = []
for sub in sub_sitemaps:
all_urls.extend(get_sitemap_urls(sub.text, proxies))
return all_urls
# もしこれが通常のsitemapであれば、最終URLを収集
urls = root.findall('.//ns:url/ns:loc', namespace)
return [url.text for url in urls]
proxy = {
"http": "http://user:pass@proxy_host:port",
"https": "http://user:pass@proxy_host:port"
}
urls = get_sitemap_urls("https://example.com/sitemap_index.xml", proxies=proxy)
print(f"見つかったURLの数: {len(urls)}")このスクリプトはインデックスファイルを再帰的に通過し、各子マップをダウンロードし、すべての最終リンクを1つのリストに収集します。出力として、サイトのナビゲーションを一度も通過することなく、商品カードのURLの完全なリストが得られます。
URLパターンによる必要なページのフィルタリング
sitemapから完全なURLリストを取得した後、ほとんどの場合、それをフィルタリングする必要があります。マーケットプレイスのsitemapファイルには、商品カード、カテゴリページ、ブログ記事、ブランドページ、サービスページなどが混在している可能性があります。おそらく、特定のカテゴリの商品カードのみが必要です。
フィルタリングには通常、URLパターンが使用されます。たとえば、サイトの商品カードが/catalog/product/12345の形式であり、カテゴリが/catalog/category/electronicsのような形式であれば、パスのセグメントを単純に比較することで簡単に区別できます。URLの構造が明確でない場合は、正規表現を使用して、一度パターンを設定し、数十万のリンクを瞬時にフィルタリングすることができます。
sitemap内の<lastmod>タグにも注目することが有益です。これにより、ページの最終変更日が表示されます。完全なカタログが必要ない場合、たとえば競合の新しい商品を監視するために、過去1週間に更新された商品だけが必要な場合は、この日付でURLをフィルタリングし、数ヶ月間変更されていないページには触れないことができます。
サイトマップの大量ダウンロードのためのプロキシ設定
sitemapへのリクエストがフル巡回の数分の一であるにもかかわらず、WildberriesやOzonのようなサイトは依然として疑わしい活動を監視しています。特定のIPからの過度のリクエスト、非典型的なUser-Agent、ブラウザのヘッダーが欠如しているなどです。したがって、sitemapファイルをダウンロードする場合でも、特に定期的な監視を計画している場合はプロキシを使用することをお勧めします。
XMLファイルのダウンロードには、通常、データセンターのプロキシで十分です。これらは高速で安価であり、sitemapへのリクエストは少なく、通常のカタログページに比べて厳しい保護が適用されることは少ないです。しかし、収集したURLから商品カードをダウンロードする段階では、リクエストがはるかに多く、保護が厳しいため、レジデンシャルプロキシに切り替える方が良いでしょう。これらは一般ユーザーの実際のIPを使用し、マーケットプレイスのアンチボットシステムによるブロックに遭遇することが少ないです。
モバイル版のサイトや、モバイルトラフィックでのみデータを提供するAPIからカタログを監視している場合は、モバイルプロキシを検討する価値があります。これらはモバイルオペレーターのIPを使用し、ほとんどのアンチフロードシステムで最も信頼されています。
スクリプトやパーサーでの実際の設定は簡単です：リクエストの該当フィールドにプロキシのホスト、ポート、ログイン、パスワードを指定します（上記のコード例のproxiesパラメータに示されているように）、または、ノーコードパーサーやDolphin AntyやAdsPowerのようなアンチデテクトブラウザを使用してサイトの構造を手動で確認する前に自動収集の設定を行う場合は、プロキシのデータをプロファイル設定に挿入します：プロキシタブを開き、HTTPまたはSOCKS5タイプを選択し、ホスト、ポート、ログイン、パスワードを挿入し、プロファイルを保存します。
sitemap作業時の一般的なミス
最初の、そして最も一般的なミスは、robots.txtを無視し、sitemapのアドレスを推測しようとすることです。これは時間の無駄であり、インデックスルールファイルを確認することで簡単に回避できます。
二つ目のミスは、sitemapが不完全である可能性を考慮しないことです。一部のサイトは、SEOにとって価値の低いページを意図的にsitemapから除外しますが、価格監視には重要です。sitemapを通じて収集したカードの数が期待よりも明らかに少ない場合は、サイトがカテゴリで表示する商品の数と照らし合わせ、必要に応じて不足しているセクションを補うためにポイント巡回を行うべきです。
三つ目のミスは、すでにダウンロードしたsitemapファイルをキャッシュしないことです。毎日監視を実行する場合、インデックスファイルやすべての子マップを毎回再ダウンロードする必要はありません。ほとんどは毎日変更されるわけではありません。URLリストをローカルに保存し、lastmodの日付で実際に変更されたものだけを更新します。
四つ目のミスは、リクエストヘッダーを忘れることです。単純なXMLファイルのダウンロードでさえ、リクエストがボットからのものである場合、ブロックされる可能性があります：User-Agentなし、Accept-Languageなし、リクエストライブラリがデフォルトで設定する非典型的なヘッダーで。リアルなブラウザのヘッダーを追加し、プロキシと組み合わせることで、この段階でのブロックの可能性を大幅に減少させることができます。
sitemapを通じたパース開始のチェックリスト
カタログの本格的な収集を開始する前に、短いステップリストを確認して、ミスで時間を無駄にしないようにしましょう：
- サイトのrobots.txtを確認し、sitemapまたはsitemap indexの正確なアドレスを見つけた
- sitemapの構造が二段階（インデックス + 子マップ）または一段階であることを確認した
- 子ファイルがgzipで圧縮されていないか確認した
- 必要なページのURLパターンを特定した（商品カード、カテゴリなど）
- 新しいポジションが必要な場合、パターンまたはlastmodの日付でフィルタリングを設定した
- sitemapファイルのダウンロード用にプロキシを接続し、商品カードのダウンロード用に別途接続した
- リアルなリクエストヘッダーを追加した（User-Agent、Accept-Language）
- 再実行のためのキャッシュと日付比較を設定した
- 最終的なURLの数をサイト上の商品の概算数と照らし合わせた
結論
sitemapファーストアプローチはハックでも防御の回避でもなく、サイトが検索エンジンのために自ら公開している情報を利用することです。ナビゲーション、カテゴリ、ページネーションへの何千ものリクエストの代わりに、XMLファイルへの数十のリクエストで必要なページのリストを取得できます。これにより、パースの開始にかかる時間を節約し、プロキシトラフィックの消費を減らし、IPのブロックリスクを大幅に減少させることができます。なぜなら、サイトへの負荷はフル巡回よりもはるかに少ないからです。
Wildberries、Ozon、または他の大規模なサイトのカタログ監視を始めたばかりの方は、sitemapから始めてください。おそらく、最初の実行で数時間の作業を節約できるでしょう。sitemapファイルのダウンロードには安価なデータセンターのプロキシで十分ですが、商品カードに関するデータを定期的に収集する場合は、ブロックのリスクが高いため、レジデンシャルプロキシを検討する価値があります。これにより、長期的にパーサーの安定した動作を確保し、頻繁なブロックを回避できます。