很多站点运营問题，不是蜘蛛不来，而是它来了却看不到内容。你在浏览器里能正常浏览的頁面，搜尋蜘蛛拿到的初始 HTML 可能只有一個導航、一個空容器和几段脚本。是否渲染、渲染到什么程度，取决于搜尋引擎的能力和你的頁面實現。定期做一次渲染方式自查，可以避免整站内容在抓取环节就被打薄。
蜘蛛拿到的是初始 HTML，不是你的屏幕
搜尋引擎抓取一個 URL 时，首先获取服務器返回的 HTML 文档。之後是否执行 JavaScript、执行多久、执行後是否重新入库，属于額外的渲染流程，不同引擎、不同頁面類型並不完全一致。對于依赖客戶端渲染的頁面，如果接口資料、正文、列表連結都靠脚本插入，蜘蛛在第一步就可能只拿到空壳。
這不等于所有 JS 頁面都不會被索引，但意味着你把内容可见性押在了不可控的环节上。站点运营更稳妥的思路是：核心内容在初始 HTML 中就能看到，脚本只做增强。
三類容易被忽略的空壳寫法
正文完全靠前端接口拼装
頁面 HTML 里只有一個空容器，标题、正文、發布時間、作者都等接口返回後再渲染。訪客体驗可能很好，但蜘蛛拿到的初始文档信息量极低。若站点地图又直接提交了大量這類 URL，抓取预算會被消耗在重复的渲染尝试上。
列表和栏目連結由脚本生成
栏目頁的詳情連結寫在 JSON 資料里，通過模板循环輸出。蜘蛛如果不执行脚本，就發現不了下一层 URL；如果执行，也可能因為超时只拿到前几條。URL 發現鏈路因此變窄，新内容上线後等待時間變長。
图片、選項卡和折叠内容預設不落地
图片使用 data-src 懒加载，但没有 src 占位；選項卡内容点击後才請求；商品參數需要展開才顯示。這些做法對性能友好，但要把關键信息留在初始 HTML 中，或者至少提供可抓取的連結與文本。
运营层面的處理顺序
- 先分清頁面類型。詳情頁、栏目頁、帮助文档、商品頁這類承担收錄和轉化的頁面，優先保證初始 HTML 可讀。纯交互工具頁、後台頁不必强求。
- 核心内容改由服務端輸出或预渲染。服務端渲染、静態生成、预渲染都可以，關键是服務器返回的 HTML 里有正文和連結。
- 導航與分頁使用真實連結。用 <a href> 輸出可抓取地址，不要只绑 onclick。參數分頁、篩選排序也要控制可發現范围。
- 图片與媒体补上基础标簽。img 的 src、alt，视频的标题與說明，尽量在初始 HTML 中给出。
- 用日誌和抓取结果驗證。看服務器日誌里蜘蛛請求的狀態碼、响應字节數，以及它請求了哪些 URL。再结合搜尋片段判断内容是否被识別。
服務器與缓存也要一起看
有些空壳不是前端造成的，而是缓存层返回了错誤版本。比如 CDN 缓存了未渲染的模板、Vary 头配置不当、接口超时後返回空資料。运营和開發需要一起確認：不同 User-Agent、不同地区、有無 Cookie 时，HTML 是否稳定。必要时對重要頁面設定合理的缓存策略，並在發布後主動刷新缓存。
搜尋引擎的渲染能力是补充，不是兜底方案。把内容放進初始 HTML，仍然是最省心的做法。
一份简單的自查清單
- 用 curl 或查看網頁源代碼，確認正文、标题、主要連結是否出現在 HTML 中。
- 對比浏览器渲染後的頁面與源代碼，差异是否集中在核心内容区。
- 检查栏目頁前几條詳情連結是否存在于初始 HTML。
- 查看日誌中蜘蛛請求的响應字节數，是否長期偏小。
- 检查站点地图提交的 URL，是否大量指向需要脚本才能顯示内容的頁面。
- 前端框架升級、模板改版、CDN 規則調整後，重新抽查一轮。
渲染方式自查不需要一次改完整個站。先從流量大、更新频繁的栏目開始，把正文和服務端連結稳定住，再逐步處理次要頁面。蜘蛛能稳定拿到内容，後續的 URL 發現、收錄和排名才有讨论的基础。