サイトにいくつかのクローラーがいます。コンテンツにアクセスされるリスクはありますか？
ブロック手順を実行する前に、「許容できるクローラーの負荷/リスク」はどの程度ですか？私はほとんど、あるいは全く専門知識がありません。
それらは公開サイトしかクロールできないため、セキュリティ侵害はありません。しかし、はい、公開コンテンツにはアクセスできます。
「いいね！」 2
負荷が高すぎると悪影響があり、CPUやRAMを増設する必要があります。Discourseでそれがどれほど簡単に起こりうるかはわかりませんが、PHPベースのWordPressは簡単にダウンさせることができます。しかし、Discourseはボットに対して静的で軽量なコンテンツを提供しており、人間とボットを区別できます。ボットが非常に偽のユーザーエージェントを提供した場合、何を得られるでしょうか…たくさんのJSONテキストでしょうか？
ボットがログインや信頼レベルの障壁などを突破した場合、チームはパニックモードになり、すぐにすべての手を動かす必要があると推測します😜
また、管理設定から簡単にクローラーをブロックできることにも注意してください。
どうすれば…か教えていただけると大変助かります。
「いいね！」 1
それがrobots.txtの編集だけではないことを願っています。なぜなら、それは良い振る舞いをするものにしか効果がないからです。実際には、効果的ですが少し難しい解決策が1つだけあります。それはリバースプロキシです。
そのアプローチは効果的です。私たちはそれ自体を使用しており、ホスティングをご利用のお客様にもお勧めしています。
Discourseがフィルタリングを使用していることを読むべきですか？
何をお尋ねになりたいのか分かりません。デフォルトでは何もブロックしませんが、管理者が選択的にブロックできるツールを提供します。
ボットは a) robots.txt を読み、b) ルールに従うと信頼しているのですね。しかし、悪質なボットはどちらも実行しません。そして、私たちは元の場所に戻りました。ボットが何らかの問題を引き起こす場合、リバースプロキシが最善の解決策です。
ありがとうございます。それを知りたかったです。
なるほど、言いたいことは分かります。すべてのボットがクローラーとして自己識別したり、ルールに従ったりすると仮定しているわけではありません。確かに、これは正確な科学ではありません。私は単にOP（元の投稿者）への最初の緩和策を提案していただけです。
現在、トラフィックをより具体的に制限する方法に取り組んでいますが、簡単な作業ではありません。
「いいね！」 1
Discourseホストサイトのクローラー数がDigital Oceanサーバーサイトよりも大幅に少ないことに気づきました。どちらもデフォルトの管理者設定です。
ホストサイトは通常、1日あたり10未満のクローラーで、平均約4です。最近の1月の最終日には77クローラーというスパイクがありました。
ほとんどアクティビティのないDigital Oceanサイトは、1日あたり平均約30クローラーですが、サーバーの種類やドメインによってクローラーが多くなる理由がわかる方はいらっしゃいますか？
これらは一般的に、検索エンジンがそれらを見つけられるように、公開サイトやコンテンツを検索/インデックス化しています。これは、より広いオーディエンスにリーチしたいサイトにとっては良いことです。人々は、Discourseサイトで話題になっているものを検索した場合、あなたのサイトを見つけることができます。
クローラーには他の目的があるかもしれませんが、それらが何のためにあるのかすべてはわかりません。これらは、おそらくすでに知っているように、設定でデフォルトでアクセスが拒否されています。
比較的コンピューターに疎い私ですが、あなたのクローラーに関する専門的な意見を、まるで全米オープン決勝戦を観戦するハンディキャップを持つ観客のようにフォローしてきました…このサイトセキュリティの不可解な部分を紹介してくれてありがとう。
Discourseによって非常に効率的にホストされている私たちのフォーラムは、非常に機密性の高いものです。招待制で参加するユーザーは機密性について非常に神経質になっており、私はできる限り安心させようとしています。クローラーはそれほど有害ではないかもしれませんが（？！）、もし可能であれば完全に排除したいと思っています。私たちのコンテンツがインデックス化されたり、何らかの方法で知られたりすることに関心がないため、それらは私たちにとって何の役にも立ちません。
設定の最適化が最初に行うべきことだと今気づきました。Commitechサポートグループの誰かにこの点で私の設定を調べてもらうことは可能ですか？
ご配慮ありがとうございます。
「いいね！」 1
それは良いことですね。Redisに頼って最近レンダリングされたコンテンツをより速く提供するだけだと思っていました。あなたが言及したように、私のフォーラムがDrupalで実行されていたとき、悪質なボットや検索エンジンのクローラーさえも時々ダウンさせていました。しかし、匿名でアクセスされたページの静的HTMLファイルキャッシュを作成し、それらのためのNginxリライトルールを自動的に作成するプラグインをインストールしました。NginxはDrupalのPHPコードをブートストラップせずにそれらを提供し、それは非常に高速で、はるかに多くの匿名トラフィック負荷を処理できました。
「いいね！」 1
こんにちは。これはセキュリティ上の問題には全く影響しないということを認識しておくことが非常に重要です。クローラーは公開サイトにしかアクセスできません。ログインが必要なサイトであれば、それらにアクセスすることはできません。
もう1つの明確化は、Communiteqは当社とは一切関係がないため、もし彼らがあなたのホストである場合、あなたはDiscourseによってホストされているわけではないということです。 
「いいね！」 2
プライベートで返信しようと思っていましたが、他の人にも役立つかもしれないので、ここに投稿します。
それらはあなたのホームページ（ログイン）ページにのみアクセスしており、コンテンツにアクセスすることはできません。
有害な場合があります。クローラーの種類によっては、公開したくない情報がアクセス可能になっている可能性があります。技術的には、クローラーは公開情報にしかアクセスできませんが、クローラー（および関連する検索エンジン）は情報を発見し、アクセス可能にするのが非常に得意です。
それでは、あなたの状況を見てみましょう。
あなたの robots.txt は次のように表示されています
User-agent: *
Disallow: /
したがって、すべての検索エンジンのクローラーを拒否するように設定されています。 
しかし、これだけでは十分ではありません。robots.txt は礼儀に基づいていますが、「悪意のある」ロボットには尊重されません。悪意のあるロボットは robots.txt を無視することを選択できます。これは「立ち入り禁止！」の標識のようなもので、泥棒はそれを尊重しません。
あなたのフォーラムの主なセキュリティは、ログイン必須が有効になっているという事実に依存しています。これで、どのクローラーも締め出すのに十分です。
クローラーが侵入できないことはすでに確認しましたが、さらに一歩進めるのが良いかもしれません。
また、招待制と新規登録を許可が有効になっており、招待を許可するグループはTL2に設定されています。これは、任意の人がサインアップできるわけではありませんが、TL2以上のユーザーであれば他のユーザーをコミュニティに招待できることを意味します。セーフティネットとして、ユーザーの承認が必要を有効にしているので、それは良いことです。あなたのコミュニティにアクセスする唯一の方法は、すでにコミュニティの信頼できるメンバーである誰かから招待を受け、かつ管理者があなたを入れることです。
「いいね！」 4