機器人排除協議（REP）是荷蘭軟體工程師 Martijn Koster 於 1994 年提出的一個標準，幾乎已經成為了網站不希望被搜尋引擎收錄的註釋的事實標準。
（截圖 via VentureBeat）
比如谷歌爬蟲（Googlebot）就會在索引某個網站時掃描 robots.txt 檔案，以確定其應該忽略掉哪些部分。如果根目錄中未包含該檔案，那搜尋引擎就會預設索引（index）全站內容。
值得一提的是，，該檔案不僅可以用於提供直接的爬蟲索引，還可以被用來填充一些關鍵字，以實現“搜尋引擎最佳化”（SEO）。此外，並非所有抓取工具都會嚴格遵從 robots.txt 檔案。
比如幾年前，網際網路檔案光就選擇了為其“時光機”（Wayback Machine）歸檔工具提供支援，另外一些惡意抓取工具也會有意忽略 REP 。
不過需要指出的是，即便 REP 已經成為了預設的實施標準，但它實際上從未成為真正的網際網路標準，正如網際網路工程任務組（IETF - 一家非營利性開放標註組織）所定義的那樣。
為了推動這項轉變，谷歌正在積極參與行動。這家搜尋巨頭表示，當前的 REP 可以被“解釋”，但並不總是涵蓋邊緣化的案例。
作為補充，谷歌提出了更全面的“未定義場景”。比如在執行一次“掃描已知內容”的任務時，爬蟲該如何處理“伺服器出現不可訪問故障”的 robots.txt 檔案、或者有拼寫錯誤的規則？
谷歌在一篇部落格文章中寫到：“對於網站所有者來說，這是一項極具挑戰性的問題。因為模糊的事實標準，讓他們很難恰當地編寫規則”。
我們希望幫助網站所有者和開發者在網際網路上創造出令人驚歎的體驗，而無需擔心如何對抓取工具加以限制。
於是谷歌與 REP 原作者 Martijn Koster、網站管理員、以及其它搜尋引擎合作，向 IETF 提交了一份關於《如何在現代網路上適用 REP》的提案。
該公司尚未公佈該草案的全貌，但卻是提供了一些指引。比如任何基於 URI 的傳輸協議，都可以適用 robots.txt 。且其不再侷限於 HTTP，亦可面向 FTP 或 CoAP 。
據悉，開發者必須至少解析 robots.txt 的前 500 KB 內容。定義檔案的大小，可確保每個連線的開啟時間不會太長，從而減輕不必要的伺服器壓力。
另外，新的最大快取時間被設定為 24 小時（或可用的快取指令值），使得網站所有者能夠隨時靈活地更新他們的 robots.txt，且爬蟲不會因此而讓網站超載。
例如，在 HTTP 的情況下，可使用 Cache-Control 報頭來確定快取時間。而當先前可訪問的 robots.txt 檔案由於伺服器故障而變得不可用時，則會在相當長的時間段內不再檢索該網站。
這裡需要點明的是，抓取工具可以用不同的方式去解析 robots.txt 檔案中的說明，這可能會導致網站所有者的混淆。
為此，谷歌特地推出了 C++ 庫，其支援 Googlebot 在 GitHub 上給出的解析和匹配系統，以供任何人訪問。
根據 GitHub 上的釋出說明，Google 希望開發者構建自己的解析器，以更好地反映 Google 的 robots.txt 檔案的解析和匹配。
機器人排除協議（REP）是荷蘭軟體工程師 Martijn Koster 於 1994 年提出的一個標準，幾乎已經成為了網站不希望被搜尋引擎收錄的註釋的事實標準。
（截圖 via VentureBeat）
比如谷歌爬蟲（Googlebot）就會在索引某個網站時掃描 robots.txt 檔案，以確定其應該忽略掉哪些部分。如果根目錄中未包含該檔案，那搜尋引擎就會預設索引（index）全站內容。
值得一提的是，，該檔案不僅可以用於提供直接的爬蟲索引，還可以被用來填充一些關鍵字，以實現“搜尋引擎最佳化”（SEO）。此外，並非所有抓取工具都會嚴格遵從 robots.txt 檔案。
比如幾年前，網際網路檔案光就選擇了為其“時光機”（Wayback Machine）歸檔工具提供支援，另外一些惡意抓取工具也會有意忽略 REP 。
不過需要指出的是，即便 REP 已經成為了預設的實施標準，但它實際上從未成為真正的網際網路標準，正如網際網路工程任務組（IETF - 一家非營利性開放標註組織）所定義的那樣。
為了推動這項轉變，谷歌正在積極參與行動。這家搜尋巨頭表示，當前的 REP 可以被“解釋”，但並不總是涵蓋邊緣化的案例。
作為補充，谷歌提出了更全面的“未定義場景”。比如在執行一次“掃描已知內容”的任務時，爬蟲該如何處理“伺服器出現不可訪問故障”的 robots.txt 檔案、或者有拼寫錯誤的規則？
谷歌在一篇部落格文章中寫到：“對於網站所有者來說，這是一項極具挑戰性的問題。因為模糊的事實標準，讓他們很難恰當地編寫規則”。
我們希望幫助網站所有者和開發者在網際網路上創造出令人驚歎的體驗，而無需擔心如何對抓取工具加以限制。
於是谷歌與 REP 原作者 Martijn Koster、網站管理員、以及其它搜尋引擎合作，向 IETF 提交了一份關於《如何在現代網路上適用 REP》的提案。
該公司尚未公佈該草案的全貌，但卻是提供了一些指引。比如任何基於 URI 的傳輸協議，都可以適用 robots.txt 。且其不再侷限於 HTTP，亦可面向 FTP 或 CoAP 。
據悉，開發者必須至少解析 robots.txt 的前 500 KB 內容。定義檔案的大小，可確保每個連線的開啟時間不會太長，從而減輕不必要的伺服器壓力。
另外，新的最大快取時間被設定為 24 小時（或可用的快取指令值），使得網站所有者能夠隨時靈活地更新他們的 robots.txt，且爬蟲不會因此而讓網站超載。
例如，在 HTTP 的情況下，可使用 Cache-Control 報頭來確定快取時間。而當先前可訪問的 robots.txt 檔案由於伺服器故障而變得不可用時，則會在相當長的時間段內不再檢索該網站。
這裡需要點明的是，抓取工具可以用不同的方式去解析 robots.txt 檔案中的說明，這可能會導致網站所有者的混淆。
為此，谷歌特地推出了 C++ 庫，其支援 Googlebot 在 GitHub 上給出的解析和匹配系統，以供任何人訪問。
根據 GitHub 上的釋出說明，Google 希望開發者構建自己的解析器，以更好地反映 Google 的 robots.txt 檔案的解析和匹配。