不少站点把 RSS 当成上一個时代的产物：後台還留着開關，前台早就撤了入口，订阅源本身也常年不更新。但如果從 URL 發現的角度看，订阅源仍然是一件很划算的工具——它是一份格式固定、体积很小、持續更新的連結清單，爬虫解析它的成本遠低于抓取首頁再顺着導航层层深入。
订阅源在 URL 發現里的位置
一個正常的發現路径大致是：首頁或栏目頁被發現，然後顺着内鏈、站点地图、订阅源等入口扩散。订阅源的特点是"新"和"少"：它通常只保留最近几十條内容，正好對應站点刚刚更新的那部分 URL。對于更新频繁、栏目众多的站点，订阅源能起到一個轻量索引的作用。
需要注意的是，订阅源只是入口之一，它决定的是"這條 URL 有没有被看到"，而不是"會不會被收錄"。能不能被收錄，最终還要看内容质量、頁面可訪問性和站点整体的信任度。
影响 URL 發現的几個字段
- item 的 link：這是最重要的字段，必须寫成绝對地址，且與頁面的 canonical 保持一致。相對路径在部分解析器里會被拼错，直接導致抓取失敗。
- guid / isPermaLink：用来标识條目唯一性。如果 guid 不是連結，最好顯式声明 isPermaLink="false"，避免解析器把一段哈希值当成網址去請求。
- pubDate 與 lastBuildDate：影响爬虫判断"這份源有没有變化"。日期長期不變，抓取频次自然會下降。
- description：只放摘要，不要把整篇正文、大量内联样式或脚本塞進去，否則文件体积會迅速膨胀。
- enclosure：附件、音视频下载連結如果放在這里，同样會被识別為可訪問资源，注意別把後台接口暴露出去。
全量輸出還是增量輸出
常见的错誤是把整個站点的所有文章都塞進一個 feed。文件一旦涨到几兆，解析和传輸都變得沉重，反而降低了更新部分的可见度。更稳妥的做法是保留最近 20 到 50 條，同时按栏目拆分出若干子源，让每條 URL 都能出現在與其相關的上下文里。
缓存與生成时机
如果订阅源是動態生成的，要確認它不會因為查询過重而超时；如果做了静態缓存，缓存時間不宜设得太長，否則新發布的 URL 要等很久才會出現在源里，白白浪費了發布後的黄金时段。發布文章後主動触發一次订阅源重建，是個成本很低的习惯。
常见的翻车現场
- 订阅源放在需要登入或带訪問限制的目錄下，爬虫只能拿到 403。
- 多語言站点把几種語言的條目混在一個源里，連結指向混乱，還容易触發語言版本之間的重复問题。
- 编碼没有统一為 UTF-8，标题里的中文變成乱碼，連結里的參數也可能被截断。
- 源里残留已刪除、已下线的舊 URL，長期返回 404，消耗抓取预算。
- 把草稿、预览連結、測試环境的地址誤寫入條目，等于给爬虫指错路。
和 Sitemap、内鏈怎么分工
订阅源负责"新"，Sitemap 负责"全"，内鏈负责"關系"。三者用途不同，不必互相替代，也不该让其中任何一份長期處于無人维護的狀態。
Sitemap 适合覆盖全站可索引頁面並标注更新時間；订阅源适合突出最近更新；内鏈和面包屑則告诉爬虫頁面之間的层級和相關性。日常运营中，只要保證這三條通道的 URL 一致、可訪問、没有互相矛盾的狀態碼，URL 發現环节基本不會出大問题。
日常检查清單
- 浏览器直接打開订阅源地址，確認能正常返回内容且没有登入拦截。
- 随机挑几條連結点進去，確認都是绝對地址、能返回 200、canonical 指向自身。
- 检查條目數量是否被截断，日期是否随發布更新。
- 對比订阅源與 Sitemap 中的 URL 集合，找出只在一方出現或已经失效的地址。
- 確認编碼、命名空間声明正确，避免解析器报错。
- 把订阅源地址登记在站点的明顯位置，方便自己也方便別人找到。
订阅源不是什么神奇手段，它更像一根被遗忘的线头。重新把它接上、保持干净、跟随發布节奏更新，URL 發現這條鏈路就少了一個容易漏水的环节。