要确认百度蜘蛛抓取动态页面时能看到什么,不能只看浏览器里的画面,而应回到“抓取时返回的HTML源码”。动态页面常见两种处理方案:服务端渲染(SSR)和客户端渲染(CSR)。判断核心是:百度蜘蛛拿到的那份HTML里,目标内容是否已经存在。若不存在,就需要进一步观察百度蜘蛛是否执行JavaScript、执行到什么程度,再决定改用哪种方案。
用浏览器打开动态页,按 Ctrl+U 查看“查看网页源代码”,而不是按 F12 看Elements面板。Elements显示的是JavaScript执行后的DOM,源码才是服务器最初返回的内容。对比两者:
<div id="app"></div>,目标文字全部由脚本注入,说明依赖JavaScript渲染。这一步只能说明“初始HTML是否包含内容”,不能直接断定百度蜘蛛一定看不到。百度对JavaScript渲染有一定处理能力,但渲染结果受资源加载、脚本执行时间、抓取配额等影响,不能假设与浏览器完全一致。因此需要继续做抓取层面的核查。
百度搜索资源平台提供抓取诊断类工具,可提交具体URL并查看抓取返回的HTML。操作步骤:
同时检查服务器访问日志,筛选百度蜘蛛的User-Agent,观察它请求了哪些URL、返回状态码是多少、是否请求了JS和CSS资源。判断结果:
需要注意,robots.txt 的抓取限制不等于可靠的索引移除。若用robots.txt屏蔽JS或接口,可能让蜘蛛无法获取渲染所需资源,反而使内容不可见;而即使屏蔽了抓取,已收录页面也不一定立即消失。
方案一:服务端渲染(SSR)。服务器在返回HTML前就把动态数据拼好,蜘蛛拿到的源码直接包含可见内容。适用条件:内容对收录和排名重要、页面数量可控、团队能维护服务端逻辑。优点是抓取确定性高,不依赖蜘蛛执行JS;缺点是服务器压力较大,前端与后端协作成本更高。
方案二:客户端渲染(CSR)配合预渲染或动态渲染。保持前端框架不变,对百度蜘蛛返回预渲染后的静态HTML,对普通用户仍走客户端渲染。适用条件:已有成熟前端工程、不想大改架构、页面内容更新频率可接受预渲染延迟。优点是改动相对小;缺点是预渲染服务需要维护,内容时效性可能滞后,且要确认百度蜘蛛识别与返回策略是否正确。
选择依据可以归纳为:如果抓取诊断显示百度蜘蛛稳定拿到完整内容,可维持现状并持续监控;如果显示目标内容缺失,且日志确认蜘蛛未执行关键JS,优先考虑SSR;如果短期内无法改架构,可先用预渲染兜底,但要把它当作过渡而非永久方案。
调整方案后,按以下项目复查:
复查周期建议以周为单位,观察抓取频次和返回内容是否稳定。若内容仍不可见,回到第一步重新对比源码与渲染结果,定位是资源加载失败、脚本报错还是抓取策略问题。下一步可直接选取一个代表性动态页,完成一次抓取诊断并保存返回HTML,作为后续对比基线。