サイトのスクレイピングを防ぐにはどうすればよいですか？
大規模なアーティストデータベースを備えたかなり大きな音楽Webサイトがあります。他の音楽サイトがサイトのデータをスクレイピングしていることに気付きました（ダミーのアーティスト名をあちこちに入力してから、Google検索を実行します）。
スクリーンスクレイピングを防ぐにはどうすればよいですか？それも可能ですか？
注：この回答の完全なバージョンはスタックオーバーフローの長さ制限を超えているため、 GitHub に進んで、拡張バージョンを読み、ヒントと詳細を読んでください。
スクレイピングを妨げるため（Webscraping、Screenscraping、Web data mining、Web harvesting、または- Webデータ抽出）、これらのスクレイパーがどのように機能するかを知るのに役立ちます。
スクレーパーにはさまざまなタイプがあり、それぞれ異なる動作をします。
Googleのボット などのスパイダー、または HTtrack などのウェブサイトコピー機は、データを取得するために他のページへのリンクを再帰的にたどります。これらは、特定のデータを取得するためにターゲットスクレイピングに使用されることがあり、多くの場合、各ページから目的のデータを抽出するHTMLパーサーと組み合わせて使用されます。
シェルスクリプト：時々、一般的なUnixツールがスクレイピングに使用されます：ページをダウンロードするWgetまたはCurl、およびデータを抽出するGrep（正規表現）。
Jsoup、 Scrapy などに基づいたHTMLパーサー。シェルスクリプトの正規表現ベースのものと同様に、これらはHTMLのパターンに基づいてページからデータを抽出することで機能し、通常は他のすべてを無視します。
例：Webサイトに検索機能がある場合、このようなスクレイパーは検索のリクエストを送信し、結果ページのHTMLからすべての結果リンクとそのタイトルを取得して、検索結果リンクとそのタイトルのみを具体的に取得します。これらが最も一般的です。
例えばに基づいて、スクリーンスクレーパー。 Selenium または PhantomJS 。実際のブラウザでWebサイトを開き、JavaScript、AJAXなどを実行してから、通常はWebページから目的のテキストを取得します。
ページが読み込まれ、JavaScriptが実行された後、ブラウザーからHTMLを取得し、HTMLパーサーを使用して目的のデータを抽出します。これらは最も一般的であり、HTMLパーサー/スクレーパーを破るための多くのメソッドもここで機能します。
レンダリングされたページのスクリーンショットを撮り、OCRを使用してスクリーンショットから目的のテキストを抽出します。これらはまれであり、データを本当に必要とする専用のスクレイパーのみがこれを設定します。
ScrapingHub または Kimono などのWebscrapingサービス。実際、サイトをスクレイピングする方法を見つけ出し、他の人が使用できるようにコンテンツを引き出すことを仕事とする人々がいます。
当然のことながら、プロのスクレイピングサービスは阻止するのが最も困難ですが、サイトをスクレイピングする方法を見つけ出すのが難しくて時間がかかる場合、これらの（およびそのためにそれらを支払う人々）はあなたのウェブサイトをスクレイピングすることを気にかけないかもしれません。
frames を使用して他のサイトのページにWebサイトを埋め込み、モバイルアプリにサイトを埋め込みます。
技術的にスクレイピングではありませんが、モバイルアプリ（AndroidおよびiOS）はWebサイトを埋め込み、カスタムCSSおよびJavaScriptを挿入することができます。したがって、ページの外観が完全に変わります。
人間のコピー-貼り付け：他の人がコンテンツを使用するために、コンテンツをコピーして貼り付けます。
これらの異なる種類のスクレーパーの間には多くの重複があり、多くのスクレーパーは、たとえ異なる技術や方法を使用しても、同様に動作します。
これらのヒントの大部分は、自分自身のアイデア、スクレーパーの作成中に遭遇したさまざまな困難、およびインターウェブ周辺の情報やアイデアの断片です。
スクレイピングを停止する方法
それを完全に防ぐことはできません、何をするにしても、決心したスクレイパーはまだスクレイピングの方法を見つけ出すことができるからです。ただし、いくつかのことを行うことで、大量のスクレイピングを停止できます。
ログとトラフィックパターンを監視します。異常なアクティビティが見られる場合はアクセスを制限します。
ログを定期的に確認し、同じIPアドレスからの多くの同様のアクションなど、自動アクセス（スクレーパー）を示す異常なアクティビティの場合、アクセスをブロックまたは制限できます。
具体的には、いくつかのアイデア：
レート制限：
ユーザー（およびスクレイパー）が特定の時間に限られた数のアクションのみを実行できるようにします。たとえば、特定のIPアドレスまたはユーザーからの1秒あたりの検索を数回のみ許可します。これにより、スクレーパーが遅くなり、無効になります。アクションが実際のユーザーよりも速く、または速く完了する場合、キャプチャを表示することもできます。
異常なアクティビティを検出：
特定のIPアドレスからの同様のリクエストが多数ある、異常な数のページを閲覧している、または異常な数の検索を実行しているなど、異常なアクティビティが発生した場合、アクセスを禁止したり、後続のリクエストに対してキャプチャを表示したりできます。
IPアドレスによる監視とレート制限だけでなく、他のインジケータも使用してください：
ブロックまたはレート制限を行う場合、IPアドレスごとに行うだけではありません。他のインジケータと方法を使用して、特定のユーザーまたはスクレイパーを識別することができます。特定のユーザー/スクレーパーを識別するのに役立ついくつかの指標は次のとおりです。
ユーザーがフォームに入力する速度、およびボタンのどこをクリックするか。
JavaScriptを使用すると、画面サイズ/解像度、タイムゾーン、インストールされているフォントなど、多くの情報を収集できます。これを使用してユーザーを識別できます。
HTTPヘッダーとその順序、特にUser-Agent。
例として、同じユーザーエージェント、画面サイズ（JavaScriptで決定）、およびユーザー（この場合はスクレイパー）を使用して、同じ方法で常にボタンをクリックすると、単一のIPアドレスから多くのリクエストを取得する場合定期的な間隔で、おそらくスクリーンスクレーパーです。また、同様のリクエストを一時的にブロックすることができます（たとえば、そのユーザーエージェントとその特定のIPアドレスからの画面サイズを持つすべてのリクエストをブロックします）。共有インターネット接続の場合。
分散スクレイピング（ボットネットまたはプロキシのネットワークを使用するスクレイパー）を示す、異なるIPアドレスからのものであっても、同様のリクエストを識別できるため、これをさらに進めることができます。他の点では同一のリクエストを多数受け取り、それらは異なるIPアドレスからのものである場合、ブロックできます。繰り返しますが、実際のユーザーを誤ってブロックしないように注意してください。
これは、JavaScriptを実行するスクリーンスクレイパーに対して効果的です。JavaScriptから多くの情報を取得できるからです。
セキュリティスタック交換に関する関連質問：
同じ外部IPアドレスを持つユーザーを一意に識別する方法 詳細、および
IPアドレスが頻繁に変更される場合に、なぜ人々はIPアドレスの禁止を使用するのですか？ これらの方法の制限に関する情報。
アクセスを一時的にブロックする代わりに、キャプチャを使用します：
レート制限を実装する簡単な方法は、一定時間アクセスを一時的にブロックすることですが、キャプチャを使用する方が良い場合があります。キャプチャのセクションを参照してください。
登録とログインが必要
コンテンツを表示するためにアカウントの作成が必要です（サイトで実行可能な場合）。これはスクレイパーにとっては良い抑止力ですが、実際のユーザーにとっても良い抑止力です。
- アカウントの作成とログインが必要な場合は、ユーザーとスクレーパーのアクションを正確に追跡できます。これにより、特定のアカウントがスクレイピングに使用されていることを簡単に検出し、それを禁止できます。 IPアドレスだけでなく特定のスクレイパーを特定できるため、レート制限や不正使用の検出（短時間での膨大な数の検索など）が容易になります。
多くのアカウントを作成するスクリプトを回避するには、次のことを行う必要があります。
登録に電子メールアドレスを要求し、アカウントをアクティブにするために開く必要があるリンクを送信して、その電子メールアドレスを確認します。メールアドレスごとに1つのアカウントのみを許可します。
登録/アカウント作成中にキャプチャを解決する必要があります。
コンテンツを表示するためにアカウントの作成が必要になると、ユーザーと検索エンジンが不要になります。記事を表示するためにアカウントの作成が必要な場合、ユーザーは別の場所に移動します。
クラウドホスティングおよびスクレイピングサービスIPアドレスからのアクセスをブロックする
スクレイパーは、Amazon Web ServicesやGAE、VPSなどのウェブホスティングサービスから実行される場合があります。このようなクラウドホスティングサービスで使用されるIPアドレスからのリクエストについては、Webサイトへのアクセスを制限します（またはキャプチャを表示します）。
同様に、スクレイパーはこのようなプロキシサーバーを使用して多くの要求が検出されないようにするため、プロキシまたはVPNプロバイダーが使用するIPアドレスからのアクセスを制限することもできます。
プロキシサーバーとVPNからのアクセスをブロックすると、実際のユーザーに悪影響を与えることに注意してください。
ブロックする場合は、エラーメッセージを説明なしにします
アクセスをブロック/制限する場合は、スクレーパーにブロックの原因を伝えないようにして、スクレーパーの修正方法に関する手がかりを与えるようにしてください。したがって、次のようなテキストでエラーページを表示するのは悪い考えです。
IPアドレスからのリクエストが多すぎます。しばらくしてからもう一度お試しください。
エラー、ユーザーエージェントヘッダーが存在しません！
代わりに、原因をスクレーパーに伝えないわかりやすいエラーメッセージを表示します。このようなものははるかに優れています：
- 申し訳ありませんが、何かがうまくいきませんでした。問題が解決しない場合は、
[email protected]経由でサポートに連絡できます。
このようなエラーページが表示された場合、実際のユーザーにとっても、これはユーザーフレンドリーです。また、実際のユーザーにエラーメッセージが表示された場合にブロックするのではなく、正当なユーザーに連絡するように、ハードブロックの代わりに後続のリクエストにキャプチャを表示することを検討する必要があります。
スクレイパーがWebサイトにアクセスしている疑いがある場合は、キャプチャを使用します。
Captchas（「コンピューターと人間を区別するための完全に自動化されたテスト」）は、スクレーパーの停止に対して非常に効果的です。残念ながら、それらはユーザーを刺激するのにも非常に効果的です。
そのため、スクレイパーではなく実際のユーザーである場合にアクセスをブロックすることなく、スクレイパーの可能性があると思われる場合やスクレイピングを停止したい場合に役立ちます。スクレイパーが疑われる場合は、コンテンツへのアクセスを許可する前にキャプチャを表示することを検討してください。
Captchasを使用する際の注意事項：
独自のロールをしないで、Googleのようなものを使用してください reCaptcha ：キャプチャを自分で実装するよりもはるかに簡単です。ぼやけてゆがんだテキストソリューションよりもユーザーフレンドリーです（ユーザー）多くの場合、ボックスにチェックを入れるだけで済みます。また、サイトから提供される単純な画像よりも、スクリプト作成者が解決するのは非常に困難です。
HTMLマークアップにcaptchaの解決策を含めないでください。実際にcaptchaの解決策を持つWebサイトを1つ見ましたページ自体の中（非常によく隠されていますが）役に立たない。このようなことをしないでください。繰り返しますが、reCaptchaのようなサービスを使用すると、この種の問題は発生しません（適切に使用する場合）。
キャプチャは一括で解決できます：実際の低賃金の人間がキャプチャを一括で解決するキャプチャ解決サービスがあります。繰り返しますが、ここではreCaptchaを使用することをお勧めします。これには保護機能があるためです（ユーザーがキャプチャを解決するために比較的短い時間を使用するなど）。この種のサービスは、データが本当に価値がない限り使用されることはほとんどありません。
テキストコンテンツを画像として提供する
テキストを画像サーバー側にレンダリングし、表示するために提供することができます。これにより、テキストを抽出する単純なスクレーパーが妨げられます。
ただし、これはスクリーンリーダー、検索エンジン、パフォーマンス、その他ほとんどすべてにとって悪いことです。また、一部の場所では違法です（アクセシビリティのため、たとえばアメリカ障害者法など）。また、一部のOCRで簡単に回避できるため、やらないでください。
CSSスプライトでも同様のことができますが、同じ問題が発生します。
完全なデータセットを公開しないでください：
可能であれば、スクリプト/ボットがすべてのデータセットを取得する方法を提供しないでください。例として、多数の個別の記事があるニュースサイトがあるとします。これらの記事は、オンサイト検索で検索することによってのみアクセス可能にすることができます。また、allのサイトとそのURLのリストがどこにもなければ、それらの記事は検索機能を使用することによってのみアクセスできます。つまり、サイトからすべての記事を取得したいスクリプトは、記事に表示される可能性のあるすべてのフレーズを検索してすべてを見つける必要があり、時間がかかり、恐ろしく非効率的で、うまくいけばスクレーパーはあきらめます。
次の場合、これは無効になります。
- とにかくボット/スクリプトは完全なデータセットを必要としない/必要としません。
- 記事は
example.com/article.php?articleId=12345のようなURLから提供されます。これ（および同様のこと）により、スクレイパーはすべてのarticleIdsを繰り返し処理し、すべての記事をそのように要求できます。 - 他の記事につながる記事内のリンクをたどるスクリプトを作成するなど、最終的にすべての記事を見つける方法は他にもあります。
- 「and」や「the」などを検索すると、ほとんどすべてが明らかになる可能性があるため、注意が必要です。 （上位10件または20件の結果のみを返すことで、これを回避できます）。
- コンテンツを見つけるには検索エンジンが必要です。
API、エンドポイントなどを公開しないでください：
意図せずにAPIを公開しないようにしてください。たとえば、AJAXまたはAdobe FlashまたはJavaアプレット（God forbid！）内からのネットワーク要求を使用してデータをロードしている場合、ネットワーク要求を見るのは簡単ですページを開き、それらのリクエストの送信先を特定し、それらのエンドポイントをスクレイパープログラムでリバースエンジニアリングして使用します。説明したように、エンドポイントを難読化し、他のユーザーが使用しにくいようにします。
HTMLパーサーとスクレーパーを抑止するには：
HTMLパーサーは、HTMLの識別可能なパターンに基づいてページからコンテンツを抽出することで機能するため、これらのスクレイパーを破壊するために、またはそれらをねじ込むために、意図的にこれらのパターンを変更できます。これらのヒントのほとんどは、スパイダーやスクリーンスクレーパーなどの他のスクレーパーにも適用されます。
HTMLを頻繁に変更する
HTMLを直接処理するスクレーパーは、HTMLページの特定の識別可能な部分からコンテンツを抽出することにより、HTMLを直接処理します。例：Webサイトのすべてのページに、article-contentというIDを持つdivがあり、これに記事のテキストが含まれている場合、サイトのすべての記事ページにアクセスして抽出するスクリプトを書くのは簡単です各記事ページのarticle-content divのコンテンツテキスト、およびvoilà、スクレーパーには、サイトのすべての記事が他の場所で再利用できる形式で含まれています。
HTMLとページの構造を頻繁に変更すると、このようなスクレーパーは機能しなくなります。
HTML内の要素のIDとクラスを頻繁に、おそらくは自動的に変更することもできます。したがって、
div.article-contentがdiv.a4c36dda13eaf0のようになり、毎週変更される場合、スクレーパーは最初は正常に機能しますが、1週間後に壊れます。 ID /クラスの長さも必ず変更してください。変更しないと、スクレーパーは代わりにdiv.[any-14-characters]を使用して目的のdivを見つけます。他の同様の穴にも注意してください。マークアップから目的のコンテンツを見つける方法がない場合、スクレイパーはHTMLの構造からそれを行います。したがって、
h1の後にあるdiv内のすべてのdivが記事コンテンツであるという点ですべての記事ページが類似している場合、スクレーパーはそれに基づいて記事コンテンツを取得します。繰り返しになりますが、これを壊すために、HTMLに追加のマークアップを追加/削除できます。余分なdivsまたはspansを追加します。最新のサーバー側のHTML処理では、これはそれほど難しくないはずです。
知っておくべきこと：
実装、保守、デバッグが面倒で困難になります。
キャッシュを妨害します。特にHTML要素のIDまたはクラスを変更する場合、CSSファイルとJavaScriptファイルで対応する変更が必要になります。つまり、それらを変更するたびに、ブラウザーによってそれらを再ダウンロードする必要があります。これにより、リピート訪問者のページ読み込み時間が長くなり、サーバーの負荷が増加します。週に一度だけ変更すれば、大きな問題にはなりません。
賢いスクレーパーは、実際のコンテンツがどこにあるかを推測することで、コンテンツを取得できます。ページ上のテキストの大きな単一ブロックが実際の記事である可能性が高いことを知っています。これにより、ページから目的のデータを引き続き検索および抽出できます。 Boilerpipe はまさにこれを行います。
基本的に、スクリプトがすべての同様のページに必要な実際のコンテンツを見つけるのが容易でないことを確認してください。
PHPでこれを実装する方法の詳細については、 XPathに依存するクローラーがページコンテンツを取得しないようにする方法 も参照してください。
ユーザーの場所に基づいてHTMLを変更する
これは前のヒントに似ています。ユーザーの場所/国（IPアドレスで決定）に基づいて異なるHTMLを提供すると、ユーザーに配信されるスクレーパーが破損する可能性があります。たとえば、サイトからデータをスクレイピングするモバイルアプリを誰かが作成している場合、最初は正常に機能しますが、実際にはユーザーに配信されると壊れます。ユーザーは別の国にいるため、異なるHTML組み込みスクレーパーは、消費するように設計されていません。
HTMLを頻繁に変更し、スクレーパーを積極的に変更してください！
例：example.com/search?query=somesearchqueryにあるWebサイトに検索機能があり、次のHTMLが返されます。
<div class="search-result">
<h3 class="search-result-title">Stack Overflow has become the world's most popular programming Q & A website</h3>
<p class="search-result-excerpt">The website Stack Overflow has now become the most popular programming Q & A website, with 10 million questions and many users, which...</p>
<a class"search-result-link" href="/stories/story-link">Read more</a>
</div>
(And so on, lots more identically structured divs with search results)
ご想像のとおり、これは簡単にスクレイピングできます。スクレイパーが行う必要があるのは、クエリで検索URLにアクセスし、返されたHTMLから目的のデータを抽出することだけです。上記のようにHTMLを定期的に変更することに加えて、古いIDとクラスで古いマークアップを残し、CSSで非表示にし、偽のデータを入力して、スクレーパー。検索結果ページを変更する方法は次のとおりです。
<div class="the-real-search-result">
<h3 class="the-real-search-result-title">Stack Overflow has become the world's most popular programming Q & A website</h3>
<p class="the-real-search-result-excerpt">The website Stack Overflow has now become the most popular programming Q & A website, with 10 million questions and many users, which...</p>
<a class"the-real-search-result-link" href="/stories/story-link">Read more</a>
</div>
<div class="search-result" style="display:none">
<h3 class="search-result-title">Visit Example.com now, for all the latest Stack Overflow related news !</h3>
<p class="search-result-excerpt">Example.com is so awesome, visit now !</p>
<a class"search-result-link" href="http://example.com/">Visit Now !</a>
</div>
(More real search results follow)
これは、クラスまたはIDに基づいてHTMLからデータを抽出するために記述されたスクレーパーが引き続き機能するように見えることを意味しますが、CSSで隠されているため、実際のユーザーには表示されない偽のデータまたは広告さえも取得します。
スクレーパーをねじ込む：目に見えない偽のハニーポットデータをページに挿入する
前の例に加えて、見えないハニーポットアイテムをHTMLに追加して、スクレーパーをキャッチできます。前述の検索結果ページに追加できる例：
<div class="search-result" style="display:none">
<h3 class="search-result-title">This search result is here to prevent scraping</h3>
<p class="search-result-excerpt">If you're a human and see this, please ignore it. If you're a scraper, please click the link below :-)
Note that clicking the link below will block access to this site for 24 hours.</p>
<a class"search-result-link" href="/scrapertrap/scrapertrap.php">I'm a scraper !</a>
</div>
(The actual, real, search results follow.)
すべての検索結果を取得するために書かれたスクレイパーは、ページ上の他の実際の検索結果と同様にこれを取得し、リンクにアクセスして目的のコンテンツを探します。本物の人間は、そもそも（CSSで隠されているため）表示されることさえなく、リンクにアクセスしません。 robots.txtで/scrapertrap/を許可していないため、Googleなどの本物で望ましいスパイダーもリンクにアクセスしません。
scrapertrap.phpに、アクセスしたIPアドレスへのアクセスをブロックするなどの操作をさせたり、そのIPからの以降のすべてのリクエストに対してキャプチャを強制することができます。
Robots.txtファイルでハニーポット（
/scrapertrap/）を禁止することを忘れないでください。検索エンジンボットがハニーポットに陥らないようにするためです。これを、HTMLを頻繁に変更するという以前のヒントと組み合わせることができます/すべきです。
スクレーパーは最終的にそれを回避することを学ぶので、これも頻繁に変更してください。ハニーポットのURLとテキストを変更します。また、スクレイパーはコンテンツを隠すために使用されるCSSで
style属性を持つものを避けることを学ぶので、非表示に使用されるインラインCSSの変更を検討し、代わりにID属性と外部CSSを使用します。また、時々有効にするだけにして、スクレーパーは最初は動作しますが、しばらくすると壊れます。これは前のヒントにも当てはまります。悪意のある人は、ハニーポットへのリンクを共有するか、そのリンクを画像として（たとえば、フォーラムに）埋め込むことによって、実際のユーザーのアクセスを妨げることができます。 URLを頻繁に変更し、禁止時間を比較的短くしてください。
スクレーパーを検出した場合、偽の無用なデータを提供する
明らかにスクレーパーであるものを検出した場合、偽の無用なデータを提供できます。これにより、スクレイパーがWebサイトから取得したデータが破損します。また、このような偽のデータと実際のデータを区別できないようにする必要があります。これにより、スクレイパーは、それらがねじ込まれていることを知りません。
例として、ニュースWebサイトがあるとします。スクレイパーを検出した場合、アクセスをブロックする代わりに、偽の ランダムに生成された 記事を提供します。これにより、スクレイパーが取得するデータが汚染されます。偽のデータを本物と区別できないようにすると、スクレイパーが望むもの、つまり実際の実際のデータを取得するのが難しくなります。
ユーザーエージェントが空/欠落している場合、要求を受け入れない
多くの場合、すべてのブラウザと検索エンジンスパイダーが送信するのに対して、遅延書き込みスクレーパーはリクエストにユーザーエージェントヘッダーを送信しません。
User Agentヘッダーが存在しないリクエストを受け取った場合は、キャプチャを表示するか、単にアクセスをブロックまたは制限できます。 （または、上記のように偽のデータを提供するか、他の何かを提供します。）
スプーフィングは簡単ですが、記述が不十分なスクレーパーに対する対策としては実装する価値があります。
ユーザーエージェントが一般的なスクレイパーの場合、リクエストを受け入れないでください。スクレーパーが使用するブラックリスト
場合によっては、スクレイパーは、次のような実際のブラウザや検索エンジンのスパイダーが使用しないユーザーエージェントを使用します。
- 「Mozilla」（それ以外は何もありません。ここでスクレイピングについての質問をいくつか見てきました。実際のブラウザはそれだけを使用しません）
- 「Java 1.7.43_u43」（デフォルトでは、JavaのHttpUrlConnectionはこのようなものを使用します。）
- 「BIZCO EasyScraping Studio 2.0」
- 「wget」、「curl」、「libcurl」、..（WgetおよびcURLは、基本的なスクレイピングに使用されることがあります）
特定のユーザーエージェント文字列がサイトのスクレイパーによって使用されており、実際のブラウザや正当なスパイダーによって使用されていないことがわかった場合は、ブラックリストに追加することもできます。
アセット（CSS、画像）を要求しない場合、実際のブラウザではありません。
実際のブラウザは、（ほとんどの場合）画像やCSSなどのアセットをリクエストしてダウンロードします。 HTMLパーサーとスクレイパーは、実際のページとそのコンテンツのみに関心があるため、気になりません。
アセットへのリクエストをログに記録することができます。HTMLのみに対するリクエストが多数表示される場合は、スクレイパーである可能性があります。
検索エンジンボット、古代のモバイルデバイス、スクリーンリーダー、設定の誤ったデバイスもアセットを要求しない可能性があることに注意してください。
Cookieを使用および要求します。それらを使用して、ユーザーおよびスクレーパーのアクションを追跡します。
Webサイトを表示するには、Cookieを有効にする必要があります。これは経験の浅い初心者のスクレイパーライターを思いとどまらせますが、スクレイパーがCookieを送信するのは簡単です。それらを使用し、必要とする場合は、それらを使用してユーザーおよびスクレーパーのアクションを追跡し、IPごとではなくユーザーごとにレート制限、ブロック、またはキャプチャの表示を実装できます。
たとえば、ユーザーが検索を実行するときに、一意の識別Cookieを設定します。結果ページが表示されたら、そのCookieを確認します。ユーザーがすべての検索結果を開く場合（Cookieからわかる）、おそらくスクレーパーです。
スクレイパーはリクエストとともにCookieを送信し、必要に応じて破棄できるため、Cookieの使用は効果的ではない場合があります。サイトがCookieのみで動作する場合、Cookieが無効になっている実際のユーザーのアクセスも禁止します。
JavaScriptを使用してCookieを設定および取得する場合、JavaScriptを実行しないスクレイパーはブロックされます。これは、リクエストでCookieを取得および送信できないためです。
JavaScript + Ajaxを使用してコンテンツを読み込む
JavaScript + AJAXを使用して、ページ自体のロード後にコンテンツをロードできます。これにより、JavaScriptを実行しないHTMLパーサーがコンテンツにアクセスできなくなります。これは多くの場合、初心者や経験の浅いプログラマーがスクレーパーを書くのに効果的な抑止力です。
次のことに注意してください。
JavaScriptを使用して実際のコンテンツを読み込むと、ユーザーエクスペリエンスとパフォーマンスが低下します
検索エンジンもJavaScriptを実行しないため、コンテンツのインデックス作成ができません。これは検索結果ページでは問題にならないかもしれませんが、記事ページなど他の問題では問題になります。
マークアップ、スクリプトからのネットワーク要求、その他すべてを難読化します。
AjaxとJavaScriptを使用してデータをロードする場合、転送されるデータを難読化します。例として、サーバー上でデータをエンコードし（base64などの単純なものまたはより複雑なものを使用）、Ajax経由でフェッチした後、クライアント上でそれをデコードして表示できます。これは、ネットワークトラフィックを検査する人がページの動作とデータのロードをすぐに確認できないことを意味します。また、スクランブル解除アルゴリズムをリバースエンジニアリングする必要があるため、エンドポイントからリクエストデータを直接リクエストすることは困難です。
データの読み込みにAjaxを使用する場合、最初にページを読み込まずにエンドポイントを使用するのを難しくする必要があります。たとえば、セッションキーをパラメーターとして要求し、JavaScriptまたはHTMLに埋め込むことができます。
難読化されたデータを最初のHTMLページに直接埋め込み、JavaScriptを使用して難読化を解除して表示することもできます。これにより、余分なネットワーク要求が回避されます。これを行うと、JavaScriptを実行しないHTMLのみのパーサーを使用してデータを抽出することが非常に難しくなります。スクレーパーを作成するパーサーはJavaScriptをリバースエンジニアリングする必要があるためです（難読化する必要があります）。
難読化の方法を定期的に変更して、それを理解したスクレイパーを破壊することができます。
ただし、このようなことを行うにはいくつかの欠点があります。
実装、保守、デバッグが面倒で困難になります。
実際にJavaScriptを実行してからデータを抽出するスクレイパーやスクリーンスクレイパーに対しては効果がありません。 （もっとも単純なHTMLパーサーはJavaScriptを実行しません）
実際のユーザーがJavaScriptを無効にしている場合、サイトは機能しなくなります。
パフォーマンスとページ読み込み時間が低下します。
非技術的な：
人々にこすらないように伝えてください。
弁護士を探す
データを利用可能にし、APIを提供します。
データを簡単に利用できるようにし、帰属とサイトへのリンクを要求することができます。おそらく$$$を請求してください。
その他：
Cloudflareまたは Distill Networks （仕組みの詳細 here ）によるスクレイピング防止などの商用スクレイピング保護サービスもあります。君は。
実際のユーザーの使いやすさと耐スクレーパー性のバランスを見つけます。あなたがすることはすべて、何らかの形でユーザー体験に悪影響を及ぼし、妥協を見つけます。
モバイルサイトとアプリを忘れないでください。モバイルアプリをお持ちの場合は、それもスクリーンスクレイピングでき、ネットワークトラフィックを検査して、使用するRESTエンドポイントを判断できます。
スクレイパーは他のスクレイパーをスクレイピングできます：あなたのコンテンツをスクレイピングしたWebサイトがある場合、他のスクレイパーはそのスクレイパーのWebサイトからスクレイピングできます。
参考文献：
Webスクレイピングに関するウィキペディアの記事 。関連するテクノロジーとさまざまな種類のWebスクレーパーに関する多くの詳細。
スクリプト作成者がWebサイトを1秒間に何百回も非難しないようにする 。よく似た問題に関するQ＆A-ボットがWebサイトをチェックし、販売されたらすぐに購入する。多くの関連情報、特に。 Captchasとレート制限。
robots.txtをセットアップしたと仮定します。
他の人が述べたように、スクレーパーは彼らの活動のほぼすべての側面を偽造することができ、おそらく悪者からの要求を識別することは非常に困難です。
私は考慮します：
- ページ
/jail.htmlをセットアップします。 robots.txtのページへのアクセスを禁止します（したがって、敬意を表するスパイダーはアクセスしません）。- ページの1つにリンクを配置し、CSS（
display: none）で非表示にします。 /jail.htmlへの訪問者のIPアドレスを記録します。
これは、robots.txtを無視しているスクレイパーからのリクエストをすばやく特定するのに役立つ場合があります。
/jail.htmlを、通常のページと同じ正確なマークアップを持ち、偽のデータ（/jail/album/63ajdka、/jail/track/3aads8など）を含むWebサイト全体にすることもできます。このようにして、不良スクレーパーは、完全にブロックする機会が得られるまで、「異常な入力」について警告されません。
スー 'em。
真面目な話：お金があれば、インターネットでの道をよく知っている素敵な若い弁護士に相談してください。ここで何かできることがあります。サイトの拠点に応じて、弁護士に自国での停職処分またはそれに相当するものを作成してもらうことができます。あなたは少なくともろくでなしを怖がらせることができるかもしれません。
ダミー値の挿入を文書化します。明確に（ただしあいまいに）指すダミー値を挿入します。これは電話帳会社の一般的な慣行であり、ここドイツでは、コピーキャットが1対1でコピーした偽のエントリによって破壊された事例がいくつかあったと思います。
これにより、HTMLコードを台無しにして、SEO、有効性などをドラッグダウンさせてしまうのは残念です（同じページのリクエストごとに少し異なるHTML構造を使用するテンプレートシステムが既に役立つ場合がありますが- lotコンテンツを取得するために常にHTML構造とクラス/ ID名に依存するスクレイパーに対して）
このような場合は、著作権法が有効なものです。お金を稼ぐために他の人の正直な仕事を剥奪することはあなたが戦うことができるべきである何かです。
これを完全に防ぐ方法はありません。スクレイパーは、ユーザーエージェントを偽装し、複数のIPアドレスを使用するなどして、通常のユーザーとして表示されます。できることは、ページのロード時にテキストを使用できないようにすることだけです。イメージ、フラッシュ、またはJavaScriptでロードしてください。ただし、最初の2つは悪いアイデアであり、最後の1つは、一部の一般ユーザーに対してJavaScriptが有効になっていない場合のアクセシビリティの問題です。
彼らがあなたのサイトを完全に非難し、あなたのすべてのページをthroughしているなら、何らかの種類のレート制限を行うことができます。
しかし、いくつかの希望があります。スクレイパーは、サイトのデータが一貫した形式であることに依存しています。何らかの方法でランダム化できれば、スクレーパーが破損する可能性があります。読み込みごとにページ要素のIDやクラス名を変更するなど。そして、それでも、彼らはおそらく十分な献身でそれを回避することができました。
データにアクセスするためのXML APIを提供します。使いやすい方法で。人々があなたのデータを望んでいるなら、彼らはそれを手に入れます。
このようにして、機能のサブセットを効果的な方法で提供し、少なくともスクレイパーがHTTPリクエストと大量の帯域幅を使い果たすことがないようにします。
その後、あなたがしなければならないことは、あなたのデータがAPIを使用することを望む人々を説得することです。 ;）
申し訳ありませんが、これを行うのは本当に難しいです...
コンテンツを使用しないよう丁寧に依頼することをお勧めします（コンテンツが著作権で保護されている場合）。
もしそうであり、彼らがそれを取り下げないなら、あなたは次の行動を取ることができ、それらに 停止と破棄の手紙 を送ることができます。
一般的に、スクレイピングを防ぐためにあなたが何をするにしても、おそらくよりマイナスの効果があります。アクセシビリティ、ボット/スパイダーなど。
さて、すべての投稿が言っているように、もしあなたがそれを検索エンジンに優しいものにしたいなら、ボットは確実にこすることができます。
しかし、あなたはまだいくつかのことを行うことができ、60-70％のスクレイピングボットに影響を与える可能性があります。
以下のようなチェッカースクリプトを作成します。
特定のIPアドレスが非常に高速にアクセスしている場合、数回（5〜10回）アクセスした後、そのIPアドレスとブラウザ情報をファイルまたはデータベースに入れます。
次のステップ
（これはバックグラウンドプロセスであり、常に実行されるか、数分後にスケジュールされます。）これらの疑わしいIPアドレスをチェックし続けるスクリプトをもう1つ作成します。
ケース1.ユーザーエージェントがGoogleのような既知の検索エンジンである場合、 Bing 、 Yahoo （グーグルでユーザーエージェントの詳細を確認できます）。次に、 http://www.iplists.com/ を確認する必要があります。このリストとパターンの一致を試みます。偽のユーザーエージェントのように思える場合は、次回の訪問時に CAPTCHA を入力するように依頼します。 （ボットのIPアドレスについてもう少し調査する必要があります。これが達成可能であることを知っているし、IPアドレスのwhoisも試してみてください。これは役立つ場合があります。）
ケース2。検索ボットのユーザーエージェントがいない場合：次回の訪問時にCAPTCHAの入力を要求するだけです。
遅い答え-そして、この答えはおそらくあなたが聞きたいものではありません...
私はすでに多数（数十）のさまざまな特殊データマイニングスクレーパーを作成しました。 （「オープンデータ」哲学が好きだからです）。
他の回答にはすでに多くのアドバイスがあります-今、私は悪魔の擁護者の役割を果たし、その有効性を拡張および/または修正します。
最初：
- 誰かが本当にあなたのデータが欲しい場合
- あなたは効果的に（技術的に）データを隠すことができません
- データが「一般ユーザー」に公的にアクセス可能である場合
いくつかの技術的な障壁を使用しようとしても、トラブルに見合う価値はありません。
- ユーザーエクスペリエンスを悪化させることにより、通常のユーザーに
- 通常のボット（歓迎されているボット）（検索エンジン）
- 等...
Plain HMTL-最も簡単な方法は、明確に定義された構造とcssクラスを使用して、プレーンなHTMLページを解析することです。例えば。 Firebugで要素を検査し、スクレーパーで適切なXpathやCSSパスを使用するだけで十分です。
HTML構造を動的に生成できます。また、CSSクラス名（およびCSS自体も）を動的に生成できます（たとえば、ランダムなクラス名を使用して）。
- 通常のユーザーに一貫した方法で情報を提示したい
- 例えば再び-スクレーパーをセットアップするには、ページ構造をもう一度分析するだけで十分です。
- また、「既知のコンテンツ」を分析することで自動的に実行できます
- 誰かが既に知っていたら（以前のスクレイプで）、例えば：
- 「フィルコリンズ」に関する情報を含むもの
- 「phil collins」ページを十分に表示し、（今日）ページの構造を（自動的に）分析します:)
通常のユーザーはあなたを嫌うので、すべての応答の構造を変更することはできません。また、これはスクレーパーではなく、あなた（メンテナンス）にとってより多くのトラブルを引き起こします。 XPathまたはCSSパスは、既知のコンテンツから自動的にスクレイピングスクリプトによって決定できます。
Ajax-最初は少し難しくなりますが、何回もスクレイピングプロセスを高速化します:)-なぜですか？
要求と応答を分析するとき、私は自分のプロキシサーバー（Perlで記述された）をセットアップするだけで、Firefoxはそれを使用しています。もちろん、それは私自身のプロキシであるため、完全に隠されているため、ターゲットサーバーは通常のブラウザとして認識します。 （つまり、X-Forwarded-forなどのヘッダーはありません）。プロキシログに基づいて、ほとんどの場合、ajaxリクエストの「ロジック」を判断できます。ほとんどのhtmlスクレイピングをスキップして、よく構造化されたAjax応答（ほとんどはJSON形式）を使用できます。
したがって、ajaxはあまり役に立ちません...
もっと複雑なのは、muchパックされたjavascript関数を使用するページです。
ここでは、2つの基本的な方法を使用できます。
- jSを解凍して理解し、Javascriptロジックに従うスクレーパーを作成します（難しい方法）
- または（できれば自分で使用する）-スクレイプのために Mozrepl でMozillaを使用するだけです。例えば。実際のスクレイピングは、適切な要素をクリックして、ブラウザウィンドウから直接「デコードされた」応答を取得するようにプログラムされた、フル機能のJavaScript対応ブラウザで行われます。
このようなスクレイピングは低速です（スクレイピングは通常のブラウザーのように行われます）が、
- セットアップと使用が非常に簡単
- それに対抗することはほぼ不可能です:)
- とにかく「遅さ」は「急速に同じIPベースのリクエストをブロックする」に対抗するために必要です
User-Agentベースのフィルタリングはまったく役に立ちません。真面目なデータマイナーは、それを自分のスクレイパーで正しいものに設定します。
ログインが必要-役に立たない。最も簡単な方法は、ログインプロトコルを分析および/またはスクリプト化せずに、Mozillaを使用し、Mozreplベースのスクレーパーを実行した後、通常のユーザーとしてサイトにログインすることです。
require loginは匿名ボットには役立ちますが、データをスクレイプしたい人には役立ちません。彼は自分自身を通常のユーザーとしてあなたのサイトに登録するだけです。
framesを使用してもあまり効果的ではありません。これは多くのライブムービーサービスで使用されており、非常に難しくありません。フレームは、分析に必要なHTML/Javascriptページの1つにすぎません...データに問題がある場合-データマイナーが必要な分析を行います。
IPベースの制限はまったく効果的ではありません-ここには公開プロキシサーバーが多すぎ、TORもあります... :) tは、スクレイピングを遅くします（本当にあなたのデータが欲しい人のために）。
非常に難しいのは、画像に隠されたデータのスクレイピングです。 （たとえば、単にデータをサーバー側の画像に変換する）。 "tesseract"（OCR）を採用することは何回も役立ちますが、正直なところ、データはスクレイパーにとってのトラブルに見合ったものでなければなりません。 （これは何度も価値がありません）。
その一方で、ユーザーはこれを嫌います。私は、（スクレイピングではない場合でも）ページコンテンツをクリップボードにコピーできないWebサイトを嫌います（情報が画像に含まれているため、または（ばかげたもの）右クリックしてカスタムJavascriptイベントを結合しようとするため）。 ）
最も難しいのは、Javaアプレットまたはflashを使用し、アプレットが使用するサイトセキュアhttpsは、内部的に自身を要求します。しかし、考え直してください-あなたのiPhoneユーザーはどれほど幸せになるでしょう...;）。したがって、現在それらを使用しているサイトはごくわずかです。自分、ブラウザのすべてのフラッシュコンテンツをブロックする（通常のブラウジングセッションで）-Flashに依存するサイトを使用しない。
あなたのマイルストーンは...かもしれないので、この方法を試すことができます-覚えておいてください-あなたはおそらくあなたのユーザーの一部を失うでしょう。また、いくつかのSWFファイルは逆コンパイル可能であることを忘れないでください。 ;）
Captcha（良いもの-reCaptchaのような）は大いに役立ちます-しかし、あなたのユーザーはあなたを嫌います...-ちょうどあなたのユーザーがあなたを愛する方法を想像してください音楽アーティストに関する情報を表示するすべてのページのいくつかのキャプチャを解決する必要がある場合。
おそらく続行する必要はありません-あなたはすでに絵に入っています。
今、あなたがすべきこと：
覚えておいてください：反対側で通常のユーザーに（友好的な方法で）公開したい場合、データを隠すことはほとんど不可能です。
そう、
- データを簡単にアクセスできるようにする-いくつかのAPI
- これにより、簡単にデータにアクセスできます
- 例えばサーバーをスクレイピングからオフロードする-あなたに良い
- 適切な使用権を設定します（たとえば、ソースを引用する必要があります）
- 多くのデータは著作権で保護されていないことを忘れないでください-そしてそれらを保護するのは難しいです
- 既に行ったように、いくつかの偽データを追加し、法的ツールを使用します
- 他の人がすでに言ったように、「停止と破棄の手紙」を送る
- 他の法的措置（訴訟など）は、おそらく費用がかかりすぎて勝ちにくい（特に米国以外のサイトに対して）
いくつかの技術的障壁を使用する前に、よく考えてください。
データマイナーをブロックしようとするのではなく、Webサイトのユーザビリティに努力を注ぐだけです。ユーザーはあなたを愛します。技術的な障壁に費やされた時間（＆energy）は通常は価値がありません-より良いウェブサイトを作るために時間を費やす方が良いです...
また、データ泥棒は通常の泥棒とは異なります。
安価なホームアラームを購入し、「この家は警察に接続されています」という警告を追加すると、多くの泥棒が侵入しようとさえしなくなります。彼による1つの間違った動き-そして彼が刑務所に行くので...
したがって、投資する投資額はわずかですが、泥棒の投資とリスクは非常に大きくなります。
しかし、データ窃盗にはそのようなリスクはありません。ちょうど逆です-間違った動きをすると（たとえば、技術的な障壁の結果としてバグを導入した場合）、ユーザーを失うことになります。スクレイピングボットが初めて機能しない場合、何も起こりません。データマイナーは別のアプローチを試すか、スクリプトをデバッグします。
この場合、はるかに多くの投資が必要になり、スクレーパーの投資ははるかに少なくなります。
時間とエネルギーを投資したい場所を考えてください...
PS：英語は私のネイティブではありません-私の壊れた英語を許してください...
初心者のスクレイパーに対して機能する可能性のあるもの：
- IPブロッキング
- 多くのajaxを使用する
- リファラー要求ヘッダーを確認する
- ログインが必要
一般的に役立つもの：
- 毎週レイアウトを変更する
- robots.txt
助けになるが、ユーザーを嫌うもの：
- captcha
私は多くのWebスクレイピングを行い、いくつかの Webスクレーパーを止めるテクニック を要約しました。
これは、ユーザーとスクレイパーの間のトレードオフです。 IPを制限したり、CAPTCHAを使用したり、ログインを要求したりすると、スクレイパーにとって困難になります。しかし、これはあなたの本物のユーザーを追い払うかもしれません。
技術的な観点から：一度に多すぎるクエリでヒットした場合のGoogleの動作をモデル化します。それはそれの多くを停止するはずです。
法的観点から：あなたが公開しているデータは所有権がないようです。つまり、著作権で保護されていない名前や統計、その他の情報を公開しています。
この場合、スクレイパーはアーティスト名などの情報を再配布することで著作権を侵害していません。ただし、サイトに著作権のある要素（レイアウトなど）が含まれているため、サイトをメモリに読み込むときに著作権を侵害している可能性があります。
Facebook v。Power.comについて読んで、Facebookがスクリーンスクレイピングを停止するために使用した引数を確認することをお勧めします。誰かがあなたのウェブサイトをスクレイピングするのを阻止しようとすることができる多くの法的方法があります。彼らは広範囲で想像力豊かです。時々、裁判所は議論を買います。時々そうではありません。
ただし、名前や基本的な統計情報のように著作権で保護されていないパブリックドメイン情報を公開していると仮定した場合は、言論の自由やオープンデータの名前でそれを許可する必要があります。それは、ウェブのすべてについてのことです。
残念ながら、かなり手作業です。IPアドレスをスクレイピングして禁止していると思われるトラフィックパターンを探してください。
あなたは公開サイトについて話しているので、サイト検索エンジンをフレンドリーにすることは、サイトをスクレイピングしやすくします。検索エンジンがサイトをクロールしてスクレイピングできる場合、悪意のあるスクレーパーも同様にクロールできます。歩いて行けます。
確かにそれは可能です。 100％成功するには、サイトをオフラインにしてください。
実際には、someを実行して、スクレイピングを少し難しくすることができます。 Googleはブラウザのチェックを行って、検索結果をスクレイピングするロボットではないことを確認します（ただし、これは、他のほとんどすべてと同様に、なりすましが可能です）。
サイトへの最初の接続とその後のクリックの間に数秒を必要とするようなことを行うことができます。理想的な時期がどうなるか、正確にどのように行うかはわかりませんが、それは別のアイデアです。
もっと多くの経験を持っている人は他にも何人かいると思いますが、それらのアイデアが少なくともいくらか役立つことを願っています。
- いいえ、停止することはできません（とにかく）
- それを受け入れます。 RDFaとして公開し、スーパー検索エンジンに対応し、データの再利用を促進してみませんか？人々はあなたに感謝し、いつでもクレジットを提供します（例としてmusicbrainzを参照してください）。
それはおそらくあなたが望む答えではありませんが、なぜあなたが公開しようとしているものを隠すのですか？
画面のスクレイピングを防止するためにできることはいくつかあります。いくつかはあまり効果的ではありませんが、他のもの（CAPTCHA）は効果的ですが、使いやすさを妨げます。検索エンジンのインデックスなど、正当なサイトスクレイパーを妨げる可能性があることにも留意する必要があります。
ただし、スクレイプしたくない場合は、検索エンジンでもインデックスを作成しないようにする必要があります。
あなたが試すことができるいくつかの事柄はここにあります：
- 画像にテキストを表示します。これは非常に信頼性が高く、CAPTCHAほどユーザーの苦痛はありませんが、カットアンドペーストができず、きれいに拡大したりアクセスしたりすることができません。
- CAPTCHAを使用し、ページを返す前に完了する必要があります。これは信頼できる方法ですが、ユーザーに課せられる最大の苦痛でもあります。
- ページを表示する前にユーザーにアカウントへのサインアップを要求し、メールアドレスを確認します。これは非常に効果的ですが、完全ではありません-スクリーンスクレーパーがアカウントを設定し、スクリプトを巧みにプログラムしてログインします。
- クライアントのユーザーエージェント文字列が空の場合、アクセスをブロックします。多くの場合、サイトスクレイピングスクリプトは遅延プログラムされ、ユーザーエージェント文字列は設定されませんが、すべてのWebブラウザーは設定されます。
- 既知のスクリーンスクレーパーユーザーエージェント文字列のブラックリストを発見したときに設定できます。繰り返しますが、これは遅延コード化されたもののみを助けます。自分が何をしているかを知っているプログラマーは、ユーザーエージェント文字列を設定してWebブラウザーになりすますことができます。
- URLパスを頻繁に変更します。変更するときは、1人のユーザーがブラウザを開いている可能性が高い場合にのみ、古いユーザーが動作していることを確認してください。新しいURLパスがどうなるかを予測しにくくします。これにより、URLがハードコードされている場合、スクリプトがそれを取得するのが難しくなります。何らかのスクリプトを使用してこれを行うのが最善です。
これをしなければならなかった場合、正当なユーザーへの不便を最小限に抑えるため、おそらく最後の3つの組み合わせを使用するでしょう。ただし、この方法ですべてのユーザーをブロックすることはできないことを受け入れる必要があり、誰かがそれを回避する方法を見つけたら、彼らはそれを永久にスクレイプできるようになります。その後、IPアドレスをブロックしようとする可能性があります。
方法1（小規模サイトのみ）：
暗号化/エンコードされたデータを提供します。
python（urllib、requests、beautifulSoupなど）を使用してWebをスケープし、暗号化/エンコードされたデータを提供する多くのWebサイトを見つけました。暗号化方式が存在しません。
PHP Webサイトで出力を暗号化して最小化することでこれを達成しました（警告：これは大規模なサイトにはお勧めできません）応答は常にごちゃごちゃしたコンテンツでした。
PHPの出力を最小化する例（ PHPページのHTML出力を最小化する方法？ ）：
<?php
function sanitize_output($buffer) {
$search = array(
'/\>[^\S ]+/s', // strip whitespaces after tags, except space
'/[^\S ]+\</s', // strip whitespaces before tags, except space
'/(\s)+/s' // shorten multiple whitespace sequences
);
$replace = array('>', '<', '\\1');
$buffer = preg_replace($search, $replace, $buffer);
return $buffer;
}
ob_start("sanitize_output");
?>
方法2：
それらを止めることができない場合、それらをねじ込み、応答として偽の/役に立たないデータを提供します。
方法3：
一般的なスクレイピングユーザーエージェントをブロックします。ユーザーエージェントとして「python3.4」を使用してスクレイピングすることは不可能であるため、これは主要/大規模Webサイトで表示されます。
方法4：
すべてのユーザーヘッダーが有効であることを確認してください。スクレーパーが本物のユーザーのように見えるように、可能な限り多くのヘッダーを提供することがあります。
これは、私がよく提供するヘッダーのリストです。
headers = {
"Requested-URI": "/example",
"Request-Method": "GET",
"Remote-IP-Address": "656.787.909.121",
"Remote-IP-Port": "69696",
"Protocol-version": "HTTP/1.1",
"Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8",
"Accept-Encoding": "gzip,deflate",
"Accept-Language": "en-FU,en;q=0.8",
"Cache-Control": "max-age=0",
"Connection": "keep-alive",
"Dnt": "1",
"Host": "http://example.com",
"Referer": "http://example.com",
"Upgrade-Insecure-Requests": "1",
"User-Agent": "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.111 Safari/537.36"
}
ボットをブラックリストに登録するのではなく、ホワイトリストに登録する必要があります。上位2、3のエンジンの検索結果を削除したくない場合は、一般的に広く公開されているユーザーエージェント文字列をホワイトリストに登録できます。あまり倫理的でないボットは、人気のあるWebブラウザーのユーザーエージェント文字列を偽造する傾向があります。上位のいくつかの検索エンジンは、トラフィックの95％を上回っています。
他のポスターが提案した手法を使用して、ボット自体を識別することはかなり簡単です。
これへの迅速なアプローチは、ブービー/ボットトラップを設定することです。
一定の回数開いた場合、またはまったく開いた場合でも、IPやその他の情報などの特定の情報を収集するページを作成します（不規則性やパターンも考慮することができますが、このページを開く必要はまったくありません）。
CSS display：noneで非表示になっているページへのリンクを作成します。または左：-9999px; positon：absolute;ボットはページの特定の部分を忘れてしまうことがあるため、フッターではなくコンテンツが該当する場所など、無視される可能性が低い場所に配置してください。
Robots.txtファイルで、友好的なボット（LOL、幸せそうな顔をしているような！）に情報を収集させたくないページに不許可ルールを設定し、このページをそれらの1つとして設定します。
フレンドリーなボットが登場した場合、そのページを無視する必要があります。そうですが、それでもまだ十分ではありません。これらのページをさらに2つ作成するか、異なる名前を受け入れるように何らかの方法でページを再ルーティングします。そして、無視したいページと一緒にrobots.txtファイルのこれらのトラップページにより多くの不許可ルールを配置します。
これらのボットまたはこれらのページにアクセスする人のIPを収集し、それらを禁止せず、乱数、著作権表示、特定のテキスト文字列などの麺の入ったテキストを表示する機能を作成します。良いコンテンツ。ロードするのに永遠にかかるページを指すリンクを設定することもできます。 PHPでは、sleep（）関数を使用できます。一度にX個のリンクを処理するように書かれたボットが設定されているため、ロードに時間がかかりすぎるページをバイパスする何らかの検出がある場合、これによりクローラーが反撃されます。
特定のテキスト文字列/文を作成した場合、お気に入りの検索エンジンに移動して検索してみてください。コンテンツがどこにあるのかがわかります。
とにかく、戦術的かつ創造的に考えるなら、これは良い出発点かもしれません。最善の方法は、ボットの仕組みを学ぶことです。
また、いくつかのIDを詐欺したり、ページ要素の属性が表示される方法を考えたりします。
<a class="someclass" href="../xyz/abc" rel="nofollow" title="sometitle">
一部のボットはページまたはターゲット要素の特定のパターンを検索するように設定されている可能性があるため、その形式は毎回変更されます。
<a title="sometitle" href="../xyz/abc" rel="nofollow" class="someclass">
id="p-12802" > id="p-00392"
上記のほとんどの投稿に同意します。また、サイトが検索エンジンに優しいほど、サイトがスクレイプ可能になることを付け加えます。スクレイパーにとって難しくなる非常にいくつかのことを試してみることもできますが、それは検索能力にも影響を与える可能性があります。
ほとんどはすでに言われていますが、CloudFlareの保護を検討しましたか？私はこれを意味します：
他の企業もおそらくこれを行っています。CloudFlareは私が知っている唯一の会社です。
それは彼らの仕事を複雑にするだろうと確信しています。また、レート制限のためにCloudFlareで保護されたサイトのデータを破棄しようとしたときに、4か月間IPが自動的に禁止されたことがあります（単純なAJAX要求ループを使用しました）。
通常の画面スクレイピングを停止することはできません。良くも悪くも、それはウェブの性質です。
登録済みユーザーとしてログインしない限り、特定のもの（音楽ファイルを含む）に誰もアクセスできないようにcanできます。それほど難しくありません Apacheで行うには 。 IISで行うのもそれほど難しくないと思います。
1つの方法は、コンテンツをXML属性、URLエンコードされた文字列、HTMLエンコードされたJSONでフォーマットされたテキスト、またはデータURIとして提供し、クライアント上でHTMLに変換することです。これを行うサイトは次のとおりです。
Skechers ：XML
<document filename="" height="" width="" title="SKECHERS" linkType="" linkUrl="" imageMap="" href="http://www.bobsfromskechers.com" alt="BOBS from Skechers" title="BOBS from Skechers" />Chromeウェブストア ：JSON
<script type="text/javascript" src="https://apis.google.com/js/plusone.js">{"lang": "en", "parsetags": "explicit"}</script>Bing News ：データURL
<script type="text/javascript"> //<![CDATA[ (function() { var x;x=_ge('emb7'); if(x) { x.src='data:image/jpeg;base64,/*...*/'; } }() )Protopage ：URLエンコードされた文字列
unescape('Rolling%20Stone%20%3a%20Rock%20and%20Roll%20Daily')TiddlyWiki ：HTMLエンティティ+事前にフォーマットされたJSON
<pre> {"tiddlers": { "GettingStarted": { "title": "GettingStarted", "text": "Welcome to TiddlyWiki, } } } </pre>Amazon ：遅延読み込み
amzn.copilot.jQuery=i;amzn.copilot.jQuery(document).ready(function(){d(b);f(c,function() {amzn.copilot.setup({serviceEndPoint:h.vipUrl,isContinuedSession:true})})})},f=function(i,h){var j=document.createElement("script");j.type="text/javascript";j.src=i;j.async=true;j.onload=h;a.appendChild(j)},d=function(h){var i=document.createElement("link");i.type="text/css";i.rel="stylesheet";i.href=h;a.appendChild(i)}})(); amzn.copilot.checkCoPilotSession({jsUrl : 'http://z-ecx.images-Amazon.com/images/G/01/browser-scripts/cs-copilot-customer-js/cs-copilot-customer-js-min-1875890922._V1_.js', cssUrl : 'http://z-ecx.images-Amazon.com/images/G/01/browser-scripts/cs-copilot-customer-css/cs-copilot-customer-css-min-2367001420._V1_.css', vipUrl : 'https://copilot.Amazon.com'XMLCalabash ：名前空間付きXML +カスタムMIMEタイプ+カスタムファイル拡張子
<p:declare-step type="pxp:Zip"> <p:input port="source" sequence="true" primary="true"/> <p:input port="manifest"/> <p:output port="result"/> <p:option name="href" required="true" cx:type="xsd:anyURI"/> <p:option name="compression-method" cx:type="stored|deflated"/> <p:option name="compression-level" cx:type="smallest|fastest|default|huffman|none"/> <p:option name="command" select="'update'" cx:type="update|freshen|create|delete"/> </p:declare-step>
上記のいずれかでソースを表示すると、スクレイピングは単にメタデータとナビゲーションを返すことがわかります。
スクリーンスクレイパーは、HTMLを処理することで機能します。そして、彼らがあなたのデータを取得しようと決心している場合、人間の眼球が何かを処理するため、技術的にできることはあまりありません。法的には既にいくつかの手段があるかもしれないと指摘されていますが、それが私の推奨事項です。
ただし、非HTMLベースのプレゼンテーションロジックを使用して、データの重要な部分を隠すことができます。
- アーティスト/アルバムなどごとに Flash ファイルを生成します。
- アーティストコンテンツごとに画像を生成します。たぶん、アーティスト名などの画像だけで十分でしょう。これを行うには、テキストをサーバー上の JPEG / PNG ファイルにレンダリングし、その画像にリンクします。
これはおそらく検索ランキングに影響することを覚えておいてください。
HTML、CSS、およびJavaScriptを生成します。パーサーよりジェネレーターを作成する方が簡単なので、提供される各ページを別々に生成できます。その場合、キャッシュまたは静的コンテンツを使用できなくなります。
素晴らしい例をご覧になりたい場合は、 http://www.bkstr.com/ をご覧ください。彼らはj/sアルゴリズムを使用してCookieを設定し、ページをリロードして、Cookieを使用してリクエストがブラウザー内で実行されていることを検証できるようにします。スクレイピング用に構築されたデスクトップアプリはこれで間違いなく取得できますが、ほとんどのcURLタイプのスクレイピングは停止します。
コンテンツをキャプチャの背後に置くことは、ロボットがコンテンツにアクセスするのを難しくすることを意味します。ただし、人間にとっては不便であるため、望ましくない場合があります。