頁面用前端框架渲染，在浏览器里看一切正常，但搜尋索引里要么找不到這個地址，要么标题和摘要都是模板里的預設值。遇到這種情况，常见的解释是「蜘蛛不执行 JavaScript」。這個说法只说對了一半。更准确的描述是：蜘蛛處理頁面分成原始 HTML 和渲染後 DOM 两個阶段，两個阶段之間的差距，决定了這條 URL 最终能不能進索引。
抓取和索引之間，差的可能是一整次渲染
蜘蛛第一次請求拿到的，通常是最初返回的那份 HTML 源碼。如果标题、主内容、正文内鏈都要等脚本执行之後才出現，那么這次請求在它眼里就是一個空壳。空壳不一定會被直接丢掉，它可能進入渲染队列等待二次處理，也可能因為信号太弱被搁置。索引里最终留下什么，取决于渲染這一步有没有顺利完成。
所以「抓到了」和「收錄了」中間還隔着一层。站点日誌里有訪問记錄，只能說明抓取發生過，不能說明它讀到了你希望它讀到的内容。
先做一次不执行脚本的自检
成本最低的核對方式，是把頁面的 JavaScript 關掉再看一遍。
- 在浏览器里禁用 JS 後重新加载，看還剩多少可讀内容；
- 查看「查看網頁源代碼」，而不是開發者工具里的 Elements 面板；
- 用不执行脚本的方式請求一次，對比返回的 HTML 與你看到的是否一致；
- 確認标题、主段落、正文内鏈是否已经出現在這次返回里；
- 检查结构化資料是寫在 HTML 中，還是靠脚本注入的。
如果關掉 JS 之後頁面几乎空白，那收錄問题大概率就出在這里，而不是別的地方。
怎么判断蜘蛛有没有真的渲染
渲染是要額外消耗资源的，不一定會對每個地址都做。可以從几個侧面观察：
- 日誌里渲染請求往往来自另一批 IP 或带不同的 UA 标识，出現频次明顯低于普通抓取；
- 站長平台的網址检查工具通常會分別展示原始 HTML 和渲染後的结果，直接對比即可；
- 如果渲染队列迟迟没有来，索引里留下的自然只有原始 HTML 那点信息。
渲染环节常见的几個卡点
内容依赖交互才出現
点击、滚動、切換标簽頁之後才加载的内容，渲染阶段未必會触發。把關键内容放在預設狀態、首屏位置，稳妥得多。
接口請求被規則挡住
頁面本身允许抓取，但它調用的接口被 robots 規則或防火墙拦截，渲染出来依然是空的。排查时要连着接口路径一起看，別只盯着頁面地址。
超时與资源阻塞
第三方脚本、埋点、字体加载慢，渲染可能在内容出現之前就結束了。核心内容尽量不依赖外部资源，越早進入 DOM 越好。
一個可执行的核對顺序
- 關掉 JS，確認原始 HTML 里有没有标题和主内容；
- 比對渲染前後两份结果，看差距有多大；
- 查日誌，確認渲染請求有没有發生、频率如何；
- 检查渲染所依赖的接口與静態资源是否可訪問；
- 把必须進索引的内容前置到原始 HTML，再观察索引狀態的變化。
不一定要整套上服務端渲染
很多頁面只是「主内容在脚本里」這一個問题。把标题、摘要、正文主体、關键内鏈放在服務端輸出的 HTML 中，其余交互留给前端，往往就够用了。全部改成服務端渲染，改造量更大，也未必是目前最需要做的事。
收錄核對的重点不是争论蜘蛛的渲染能力，而是找出原始 HTML 里缺了哪一块。补齐那一块，通常比反复解释「它能执行 JS」更有用。