在当今快节奏且信息快速过时的情况下，索引速度是成功的关键因素之一。
但为什么 Discource 完全不支持此协议？https://www.indexnow.org/
3 个赞
因为没有人足够关心去构建一个插件或拉取请求来支持它。我想这可能是因为谷歌不支持 IndexNow，而 IndexNow 是大多数人关心的搜索引擎。
但如果你想构建一个插件来添加这个功能，我们非常欢迎！
14 个赞
我想为社区做出贡献并编写此扩展，但我们不是程序员。
Google 对 IndexNow 的态度是他们正在测试它，我们拭目以待。
关于 Index Now 有什么消息吗？现在就连 OpenAI 都运行了一个从 Bing 索引中提取信息并与 IndexNow 相关联的搜索引擎，这似乎更有意义了。
那么您可以在 Marketplace 委托开发插件。我能想到 500 美元到 2000 美元的解决方案。其他人可能比我更有想象力。
3 个赞
我同意，现在似乎是 Discourse 支持 IndexNow 的绝佳时机 :))
1 个赞
在审查了 IndexNow 功能后，我同意这应该是核心功能/插件之一。我也明白开发资源有限。
以下是我对协助核心团队所需的插件的看法。请随时添加其他评论。
假设：
- IndexNow 插件将使用计划时间模型的批量通知 - 请参阅设计注意事项 #1
- 批量通知将按时间间隔设置
- 通知将仅使用公共主题
- 启用插件后，通知将仅针对新/已更改/已删除的主题。
- 插件不会追溯通知历史更改/事件。
用户说明：
- 在您选择的 IndexNow 搜索引擎上注册。
- 获取您的 API 密钥
- 获取搜索引擎端点 URL
- 安装插件
- 设置管理员
用例 - 管理员设置
- 允许用户打开/关闭自动提交功能
- 允许用户输入 IndexNow 搜索引擎端点。请参阅设计注意事项 #3。
- 输入字段为文本参数
- 输入字段必须是有效 URL
- 默认为 Bing URL
https://www.bing.com/indexnow
- 允许用户输入并存储 API 密钥
- 用于存储 API 密钥的输入字符串字段
- 输入字段为字母数字
- 默认值为“”
- 允许用户为批量通知定义计划时间参数
- 时间参数将按小时间隔设置
- 用于存储小时值的输入字符串
- 有效输入将是整数
- 有效输入范围可以从 1 到 24
- 默认值为 12
用例 - 文本密钥文件
- 系统将生成一个名为 indexnowkey.txt 的文件
- 密钥文件必须存储在根目录下。
- 系统将用 API 密钥填充文件
- 任何远程用户/系统都可以通过 http/https 访问该文件
用例 - 批量通知流程调度
- 系统将根据管理员设置中定义的设置按间隔安排作业进行处理。
- 间隔值定义作业之间的小时延迟。例如，输入值为 2 表示作业应每 2 小时运行一次。值为 4 表示作业应每 4 小时运行一次。值为 24 表示作业应每天运行一次。
用例 - 批量通知流程
- 系统将通过管理员设置中定义的站点设置确定通知流程是否已激活。
- 系统将确定站点设置中的 API 密钥是否有效 - 不为空。
- 系统将根据定义的间隔设置创建一个主题列表。请参阅设计注意事项 #2 关于查询时间范围。包含的主题参数为：
- 主题必须仅限公开查看
- 新主题
- 有新帖的主题
- 已编辑帖子的主题
- 已删除的主题
- 主题列表必须不重复 - 无重复项
- 系统将使用以下格式创建 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"
]
}
- JSON 数据包将发送到以下位置
- URL：
sitesettings.search_engine_indexnow_endpoint
- URL：
- JSON 数据包将使用以下标头发送
- Content-Type: application/json; charset=utf-8
- Http/1.1
- Host: bing
- 验证 HTTP 请求的提交收据
- http 200 - 提交成功 - 结束流程
- Http 429 - 提交尝试次数过多 - 向管理员发送通知以增加间隔时间
设计注意事项：
- 批量通知与单次通知 — 单次通知对于小型域来说是可以接受的，但对于大型论坛来说，为每个新/更新的帖子添加通知可能会产生许多事件流程。从搜索引擎索引性能的角度来看，每小时一次的批量通知对于 80% 的论坛来说是可以接受的。
- 批量通知查询时间 — SideKiq 控制间隔时间。如果 SideKiq 处于繁重处理状态，批量通知流程可能会延迟。如果查询时间范围等于调度间隔，批量通知流程可能会错过新/更新的主题。时间参数是否应扩展查询以涵盖延迟的流程？或者是否可以将调度程序传递已启动的时间戳以控制查询时间间隔？或者我们需要为已提交的主题创建数据库表/值（带时间戳）？
- 我们是否应该构建一个包含每个搜索引擎和定义的 IndexNow URL 端点的内部表？用户可以从下拉菜单中选择选项，而不是输入 URL。这消除了潜在的人为错误。
缺少什么？您会添加什么？
我们能否利用现有的传出 webhook 支持来实现您想要的部分或全部功能？
1 个赞
这似乎是一个相当不错的纲要。我认为我只会进行批量/批次提交，以避免两种编写、调试、测试和维护的方法。
或者，一个单一的批量/批次作业可以避免速率限制问题，然后只有一种提交内容的方式（仅以批次形式，从不以单个帖子形式）。
一个提交到单个端点的版本，如果看起来可行且错误处理最少，可能需要 2000 美元，如果至少有一些用于测试的规格，则需要 5000 美元；并且可能能够处理通知多个端点？
您提出了一个很棒的“如何”问题。我不是回答 Discourse“如何”问题的最佳人选。
我擅长记录“需要什么”。获得对“需要什么”的良好、清晰的定义将使编码更快，从而更便宜。
为了回答关于 webhook 的“需要什么”，我认为它指的是单次通知与批量通知。我有一个中等规模的论坛，我更喜欢批量通知。
- 我不需要搜索引擎在主题创建或更新时得到通知。
- 我不喜欢在主题和帖子创建等关键流程中添加低优先级事件。添加额外事件会增加用户的等待时间。批量方法只需要一次 SQL 查询和一次 HTTP 发送。它可以作为用户交互之外的后端事件进行处理。
该插件只需要为一个端点开发。IndexNow协议要求搜索引擎之间共享提交。也就是说，您提交给必应，然后必应会提交给其他符合IndexNow的搜索引擎。
我们需要30名成员每人众筹100美元来开发该插件。
1 个赞