2019 年 7 月 1 日，星期一
25 年來，《漫遊器排除通訊協定》(REP) 已經成為網路最基本且最重要的元件之一。可讓網站擁有者排除自動化用戶端 (例如網路檢索器)，部分或完全禁止存取他們的網站。
1994 年，Martijn Koster (本身就是網站管理員) 自己的網站遭檢索器流量淹沒之後，就建立了初步標準。納入其他網站管理員的意見後，REP 就此誕生，搜尋引擎也予以採用，協助網站擁有者輕鬆管理伺服器資源。
然而，REP 從未成為正式的網際網路標準，這表示開發人員多年來解讀通訊協定的方式稍有不同。自從 REP 推出以來，從未針對現今的特殊案件進行更新。對網站擁有者來說，這會是一大難題，因為模糊不清卻又實際存在的標準，讓人難以正確撰寫規則。
我們希望協助網站擁有者和開發人員在網際網路上打造優質的體驗，而不用擔心如何控制檢索器。我們和通訊協定的原作者、網站管理員和其他搜尋引擎共同合作，記錄了 REP 在現代網路中的使用方式，並提交給網際網路工程任務組 (IETF)。
REP 草稿提案反映了超過 20 年來仰賴 robots.txt 規則的真實情況，Googlebot 和其他主要檢索器，以及大約五億個採用 REP 的網站，都採用 robots.txt 規則。有了這些精細的控制項，發布者就能自行決定自家網站的哪些內容要開放檢索，可以向有興趣的使用者顯示。這不會改變 1994 年建立的規則，而是從基礎上定義 robots.txt 剖析和比對的所有未定義情境，並擴展到現代網路。注意事項：
- 任何以 URI 為基礎的傳輸通訊協定都可以使用 robots.txt。例如，現在已經不再限於 HTTP，也可以用於 FTP 或 CoAP。
- 開發人員至少必須剖析 robots.txt 的前 500 KiB。定義檔案大小上限可確保連線不會開啟過長時間，進而減少伺服器中不必要的負荷。
- 新的快取時間上限是 24 小時或是快取指令值 (如果有的話)，讓網站擁有者能夠隨時靈活更新 robots.txt，而檢索器也不會透過 robots.txt 要求讓網站超載。例如，如果是 HTTP，可以使用 Cache-Control 標頭來決定快取時間。
- 按目前的規定，如果因為伺服器故障而無法存取原本可以存取的 robots.txt 檔案，系統在一段合理期間內，會繼續保持不去檢索已知禁止的網頁。
此外，我們也更新了網際網路草稿中的擴增 Backus-Naur 表單，更妥善地定義 robots.txt 的語法，讓開發人員能夠剖析。
RFC 代表「要求評論」(Request for Comments)，我們也確實希望收到意見：我們已將這份草稿上傳到 IETF，希望能夠獲得關心網際網路基本構成要素的開發人員的意見回饋。我們致力於讓網路創作者能夠掌控要開放多少資訊讓 Googlebot 檢索，進而能夠顯示在 Google 搜尋中，我們必須把這件事做好。
如要留下評論、提出問題甚至只是想打個招呼，都歡迎前往 Twitter 和網站管理員社群與我們聯絡，離線和線上皆可使用。