Google搜索收录 - 改动前怎样保存原始状态
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /d98f2048276f.html
📄
Google搜索收录 - 改动前怎样保存原始状态
改动前要保存的原始状态，不只是把文件复制一份，而是同时记录“线上正在生效的内容”“服务器实际返回的响应”“Google当前已抓取到的版本”这三层。只备份源码，无法在出现收录异常时判断是代码改动、服务器配置还是Google缓存造成的差异。
常见误解：备份文件就等于保存了原始状态
多人协作时最常见的做法是新建一个文件夹，把当前页面文件复制进去，命名为“备份”或“旧版”。这个动作只保存了源码，没有保存源码运行后的结果。对于静态页面，源码和线上内容基本一致；但对于依赖模板、数据库、重定向规则、CDN配置的页面，同一份源码可能输出完全不同的HTML。改动后如果收录下降，只凭源码备份无法还原当时的真实输出。
另一个误解是把Git提交当作完整备份。版本控制能记录文件变化，但不会记录robots.txt的线上状态、服务器返回的状态码、canonical标签的最终输出，也不会记录Google当时索引的标题和摘要。这些恰恰是判断收录问题的关键证据。
改动前应该保存哪些原始状态
按可核对、可对比的原则，至少保存以下内容：
- 线上页面的完整HTML：用浏览器“查看网页源代码”保存，而不是只看开发者工具里的DOM，因为DOM可能已被脚本修改。
- HTTP响应头：记录状态码、
Content-Type、X-Robots-Tag、Location等字段。 - robots.txt原文：保存当前生效的完整内容，并记录它返回的状态码。
- canonical与hreflang标签的最终输出：从保存的HTML中确认，而不是从模板文件推断。
- XML站点地图的当前版本：保存文件内容和它声明的URL数量。
- Google已收录版本的快照：记录当前搜索结果中该页面的标题、摘要和缓存时间。
这些内容合在一起，才能构成一份可对比的基线。缺少任何一项，改动后出现收录变化时都可能无法定位原因。
可执行步骤：建立一份改动前基线
假设你要调整一个栏目的模板和URL结构，改动前按以下顺序操作：
- 用命令行保存响应头和正文，例如：
curl -I https://example.com/page记录响应头，curl -s https://example.com/page -o page-before.html保存正文。把输出存进以日期命名的文件夹。 - 单独保存robots.txt和站点地图：
curl -s https://example.com/robots.txt -o robots-before.txt，站点地图同理。 - 在Google搜索该页面的完整URL，记录标题、摘要和是否有缓存入口。把结果截图或抄录到同一个文件夹的说明文件里。
- 在说明文件中写清改动范围：哪些模板、哪些URL规则、哪些重定向会被修改，以及负责人和计划上线时间。
- 把上述文件夹提交到版本控制或共享存储，确保协作者都能访问，而不是只留在某个人本地。
这套步骤适用于任何会改变页面输出或抓取路径的改动。如果只是修改页面内的文案，可以省去站点地图部分，但HTML和响应头仍应保存。
改动后怎样用这份基线判断问题
改动上线后，用同样的命令抓取一次，与基线逐项对比。判断逻辑如下：
- 如果响应头中的状态码从200变成301或404，先检查重定向规则，而不是急着提交收录请求。
- 如果HTML中的canonical指向了不同URL，说明模板或配置改动影响了规范化目标，需要确认这是否是预期结果。
- 如果robots.txt新增了
Disallow，要意识到抓取限制不等于索引移除，已收录页面可能仍会出现在结果中，但Google无法抓取新内容。 - 如果HTML和响应头都没变，只是搜索结果显示异常，可能是Google尚未重新抓取，此时对比缓存时间比反复修改页面更有意义。
需要区分“可能原因”和“已经定位的原因”。状态码变化是已经定位的事实；收录下降只是现象，可能由抓取延迟、规范化变化、内容质量判断等多种因素造成，不能仅凭一次对比就下结论。
多人协作时的交付要点
基线文件夹里应包含一份简短的说明，写明抓取时间、使用的命令、改动范围和预期影响。协作者接手时，先读说明再对比文件，能减少“改了哪里”“为什么收录变了”这类返工沟通。如果改动涉及多个页面，按URL分别保存，不要只保存一个代表页面。
下一步：在下一次改动前，先按上面的命令抓取一份当前状态，并把文件夹和说明一起提交给协作者确认，再开始改代码。
