不少站点在浏览器里点起来很顺，導航、列表、翻頁都能跳轉，但抓取工具取回的初始 HTML 里可能一條連結都没有。連結是頁面被發現的入口，如果它只在脚本执行之後才出現，URL 就會晚一步進入队列，嚴重时干脆進不去。這篇讲的是渲染前後連結可见性的差別，以及怎么把這件事查清楚。
抓取工具看到的，和用戶看到的不是同一個東西
處理一條 URL 大致分两步：先把原始 HTML 取回来，再在需要时执行脚本、拿到渲染後的 DOM。第一步拿到的是源碼，第二步才接近用戶眼里的頁面。如果導航、列表項、分頁入口全部由脚本注入，第一步就看不到這些地址。
這不等于一定收不到，但要意识到一件事：新 URL 的發現路径被拉長了，而且多了一道依赖。
哪些寫法會让連結“渲染後才出現”
- 用 div、span 加点击事件做跳轉，而不是 a 标簽带 href。
- 前端路由切換视图，初始 HTML 只是一個几乎空的容器。
- “加载更多”按钮靠事件监听發請求，拼接出来的地址只存在于接口參數里。
- 标簽頁、折叠面板的内容由脚本請求後插入，展開前頁面里没有對應連結。
- 無限滚動列表，後續條目没有各自獨立的静態地址。
這些寫法對用戶体驗往往没問题，但把“可發現”這件事完全押在了脚本执行上。
URL 進入抓取队列的常见入口
- 站内 a 标簽的 href，包括導航、面包屑、正文内鏈。
- sitemap 文件里列出的地址。
- 外部頁面指向本站的連結。
- 已抓取頁面在渲染後讀到的連結。
- 歷史抓取记錄中出現過、之後被重新检查的地址。
前三條不依赖脚本执行，属于相對稳定的来源；第四條要看渲染能力，通常更慢也更不确定。如果你的重要頁面只有第四條能走到，节奏就不在自己手里。
自查顺序：從“能不能看到”開始
- 用禁用 JavaScript 的方式打開頁面，看導航和正文里還能不能找到指向目标頁的普通連結。
- 检查關键入口是否用的是 href，而不是点击事件或脚本跳轉。
- 看 sitemap 是否覆盖了需要被發現的地址，尤其是深层詳情頁和分頁後續頁。
- 看分頁與“加载更多”是否對應可被抓取的静態地址，比如带頁碼參數的獨立 URL。
- 確認重要頁面至少有一條来自其他頁面的普通連結，不是只靠脚本生成。
- 對照服務端日誌或抓取记錄，確認目标地址到底有没有被訪問過。
這六步走完，基本能分清問题出在發現环节，還是出在發現之後的抓取與處理环节。
可以做的一些調整
让初始 HTML 里就有連結
把重要導航、分類入口、分頁連結改成服務端輸出或预渲染輸出，保證源碼里就有可讀的 a 标簽。前端路由接管跳轉可以保留，但底层留一個真實連結做兜底。
给批量内容留獨立地址
無限滚動配合分頁 URL，每個片段都有稳定地址；标簽頁内容如果值得被單獨發現，也尽量给一個可訪問的地址，而不是只存在于展開動作之後。
把 sitemap 当补充，而不是唯一依靠
sitemap 能帮助列出一批地址，但它替代不了站内連結所表達的层級和重要性。两者都缺的时候，深层内容最容易掉队。
脚本渲染只是把連結送到抓取工具面前的一種方式，它本身不保證頁面被收錄。正文质量、重复程度、URL 規范，仍然决定後續结果。
什么时候可以不用太紧張
如果脚本生成的連結只是锦上添花，核心頁面在初始 HTML 里已经有一套完整入口，那渲染差异带来的影响通常有限。反過来，如果整站導航都靠脚本拼出来，就把“連結可见性”当成一項常規检查項，而不是等出問题再回头补。