現在不少站点是用前端框架搭出来的，頁面在浏览器里看着正常，但右键查看源代碼，body 里可能只有一個空的 div。蜘蛛第一次拿到的，往往就是這份原始 HTML。如果正文、連結、标题信息全靠脚本执行之後才出現，就等于把發現内容的门槛抬高了。這篇自查不讨论哪種技術方案更好，只關注一件事：蜘蛛實际拿到的頁面里，有没有你要它看到的東西。
先確認蜘蛛看到的是什么
不要只在浏览器里看效果，那看到的是脚本执行後的 DOM，不是服務器返回的原始内容。几個低成本的動作可以先做起来：
- 查看源代碼：右键選“查看網頁源代碼”，而不是“检查元素”。前者是服務器返回体，後者是渲染结果，两者经常差別很大。
- 命令行取頁面：用 curl 拉一份 HTML，例如 curl -s https://example.com/page | head -50，看 title、正文關鍵詞、主要内鏈有没有出現在返回体里。
- 抓取調试工具：各家搜尋平台一般都有 URL 检查或抓取測試，可以對照抓取到的 HTML 與渲染後的结果。
- 關閉 JavaScript：浏览器禁用 JS 後刷新，没有脚本时剩下什么内容，一眼就能看出来。
几種渲染方式，風險点不一样
服務端渲染
服務器直接把完整 HTML 返回，蜘蛛拿到的就是你想给它的内容。要注意的是服務端多做一层渲染，首字节時間會變長，缓存和並發能力要跟上，否則抓取速度會明顯變慢。
预渲染
對不常變的内容提前生成静態 HTML，再由前端接管交互。要确保预渲染版本和线上實际内容一致，別出現過期快照被蜘蛛長期儲存的情况，内容更新後记得触發重新生成。
纯客戶端渲染
原始 HTML 近乎空壳，正文、列表、内鏈都要等接口返回後才能拼出来。搜尋引擎虽然也會排队做渲染，但渲染资源有限且有超时，頁面层級越深，越容易被跳過。
自查清單
- 關键信息是否在原始 HTML 中：title、meta description、canonical、正文首段、主要小标题。
- 内鏈是否為真實的 a 标簽 href，而不是 onclick 跳轉或 div 绑定点击事件。
- 接口是否允许抓取：robots.txt 里被誤屏蔽的資料接口路径，會让渲染阶段拿不到資料。
- 渲染是否依赖登入態、地区、cookie 等條件，這些條件蜘蛛通常不具备。
- 懒加载是否把首屏图片地址寫在 data-src，而在無脚本时没有可用的 src。
- 分頁、标簽頁、折叠内容是否只在点击之後才插入 DOM。
- 渲染超时：接口慢的时候，脚本還没执行完，抓取就已经結束了。
- 移動端與桌面端是否共用同一套渲染逻辑，避免一端正常、另一端空壳。
從服務器日誌里找线索
頁面抓取和接口請求通常會分別落在日誌里。可以观察同一次訪問中，頁面 URL 之後有没有跟着對應的資料接口請求；如果只看到頁面 URL，或者接口返回 403、500，說明渲染鏈路在某一步断了。這類問题往往只在特定目錄或特定模板上出現，按路径分组統計比整体看更容易定位。
渲染只是让内容對蜘蛛可见，能不能被收錄、排到什么位置，仍取决于内容本身和站点整体质量。自查的作用是排除障碍，不是替代内容建设。
相對稳妥的做法
優先保證首屏關键内容由服務端輸出；把主要導航、面包屑、正文連結放在 HTML 里；前端路由配合真實可訪問的 URL；資料接口對爬虫放開；给渲染结果加一层缓存。調整完之後，用同一批 URL 再跑一次對比，看看原始 HTML 里多出了什么、少了什么，比凭感觉判断靠谱。
渲染方式不是一次性决定的事。站点改版、換框架、新增栏目，都可能悄悄改變蜘蛛看到的内容。把它列進每次上线前的检查項，比等到發現收錄下滑再回头排查要省事得多。