不少站長遇到過這样的场景：浏览器里打開頁面，正文、價格、评论区都在；一旦換成不执行脚本的方式去取同一份 HTML，返回的源碼里却只剩容器和占位符。而蜘蛛第一次拿到的，往往就是這份源碼。抓取問题的起点常常就在這里。
蜘蛛先拿到的是源碼，不是渲染後的画面
抓取一般分两步：先按 URL 取回 HTML，再排队做渲染。渲染要排队、要耗资源，不是每個 URL 都能立刻轮到，尤其当站点脚本重、接口慢、资源多的时候。所以判断一個頁面能不能被抓到，先看它在不执行脚本的情况下還剩多少内容，會比看截图更接近實际情况。
几種常见渲染方式對應的抓取结果
- 服務端直出：HTML 里就有正文和連結，取回即可解析，最省事。
- 同构或预渲染：首屏内容在源碼里，後續交互靠脚本，抓取基本没問题。
- 纯前端渲染：源碼是空壳，必须等脚本跑完，结果取决于渲染队列是否處理到你。
- 混合渲染：部分区块直出、部分延迟拉取，要逐块確認哪些在源碼里。
不必追求全站改成服務端直出，但至少要保證正文主体、主要導航、指向詳情頁的連結在源碼里能讀到。
懒加载最容易漏掉什么
懒加载的出發点是省流量、加快首屏，但對抓取並不友好，常见的有三個位置：
- 图片和视频先用占位图，進入视口才換成真實地址，图片资源可能一直没被取到。
- 列表頁第二屏之後的内容靠滚動加载，蜘蛛不會一直往下滚，後面的條目相当于没有入口。
- 评论区、規格參數、問答等模块要点「展開更多」才請求接口，這部分内容基本不會被讀到。
處理思路不是全部取消懒加载，而是留一层兜底：列表頁保留可点開的翻頁連結，折叠内容有獨立且可訪問的 URL，重要信息在源碼里至少有摘要。
内鏈和 URL 發現受影响更大
抓取路径是從連結開始的。如果連結要靠脚本点击才拼出来，蜘蛛很可能走不到下一頁。
比較稳妥的做法是：導航、面包屑、列表翻頁、相關阅讀這類结构，使用可被直接解析的 a 标簽加 href，指向真實的、返回 200 的 URL。脚本可以做增强，但不要让脚本成為唯一入口。配合 Sitemap 提交主要 URL，能补上一部分發現路径，但 Sitemap 替代不了站内連結。
怎么自查
- 用抓取工具或在浏览器里禁用脚本取一遍頁面，看标题、正文、内鏈是否還在。
- 對照服務器日誌，確認蜘蛛取回的 URL 是否返回 200，响應体長度是否正常。
- 抽查几個重要落地頁，比較「源碼里有的内容」和「用戶看到的内容」差多少。
- 用抓取調试類工具查看解析後的内容，辅助判断差异出在渲染還是接口。
改造顺序建议
優先做收益明顯的部分：把正文和主要導航直出；把列表頁翻頁做成真實連結；给 Sitemap 补齐核心栏目；把折叠内容拆成可訪問的獨立地址。服務器與接口的稳定性也要跟上，渲染队列排到你的頁面时如果接口超时或返回 5xx，這一趟基本等于白来。
最後提醒一句：要不要全站服務端渲染，取决于站点規模和维護成本。多數内容站只要保證「關键内容不依赖脚本、關键連結不依赖点击」，抓取路径就會顺畅不少。具体效果因站而异，建议改完之後用日誌观察一段時間，再决定下一步動哪里。