不少站点把 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 发现这条链路就少了一个容易漏水的环节。