响应头也是入口，只是不写在页面里
盘点 URL 发现入口时，多数人看的是页面源码：导航、正文链接、面包屑、Sitemap。但抓取程序在读到正文之前，先拿到的是 HTTP 响应头。如果头部里带有 Link 字段，部分抓取程序会把它当作一条可跟随的地址线索。它替代不了内链，却能在某些场景补上一条通道。
Link 头里常见的几种关系值
rel="canonical"
用响应头声明规范地址，作用与页面里的 canonical 标签接近，常用于 PDF、文档包这类不便在文件内写标签的资源。要注意它表达的是“同一内容以哪个地址为准”，本身不是新增入口；写错反而会把抓取注意力引到别的地址上。
rel="alternate" 与多语言版本
多语言、多区域站点可以用 Link 头把各语言版本互指。它能让抓取方知道同一内容还有哪些语言地址，对这些地址的发现有一定帮助。前提是地址真实可访问，并且与页面内的 hreflang 标注保持一致；两处写法矛盾时，只会增加判断成本。
rel="next" / "prev"
分页序列过去常用这种方式声明。现在主流搜索引擎对它的使用已经弱化，不建议把它当成分页发现的主要手段。列表页之间的翻页，还是靠可点击链接更稳妥。
其他关系值
preload、preconnect、dns-prefetch 这类多用于资源加载优化，和 URL 发现关系不大，不必把它们当成提交入口来用。
什么时候值得用，什么时候不必用
- 非 HTML 文件（PDF、图片、文档包）不方便在文件内部写标签时，可以借响应头补充关系声明。
- 多语言版本互指，且页面内已经写了 hreflang，响应头可作为一致的第二来源。
- 普通 HTML 页面之间的内链关系，用正文链接就够了，不必绕到响应头。
- 想靠响应头“多提交一批 URL”，通常不会有预期效果，还容易出现与页面标注冲突的情况。
容易出问题的几个点
一是地址写成相对路径或带临时参数，解析时容易落到错误地址上。二是响应头体积过大，部分服务器或中间层会截断，Link 字段直接丢失。三是缓存层返回旧版本头部，更新后生效延迟。四是与页面内 canonical、hreflang 写法不一致，形成互相矛盾的信号。五是同一地址在多个字段里出现不同关系值，抓取方难以取舍。
和内链、Sitemap 的关系
把三条通道排一下顺序会更清楚：内链负责日常发现和权重传递，Sitemap 负责把已知地址批量交底，响应头只在个别场景做补充说明。它适合当补丁，不适合当主力。无论走哪条通道，地址都应当能返回正常内容，否则补进去也只是多一次无效抓取。
排查顺序
- 用抓取工具或命令行查看原始响应头，确认 Link 字段确实返回了，而不是只写在配置文件里。
- 核对字段里的每个地址是否为绝对路径、能否访问、状态码是否正常。
- 与页面内的 canonical、hreflang、内链标注逐条比对，确认没有互相矛盾。
- 确认缓存层没有返回过期的头部版本。
- 观察一段时间的服务器日志，看这些地址有没有被实际请求过；没有被走过，就说明它没起到入口作用。
响应头里的入口属于锦上添花。先把内链结构和 Sitemap 做扎实，再考虑是否需要用头部补充说明；顺序反过来，往往收效有限。