2025 年 3 月 28 日，星期五
在之前有關漫遊器排除通訊協定 (REP) 的文章中，我們介紹了可以透過這項協定各種元件 (也就是 robots.txt 和 URI 層級控制項) 執行的作業。本文將探討 REP 如何在自動化用戶端和人類網路之間不斷演變的關係中發揮重要的作用。
REP (特別是 robots.txt) 已於 2022 年成為標準，稱為 RFC9309。不過，在標準化之前，我們已完成所有繁雜的作業：在 1994 年至 2022 年間，我們不斷進行測試，讓這項技術普及到足以被數十億部主機和幾乎所有主要檢索器營運者 (不包括惡意軟體掃描器等對抗性檢索器) 採用。這是一種直截了當、巧妙的解決方案，可透過簡單且功能多元的語法表達偏好設定。REP 問世 25 年，其原始形式幾乎完全沒有任何演進，如果只考量檢索器普遍支援的規則，就只有 allow 規則。
但這並不代表 REP 沒有其他規則，任何檢索器營運者都可以自行制定規則。舉例來說，「clean-param」和「crawl-delay」這類規則並非 RFC9309 的一部分，但部分搜尋引擎 (不是 Google 搜尋) 支援這類規則。所有主要搜尋引擎都支援「sitemap」規則，但這同樣並非 RFC9309 的一部分。如果獲得足夠的支持，這項規則就可能成為 REP 的正式規則。
因為 REP 實際上可以取得「更新」。這是廣受支援的通訊協定，應該會隨著網際網路的發展而成長。變更 REP 並非不可能，但並不容易；由於 REP 廣受支援，因此不應輕易變更。如同對任何標準進行變更一樣，都必須達成共識，確保變更對大多數的通訊協定使用者都有益，包括發布商和檢索器營運者。
由於 REP 簡潔明瞭且廣泛採用，因此是執行新檢索偏好設定的絕佳選擇。舉例而言，數十億個發布商都已熟悉 robots.txt 及其語法，因此變更 REP 就更為自然。另一方面，檢索器營運者已擁有可靠且經過充分測試的剖析器和比對器 (Google 也將 robots.txt 剖析器的原始碼設為開源)，因此新規則不太可能發生剖析問題。
REP URI 層級擴充功能、X-robots-tag HTTP 標頭及其對應的中繼標記也是如此。如果需要新規則來執行停用偏好設定，很容易就可以擴充這些規則。但要如何做到？
讀者最重要的工作，就是公開討論自己的想法，並爭取獲得支持。由於 REP 是公開標準，因此任何實體都無法單方面進行變更；當然，他們可以為自家的新產品導入支援功能，但這不會成為標準。不過，透過討論這項變更，並且向生態系統 - 包括檢索器營運者和發布生態系統 - 展示這項變更對所有人都有益，就能取得共識，進而為更新標準做好準備。
同樣地，如果通訊協定缺少某些內容，請公開討論。sitemap 成為 robots.txt 中廣受支援的規則，因為此規則對內容創作者和搜尋引擎而言很實用，可以為擴充功能採用做好準備。如果對規則有新的想法，請詢問 robots.txt 使用者和建立者有何看法，並與對方合作解決他們提出的潛在 (和可能的) 問題，並撰寫提案。
如果您的動力是為了服務公共利益，那麼一切就值得了。