把目标連結用 JavaScript 動態插入入口頁，是很多人图省事的做法：改一個資料文件就能批量換連結。但搜尋蜘蛛能不能看到這些連結，答案並不是简單的“能”或“不能”，而是取决于它有没有走到渲染這一步，以及渲染有没有成功。
搜尋蜘蛛處理 JS 的两個阶段
主流搜尋引擎抓取一個頁面，通常分两步走：先用抓取器拿到服務器返回的原始 HTML，把它放進待處理队列；之後如果判断頁面需要渲染，再排一次队，用無头浏览器执行 JS，拿到渲染後的 DOM，從中提取連結和内容。
問题就出在第二步。渲染是額外開销，需要排队，也需要抓取预算。入口頁本身如果内容單薄、數量又多、更新還频繁，渲染队列的排期可能很長，甚至部分頁面根本轮不到渲染。不同搜尋引擎的渲染能力差別也很大，有的對 JS 渲染支持比較完整，有的仍然以初始 HTML 為主要依據。
哪些寫法最容易让連結被漏掉
- 点击後才加载。連結藏在“展開更多”、分頁按钮、Tab 切換後面，不点击就不出現在 DOM 里，渲染器一般不會去点。
- 滚動到底才出現。無限滚動或懒加载，首屏 DOM 里没有目标連結。
- 接口返回後再拼 DOM。前端先請求接口拿 JSON，再用脚本生成 a 标簽，任何一步失敗或超时，連結就没了。
- URL 由字符串拼接生成。没有寫死在 HTML 里的 href，抓取器只能靠执行结果推断。
- JS 文件本身被 robots.txt 挡住。渲染器拿不到脚本，自然渲染不出連結。
這些寫法在浏览器里看着完全正常，但對抓取器来说，初始 HTML 里可能一個目标連結都没有。
想让連結稳定被發現，可以這样調整
- 關键入口頁尽量服務端渲染。让目标連結在服務器返回的 HTML 里就存在，不依赖浏览器执行。
- 用真實的 a 标簽和 href。避免用 onclick 跳轉、div 绑定事件、window.location 赋值来替代連結。
- 首屏就要有内容。把需要被發現的目标連結放在頁面靠前、不需要交互的位置。
- 用 sitemap 做补充。頁面内連結负责發現，sitemap 负责兜底，两者並不冲突。
- 控制單頁連結數量。連結太多、模板太像，分配到這一個頁面的抓取预算會被摊薄。
怎么確認搜尋蜘蛛到底拿到了什么
- 看服務器日誌，区分請求原始 HTML 的抓取和請求 JS、静態资源的渲染請求，两者的 UA 與行為通常能看出来。
- 用站長平台提供的 URL 检查 / 抓取诊断工具，對比“原始 HTML”和“渲染後 HTML”里的連結差异。
- 本地用關閉 JS 的方式抓一次頁面（例如 curl 或浏览器禁用 JS），看看還能剩下多少目标連結。
- 连續观察几天日誌，看入口頁被反复抓取时，目标 URL 是否出現在後續的抓取记錄里。
判断标准很简單：如果關掉 JS 後頁面里一個目标連結都不剩，那這些 URL 能否被發現，就只能靠渲染队列的排期了。
几個常见誤区
第一種誤区是“能渲染就等于一定被發現”。渲染只是必要條件，不是充分條件，渲染失敗、排队太久、頁面被判定為低價值，都會让連結長期停留在“已發現未抓取”的狀態。第二種誤区是把 JS 生成的連結当成高质量外鏈，實际上它首先解决的是發現路径問题，和權重、排名的關系是两回事。第三種誤区是入口頁全部套用同一種前端模板，一旦渲染环节出問题，整批連結會一起消失。
總的来说，JS 動態插入的目标連結不是不能用，但不适合当作唯一通道。把服務端可讀的 HTML 連結当作主路径，把 JS 渲染当作补充，再配合日誌和抓取工具做驗證，才是相對稳妥的做法。