SEO専門家が大規模サイトの技術監査を開始すると、10分後にはScreaming Frogが連続して403 Forbiddenや429 Too Many Requestsを返し始めます。セキュリティサーバーはクローラーを攻撃ボットと見なし、IPアドレスをブロックしました。その結果、監査を再起動しなければならず、クライアントに報告が遅れた理由を説明しなければなりません。クローラーのためのプロキシを適切に設定することでこの問題は解決できます。具体的にどのように行うかを見ていきましょう。
監査中にサイトがScreaming Frogをブロックする理由
Screaming Frog、Sitebulb、JetOctopus、Netpeak Spiderは、技術的には検索エンジンのボットと同様に機能します。これらは、数千のURLを迅速に巡回し、HTML、CSS、JS、画像をダウンロードし、リダイレクトやステータスコードを確認します。サイトの保護（Cloudflare、Qrator、DDoS-Guard、ホスティングの組み込みWAF）から見ると、これは疑わしい活動として見なされます。短時間で1つのIPからのリクエストが多すぎるためです。
特に監査中にブロックが発生することが多いのは次のような場合です：
- 独自のパース防止機能を持つWildberriesのようなインフラを持つ大規模なオンラインストア;
- Cloudflareの保護が有効になっているサイト、または高いセキュリティレベルのサイト;
- 各リクエストがサーバーに負荷をかける動的コンテンツを持つポータル（検索、フィルター、商品リスト）;
- 競合他社のサイトを自ドメイン以外から分析する場合 — 彼らはあなたのIPを信頼する理由がありません。
追加の複雑さ：エージェンシーが1つの静的IPを持っている場合、サイトの監査が定期的に行われると（1日に複数のクライアント）、このIPはすぐに保護システムのブラックリストに載ります。その後、現在の監査だけでなく、同じアドレスからの将来の監査もブロックされます — 以前は問題なく開いていたサイトに対しても。
応答コードによるブロックの認識方法
プロキシの設定を変更する前に、何が起こっているのかを理解することが重要です。Screaming Frogは、ステータスコードの列に応答コードを表示します。これにより、クローリングの停止原因を簡単に特定できます。
| 応答コード | 意味 | 対処法 |
|---|---|---|
| 403 Forbidden | IPがサイトの保護によってブロックされました | IPを変更し、クローリング速度を下げる |
| 429 Too Many Requests | 時間単位のリクエスト制限を超えました | スレッド数を減らし、遅延を追加する |
| 503 Service Unavailable | サーバーが過負荷またはボット保護が有効です | User-Agentを変更し、居住用IPを使用する |
| 応答なし / タイムアウト | IPがブラックリストに載っており、リクエストが届かない | プロキシプールを完全に交換する |
レポートに同じコードが数千のURLにわたって大量に表示される場合、ほとんどの場合、IPによるブロックであり、サイトの実際の問題ではありません。この仮説を確認するのは簡単です：同じIPから通常のブラウザで問題のあるURLを開いてみてください。ページが正常に開くが、Screaming Frogが403を受け取る場合、問題はクローラーにあり、サイトにはありません。
SEOクローリングに適したプロキシ
プロキシの種類の選択は、タスクによって異なります：自サイトの一回限りの監査、競合の定期的な監視、または保護されたマーケットプレイスのスキャン。3つの主要なタイプとそれらのクローラーへの適用性を見ていきましょう。
| プロキシの種類 | 速度 | ブロックのリスク | 使用するタイミング |
|---|---|---|---|
| データセンタープロキシ | 高い | 保護されたサイトでは中〜高 | 厳しい保護がない自サイトの監査 |
| 居住用プロキシ | 中 | 低い | 競合の監査、Cloudflareの背後にあるサイト、マーケットプレイス |
| モバイルプロキシ | 中〜低 | 最小限 | 最も攻撃的な保護、稀なスポット監査 |
大多数の定期的な技術監査には、居住用プロキシが最適なバランスを提供します。これらはプロバイダーの実際のIPアドレスを使用するため、サイトの保護はクローラーのリクエストを通常のユーザートラフィックとして認識します。これは、あなたが自分のドメインではなく、競合他社のサイトや厳しいアンチボットシステムを持つマーケットプレイスを分析する場合に特に重要です。
データセンタープロキシは、自サイトを監査し、事前にWAFやCloudflareのレベルでIP範囲をホワイトリストに追加できる場合には良い選択肢です。この場合、スキャン速度は最大になり、ブロックのリスクはありません。
Screaming Frogでのプロキシのステップバイステップ設定
Screaming Frogは「箱から出して」プロキシをサポートしており、設定は数分で完了します：
- プログラムを開き、メニューConfiguration → System → Proxyに移動します。
- Use Proxy Server for All Trafficにチェックを入れます。
- プロバイダーから受け取ったプロキシサーバーのアドレスとポートを入力します。
- プロキシがユーザー名とパスワードによる認証を必要とする場合、最初のリクエスト時にポップアップウィンドウでそれらを指定します。
- OKをクリックし、設定を適用するためにクローリングを再起動します。
重要な点：Screaming Frogの無料版と有料版は、組み込みインターフェースを介して同時に1つのプロキシサーバーでのみ動作します。IPのローテーションが必要な場合（50,000ページ以上のスキャン時に関連）、プロバイダー側で自動的にIPを変更するプロキシを使用してください。これはクローラー内ではなく、プロキシサービスの個人アカウントで設定され、IPの変更間隔（例えば、10分ごとまたは新しいリクエストごとに）を指定します。
このスキームは1つのアドレスへの負荷を軽減します：クローラーは1つのポートで動作し続け、IPは自動的に変更され、サイトは特定のアドレスからの異常に高いリクエスト頻度を認識しません。
大規模サイトのための速度とスレッドの設定
動作するプロキシを使用していても、クローリングの速度があまりにも攻撃的な設定だとブロックを引き起こす可能性があります。Screaming Frogでは、これをConfiguration → Speedのセクションで管理します。100,000ページ以上のサイトに推奨される値は次のとおりです：
- Max Threads: 保護されたサイトでは2〜5、厳しい保護がないサイトでは10〜15;
- Max URI/s: 最初は2〜3リクエスト/秒に制限し、応答コードを観察しながら徐々に増やします;
- Custom User-Agent: Configuration → HTTP Headerのセクションで、サイトがクローラーをヘッダーでブロックする場合、標準の「Screaming Frog SEO Spider」の代わりに実際のブラウザのUser-Agentを使用します;
- Respect robots.txt / crawl-delay: Crawl-delayが指定されている場合は、その指示を考慮します — 無視するとサーバーレベルでの禁止につながることがよくあります。
ボットからの攻撃が激しいサイトの場合、JavaScript Renderingモードを本当に必要な場所（React/VueのSPAサイト）でのみ有効にすることも役立ちます — JSのレンダリングはサーバーへの負荷を急激に増加させ、1つのIPでのクローリング時にブロックの可能性を高めます。
100,000ページ以上のスキャン時のIPローテーション
サイトが大規模になるほど、IPアドレス間での負荷を適切に分散させることが重要です。この規模の監査には、2つのスキームが機能します：
時間によるローテーション。 IPはリクエスト数に関係なく、5〜15分ごとに自動的に変更されます。これは、数時間にわたって均等にクローリングする場合に適しています。
リクエストによるローテーション。 各新しいHTTPリクエストはプールから新しいIPで送信されます。このモードはブロックからの最大の保護を提供しますが、クッキーに基づく認証やサイトのセッションパラメータの正常な動作を妨げる可能性があります — 純粋な技術監査（ステータスコード、リダイレクト、メタタグの収集）には重要ではありません。
複数のクライアントサイトの並行監査を行うエージェンシーの場合、プロジェクトごとにIPプールを分けることが合理的です — これにより、1つのドメインでのブロックが「誤って」他のサイトでの作業時にIPの評判に広がる状況を防ぎます。
実践のアドバイス： 大規模な監査の前に、現在の速度とプロキシ設定で500〜1000のURLでテストクローリングを実行します。この間に403/429エラーが発生しなければ、全サイトのスキャンを安全に拡大できます。
監査開始前のチェックリスト
- ✅ プロキシが接続され、可用性がテストされている（curlまたは別のブラウザでの確認）;
- ✅ Max ThreadsとMax URI/sが初回の実行のために保守的に設定されている;
- ✅ User-Agentが正しく設定され、WAFに疑念を抱かせない;
- ✅ robots.txtを尊重する設定が有効になっている場合、サイトが明示的にCrawl-delayを守るように求めている;
- ✅ JavaScript Renderingは本当に必要な場合にのみ有効になっている;
- ✅ サイトのボリュームが20,000〜30,000ページ以上の場合、IPのローテーションが設定されている;
- ✅ セッションが切断された場合に備えて、クローリングの進捗が保存される設定が有効になっている（Configuration → Save Crawl）;
- ✅ マーケットプレイスや保護されたポータルの監査には、データセンターの代わりに居住用またはモバイルプロキシが選択されている。
プロキシを使用したクローリングの一般的な誤り
開始時の速度が高すぎる。 専門家は、監査を迅速化しようとするあまり、すぐに最大スレッド数を設定します。その結果、サイトの保護が瞬時に反応し、数分後にはプロキシプール全体がブラックリストに載ってしまいます。
すべてのクライアントプロジェクトに対して1つの静的IP。 エージェンシーが月に数十の監査のために同じデータセンタープロキシを使用する場合、そのIPの評判は急速に低下します — 異なるサイトの保護システムは、共通のデータベースを介して疑わしいアドレスに関する情報を交換します（例えば、Cloudflare IP Reputation）。
geoターゲティングの無視。 監査対象のサイトが特定の地域に設定されている場合（例えば、海外トラフィックの地理的ブロックを持つロシアのオンラインストア）、他国のIPを持つプロキシを使用すること自体がアクセス制限を引き起こします — 攻撃的なクローリングがなくても。
プロセス中の監視の欠如。 数時間にわたってクローリングを開始した後、専門家はしばしば中間の応答コードを確認しません。その結果、監査が終了したときに、レポートの半分がブロックエラーで構成され、サイトに関する実際のデータが得られないことになります。
結論
Screaming Frogでの技術監査中のブロックは、ほぼ常に3つの要素の組み合わせで解決されます：適切なプロキシの種類、合理的なクローリング速度、そして適切なIPローテーションです。厳しい保護がない自サイトには、ホワイトリストに追加されたデータセンタープロキシで十分です。競合他社、マーケットプレイス、Cloudflareの背後にあるサイトの監査には、通常のユーザートラフィックのように見えるIPが必要です。
他のドメインや保護されたプラットフォームを定期的に監査する場合は、居住用プロキシから始めることをお勧めします — これにより、最も攻撃的なアンチボットシステムでのブロックリスクが低減します。最大限に保護されたリソースでの特定のタスクには、モバイルプロキシを検討し、自社のインフラストラクチャでの大規模な監査にはデータセンタープロキシが良い迅速な解決策となります。