用前端框架搭站点已经不稀奇，但從抓取角度看，它带来一個容易被忽略的變化：蜘蛛第一次請求某個 URL 时，拿到的 HTML 往往只有骨架，标题、正文、列表和内鏈都還没出現。
抓取和渲染是两步，不是一步
搜尋引擎處理一個 URL 时，通常會先取回服務器直接返回的 HTML，這一步决定了它能不能立刻看到連結和内容。對于依赖 JavaScript 生成的頁面，可能還要進入渲染队列，等浏览器环境把頁面执行一遍，才能看到完整结果。
渲染不是免費的。它占用更長的處理時間，也有排队和次數上的限制。原始 HTML 里就有内容的頁面，通常能更快完成解析，連結也能更早進入待抓队列。
内鏈藏在脚本里，URL 發現會慢一拍
問题不在于 JavaScript 本身，而在于關键路径是否只存在于 JavaScript 里。常见的几種寫法值得检查：
- 導航和頁脚連結由脚本注入，服務器返回的 HTML 里没有任何 a 标簽。
- 列表項用 div 加点击事件跳轉，没有可跟随的連結地址。
- 分頁做成按钮形式，只有狀態變化，没有指向下一頁的地址。
- 正文和目錄連結通過接口异步加载，要等請求返回才出現。
這些做法在浏览器里体驗正常，但對第一次抓取来说，頁面在 HTML 层面是偏薄的。蜘蛛如果只看這份 HTML，能走的路就只剩下少數几條。
把關键路径留在原始 HTML 里
不需要把所有内容都做成服務端渲染，但入口和路径類連結最好留在 HTML 中：
- 主導航、面包屑、頁脚分類，直接在 HTML 里輸出連結。
- 列表頁的分頁，第一頁就带上下一頁的真實地址。
- 正文里的相關阅讀、上一篇下一篇，用連結而不是脚本跳轉。
- 栏目頁至少輸出一批静態可见的條目，不要全靠滚動加载。
如果站点已经用了前端框架，可以考虑服務端渲染、静態生成或预渲染，让首屏 HTML 自带内容與連結。渲染层再复杂，第一份 HTML 最好也能獨立說明這是什么頁面、接下来能去哪。
渲染本身也要花時間，別让路径串行太深
即便走渲染，頁面的加载顺序也會影响抓取体驗。一次渲染里若需要连續請求多個接口，每一层都可能超时或失敗，最终渲染出的頁面連結不全。把關键資料合並、减少串行請求、控制首屏脚本体积，都是在给抓取让路。
另外，渲染出来的連結地址要與 HTML 中的地址保持一致。如果脚本生成的 URL 带一堆參數，或與站内實际路径不一致，容易出現同一内容被拆成多個地址的情况，反而增加後續收敛的成本。
一份可以照着走的检查清單
- 關掉 JavaScript，打開頁面，看還剩哪些内容和連結。
- 用抓取工具模拟蜘蛛，對比原始 HTML 與渲染後的差异。
- 確認分頁、面包屑、栏目列表在第一份 HTML 里可见。
- 检查是否有只靠点击事件跳轉的入口。
- 把重要的 URL 同时寫進 Sitemap，给發現留一條备用通道。
前端渲染影响的不只是内容展示，更是連結能不能被看到。連結看不到，URL 發現和後續抓取都會跟着變慢。
抓取和渲染的分工不會因為技術栈改變，但站点可以决定把什么放進第一份 HTML。導航、分頁、列表、正文入口這些路径信息越早出現，蜘蛛在站内走起来就越顺，也越不容易在空壳頁面上停下。