搜狗收录提交：静态响应与脚本渲染结果不同时怎样定位差异
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /8b6be3d65c94.html
📄
搜狗收录提交：静态响应与脚本渲染结果不同时怎样定位差异
先给结论：如果静态响应里看不到正文，而浏览器执行脚本后能看到，差异通常出在“搜狗抓取到的是哪一版”这一层，而不是提交动作本身。定位时优先用不带脚本的请求核对原始响应，再决定是让内容进入静态响应，还是继续依赖脚本渲染；两种选择成立的条件不同，不能混用一套判断。
先确认差异发生在哪一层
把同一地址分别用两种方式取回：一种关闭脚本执行，只取服务器直接返回的字节；另一种允许脚本运行后再读取最终文档。比较三处：正文是否出现、链接是否出现、关键文本是否出现。如果关闭脚本时正文为空，开启脚本后正文完整，说明差异在渲染层，不在提交入口。
这一步的动作会产生明确后果：若原始响应里连标题和主体文本都缺失，那么后续所有“提交后多久收录”的讨论都失去意义，因为搜狗拿到的初始文档没有可索引内容。此时应先修响应，而不是反复提交。
两种选择成立的条件
选择一：把关键内容放进静态响应。成立条件是内容相对稳定、更新频率可控、且不依赖用户交互才出现。做法是让服务器直接输出标题、主体文本和主要链接，脚本只负责增强。结果是原始响应与渲染结果趋同，差异消失，后续核对只需看一个版本。
选择二：保留脚本渲染，但确保初始响应包含可索引的骨架。成立条件是内容高度依赖前端状态、静态化成本过高，且能保证初始文档里有标题、摘要和指向详情的链接。结果是搜狗仍可能只取到骨架，因此必须接受“收录内容可能不完整”的取舍，并持续用原始响应核对，而不是只看浏览器里的最终画面。
两种选择的判断依据不是“哪种更先进”，而是“搜狗实际取回的那一版里有没有你要被收录的文本”。
用可核对的证据区分原因
常见解释有三种，需要分开验证：
- 响应本身缺内容：关闭脚本后正文为空，开启后出现。证据是两次取回的文本长度差异明显。此时优先改响应。
- 内容在响应里但被脚本覆盖：关闭脚本能看到文本，开启后反而被替换或清空。证据是渲染后关键文本消失。此时问题在前端逻辑，不在提交。
- 内容依赖异步请求：初始响应只有占位符，正文由后续接口返回。证据是原始响应里存在占位节点，渲染后才填充。此时要判断该接口是否可被抓取，以及失败时页面是否仍保留可读文本。
假设一个例子：某页面关闭脚本时返回的正文只有一句“加载中”，开启脚本后出现完整文章。这个证据只能说明初始响应缺内容，不能证明提交无效。下一步应是让服务器输出文章主体，再重新核对原始响应，而不是增加提交次数。
实施动作与例外
先做一个最小改动：让服务器在初始响应中输出标题、首段和主要链接，脚本只做交互增强。改完后用关闭脚本的方式重新取回，确认关键文本已出现。这个动作的结果直接决定下一步：如果原始响应已包含正文，就进入常规核对；如果仍为空，说明改动没落到响应层，需要继续查模板或接口。
例外也要说明：robots.txt 的抓取限制不等于可靠的索引移除，站点地图也不保证收录；即使原始响应完整，搜狗仍可能因其他原因不收录。因此定位差异时，只把“静态与渲染是否一致”当作一个可验证的环节，不要把它当成收录结果的唯一解释。
最后，若差异只出现在个别页面，先抽样核对原始响应，再决定是统一改模板还是单页修复；若差异覆盖整站，则优先检查渲染入口和初始文档输出，避免在提交层面反复消耗时间。
