不少人在入口頁做優化时，會想到用 JSON-LD 来放目标連結，理由也很直接：结构化資料是搜尋引擎官方支持的格式，看起来比一堆 a 标簽更“正規”。但把它当成連結發現的通道，通常是要落空的。
先说结论：JSON-LD 里的 URL 是資料，不是連結
搜尋蜘蛛發現 URL 的主要途径，是解析 HTML 里能构成連結的节点：a 标簽的 href、link 标簽、表單 action、iframe src 等。這些元素在文档里承担的是“導航”语义，爬虫會按連結規則去解析、去重、排队。
JSON-LD 是一段脚本内容，它的作用是向搜尋引擎描述頁面實体，比如這是什么頁面、属于谁、價格多少。里面的 URL 字段是属性值，不是可点击、可跳轉的連結。爬虫讀它，是為了理解實体關系，不是為了顺着它去發現新頁面。
為什么這個誤解很普遍
- 结构化資料确實會被解析，URL 字段也确實能被讀到，于是“能讀到”被誤当成“會跟進”。
- 某些结构化資料里的 URL 會影响索引展示，比如面包屑、站内搜尋框，這让人以為它同样能带爬虫進入新 URL。
- 有些頁面同时存在 a 标簽和 JSON-LD，爬虫跟着 a 标簽抓到了目标頁，结果被算成 JSON-LD 的功劳。
和普通 a 标簽的差別在哪
- 语义不同：a 标簽表達的是導航關系，结构化資料表達的是属性描述。
- 去重與優先級不同：爬虫會把 a 标簽收進待抓队列並排優先級，單纯的字符串没有這個待遇。
- 可控性不同：a 标簽能被 rel 属性、锚文本、所在位置影响，JSON-LD 基本只能被動等待解析。
- 容错不同：JSON-LD 一旦语法出错，整段可能被丢弃；a 标簽寫错顶多這一條没用。
什么情况下结构化資料里的 URL 會被用到
如果這個 URL 本来就是一個可索引的實体地址，比如 canonical、面包屑里的頁面地址、图片的 contentUrl，搜尋引擎可能會拿它去核對信息、补充展示。但前提通常是：這個 URL 已经通過其他方式被發現，结构化資料只是让描述更准确，而不是负责發現。
把發現渠道和描述渠道分開看：發現靠連結和站点地图，描述靠结构化資料。两者混用，最容易出現“寫了却迟迟没被抓”的情况。
更稳妥的做法
- 目标連結老老實實寫成 a 标簽，放在正文里，別只放在脚本里。
- JSON-LD 保留，用来补充實体信息，但不要指望它承担發現任務。
- 重要 URL 同时進站点地图，减少對單一渠道的依赖。
- 入口頁數量變多以後，定期抽查抓取日誌，看目标 URL 是被哪條路径带進去的。
怎么驗證是不是真的被發現了
- 在服務端日誌里搜目标 URL 的路径特征，看有没有搜尋蜘蛛的訪問记錄。
- 做對比：把 JSON-LD 里的連結挪到 a 标簽，观察目标 URL 首次被抓的時間是否變化。
- 用抓取工具模拟，检查渲染後的 DOM 里有没有真正的連結节点。
最後提醒一句：入口頁本身的设計、站点整体质量、抓取预算都會影响跟進速度。把連結寫在 JSON-LD 里不會立刻带来什么惩罚，但它也不是一條捷径，指望靠它提升發現效率，多半會失望。