产品参数表由接口异步加载，百度抓取时看不到怎么办

网站项目验收时，产品页在浏览器里看起来很完整：型号、额定压力、接口尺寸都排在参数表中。可一看网页源代码，这些规格一个也没有，页面只留着一个名为 spec-table 的空容器。参数要等浏览器执行 JavaScript，再向产品接口取回数据。用户能看到，不代表百度抓取时一定拿得到。遇到这种产品参数表异步加载问题，先确认关键规格究竟由服务器输出，还是只存在于脚本运行后的页面里。

产品参数表异步加载，先分清数据停在哪一层

检查时不要只用鼠标看页面。打开“查看网页源代码”，搜索一个确定存在的型号或参数名，再到开发者工具的 Elements 面板搜索同一内容。源代码没有、Elements 里有，说明浏览器执行脚本后才把参数写入 DOM。接着查看 Network 中的 Fetch/XHR 请求，记录接口地址、请求方法、状态码和返回时间。常见请求类似 /api/product/spec?id=128，返回值里应能找到字段名、单位和对应数值。

接口返回 200 也不能直接判定抓取正常。返回体可能要求登录，可能只有空数组，也可能依赖浏览器先写入 Cookie。还要用无登录状态访问接口，检查是否出现 401、403、跨域错误或超过十秒才返回。若参数接口被 robots.txt 禁止、需要前端临时令牌，搜索抓取程序就算执行脚本，也可能得到一个空表。网站上线时还应复核测试站遗留的 robots.txt 抓取限制，避免页面开放了，数据接口仍被挡住。

另一个容易漏掉的环节是接口字段映射。后台保存的是 rated_pressure，前端模板却读取 working_pressure，浏览器可能显示占位符或旧缓存。核对时要从产品资料表选取两项稳定字段，例如型号和接口尺寸，再沿着数据库记录、接口 JSON、页面 DOM 逐层比对。参数名称、单位和空值规则都应一致，不能只确认“表格出现了”。

让关键规格跟着首个HTML响应一起到达

对采购判断有直接作用的规格，适合由服务器在首个 HTML 响应中输出。型号、适用介质、尺寸范围和资料版本可以先生成静态表格，筛选、排序或单位切换再交给 JavaScript。这样即使脚本加载失败，页面仍保留可读信息。前端框架项目可采用服务端渲染或构建时生成，传统 CMS 则直接在内容模板里循环输出参数字段。

如果项目暂时不能改渲染方式，可以先做降级内容。参数区域放一份与数据库同步的基础规格表，脚本成功后再替换成可交互版本。基础表不能写成隐藏文本，也不应把全部型号塞进同一页面。每个产品页只保留当前型号及必要的选型边界，表头使用真实字段名称，单位紧跟数值。产品手册下载可作为补充，但不能让 PDF 成为网页上唯一的参数来源。

页面的 title、description 和正文也要与可见参数对应。若正文写“耐压等级详见参数表”，而首个响应里没有耐压字段，搜索摘要很难确认这句话的依据。处理前端接口时，可参照官网上线后检查前端接口地址的方法，同时核对生产域名、缓存键和接口版本，防止预发布地址继续向正式页面供数。

上线前按百度实际访问路径验收

验收应保留两份结果：一份是未执行脚本的原始 HTML，一份是浏览器渲染后的 DOM。两份文件都搜索主型号和关键参数。原始 HTML 至少应包含本页核心规格；渲染结果还要确认没有重复表格、单位错位或脚本报错。随后用手机百度常见的 User-Agent 和普通桌面 User-Agent 请求页面，比较状态码、正文长度与参数字段，排除按设备返回空内容的情况。

还要测试接口异常。临时阻断参数请求或降低网络速度，重新打开产品页。若标题、产品名称和基础规格仍然可读，降级方案才算有效。接口失败时不要把页面跳到统一错误页，更不能返回内容很少的 200 页面；这类响应容易与不存在页面返回200形成软404的问题混在一起。接口日志中应能按产品 ID 查到请求时间、响应码和版本号，便于定位是哪次发布造成参数缺失。

修正完成后，不必等待搜索结果变化才判断是否成功。直接复查规范网址、页面源代码、参数接口和站点地图中的产品地址，再从产品列表进入该页走一遍。核心规格已经出现在首个 HTML 响应中，脚本只负责增强交互，百度与采购人员看到的页面基础信息才会保持一致。