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

特徴
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 を入力する代わりにドロップダウン メニューから選択できます。これにより、人的エラーが排除されます。

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