📍 WDQWDWQD987AAAAA:216.73.217.23
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /289ce4a7830a.html
📄

域名历史_改动前怎样保存原始状态：一份可执行证据留存清单

改动域名相关配置前，要保存的“原始状态”不是一张截图，而是能证明当时解析、注册、抓取与索引状态的可核对记录。核心做法是：先固定时间点，再分别保存注册信息、DNS解析、HTTP响应、robots与站点地图、以及搜索引擎可见页面快照。每项记录都要带时间、来源和获取方式，否则事后无法判断变化发生在哪一步。

先固定一个基准时间，再开始收集

在动任何配置之前，记录当前UTC时间和你所在时区的时间。所有后续证据都以此为准。如果多人协作，让每个人用同一时间源，避免出现“我查的时候还是这样”的争议。基准时间确定后，按下面清单逐项执行，每项都保留原始文件或截图，不要只写结论。

注册与DNS记录：查什么、怎么查、说明什么

• 注册信息：通过公开的WHOIS/RDAP查询域名注册商、创建日期、到期日期、名称服务器、状态码。保存查询结果原文或截图。结果说明域名的注册归属与到期风险，但不代表网站当前是否可访问。
• DNS解析：用dig或nslookup查询A、AAAA、CNAME、MX、TXT、NS记录，并记录查询所用的递归解析器。结果说明流量被指向哪里。若改动前后解析目标不同，可据此判断是否发生了迁移或回源变化。
• 解析一致性：从至少两个不同网络或公共解析器分别查询，对比结果。若结果不一致，说明可能存在解析缓存或分线路解析，改动前必须记录清楚，否则事后无法区分是配置改动还是缓存延迟。

HTTP响应与页面快照：证明当时对外呈现什么

对首页和几个关键URL分别执行请求，保存完整响应头与状态码。可使用curl -I查看响应头，用curl -s保存正文。重点记录：状态码、Location跳转目标、X-Robots-Tag、Cache-Control、Content-Type。结果说明改动前页面是否可访问、是否被跳转、是否带有页面级抓取限制。

同时保存页面可见内容快照。可以用浏览器另存为完整网页，或保存渲染后的HTML。若页面依赖JavaScript渲染，仅保存源码可能看不到实际内容，此时应保存渲染后的DOM或截图，并注明获取方式。这一步的意义是：当改动后出现内容缺失或跳转异常时，能对比出是服务端返回变了，还是前端渲染变了。

robots.txt、站点地图与索引状态：分开记录，不要混为一谈

• robots.txt：保存当前文件原文，记录它允许或禁止了哪些路径。要明确：robots.txt的抓取限制不等于可靠的索引移除。被禁止抓取的URL仍可能因外部链接出现在搜索结果中，所以它不能作为“已从索引删除”的证据。
• 站点地图：保存站点地图文件及其中的URL列表。站点地图不保证收录，它只是提交候选URL的一种方式。记录它是为了对比改动前后提交范围是否变化。
• 索引可见性：用site:查询或搜索引擎提供的收录状态查询方式，记录当时能查到的URL。不同搜索引擎支持情况须分别核查，不能用一个引擎的结果推断另一个。HTTPS也不保证安全无漏洞或排名，它只是传输层加密，与索引状态是两回事。

改动后如何用这份记录定位原因

改动完成后，用同一套方法再采集一次，逐项对比。若状态码从200变为301，说明发生了跳转；若DNS的A记录变了，说明解析目标变了；若robots.txt新增了禁止规则，说明抓取范围被限制；若页面快照内容减少，说明内容或渲染发生了变化。把“可能原因”和“已经定位的原因”分开写：例如“收录下降”可能有抓取限制、服务器错误、内容删除、外部链接变化等多种解释，只有对比记录后才能确认是哪一项，不要在没有证据时断言唯一原因。

下一步：在改动前先复制一份上述清单，填入当前值并标注获取时间；改动后再填一份，两列并排对比。这样出现问题时，你能直接指出是哪一项记录发生了变化，而不是凭印象猜测。