先分清抓取和渲染是两步
搜尋引擎處理一個 URL，通常先取回服務器返回的 HTML 源碼，再判断要不要把它放進渲染队列执行脚本。渲染要消耗額外的計算资源，所以並不是每個頁面都會立刻渲染，也不是每次渲染都能把所有脚本顺利跑完。内容如果只存在于脚本执行之後，等于把被發現的机會押在了這一步上。
這也是為什么同一套前端框架，有的站点抓取覆盖不错，有的却長期只有首頁和几個栏目頁被收錄。差別往往不在框架本身，而在關键内容和連結是否出現在源碼里。
哪些内容最容易在渲染前看不见
- 内鏈：用脚本拼接出来的導航、列表和相關推荐，源碼里没有可点的 href，蜘蛛就找不到下一跳。
- 分頁與加载更多：靠按钮点击触發的列表，缺少可以直接訪問的分頁 URL。
- 正文主体：接口返回後再插入頁面的文字，源碼里往往只剩一個空容器。
- 标题與元信息：頁面标题、描述、canonical 若由脚本寫入，渲染前可能是缺失或預設值。
- 结构化資料：需要在客戶端注入的标记，渲染失敗时不會留下任何痕迹。
让蜘蛛少依赖脚本的几種做法
- 關键内容走服務端渲染或静態生成，至少保證首屏正文和主要内鏈出現在 HTML 源碼中。
- 列表頁给出真實可訪問的分頁地址，而不是只留一個点击事件。
- 异步加载的区域，提供無脚本也能讀到的备用連結，作為兜底入口。
- 把渲染後才出現的 URL 同步進 Sitemap，让它們有一條不依赖脚本的發現通道。
- 渲染压力大的頁面，减少第三方脚本和串行請求，让關键内容更早進入 DOM。
渲染排队也會影响發現节奏
即便頁面最终能被渲染，排队本身也有先後。首屏依赖大量脚本、报错频繁或請求超时的頁面，被完整渲染的概率會打折扣。相比之下，源碼里已经有正文和連結的頁面，即使渲染慢一点，URL 發現和基本内容判断也不會中断。
怎么確認自己頁面被看到的样子
- 查看頁面源代碼，而不是開發者工具里的元素面板，確認正文和内鏈是否真實存在。
- 用抓取工具對比原始 HTML 與渲染後 HTML，列出两者的差异清單。
- 在服務器日誌里核對這些 URL 有没有被訪問、返回什么狀態、响應体有多大。
- 對關键路径做一次检查，確認脚本失效时頁面里是否還有可走的連結。
不必追求全部交给渲染
渲染是有限资源，不适合承担全部的 URL 發現和内容理解。更稳妥的思路是：能静態呈現的部分尽量静態，必须异步的部分给出可抓取的替代路径，再用 Sitemap 和内鏈把關键 URL 稳定地交出去。
一個简單的自检方式：關掉 JavaScript 之後，頁面里還剩多少正文、還剩多少條能走的連結。剩下的這部分，基本就是蜘蛛在渲染前能拿到的東西。