响應头也是入口，只是不寫在頁面里
盘点 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 做扎實，再考虑是否需要用头部补充說明；顺序反過来，往往收效有限。