很多站点把正文、列表甚至链接都交给前端 JS 渲染，浏览器里看着正常，爬虫拿到的却是一份空壳。结果就是：页面能打开，日志里也有抓取记录，但迟迟不进索引。
第一步：先看爬虫拿到的是什么
排查的起点不是改代码，而是确认爬虫实际看到的 HTML。用查看源码、命令行请求或搜索引擎提供的网址检查工具，看原始响应里有没有正文和链接，不要只看浏览器渲染后的结果。
- 原始 HTML 里有正文和链接：问题更可能出在内容质量或索引取舍上。
- 原始 HTML 里只有挂载点和提示文案：收录慢大概率就是渲染问题。
三种常见情况
1. 内容完全由接口拉取
HTML 只剩一个空容器，正文靠页面加载后再请求接口填充。搜索引擎执行 JS 需要额外队列和延迟，也会消耗抓取资源，新页面的等待时间往往比静态输出的页面长得多。
2. 内容存在，但要交互才出现
标签页切换、折叠面板、点击“查看更多”才加载的段落，在初始渲染里通常并不存在。用户看得见，爬虫看不见，收录自然无从谈起。
3. 内容可见，链接不可发现
列表用 div 加点击事件实现，没有 a 标签和 href。爬虫即使渲染了页面，也缺少可跟随的 URL，新地址只能依赖 sitemap 被发现，收录速度会被拉长。
按这个顺序处理
- 关键内容服务端输出：正文、标题、面包屑、主要链接放在首屏 HTML 里，前端再接管交互。
- 链接用真实的 a 标签：href 指向可抓取的地址，不要只用 JS 跳转。
- 分页与列表给稳定地址：无限滚动配合分页 URL，让翻页内容有入口。
- sitemap 兜底：重要 URL 放进 sitemap，但不要用它替代站内链接。
- 提交后看日志：观察抓取频次和状态码变化，再决定是否继续调整。
几个容易忽略的细节
- 懒加载的图片和文本若在 DOM 中完全缺失，等于没发布。
- 正文分散在 iframe 或多个组件里拼接，可能被拆散甚至丢失。
- 接口或 CDN 超时导致渲染失败时，返回的可能仍是一个 200 的空壳页。
- 移动端与桌面端渲染结果差异过大，会让抓取到的版本不一致。
蜘蛛池、抓取工具之类的手段提高的是被访问的机会，解决不了“爬虫看不到内容”这件事。内容可见性和链接可发现性没做好，抓取再多也不会自动变成索引。
怎么确认改动是否生效
对比修改前后同一 URL 的原始响应，确认正文和链接已出现在 HTML 中；再结合服务端日志，看这类地址的抓取是否稳定、有没有 4xx 或 5xx。索引变化通常滞后，不必每天盯着查。若内容本身可替代、与站内已有页面高度重复，即便渲染问题解决了，也不一定被收录，这时要把精力放回内容规划和 URL 收敛上。