site查询优化：工具停服后哪些数据应该优先迁出
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /f4d0aa04b632.html
📄
site查询优化：工具停服后哪些数据应该优先迁出
优先迁出的不是“全部历史结果”，而是那些停服后无法重新生成、且还能影响你下一步判断的数据。具体说，三类最该先走：你手动标注过的差异记录、带时间戳的抓取快照、以及已确认的站点结构变更日志。其余可随时重跑的查询结果，可以排在后面甚至放弃。
先分清哪些数据停服后还能重建
判断优先级只有一个标准：这份数据是否依赖原工具的私有状态。能重建的，是任何工具重新执行同一查询都能得到的当前结果；不能重建的，是你在这个工具里积累的判断痕迹。
- 可重建：当前收录数量、当前索引页面列表、某条查询的即时结果。换一个工具重跑，结果大体可比。
- 不可重建：你标注过“这条差异是模板问题”“这个页面已确认删除”的备注、处理状态、负责人和时间。
- 半可重建：历史快照。如果原工具保留时间序列而新工具只给当前值，那这段历史一旦丢失就无法回补。
一个常见反常现象是：导出时发现行数最多的表反而最不值得迁。因为它多半是批量抓取的原始页面清单，重新抓一次成本可控；而只有几十行的标注表，才是你几个月判断的沉淀。
按“影响下一步动作”排序，而不是按数据量
迁移顺序应服务于你接下来要做的决策。假设你正处理一批疑似被误判为重复的页面，那么优先迁出的是这批页面的 URL、你此前的判定结论和判定依据。迁出后，你可以直接在新工具或表格里继续处理，而不必从头复核。
可以按这个顺序操作：
- 先导出带人工结论的记录，包括 URL、结论、依据、日期。
- 再导出时间序列快照，尤其是你用来对比前后变化的那些日期点。
- 然后导出站点结构或规则变更日志，例如某目录何时被屏蔽、某模板何时改版。
- 最后才考虑导出原始抓取清单和未处理队列。
做完第一步后，你会得到一个可独立使用的判定表。它的直接作用是：即使新工具给出的结果不同，你也能凭这张表判断是新工具口径变了，还是站点真的变了。这一步决定了后续是调整工具配置，还是调整站点本身。
用可核对的证据区分“工具差异”和“站点变化”
停服前后最容易被误读的是结果数量变化。查询量归零、抓取量骤降，可能只是原工具停止工作，也可能是站点被处理，还可能是查询方式变了。仅凭一个数字无法区分。
要区分，需要至少两组独立证据：
- 同一时间点，用另一个来源核对同一批 URL 的状态。
- 查看你迁出的变更日志，确认该时间段内站点是否有过改版、屏蔽或迁移动作。
如果两组证据都指向同一结论，才能下判断。只有一组数字变化，只能记为“待确认”，不要据此改动站点。
一个注明假设的短例子
假设某工具即将停服，你手里有一份 500 行的差异记录，其中 80 行有你的备注。优先迁出这 80 行，导出为带 URL、备注、日期的表格。迁出后，你在新工具里重跑同一批 URL，发现其中 20 行结果与旧记录不符。此时你打开迁出的表格，逐条对照备注，就能判断这 20 行是工具口径变化，还是站点在那之后确实改动过。若没有这张表，你只能重新逐条复核，成本高且容易漏掉已确认项。
迁移后的验证动作
迁出不是终点。导出完成后，至少做一次抽样复核：从迁出的记录中抽若干条，在新环境中重新核对，确认字段没有错位、日期没有丢失、结论仍然可读。如果发现某类字段在导出时被截断或合并，应回到原工具补导该类数据，而不是等到新流程跑起来再补。
验证通过后，再决定哪些原始数据可以不再保留。判断依据是：这份数据是否还能支持你下一次做同类判断。能支持的保留，不能支持的可以清理。清理前确认已有一份可独立打开的副本，避免只留在某个即将关闭的服务里。
