SEOエージェンシーや社内マーケターは、早かれ遅かれ同じ質問を自問します：なぜポジショントラッカーのサブスクリプションにお金を払うのか、自分のパーサーを作成すればいいのではないか？答えは見た目ほど簡単ではありません。独自のモニタリングのコストは、サーバーだけでなく、プロキシ、キャプチャ、スクリプトのサポートにかかる時間も含まれます。この記事では、1日あたり1000のキーワードをチェックする例を通じて、実際の数学を考察します。
なぜエージェンシーは独自のポジショントラッカーを作るのか
Topvisor、Serpstat、SE Ranking、Rush Analyticsなどの既存のサービスは便利です：プロキシ、キャプチャ、サーバーについて考える必要がなく、ただキーワードを入力してレポートを受け取るだけです。しかし、この便利さには代償があり、確認するフレーズや地域の数に比例してコストが増加します。エージェンシーが15-20のクライアントを持ち、それぞれに500-2000のキーワードがある場合、サブスクリプションの請求はすぐにジュニアスペシャリストの給与に匹敵する金額になります。
第二の理由は柔軟性です。既存のサービスでは、特定のキーワードのチェック頻度を変更したり、カスタムロジックを追加したり（たとえば、位置だけでなくスニペット、クイックリンクやレビューの有無を追跡するなど）、生データを自分のBIシステムにエクスポートすることはできません。独自のトラッカーはこれらのタスクを解決しますが、インフラストラクチャが必要です：サーバー、データベース、パーススクリプト、そして何よりも、検索エンジンの自動リクエストからの保護を回避するためのプロキシが必要です。
第三の理由はデータの管理です。NDAに基づいて大手クライアントと取引しているエージェンシーは、必ずしも外部のクラウドサービスにキーワードとドメインのリストを渡す準備ができているわけではありません。独自のトラッカーを使用すると、すべてを自分のインフラストラクチャに保存できます。
ポジションチェックのコスト構造
お金を計算する前に、メカニズムを理解する必要があります：特定のキーワードに対するサイトの位置を知るためには、パーサーがYandexまたはGoogleにリクエストを送信し、結果のHTMLページを取得して、必要なドメインを見つける必要があります。1日あたり1000のキーワードの場合、これは最低でも1000のリクエストを意味し、両方の検索エンジンと複数の地域をチェックする場合、数字は2-4倍に増加します。
検索エンジンは、1つのIPからの自動リクエストを積極的にブロックします：1つのアドレスから20-50のリクエストを連続して送信すると、Yandexはキャプチャを表示し始め、Googleは数時間の間IPを一時的に禁止します。したがって、各リクエストは別のプロキシまたは頻繁に変更されるプロキシを通過する必要があります。ここから主要なコスト項目が生じます — サーバーやスクリプトではなく、プロキシインフラストラクチャです。
完全なコスト構造は次のようになります：
- IPローテーション用のプロキシ — 主な変動コスト項目で、リクエストの量に依存します
- スクリプトをスケジュールで実行するためのサーバーまたはVPS — 固定の少額
- キャプチャ解決策（アンチキャプチャサービス） — プロキシの質が不十分な場合の追加コスト
- パーサーの作成とサポートにかかる開発者の時間 — 一時的および定期的なコスト
- データの保存と視覚化 — データベース、ダッシュボード、通常は最小限の費用
サブスクリプション vs 自分のトラッカー：コスト項目の比較
自分のトラッカーがサブスクリプションよりも有利な場合を評価するために、コスト項目を直接比較するのが便利です。以下は、特定の料金プランに依存しない要約テーブルで、選択の論理を示しています。
| パラメータ | 既存のサービス（サブスクリプション） | 自分のポジショントラッカー |
|---|---|---|
| 1日あたり1000のキーワードのコスト | プランに比例して増加し、固定の月額料金 | プロキシのトラフィック + サーバーのレンタルから成り、スムーズにスケールします |
| 設定の柔軟性 | サービスの機能に制限される | 完全な柔軟性 — 任意の頻度、地域、結果の深さ |
| 開発者が必要 | 不要 | はい、開始時と定期的にサポートのために必要 |
| 禁止/キャプチャのリスク | サービスが引き受ける | あなたにかかり、プロキシと遅延で解決される |
| 損益分岐点 | — | 通常、1日あたり3000-5000のキーワード以上 |
テーブルからの結論は簡単です：少ないキーワードのボリューム（1日あたり2000-3000まで）の場合、サブスクリプションはほぼ常に有利です。なぜなら、独自のソリューションの開発とサポートにかかるコストが回収できないからです。しかし、大量の場合 — 数千のキーワード以上、特に1日に何度もチェックする必要がある場合や異なる地域でチェックする場合 — 独自のインフラストラクチャが経済的に有利になります。
1日あたり1000のキーワードのプロキシ計算
コストの主要な質問は、禁止やキャプチャなしで1日あたり1000のリクエストに必要なプロキシの数です。実際にパーサーが使用する平均的な安全リミットを考えてみましょう：
- Yandex: 1日あたり1つのIPから30-50のリクエスト、リクエスト間に10-30秒のランダムな遅延があればキャプチャのリスクなし
- Google: 1日あたり1つのIPから15-25のリクエスト、システムは厳しく、早く禁止します
もしYandexでのみ1000のキーワードをチェックする場合、1つのIPあたり40リクエストのリミットで、1日あたり最低25のユニークなアドレスが必要です。失敗したリクエストのリトライと一時的な禁止のための余裕を考慮して、30-40のIPを用意してください。両方の検索エンジンをチェックする場合、数字は倍増し、1日あたり約60-80のIPが必要です。
重要なポイント：リクエストごとにローテーションするIPプールを使用する場合（セッションごとではなく）、同じ物理プロキシサーバーは、プロバイダーが動的ローテーションを提供している場合、はるかに多くのIPアドレスを「閉じる」ことができます。この場合、計算はアドレスの数ではなく、トラフィックの量に基づきます — 通常、1回のポジションチェックは50-200KBのHTMLを占めるため、1日あたり1000のリクエストは50-200MBのトラフィックであり、中程度のプランでも全くクリティカルな負荷ではありません。
1日あたり1000のキーワードの計算例（Yandex + Google）：
2000リクエスト/日 ÷ (平均30リクエスト/IP) ≈ 65-70のユニークIP/日。 検索結果ページの平均サイズが100KBの場合、総トラフィックは約200MB/日、 または月に約6GBになります — これはプロキシプロバイダーのトラフィックプランを選ぶ際に考慮すべき数字です。
YandexとGoogleに必要なプロキシ
プロキシの種類は、どれだけのキャプチャや禁止を受けるかに直接影響し、したがってポジションチェックの実際のコストにも影響します。3つのオプションを考察します。
データセンターのプロキシ — トラフィックコストが最も安いオプションですが、検索エンジンのデータベースでの評判が悪いです：データセンターのIPは大量にパースに使用されているため、YandexやGoogleはすぐにそれらを認識し、数回のリクエストの後にキャプチャを表示します。低頻度で少数のキーワードをチェックする場合は、データセンターのプロキシを使用することもできますが、1000以上のリクエストの場合、キャプチャの割合が高くなり、トラフィックの節約がアンチキャプチャのコストに食われます。
レジデンシャルプロキシ — 実際の家庭ユーザーのIPアドレスで、検索エンジンはこれを通常のトラフィックとして認識します。キャプチャの割合はここでははるかに低く、大量のチェック時には重要です。1日あたり1000以上のキーワードの検索結果をパースする場合、レジデンシャルプロキシは通常、コストと安定性の最良の比率を提供します。特にGoogleとの作業時には、データセンターのアドレスを最も厳しく禁止します。
モバイルプロキシ — モバイルオペレーターのIPを使用し、実際の加入者の間で頻繁に変更されます（NAT）。そのため、同じアドレスが1日の間に異なるユーザーに「属する」ことがあります。これは、攻撃的なパース時に最大の耐久性を提供しますが、コストは高くなります。モバイルプロキシは、デスクトップとは別にモバイル検索結果のポジションをチェックする場合や、特に気難しい地域のYandexのリクエストを扱う場合に正当化されます。
| プロキシの種類 | 1000リクエストあたりのキャプチャの割合 | いつ使用するか |
|---|---|---|
| データセンター | 高い | 1日あたり200-300のキーワード、低頻度 |
| レジデンシャル | 低い | 1日あたり1000以上のキーワード、GoogleとYandex |
| モバイル | 最小限 | モバイル検索結果、複雑な地域 |
独自のトラッカーのステップバイステップ設定
コードの深い理解なしに、独自のポジショントラッカーを構築するプロセスをステップごとに考察します。
- データソースの選択。 検索エンジンの結果をHTTPリクエストを介して直接パースするか、ヘッドレスブラウザ（たとえば、Puppeteer/Playwrightを介して）を使用して実際のユーザーを模倣するかを決定します。後者のオプションは、アンチボット保護に対してより信頼性がありますが、サーバーのリソースがより多くかかります。
- プロキシプールの設定。 リクエストごとまたは時間ごとにIPをローテーションするプロキシプロバイダーを接続します。YandexとGoogleには異なるプロキシプールを使用する方が良いです。なぜなら、システムには異なるブロックしきい値があるからです。
- リトライのロジック。 リクエストがキャプチャやエラーを返した場合、スクリプトは自動的にIPを変更し、リクエストを再試行する必要があります。単にエラーを記録するだけではありません。
- 結果のパース。 取得したHTMLから、検索結果における必要なドメインの位置を抽出します — 通常はリンクタグを検索し、クライアントのドメインと比較します。
- 履歴の保存。 結果はデータベースに保存され、チェックの日付とともに、ポジションの動向をグラフ化できるようにします。
- 実行スケジュール。 スクリプトはcronまたはタスクスケジューラで1日1回（またはそれ以上）実行され、1000のリクエストを時間的に均等に分配し、プロキシプールにピーク負荷をかけないようにします。
Pythonによるポジションチェックのコード例
以下は、プロキシを介して検索結果にリクエストを送信するロジックの簡略化された例です。これは、動作の原理を示すデモンストレーションの枠組みであり、完成した戦闘用ソリューションではありません。
import requests
import random
import time
PROXY_LIST = [
"http://user:[email protected]:8000",
"http://user:[email protected]:8000",
# ... 数百のアドレスからなるプロキシプール
]
HEADERS = {
"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36"
}
def check_position(keyword, domain, search_engine="yandex"):
proxy = random.choice(PROXY_LIST)
proxies = {"http": proxy, "https": proxy}
if search_engine == "yandex":
url = f"https://yandex.ru/search/?text={keyword}"
else:
url = f"https://www.google.com/search?q={keyword}"
try:
response = requests.get(url, headers=HEADERS, proxies=proxies, timeout=10)
if "captcha" in response.text.lower():
return None # IPのローテーションとリクエストの再試行が必要
position = find_domain_position(response.text, domain)
return position
except requests.RequestException:
return None
def find_domain_position(html, domain):
# 検索結果におけるドメインの位置を見つけるための簡略化されたロジック
results = extract_links(html)
for i, link in enumerate(results, start=1):
if domain in link:
return i
return None
for keyword in keyword_list:
pos = check_position(keyword, "example.com")
save_to_db(keyword, pos)
time.sleep(random.uniform(5, 15)) # リクエスト間のランダムな遅延
実際のプロジェクトでは、手動でHTMLをパースする代わりに、ヘッドレスブラウザを使用してUser-Agentやフィンガープリントを変更し、プロキシプールを自動ローテーションを提供するプロバイダーを介して接続します。これにより、アドレスのリストを手動で保存する必要がなくなり、1日あたり数千のリクエストにスケールアップするのが簡単になります。
実際に節約できる金額
節約に関する質問に答えるためには、キーワードのボリュームが増加するにつれて2つの支出モデルを比較する必要があります。
小規模なボリューム（1日あたり1000-2000のキーワードまで）の場合、既存のトラッカーのサブスクリプションコストは通常、専門家の時間を考慮すると、独自のソリューションの開発とサポートにかかる総コストと同等か、それ以下です。最小限の機能を持つパーサーをゼロから開発するには、数日から数週間かかり、検索結果のマークアップが変更されるたびに定期的なサポートが必要です — YandexとGoogleは結果のマークアップを頻繁に変更します。
転換点は、チェックのボリュームが数千のキーワードに達するか、1日に何度もポジションをチェックする必要がある場合、異なる地域やデバイス（デスクトップ/モバイル）で行う必要がある場合です。このシナリオでは、既存のサブスクリプションのコストはボリュームに応じて線形または進行的に増加し、独自のトラッカーのコストははるかに遅く増加します — 主なコスト項目（プロキシトラフィック）は、次のレベルのパッケージに移行する際のSaaSサービスの料金プランほど急激には高くなりません。
エージェンシーにとっての実用的な指標：同時に5-10以上のクライアントのポジションを追跡している場合、総ボリュームは通常5000-10000のキーワードを超えます — この規模では、独自のトラッカーがほぼ常にどんな既存のサブスクリプションよりも有利です。前提条件として、社内にパーサーをサポートできる人がいることが必要です。
独自のパース時のよくある間違い
実際には、独自のポジショントラッカーに関するほとんどの問題は、コードではなく、インフラストラクチャのニュアンスを過小評価することに関連しています。
- プロキシの節約。 安価なデータセンターのプロキシで節約しようとすると、大量のキャプチャが発生し、外部のアンチキャプチャサービスを介して解決する必要があります — 結果的に、より質の高いプロキシを最初から使用するよりも、総コストが高くなります。
- リクエスト間の遅延がない。 1つのIPからの非常に迅速な連続リクエストは、IPが質の高いものであっても、すぐにアンチボットシステムの注意を引きます。
- 地域性の無視。 Yandexは、ユーザーの地域に応じて異なる検索結果を表示します — 正しい地理的なプロキシがないと、ポジションに関するデータが不正確になります。
- パーサーの健康状態の監視がない。 検索エンジンは定期的に検索結果ページのマークアップを変更し、パースの成功率が低下した場合のアラートがないと、何週間も空のデータや不正確なデータを収集してしまう可能性があります。
- モバイル検索結果の無視。 デスクトップとモバイルの検索結果はしばしば異なり、クライアントが特にモバイルのポジションを重視する場合、適切なUser-Agentと、できればモバイルIPを使用した別のパースの流れが必要です。
結論
独自のポジショントラッカーは、チェックのボリュームが1日あたり数千のキーワードを超えると、経済的に正当化されます。また、チームにパーサーをサポートするリソースがあることが前提です。小規模なボリュームでは、既存のサブスクリプションが開発にかかる隠れたコストを考慮すると、ほぼ常に安価です。独自のソリューションのコストにおける主な変数は、サーバーやコードではなく、プロキシインフラストラクチャであり、これがキャプチャの割合とデータの安定性を決定します。
1日あたり1000以上のキーワードに対してポジショントラッカーを構築する予定がある場合は、トラフィックの計算と少数のリクエストに対するテストプロキシプールから始めてください。YandexとGoogleの安定したパースのためには、そのようなボリュームでは、レジデンシャルプロキシを最初から考慮するのが理にかなっています — これは、受け入れ可能なトラフィックコストで最小限のキャプチャの割合を提供し、追跡するクライアントの数が増加するにつれてうまくスケールします。