很多頁面在浏览器里看得见、点得動，爬虫拿到的源碼里却只有一句“請開啟 JavaScript”。這類頁面的收錄問题，往往不是内容质量不够，而是抓取阶段就没拿到可用的正文和内鏈。下面這套检查顺序，适合在頁面類型确定後、批量铺開之前先跑一遍。
先分清两件事：源碼里有的，和渲染後才有的
把頁面源碼（查看網頁源代碼，不是审查元素）複製出来，搜一下你的核心關鍵詞、标题、正文首段。如果搜不到，說明這些内容依赖脚本执行後才出現。爬虫通常先取原始 HTML，再决定是否渲染；渲染是有成本的，站点层級越深、资源越重，被完整渲染的概率越不稳定。
顺带確認三样東西是否也在源碼里：
- 正文主体和關键结论段
- 指向下一层頁面的連結（可点击的 a 标簽）
- 标题、描述、canonical 等元信息
四個常见的“自己把自己挡住”的做法
- 正文由接口异步填充。HTML 里是空的容器，内容靠 XHR 或 fetch 拿回来。爬虫不执行或只执行一部分脚本时，頁面就等于空白。
- 連結用 JS 跳轉。onclick 或路由跳轉代替了 a 标簽的 href，内鏈图谱會断掉，新頁面难以被及时發現。
- robots.txt 屏蔽了 JS、CSS 或接口。想让爬虫渲染，却不让它取渲染所需资源，结果只能看到一個残缺頁面。
- noscript 里放的是提示语而不是内容。它不會替你补上正文，只是多一段無意义的文字。
驗證爬虫實际拿到什么
比較省事的顺序是：先看源碼，再用不带脚本的方式請求一次（命令行 curl 或關閉浏览器 JS），對照两次结果的差异。差异集中在正文、列表、價格、分頁這些位置，就值得改；差异只在外层的悬浮组件、推荐模块，優先度可以往後排。
再看服務端日誌里 JS、CSS、接口請求的来源與比例。如果搜尋引擎爬虫几乎没有請求過渲染资源，說明它很可能只看到了初始 HTML。此时不用急着归因到“被降權”，先把渲染环节补上更實际。
几種調整方式，按改造成本排序
- 關键内容直出：标题、首段结论、主要連結寫成 HTML，脚本只负责增强交互。
- 预渲染或静態生成：在构建或缓存阶段生成 HTML，适合内容頁、詳情頁。
- 服務端渲染：改造量大，适合确實需要動態交互、又必须被索引的頁面類型。
- 路由與分頁 URL 分開處理：确保每個需要被發現的頁面有獨立、可直接訪問的地址。
改完之後核對什么
改動上线後，先看日誌中對應頁面類型的抓取是否發生變化，再看索引报表里這些 URL 的覆盖狀態。別只看首頁和少數样板頁，按目錄或模板各抽几條，確認正文、内鏈、canonical 都正常。收錄本身有滞後，短期没有變化是常见情况，不建议反复改動同一批 URL。
判断标准可以简化成一句：關掉 JavaScript，這個頁面還剩下多少可讀内容和可爬連結。剩下的部分越接近用戶看到的版本，收錄环节的阻力就越小。