站内連結是搜尋蜘蛛發現 URL 的主要入口，但如果這些連結要等 JavaScript 跑完才出現在頁面上，抓取路径就多了一道门槛。理解原始 HTML 與渲染後 DOM 的差別，能帮我們判断哪些入口是稳的、哪些只能看运气。
抓取通常分成两步
搜尋蜘蛛請求一個地址时，最先拿到的是服務器直接返回的 HTML。它會在這一份内容里找連結、记錄 URL，然後把新地址放進抓取队列。對于依赖 JS 才能顯示内容的頁面，搜尋引擎可能還會把頁面放進渲染队列，用浏览器环境再跑一遍，拿到渲染後的 DOM，再從里面提取連結。
問题在于渲染是有成本的，排队、执行、超时都可能让這一步延後，甚至跳過。連結如果只在渲染後才出現，它的發現时机會被推後，而且不保證每次都能被走到。
哪些寫法會让連結只活在渲染之後
- 用 div、span 加 click 事件模拟跳轉，没有真實的 a 标簽與 href。
- href 寫死成 # 或空脚本，真實地址藏在 data 属性或事件回調里。
- 列表資料由前端接口拉取後生成，服務端返回的 HTML 里没有對應連結。
- 内容預設折叠，只有展開或滚動到可视区域时才插入連結。
- 依赖 hash 路由，路径變化只体現在井号之後的部分。
這些寫法對用戶可能没什么問题，但對 URL 發現来说，入口的可靠性下降了一档。
让 JS 連結更容易被發現的几種做法
- 首屏連結用服務端渲染或静態生成。列表頁、栏目頁、詳情頁之間的關键互鏈，尽量在初始 HTML 里就已经存在。
- 保留真實的 a 标簽。即使用了前端框架做跳轉，也让 href 指向真實地址，用戶和蜘蛛都能讀到。
- 给纯前端列表留一個静態入口。比如「查看全部」指向一個服務端渲染的分頁頁，覆盖那些只在滚動里出現的地址。
- 用 sitemap 做兜底。渲染依赖很重的站点，把重要 URL 放進 sitemap，等于多一條獨立的發現路径，但它不能替代内鏈的作用。
- 控制首屏体积。渲染超时常见的原因是首屏脚本太重，關键連結還没插進去，渲染窗口就過去了。
渲染是补充手段，不是内鏈的替代品。能在原始 HTML 里出現的連結，就不该只留在渲染之後。
無限滚動與分頁的组合
無限滚動很常见，但頁面往往只加载第一屏，後面的 URL 對蜘蛛不可见。比較稳妥的做法是保留可訪問的分頁地址，滚動加载只作為体驗增强，而不是唯一入口。同理，篩選和排序如果會产生獨立 URL，最好也有一個不带參數的静態列表版本作為主干。
怎么自查
最直接的办法是禁用 JavaScript 打開頁面，看還能不能顺着連結走到下一級；或者查看頁面源代碼，確認首屏的關键連結是否出現在返回的 HTML 里。再结合服務器日誌，看看那些只靠渲染才出現的地址，是否真的被請求過。如果長期没有請求记錄，就要考虑把它們挪到原始 HTML 或 sitemap 中，减少對渲染环节的依赖。