很多页面在浏览器里看得见、点得动，爬虫拿到的源码里却只有一句“请开启 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，这个页面还剩下多少可读内容和可爬链接。剩下的部分越接近用户看到的版本，收录环节的阻力就越小。