搜索引擎抓取规则：改动前怎样保存原始状态
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /eadb5f4c717d.html
📄
搜索引擎抓取规则：改动前怎样保存原始状态
改动 robots.txt、页面结构或站点配置前，保存原始状态的核心做法是：先把当前可被抓取的内容和规则完整留档，再在独立副本上做改动。具体要保存三类东西：抓取规则文件本身、关键页面当前的可访问状态、以及改动前后的对照记录。只截图或只记一句“改过 robots”都不够，因为出问题时你需要能还原到某个确定的时间点。
先查 robots.txt 当前内容并原样留档
要查什么：站点根目录下 robots.txt 的完整文本，包括所有 User-agent、Disallow、Allow、Sitemap 行。
怎么查：用浏览器直接访问 https://你的域名/robots.txt，全选复制到本地文本文件；同时记录访问日期和响应状态码。如果返回 404，也要把“404 无此文件”这一事实记下来，而不是当成空规则。
结果说明什么：这份文本是后续比对的基准。改动后如果抓取量下降，可以逐行对比是新增了哪条 Disallow。注意 robots.txt 的抓取限制不等于可靠的索引移除：它只影响爬虫是否来抓，已经收录的页面可能仍会出现在结果里，所以不能把“加 Disallow”当成删除页面的手段。
保存关键页面的当前可访问状态
要查什么：你准备改动的页面，改动前是否能正常返回内容、返回什么状态码、是否带 noindex、canonical 指向哪里。
怎么查：对每个关键 URL 执行三步：
- 用
curl -I 页面URL看 HTTP 状态码和响应头，把输出存成文本； - 查看页面源码里的
<meta name="robots">和<link rel="canonical">，复制保存； - 记录该页面当时是否在站点地图中、是否被内部链接指向。
结果说明什么：如果改动后页面从结果中消失，你可以回查是状态码变了、noindex 被加上，还是 canonical 被改到了别处。多个原因都可能造成同一现象，只有留档才能区分，不能凭印象断定是某一个原因。
给站点地图和内部链接留一份快照
要查什么：当前 sitemap 文件包含哪些 URL，以及重要页面从首页到目标页的点击路径。
怎么查：下载 sitemap.xml 存为本地文件；用站点抓取工具或手动记录 3–5 条关键路径的链接层级。记录时写明抓取日期。
结果说明什么：sitemap 只是给爬虫的发现线索，不保证收录。留档的意义在于：改动后如果某些 URL 不再出现在 sitemap 里，或内部链接被删，你能立刻判断这是不是抓取减少的原因，而不是把问题归到 robots.txt 上。
建立改动对照表，再动手
要查什么：把“改前”和“改后”写成两列对照，每行一个具体项：robots 某一行、某个页面的状态码、某条 canonical。
怎么查：改动前先填好“改前”列并保存；改完后立即填“改后”列；两份文件都带时间戳。若使用版本管理，把 robots.txt 和模板文件纳入提交记录，提交信息写清改了什么。
结果说明什么：对照表能让你在出问题时快速回滚到确定状态。如果无法回滚，至少能向协作者说明哪一项在何时被改。适用条件是：任何会影响爬虫访问的改动都值得留档；只改文案、不影响 URL 和响应头的改动，留档要求可以放宽。
假设示例：一次 robots.txt 改动
假设你要在 robots.txt 中新增一行 Disallow: /search/。改前先保存原文，确认 /search/ 当前可被抓取且返回 200。改后如果该目录下页面从结果中减少，对照表显示只有这一行变化，就能把原因锁定在抓取规则上，而不是页面本身被删。若改动后没有变化，也不代表规则无效，可能只是爬虫尚未重新抓取该文件，需要继续观察。
下一步：现在就去复制一份 robots.txt 到本地，并对你最在意的三个页面各存一份响应头和源码片段，标注日期。这是所有后续改动比对和回滚的起点。
