該不該幫你的內容標價：RSL 補上了 robots.txt 說不出口的那一格

你的站要不要在 robots.txt 旁邊掛一張價目表？

這題可以先用一個更省事的方式問：你的內容明天被整包拿去訓練模型，你會不會因此少賺到錢。答不出來，或者答案是「不會」，那底下這套東西讀個熱鬧就好，不用動手。

robots.txt 能講的話少得可憐。Allow 跟 Disallow，就這兩格。你真正想講的從來不是「准不准爬」，而是「拿去做搜尋索引可以，拿去訓練要另外談」「學術單位免費，商業公司算錢」「歐盟境內另有條款」。這些條件在 robots.txt 裡一句都寫不出來，於是大家的做法是把 bot 名字一隻一隻列進 Disallow，用一份黑名單去模擬一套自己也講不清楚的規則。

Really Simple Licensing 想補的就是這一格。它是一份 XML，媒體型別 application/rsl+xml，掛在 robots.txt 旁邊，內容是機器讀得懂的授權條款。發起的兩個人裡，一個是 RSS 標準的共同創造者，命名的血統相當明顯。

順帶把層次先分清楚。簽章那套解的是「你是誰」，這套解的是「你能拿去做什麼、要付多少」。兩件事互不取代也互不依賴：你可以在不知道對方是誰的情況下掛條款，也可以驗完了身分卻沒有任何條款可以套上去。

把「誰、拿去幹嘛、在哪裡」拆成三格

<permits> 跟 <prohibits> 各自帶一個 type，值只有 usage、user、geo 三種。每一種底下 RSL 自己定義的詞彙是固定的那幾個，要加自訂詞得走命名空間前綴（schema 裡的 qnameToken），不能隨手塞裸字串。

usage 那排裡最值得停一下的是 ai-train 跟 ai-input 被拆成兩個值。這兩件事對站方的意義差很遠：一個是你的內容被消化成權重，之後再也認不出來；一個是模型每次回答都要回頭讀你一次。ai-index 又是另一格。ai-all 把前面幾個 AI 相關的包在一起，all 再往外包一層，連非 AI 的用途一起算。

規格另外訂了一條衝突處理原則，方向是固定的：同一個用途、同一類使用者，如果既被允許又被禁止，禁止優先。原話是 MUST be interpreted conservatively to avoid the unintended expansion of rights。翻成人話就是你寫糊塗的時候，天平會往「權利沒有授出去」那邊倒。對你有利的時候很有利，反過來也一樣。

價錢寫在哪一行

<payment> 的 type 官方列了八個：purchase、subscription、training、crawl、use、contribution、attribution、free。attribution 跟 free 也在名單上，所以這個元素講的其實不只是錢，是「你要拿什麼來換」。標明出處也算一種對價。

底下可以掛 <standard>（共用的授權框架網址）、<custom>（你自家的授權端點）、<amount currency="...">（ISO 4217 幣別）跟 <accepts type="...">。照這些元素組一份最小的檔案，大概長這樣：

1
2
3
4
5
6
7
8
9
10
11
12

<rsl xmlns="https://rslstandard.org/rsl">
  <content url="https://example.com/">
    <license>
      <permits type="usage">search ai-input</permits>
      <prohibits type="usage">ai-train</prohibits>
      <payment type="crawl">
        <amount currency="USD">0.01</amount>
        <accepts type="application/x402+json"/>
      </payment>
    </license>
  </content>
</rsl>

（這是照規格元素拼出來的示意，金額是我隨便填的。）

<accepts type="application/x402+json"> 這一格是整份規格裡最有想像力的地方。它把機器對機器的付款協定直接接進授權宣告，意思是這份條款不只寫給人看，還留了一個讓對方的程式自己去結帳的介面。條款跟收款窗口寫在同一個檔案裡，這個設計是對的。

它繞過的東西比它做到的更值得看。一份純文字的授權條款要生效，前提是對方讀了、看懂了、而且願意照做，這三件事你一件都驗不到。錢不一樣，進沒進來是查得出來的。<accepts> 真正在做的事情，是把「對方同意了嗎」這個查不到的問題，換成「對方付了嗎」這個查得到的問題。前提是對方肯走這個介面。

爬蟲怎麼找到這份文件？robots.txt 裡加一行 License: https://example.com/license.xml，或者走 HTTP Link header 帶 rel="license" 跟 type="application/rsl+xml"。前者還能塞進某個 User-agent 群組，單獨給那隻 bot 一份不一樣的條款。

402 這個狀態碼終於等到它的用途

402 Payment Required 從 HTTP 誕生就掛在規格裡，幾乎沒人用過。講到這裡為止的東西都還停在「怎麼說」，而規格自己顯然知道光會說沒有用，所以在 4.10 那節另外掛了一套協定，叫 RSL Crawler Authorization Protocol，簡稱 CAP。

