产品参数在屏幕上看得到，查看页面源码却只有一个空容器。对于依赖JavaScript的网站，读取初始HTML与运行脚本以后得到的材料可能不同。收录排查应先明确差异在哪里，不能仅凭自己的浏览器显示正常就结束。
选真实业务页，先看移动版本
在XunL Googlebot模拟器输入公开产品、分类或文章地址，选择手机版或电脑版。可以用自己正在排查的产品详情页做样本，保留完整最终路径，不要只用首页替代所有页面类型。
先记录移动结果，再按需要比较桌面。重点不只是页面能否打开，还包括关键文字、主标题、规范地址和不索引指令在两种阶段是否一致。工具使用Googlebot公开User-Agent，但请求来自本站服务器，不是Google网络，不能称作真实Google抓取记录。
找到“只有运行脚本才出现”的重要内容
假设产品页名称在原始HTML里，参数表却通过接口后加载。对比时应把参数表标记为依赖脚本，再问资源是否允许取得、脚本是否报错、请求是否在预算内完成。不要把所有黄色差异都理解为故障，也不要把渲染成功推导成所有服务都会看到同样材料。
渲染阶段还可能改变title、canonical和noindex。若初始规范地址与渲染后不同，先核对应用设计与模板来源；不应只让其中一处看起来正确。关键索引信息出现矛盾时，应由开发确认预期输出并在修改后复测。
公开参数、价格和说明等重要内容，通常更适合稳定地出现在初始HTML中，减少对额外执行步骤的依赖。但具体架构调整应结合现有系统，不要为了修一个检测差异就仓促重写整个前端。
资源限制与交互边界，也会改变观察
模拟器在隔离浏览器中进行受限渲染，遵守适用robots规则，不替你登录或提交表单，也不完整加载图片与视频。需要点击展开、滚动或登录才能出现的内容，不能按普通公开正文假定已经覆盖。
如果某个脚本被规则阻挡，先确认它是不是页面正常呈现所需资源。不要机械禁止整段公共资源目录，再期待搜索渲染仍然完整。另一方面，页面使用了某个框架，并不自动意味着内容缺失；服务端输出或静态生成同样可以让初始HTML已有正文。
用模拟定位，再用真实平台核实
把观察记录成“原始材料有什么、渲染后新增什么、哪条资源或标签异常”。修复以后用同一页复测，确认问题来源已经改变。自己拥有的站点还应使用Search Console网址检查与日志核实真实抓取、渲染与索引状态。
如果防火墙验证真实Google来源，模拟请求可能被区别对待。一次403不够证明真正Googlebot无法访问；模拟返回成功也不等于已经收录。报告适合安排下一步调查，不应被包装成搜索可见性的保证。
检测不到动态内容，就必须更换框架吗？
先查数据请求、资源权限、错误和输出方式。问题可能局部解决，也可能需要架构调整；应根据具体证据决定，不按框架名称直接判定重做。
渲染后有内容，AI服务也一定能获取吗？
不能一概而论。不同服务的获取方式与能力不同，关键公开信息在初始HTML中更容易被检查。实际获取和引用仍要另找证据。
个人微信：ssevening
