360收录：静态响应与脚本渲染结果不同时怎样定位差异
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /afa557cab97a.html
📄
360收录：静态响应与脚本渲染结果不同时怎样定位差异
先直接回答：把同一个URL分别取“不执行脚本的原始响应”和“执行脚本后的DOM”，逐段比对正文、链接、canonical、robots元标签和结构化数据；差异集中在哪一段，问题就落在哪一段的生成链路上。判断的关键不是哪份结果“更好看”，而是360搜索实际拿到的是哪一份，以及两份结果中哪一份与页面真实内容一致。
先固定比较对象，避免两边取的不是同一个页面
差异定位失败，最常见的原因是比较对象不统一。你需要在同一时间、同一URL、同一User-Agent下取两份结果：一份是禁用脚本后的原始HTML，一份是脚本执行完成后的DOM。如果两次请求之间页面内容本身在变（比如A/B测试、地域分流、登录态差异），后面的比对全部作废。
具体动作：用同一UA分别抓取，保存为两个文件，先比对HTTP状态码和最终URL。如果状态码或跳转链不同，先解决这一层，不要急着看正文。这一步的结果决定下一步：状态码一致才进入内容比对，不一致则说明差异来自服务端分流而非渲染。
按五个字段逐段比对，锁定差异发生的层级
把两份结果按下面顺序对照，先看靠前的字段，因为前面的差异会连带影响后面：
- 正文主体：原始响应里正文是否为空壳容器，脚本执行后才有文字。若是，说明内容依赖客户端渲染。
- 站内链接：原始响应中
<a href>是否缺失或为占位符，脚本执行后才注入真实地址。 - canonical：两份结果是否指向同一URL，脚本是否改写了它。
- robots元标签：脚本是否在渲染后插入
noindex，而原始响应里没有。 - 结构化数据：JSON-LD是写在原始HTML里，还是脚本拼装后才出现。
这五项里，只要有一项两边不同，就说明该字段的生成方式与其余字段不一致。差异字段越靠前，对抓取和索引的影响路径越短。
区分三种成因，它们对应的处理动作完全不同
同样是“两份结果不同”，成因不同，改法也不同：
- 纯客户端渲染：原始响应只有框架和脚本，正文、链接全靠JS生成。此时要判断360是否执行了脚本；如果拿到的是空壳，正文和链接都无从提取。
- 服务端渲染但被脚本覆盖：原始响应已有完整正文，脚本执行后又替换了一次。这种最容易被忽略——原始结果本来可用，是脚本把它改坏了。
- 部分注入：正文在原始HTML里，但链接或canonical由脚本补。差异只出现在局部字段。
区分方法：把脚本执行后的DOM与原始HTML做文本差异，如果差异是“从无到有”，偏第一种；如果是“从有到改”，偏第二种；如果只有个别标签变化，偏第三种。
一个假设例子：正文一致但链接不同时怎么走下一步
假设某详情页原始响应中正文完整，但站内推荐位链接是脚本注入的，脚本执行后DOM里才出现十几条<a href>。此时正文比对通过，链接比对不通过。
处理动作：先确认这些链接是否属于需要被发现的重要路径。如果它们只是推荐位、不影响主体内容被发现，可以暂不处理；如果它们是分类或分页入口，就需要把关键链接改为服务端输出。改完后重新取两份结果，确认链接在原始响应里已存在，再观察360对这批链接的抓取是否出现变化。注意：链接被抓取不等于被收录，抓取量上升也不能单独证明改动正确，还要看这些URL本身是否可索引、是否返回正常状态码。
把结论落到可复核的动作上
差异定位的终点不是“找到不同”，而是把不同转成一条可验证的修改。每次只改一个字段的生成方式，改完重新取两份结果，确认该字段在原始响应中已稳定存在，再进入下一个字段。如果一次同时改正文、链接和canonical，出现新问题时无法判断是哪一处引起的。
另外要确认：robots.txt的抓取限制不等于可靠的索引移除，站点地图也不保证收录，所以不要用“已提交地图”或“已屏蔽抓取”来替代对两份结果本身的比对。只有当原始响应与脚本渲染结果在关键字段上一致，或差异已被明确解释并接受，这个页面的渲染问题才算定位完成。
