なぜDiscourseはIndexNowをサポートしていないのですか？

特徴
1

今日のペースが速く、急速に時代遅れになる情報において、インデックス作成速度は成功のための最も重要な要因の1つです。

しかし、なぜDiscourceはこのプロトコルをまったくサポートしないのでしょうか？ https://www.indexnow.org/

「いいね！」 3
2

なぜなら、それをサポートするためのプラグインやプルリクエストを作成するほど気にかけている人がいなかったからです。そして、おそらくそれは、GoogleがIndexNowをサポートしていないという事実によって引き起こされていると言えるでしょう。IndexNowは、ほとんどの人が気にかけている検索エンジンです。

しかし、この機能を追加するためのプラグインを作成したいのであれば、それは歓迎される貢献です！

「いいね！」 14
3

コミュニティに貢献してこの拡張機能をプログラムしたいのですが、私たちはプログラマーではありません。

GoogleのIndexNowに対する態度は、テスト中で、様子を見るとのことです。

4

Index Nowに関するニュースはありますか？OpenAIがBingインデックスからデータを取得し、IndexNowにリンクされている検索エンジンを運用していることを考えると、さらに理にかなっています。

5

それなら、Marketplace でプラグインを依頼することができます。500ドルから2000ドルの範囲で解決策を想像できます。私よりも優れた想像力を持つ人もいるかもしれません。

「いいね！」 3
11

同意します。今こそDiscourseがIndexNowをサポートする絶好の機会です :))

「いいね！」 1
12

IndexNow の機能をレビューした結果、これがコア機能/プラグインの 1 つであるべきだと考えます。開発リソースが限られていることも理解しています。

コアチームを支援するために必要なプラグインに関する私の考えを以下に示します。追加のコメントがあれば、お気軽にお寄せください。

前提条件:

  1. IndexNow プラグインは、スケジュールされた時間モデルでバルク通知を使用します - 設計上の考慮事項 #1 を参照してください。
  2. バルク通知は時間間隔で設定されます。
  3. 通知は公開トピックのみを使用します。
  4. プラグインが有効な場合、通知は新規/変更/削除されたトピックのみを対象とします。
  5. プラグインは、過去の変更/イベントを遡って通知しません。

ユーザー向け指示:

  1. 希望する IndexNow 検索エンジンにサインアップします。
    • API キーを取得します。
    • 検索エンジン エンドポイント URL を取得します。
  2. プラグインをインストールします。
  3. 管理者をセットアップします。

ユースケース - 管理者設定:

  1. ユーザーが自動送信機能をオン/オフできるようにします。
  2. ユーザーが IndexNow 検索エンジン エンドポイントを入力できるようにします。設計上の考慮事項 #3 を参照してください。
    • 入力フィールドはテキスト パラメータです。
    • 入力フィールドは有効な URL である必要があります。
    • Bing の URL https://www.bing.com/indexnow をデフォルトにします。
  3. ユーザーが API キーを入力して保存できるようにします。
    • API キーを格納するための入力文字列フィールド。
    • 入力フィールドは英数字です。
    • デフォルト値は “” です。
  4. ユーザーがバルク通知のスケジュール時間パラメータを定義できるようにします。
    • 時間パラメータは間隔時間で設定されます。
    • 時間値を格納するための入力文字列。
    • 有効な入力は整数です。
    • 有効な入力は 1 から 24 までです。
    • デフォルト値は 12 です。

ユースケース - テキストキーファイル:

  1. システムは indexnowkey.txt という名前のファイルを生成します。
  2. キーファイルはルート レベルに格納する必要があります。
  3. システムはファイルを API キーで populat します。
  4. ファイルは、任意のリモート ユーザー/システムから http/https 経由でアクセス可能になります。

ユースケース - バルク通知プロセスのスケジュール:

  1. システムは、管理者設定で定義された設定に基づいて、間隔でジョブを処理するようにスケジュールします。
  2. 間隔値は、ジョブ間の遅延を時間単位で定義します。たとえば、入力値が 2 の場合、ジョブは 2 時間ごとに実行されます。値が 4 の場合は 4 時間ごと、値が 24 の場合は 1 日に 1 回実行されます。

