📍 WDQWDWQD987AAAAA:216.73.216.209
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /38fddf0c87c0.html
📄

百度收录查询改动前怎样保存原始状态：先留证据再动页面

做百度收录查询相关调整前，保存原始状态的核心是：把“改动前百度看到的页面”和“你自己站点的当前版本”分别留档。前者用百度搜索资源平台里的抓取诊断、索引状态截图或导出记录来固定，后者用版本控制、文件备份或页面快照来固定。两样都留，才能在后面对比“是百度没更新，还是我改坏了”。

先分清要保存的是哪两种状态

很多人只备份了代码，却忘了保存百度侧的观察结果，结果改动后无法判断问题出在哪。建议分开处理：

• 百度侧状态：收录查询结果、抓取时间、抓取到的HTML、HTTP状态码。这些是百度当时实际看到的内容，改动后可能被覆盖，必须提前留。
• 站点侧状态：页面HTML、robots.txt、sitemap.xml、模板文件、重定向规则。这些是你自己能控制的，改动前应可回滚。

如果时间和人手有限，优先保存百度侧状态，因为它最容易被新数据覆盖，且无法事后补录。

具体怎么保存：按可执行步骤操作

下面步骤以“准备修改一个已有页面的标题和正文”为例，其他改动可套用。

1. 在百度搜索资源平台对目标URL发起一次抓取诊断，记录抓取时间、HTTP状态码、抓取到的HTML。若平台提供导出或复制功能，直接导出；没有就截图，截图要包含URL和时间。
2. 用curl或浏览器“查看源代码”保存一份改动前的页面HTML，文件名带上日期，例如page-20250101.html。
3. 保存robots.txt和sitemap.xml当前内容。注意：robots.txt的抓取限制不等于可靠的索引移除，它只影响抓取，不能作为“已从百度删除”的证据。
4. 若站点使用版本控制，先提交一次并打标签，标签名写明“改动前”。没有版本控制就整目录复制一份。
5. 记录当前收录查询结果：用site:加具体URL在百度搜索中查询，截图保存结果页。收录数量本身会波动，截图是为了固定“改动前那一刻”的状态。

这些步骤里，抓取诊断和HTML留档是关键，其余是辅助。如果只能做一件事，做抓取诊断并导出。

保存时容易踩的三个坑

只存了页面，没存响应头。重定向、状态码、X-Robots-Tag都藏在响应头里。用curl -I保存一份头部信息，能避免改动后发现“原来之前就是301”。

把站点地图当成收录保证。站点地图不保证收录，它只是提交线索。保存它是为了对比提交前后URL是否有遗漏，不是用来证明收录。

用HTTPS当安全背书。HTTPS不保证安全无漏洞或排名，保存证书信息可以，但不要把它当作收录状态的判断依据。

保存完怎么用：对比与判断

改动上线后，重新做一次抓取诊断，把新旧两份HTML和响应头逐项对比。判断规则可以这样定：

• 如果百度抓取到的仍是旧HTML，说明百度还没更新，先等，不要急着回滚。
• 如果抓取到的是新HTML但收录查询结果没变，属于正常延迟，继续观察。
• 如果抓取诊断显示新页面返回404、5xx或被robots.txt拦截，说明改动引入了故障，应立即回滚到保存的版本。
• 如果新旧HTML差异超出预期，比如模板被误改，也回滚。

这套判断的前提是：你保存的百度侧状态确实来自改动前，且时间戳清晰。所以保存时务必记录时间，不要只存文件不存时间。

时间人手有限时，最先做哪一步

如果只有十分钟，先做两件事：对目标URL跑一次抓取诊断并导出或截图；用版本控制提交一次改动前状态。前者固定百度视角，后者保证可回滚。其余备份可以后续补，但这两件一旦改动上线就补不回来。

下一步建议：在真正修改页面前，先列出本次要动的文件清单和对应URL，逐个完成上述抓取诊断与留档，再开始编辑。