site命令查询工具停服后哪些数据应该优先迁出
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /11037862230e.html
📄
site命令查询工具停服后哪些数据应该优先迁出
优先迁出的不是“结果截图”，而是能重建判断依据的三类东西：查询条件本身、每条结果的原始标识、以及你当时对异常样本的备注。只搬走汇总数字，迁完就等于把证据链丢了。但如果你的用途只是看某个域的大致收录规模、不做跨期比较，那么迁移优先级可以大幅降低，先导出最近一批结果就够了。
先分清：哪些数据搬走还能用，哪些搬走就废了
site命令查询产出的数据通常分四层，停服后价值衰减速度完全不同。
- 查询语句与参数：例如查询的是主域还是子域、是否带路径、是否限定语言或地区。这层最该先搬，因为它决定了结果能不能被复现。
- 结果标识：每条结果对应的页面地址或资源标识。没有它，汇总数字无法回溯到具体页面，后续人工复核就无从下手。
- 判定与备注：你当时标记的“疑似镜像”“参数页重复”“已失效”等人工判断。这层是工具不会替你保留的部分，一旦丢失只能重做。
- 汇总统计：总量、按目录分布等。它看起来最像“数据”，实际最不耐用，因为口径一变就不可比。
按这个顺序迁，先搬查询语句和结果标识，再搬备注，最后才考虑汇总。反过来做，迁出来的往往是一堆无法验证的数字。
一个反例：样本小时成立的结论，规模化后会失效
假设你只查了三个子域，每个子域结果都不多，于是判断“导出页面地址就够了，备注可以不要”。这个判断在小样本下成立，因为你能靠记忆还原当时为什么标记某几条。
但当子域数量上升到几十个、结果里混入大量参数页和分页时，记忆不再可靠。同一条地址在不同查询条件下可能被标成不同状态，缺少备注就会把“当时认为重复”和“当时认为正常”混在一起。此时再回头核对，成本远高于当初顺手导出。
也就是说，“只导地址不导备注”这条捷径，只在结果量小、且你能持续记住判断过程时成立。一旦规模化或换人接手，它就失效。
迁移前先确认一件事：新工具能不能接受同样的查询条件
不同工具对查询语句的支持范围不一样，有的不区分路径层级，有的对通配符处理方式不同。迁移前先拿一条你最重要的查询语句，在新环境里跑一遍，比较结果集合的重合程度。
如果重合度高，说明查询条件可以平移，你只需补齐结果标识和备注；如果重合度低，说明口径已经变了，这时应该把旧数据当作历史快照单独存档，而不是硬塞进新工具做对比。这个动作的结果直接决定下一步：是继续迁移，还是转为归档。
按这个顺序执行，并保留一份可读的存档
- 导出所有查询语句及参数，存成纯文本，一行一条，便于逐条重跑。
- 导出结果标识，并附上它所属的查询语句编号，保证可回溯。
- 导出人工备注，字段至少包含标识、状态、备注时间。
- 最后才导出汇总数字，并注明它对应的查询条件与导出时间。
存档建议用不依赖特定工具的格式，例如逗号分隔的文本或 <ul> 结构的静态页面，避免停服后连打开都成问题。迁完后，用一条旧查询在新环境重跑，对比结果标识的重合情况；重合明显偏低时，不要急着下结论，先检查是不是查询条件没对齐，再决定是否需要人工复核。
