用浏览器打开页面，正文、图片、评论都正常显示，于是默认蜘蛛看到的也一样。但如果这些内容是脚本跑完之后才插进 DOM 的，抓取阶段拿到的原始 HTML 可能只有一个空容器和一句「加载中」。收录核对时这一步没分开，后面再查内链、查重复、查指令层，都容易跑偏。
抓取和渲染是两步，别把浏览器里的结果当成抓取结果
搜索引擎处理一个 URL 通常分两步：先请求 HTML，拿到响应就算完成了抓取；之后如果还有余力，才排进渲染队列，用类似浏览器的环境把页面跑一遍。第二步是有成本的，会排队、有额度，也可能失败或被跳过。
所以同一个页面会出现两种状态：原始 HTML 里已经有正文，渲染只是补充；原始 HTML 里没有正文，全文都得等渲染。只有后一种，才会把收录卡在渲染这一环上。
核对方法：把原始 HTML 和渲染后的 DOM 放在一起比
- 查看源代码，搜索正文里最有特征的一句话，确认它在不在初始响应里。
- 用命令行工具直接请求该地址，排除浏览器缓存和登录状态的影响。
- 在浏览器里禁用 JavaScript 再打开页面，看还剩多少内容能读。
- 再用开发者工具里的渲染后 DOM 对比一次，分清差异落在正文、链接还是仅样式。
- 抽一批核心 URL 批量做，按「有正文」「部分有」「全空」分成三类，不要一页一页猜。
哪些写法最容易让原始 HTML 变成空壳
- 整站客户端渲染，服务端只返回一个挂载节点。
- 正文前半段正常，后半段靠滚动懒加载，首屏之外的文字抓不到。
- 内容藏在标签页、折叠面板或轮播里，默认只渲染第一屏。
- 标题、价格、库存等字段由接口拼接，HTML 里只有占位符。
- 列表和翻页由脚本生成，站内链接同样不在初始响应中。
链接也要出现在原始 HTML 里
内容和链接是两件事。正文靠渲染补回来，还有机会补；但站内链接如果只写在脚本里，URL 发现就少了一条稳定通道——脚本不跑，这条边就不存在。核对时把详情页、栏目页的入口链接单独查一遍，确认它们是可点击的 a 标签，并且指向最终地址，而不是先跳一次再落地。
能改的方向，按优先级排
- 核心页面优先：详情页、栏目页、文章页这些要被收录的，尽量在服务端就输出正文和链接。
- 预渲染或静态化：用 SSR、SSG 或预渲染服务，把渲染成本从蜘蛛那边挪回自己这边。
- 首屏兜底：即使用了前端框架，也保证无脚本时有一段可读正文和基本导航。
- 列表与分页用真实链接：不要只靠按钮事件翻页，让每一页都有可抓的 URL。
- 不要全靠渲染赌收录：渲染队列有额度，能不能排到、排到之后是否成功，都不在站点控制之内。
核对的目的不是证明页面能被渲染出来，而是确认在蜘蛛最省事的那一次请求里，页面已经把该说的话说清楚了。
最后留一个观察窗口。把问题页面按类别修完，隔一段时间再回来看初始响应有没有变化，而不是改完当天就下结论。