ユースケース - バルク通知プロセス:

  1. システムは、管理者設定で定義されたサイト設定を通じて通知プロセスがアクティブ化されているかどうかを判断します。
  2. システムは、サイト設定の API キーが有効かどうかを判断します ( “” ではない)。
  3. システムは、定義された時間間隔設定に基づいてトピックのリストを作成します。設計上の考慮事項 #2 のクエリ時間枠を参照してください。含めるトピック パラメータは次のとおりです。
    • トピックは公開表示のみである必要があります。
    • 新規トピック
    • 新しい投稿があるトピック
    • 編集された投稿があるトピック
    • 削除されたトピック
    • トピックリストは一意である必要があります - 重複はありません。
  4. システムは、次の形式を使用して JSON パケットを作成します。
{
  "host": "current_site",
  "key": "api_key",
  "keyLocation": "https://current_site/indexnowkey.txt",
  "urlList": [
      "https://www.example.com/url1",
      "https://www.example.com/folder/url2",
      "https://www.example.com/url3"
      ]
}
  1. JSON パケットは以下に送信されます。
    • URL: sitesettings.search_engine_indexnow_endpoint
  2. JSON パケットは次のヘッダーと共に送信されます。
    • Content-Type: application/json; charset=utf-8
    • Http/1.1
    • Host: bing
  3. HTTP リクエストの送信レシートを検証します。
    • http 200 - 送信成功 - プロセス終了
    • Http 429 - 送信試行が多すぎます - 管理者に間隔時間を増やすよう通知を送信します。

設計上の考慮事項:

  1. バルク通知 vs. 単一通知—単一通知は小規模ドメインでは許容されますが、大規模なボードでは、すべての新規/更新された投稿に通知を追加すると、多くのイベントプロセスが発生する可能性があります。検索エンジンのインデックス作成パフォーマンスの観点からは、時間ごとのバルク通知は、フォーラムの 80% で許容範囲内です。
  2. バルク通知のクエリタイミング - SideKiq が間隔タイミングを制御します。SideKiq が重いプロセス状態にある場合、バルク通知プロセスが遅延する可能性があります。クエリ時間枠がスケジュール間隔と等しい場合、バルク通知プロセスは新規/更新されたトピックを見逃す可能性があります。時間パラメータは、遅延プロセスをカバーするために拡張する必要がありますか? または、スケジューラが初期化されたタイムスタンプを渡してクエリ時間間隔を制御することは可能ですか? または、タイムスタンプ付きの送信済みトピックのデータベース テーブル/値を作成する必要がありますか?
  3. 各検索エンジンと定義された IndexNow URL エンドポイントを持つ内部テーブルを構築する必要がありますか? ユーザーは URL を入力する代わりにドロップダウン メニューから選択できます。これにより、人的エラーが排除されます。

何が欠けていますか？ 何を追加しますか？

13

既存のアウトバウンド Webhook サポートを活用して、ご希望のすべてまたは一部を実現する方法はありますか？

「いいね！」 1
14

それはかなりまともなアウトラインのように思えます。書き込み、デバッグ、テスト、保守の方法を2つ避けるために、バルク/バッチ送信のみを行うと思います。

または、単一のバルク/バッチジョブでレート制限の問題を回避し、送信方法を1つだけ（バッチのみ、投稿ごとではない）にすることもできます。

単一のエンドポイントに送信するバージョンは、機能しているように見え、最小限のエラー処理がある場合は2000ドルから、少なくともいくつかのテストを行うための仕様があり、複数のエンドポイントに通知できる可能性がある場合は5000ドルになる可能性があります。

15

素晴らしい「どのように」という質問をありがとうございます。私はDiscourseの「どのように」という質問に答えるのに最適な人物ではありません。

私は「何が」必要かを文書化するのが得意です。「何が」必要かの良い、明確な定義を得ることで、コーディングがより速く、したがって安価になります。

Webhookの「何が」に答えるために、単一通知と一括通知を参照していると信じています。私は中規模のフォーラムを持っており、一括通知を好みます。

  1. トピックが作成または更新されたときに検索エンジンに通知する必要はありません。
  2. トピックや投稿の作成のような重要なプロセス内に、優先度の低いイベントを追加するのは好きではありません。追加のイベントは、ユーザーの待ち時間を増加させます。一括方法は、1つのSQLクエリとHTTP送信のみを必要とします。これは、ユーザーの操作外のバックエンドイベントとして処理できます。
16

プラグインは1つのエンドポイントに対してのみ開発すればよい。IndexNowの規約では、検索エンジンは送信情報を共有する必要がある。つまり、Bingに送信すれば、Bingが他のIndexNow準拠の検索エンジンに送信する。

プラグインを開発するには、メンバー30人がそれぞれ100ドルをクラウドファンディングする必要がある。

「いいね！」 1