网站被Google收录 - 改动前保存原始状态：先备份哪些文件与数据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /e13df3d1a3ee.html
📄
网站被Google收录 - 改动前保存原始状态：先备份哪些文件与数据
改动前保存原始状态，核心是留下一份“可回退、可对比”的快照：把当前线上可访问的HTML、robots.txt、站点地图、关键配置和数据库结构导出到本地或版本库，并记录改动时间与版本号。这样做的目的不是永久归档，而是当收录出现波动时，能判断是改动导致的，还是抓取、索引本身的变化。时间和人手有限时，优先保存与抓取和索引直接相关的文件，而不是全站所有资源。
先分清哪些状态会影响Google收录
影响收录的原始状态，大致分三层。第一层是抓取入口：robots.txt、站点地图、内链结构。第二层是页面本身：HTML源码、<meta name="robots">、规范链接<link rel="canonical">、状态码。第三层是渲染与访问条件：服务端返回内容、重定向规则、HTTPS证书状态、CDN缓存策略。改动前保存原始状态，至少覆盖前两层；第三层如果近期没动过，可以只记录当前表现，不必逐项导出。
需要提醒的是，robots.txt的抓取限制不等于可靠的索引移除。它只影响Googlebot是否抓取，已经收录的页面仍可能出现在结果中。站点地图也不保证收录，它只是提交URL的渠道之一。因此保存这些文件是为了对比“改动前后是否一致”，而不是把它们当成收录开关。
按优先级保存：时间有限时的清单
如果只能花半小时，按下面顺序执行：
- 抓取当前线上页面源码。用浏览器“查看网页源代码”或命令行
curl -L 页面URL > 页面名.html，保存首页和几个核心栏目页。注意保存的是服务器返回的原始HTML，不是开发者工具里渲染后的DOM。 - 导出robots.txt和站点地图。直接访问
/robots.txt和各站点地图URL，另存为文本或XML文件，文件名带日期，例如robots-20250101.txt。 - 记录关键URL的状态码和重定向链。用
curl -I 页面URL查看返回头，记录状态码、Location跳转目标、X-Robots-Tag。这一步能发现改动前是否已有隐藏的noindex或跳转。 - 保存站点结构快照。如果站点有数据库或CMS，导出文章标题、固定链接、发布状态的列表；纯静态站则用版本控制工具提交一次当前状态。
- 记录环境信息。写下改动日期、执行人、改动的文件或模板、DNS和CDN是否同步调整。这行记录在排查时比文件本身更省时间。
如果人手更少，可以只做第1、2、3步。第4、5步属于“能回退”的保障，不是判断收录变化的必要条件。
保存方式怎么选：本地文件、版本库还是抓取工具
三种方式各有代价。本地文件夹最简单，适合一次性改动，缺点是容易覆盖、无法追溯多次改动。版本库（如Git）适合频繁调整模板或配置的站点，能对比任意两次提交的差异，但需要先建立仓库并养成提交习惯。第三方抓取工具能批量保存大量URL的源码和响应头，适合页面数量多的站点，代价是配置时间和可能的费用，而且导出结果要自己保管。
判断依据可以简化为两条：改动会不会反复发生？如果会，用版本库；改动只此一次且页面不多，本地文件加日期命名就够。另一个判断是：改动是否涉及模板或全局配置？涉及全局时，只保存单个页面源码不够，必须保存模板文件和robots.txt这类全局文件。
保存后怎么用：对比与回退的判断点
改动上线后，如果发现某些页面从Google结果中消失或抓取频率下降，先做对比，不要急着回退。对比项包括：robots.txt是否新增了Disallow；页面源码中是否出现了新的noindex；规范链接是否指向了别的URL；核心页面状态码是否从200变成301或404。如果这些都没有变化，那收录波动可能来自抓取调度或索引更新，与本次改动无关，继续观察即可。
如果确认是改动引入的问题，回退顺序是：先恢复robots.txt和模板文件，再恢复页面内容，最后清理缓存并重新提交站点地图。回退后仍需等待Google重新抓取，不存在立即恢复收录的保证。
下一步：在动手改动前，先打开当前robots.txt和首页源码，各另存一份并标注日期；如果站点使用模板，再把模板文件提交到版本库。这一步完成后，再开始计划中的修改。
