先確認一件事：不执行脚本时，頁面還剩什么
很多站点用前端框架搭建，頁面在浏览器里看起来完整，但服務器返回的初始 HTML 可能只有一個空容器和一堆脚本标簽。對訪客来说，脚本跑完内容就出現了；對抓取端来说，如果它不执行或只执行一部分脚本，讀到的就是空壳。這不是收錄與否的保證书，但會让内容進入解析流程之前先多一道门槛。
做站点运营时，可以把它当成结构自查的一部分：不讨论蜘蛛會不會执行脚本，只看關键内容是否出現在初始响應里。如果标题、正文、内鏈、分頁入口都在 HTML 中直接可讀，後續的發現和解析會少很多不确定因素。
自查方法：三個角度看頁面輸出了什么
1. 直接查看網頁源代碼
在浏览器里按 Ctrl+U 或右键查看源代碼，搜尋正文里的一句话。如果搜不到，但在頁面上能看到，說明這段内容大概率由脚本注入。也可以關掉浏览器 JavaScript 再刷新，看看是否還能讀到主要内容。注意，部分站点關閉 JS 後頁面样式會乱，但正文仍應存在。
2. 用命令行看原始响應
使用 curl 或類似工具請求頁面，把返回内容儲存下来，再检查其中有没有目标關鍵詞、連結和结构化信息。這個方法不受浏览器渲染影响，能看到服務器實际發出的東西。重点看：标题、正文首段、栏目連結、分頁連結、canonical 地址是否在返回内容中。
3. 對比抓取日誌與頁面地址
如果站内已有抓取日誌，可以挑一些被抓取過的詳情頁，和它們目前返回的 HTML 做對照。日誌顯示抓取成功，並不代表内容被完整讀到。把日誌里的地址手動請求一遍，观察返回内容里是否有實质信息，能帮你判断問题出在渲染還是別處。
常见的“空壳”场景
- 列表頁和詳情頁由同一個前端路由渲染，服務器只返回框架入口文件。
- 正文、價格、库存、评论等資料通過接口异步加载，初始 HTML 不包含這些字段。
- “加载更多”和無限滚動只改前端狀態，分頁地址没有被寫入連結。
- 導航和面包屑用 div 加点击事件實現，没有可跟随的 a 标簽地址。
- 頁面标题和描述在脚本里動態設定，初始 HTML 里是預設值或空标簽。
這些情况不一定都影响抓取，但會增大解析成本。尤其是内鏈和分頁入口，如果它們只存在于脚本里，URL 發現的路径就變窄了。
調整思路：把關键内容放回 HTML
- 優先服務端輸出。 用服務端渲染、静態生成或预渲染，让正文、标题、内鏈在首次响應中就可讀。框架通常都有對應方案，選适合現有技術栈的即可。
- 關键字段前置。 如果整站改造周期長，至少把标题、摘要、正文首段、主要栏目連結和分頁連結放到服務端模板里。
- 連結用真實地址。 導航、面包屑、卡片、分頁都尽量使用 a 标簽指向獨立 URL，避免只用 JS 跳轉。這样既方便訪客新開标簽，也方便抓取端顺着連結走。
- 异步内容保留降級。 必须异步加载的模块，可以给出静態占位或基础信息，不要求所有内容都實时渲染，但不要让核心信息完全缺失。
- 检查缓存與响應头。 服務端渲染後，確認缓存没有把空壳版本長期存下来，也確認 Content-Type 和编碼没有引發解析問题。
渲染方式自查不是追求某種技術路线，而是確認頁面在“不跑脚本”的情况下，是否還能把主要内容、层級和入口交代清楚。
内鏈與分頁也要能被直接訪問
就算正文已经服務端輸出，内鏈和分頁如果仍然依赖脚本，URL 發現還是會變窄。检查栏目頁、标簽頁、上一篇/下一篇、分頁按钮，看它們是否對應真實可訪問的地址。分頁地址最好保持简洁稳定，不要每次渲染都生成带随机參數的連結。站内搜尋结果頁、篩選頁如果由脚本生成，也要確認是否值得让抓取端進入；如果不希望它們被反复發現，可以用合适的規則控制，而不是放任脚本不断产生新地址。
把它放進日常巡检
改版、換框架、上新栏目之後，抽几個代表性頁面做一次原始响應检查，成本不高，但能避免“頁面上看着正常，服務器返回的却是空壳”這種落差。站点运营不需要把所有頁面都改成纯静態，但至少要让重要内容在初始 HTML 中有迹可循。這样做不保證收錄或排名，只是减少内容被讀到之前的多余损耗。