CAP 引進一個叫 License 的 HTTP 認證 scheme，client 要在請求裡帶 Authorization: License <rsl-license-token>。回應端三個狀態碼分得很乾淨：401 是憑證缺漏、無效或過期，402 是還沒取得授權或付款條件沒滿足，403 是條款本身不准這個操作。

<content> 上還有一個 server 屬性，指向一台授權伺服器。規格寫得很硬：這個屬性存在時，client MUST 先去那台伺服器取得該資產的授權才能存取。

這個 MUST 約束的是「願意照規格做的 client」。對不願意的那些，這行字跟沒寫一樣。

什麼時候標價反而是壞主意

先把最常見的那條路堵掉。很多人的想法是：反正掛一份 XML 又不花錢，先寫上去，有總比沒有好。

這條路的問題不在它沒效果，在它有一個你沒算到的效果。你掛的那份文件如果沒有任何一層在檢查，對已經在抓你的爬蟲來說，它產生的唯一改變是：你留下了一份「我當時開價多少」的公開紀錄。往後真要坐下來談，對方手上先有了你的報價單，而你手上沒有任何東西能證明對方讀過它。開價這件事在你能執行之前做，等於單方面把底牌翻開。

第二個判準是你維不維護得動。條款是活的，你的內容型態會變、你願意開放的對象也會變，而上面那條保守解釋原則的方向永遠不動。一份三個月沒回頭看的條款，比沒有條款更容易在你真正要用它的那天變成麻煩。

第三個判準比較冷。這套標準 2025 年 9 月 10 日發布，到現在剛滿一年；規格本身標的文件編號是 RSL-SPEC-1.0、日期 2025-12-10、狀態寫 Recommendation。發布新聞稿列了一排支持者，Reddit、Yahoo、People Inc.、Internet Brands、Ziff Davis、Fastly、Quora、O’Reilly Media、Medium 都在上面。那是該方自己的說法，我沒有獨立來源可以交叉驗證，也查不到一份公開的採用清單能告訴我這些站今天實際掛了沒有。

我能給的客觀數字只有一個，而且它不好看。rslstandard 這個 GitHub 組織底下只有一個公開 repo，叫 rsl，47 顆星，最後一次 push 停在 2026 年 3 月 31 日，到我查的這天（2026 年 9 月 12 日）五個多月沒動過。這不代表標準死了，規格頁跟參考實作本來就是兩回事，但它也絕對不是「大家都在導入」的訊號。

那什麼情況下該標？條件其實很窄：你的內容有人真的想要、你有辦法在請求進來的當下擋住它、而且擋住之後不會連帶弄壞你原本在乎的那條流量。三個條件是連乘的，缺一個結果就是零。

最後那個最容易被忽略。搜尋索引跟訓練抓取常常共用同一批基礎設施，你在 <prohibits> 裡爽快寫下 ai-all，得先看清楚 ai-index 是不是也被你一起關掉了。少賺一點授權金，跟從搜尋結果裡消失，是兩種完全不同量級的代價。

我的順序建議

先架得住，再標價。順序不能反。

講具體一點。如果你已經在 CDN 或 WAF 那層有 bot 管理，分得出哪些請求是誰發的、也擋得掉，那 RSL 現在就值得寫，因為執行層已經在你手上，條款掛上去當天就有意義。如果你沒有，那你該做的不是先掛條款，是先去解決「我能不能認出這個請求、能不能拒絕它」。這也正是規格自己暗示的順序。

會讓我把這個順序反過來的條件也講清楚：只要哪家主流 CDN 把「讀 License: 那一行、驗 CAP token」做成一個開關，或者任何一家大型模型公司公開說它的爬蟲會照那份 XML 的價目付錢，那先標先贏就成立了，因為那時候執行層不用你自己架。在那之前，一份沒有 gate 撐著的價目表，收到的是流量，不是錢。

講一下這篇的邊界。我沒有寫過 RSL 的 XML、沒有在任何站上部署過，也沒有觀察過任何一隻爬蟲實際遵守或無視它。上面的元素名稱、屬性跟那幾份值清單，是逐項對過 rslstandard.org 的 RSL 1.0 規格頁；採用規模的部分只到新聞稿那一層，我沒辦法證實。CAP 的細節我讀的是規格描述，沒看過任何一份實作。

robots.txt 活了三十年，靠的從來不是它擋得住誰，是幾家大公司決定要遵守它。RSL 把可以寫的東西從兩格擴成一整套詞彙，但它繼承了一模一樣的前提。詞彙變豐富，不會自己長出牙齒。

• RSL 1.0 規格：https://rslstandard.org/rsl
• 官網：https://rslstandard.org/
• 發布新聞稿：https://rslstandard.org/press/rsl-standard
• 參考實作：https://github.com/rslstandard/rsl