蜘蛛先拿到的是 HTML，不是執行後的頁面
多數搜尋引擎的抓取分两步：先請求 URL 拿到响應体，再把頁面放進渲染队列执行 JavaScript。第二步是有成本的，排队、超时、资源加载失敗都可能让渲染结果與用戶看到的頁面不一致。如果主要内容、導航連結都靠脚本生成，抓取路径的起点就變得不稳定。
連結寫在脚本里，會带来三個具体問题
- 發現延迟：連結不在初始 HTML 中，通常要等渲染完成才會被提取，新頁面進入抓取队列的時間會被拉長。
- 触發依赖：只有点击“加载更多”“展開全部”才出現的連結，蜘蛛一般不會主動去点，後續頁面就成了抓取死角。
- 渲染失敗即丢失：脚本报错、接口超时或被 robots.txt 屏蔽时，渲染後的 HTML 里就没有這些連結和内容。
让重要内容出現在初始 HTML 里
不一定整站都做服務端渲染，但至少要让入口层稳定：首頁、栏目頁、詳情頁的正文與主要導航，應该在第一個响應里就能看到。常见做法是服務端渲染或静態生成，客戶端再接管交互。纯靠接口返回 JSON、再由脚本插入正文的方式，等于把抓取的成功率交给渲染队列。
列表頁最好保留可点击的真實連結
“加载更多”用按钮實現时没有 href，蜘蛛没有可跟的地址。可以在列表下方保留传统分頁連結，或者让按钮同时带一個指向下一頁的真實 URL，两種入口並存並不冲突。
渲染後的連結同样參與 URL 發現
搜尋引擎會在渲染後的 HTML 中提取連結，所以只要渲染成功，脚本生成的地址仍然有机會被發現。問题在于這條路径更長、更依赖外部條件：渲染资源被拦、接口變慢、脚本报错，都會让原本能走通的路径断掉。因此判断标准不是“渲染後有没有連結”，而是“在最差情况下還有没有連結”。
別把渲染需要的资源挡在门外
robots.txt 屏蔽 JS、CSS 或渲染依赖的接口，會让渲染结果缺内容。可以重点检查這几項：
- JS、CSS 等静態资源路径是否可被抓取；
- 渲染過程中調用的内容接口是否要求登入態或短时效 token；
- 接口是否對非浏览器 UA 做了差异化處理；
- CDN 或 WAF 是否對频繁請求返回驗證頁面。
渲染是抓取之後的第二步，第一步拿不到的東西，不要指望第二步一定补回来。
上线前的自测顺序
- 禁用 JavaScript 打開頁面，看正文、導航和主要連結是否還在；
- 查看頁面源碼（不是审查元素），確認關键連結存在于 HTML 中；
- 用抓取工具對比渲染前和渲染後的 HTML，记錄差异；
- 检查渲染依赖的脚本、样式和接口是否返回 200，是否被 robots.txt 拦截；
- 在訪問日誌里確認蜘蛛是否請求了這些资源，以及返回碼是否正常。
改造精力怎么分配
優先級可以按“是否影响 URL 發現”和“是否是主要流量頁面”来定。導航、列表頁、詳情頁正文属于高優先；评论区、個性化推荐這類次要模块放到客戶端渲染問题不大。改造後不必追求立刻见效，观察抓取日誌里渲染相關资源的請求比例、新頁面首次被抓的時間變化，比盯着單日資料更可靠。