同服务器网站查询：怎样形成可复用检查清单
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /d7d44a457efd.html
📄
同服务器网站查询：怎样形成可复用检查清单
把同服务器网站查询做成可复用检查清单，关键不是记住某个命令，而是固定“输入、证据、结论、复核”四段结构：每次查询都记录目标域名、解析到的IP、使用的查询方式、观察到的其他域名、判断依据和复核人。这样多人协作时，任何人拿到清单都能复现同一结论，减少因口径不同导致的返工。
先明确清单要解决哪类判断
同服务器网站查询通常服务于几种不同决策：判断两个站点是否共享主机、评估同IP下站点数量对风险的影响、排查某个IP是否被牵连，或为迁移与容灾做资产梳理。决策不同，清单字段也不同。
- 共享主机判断：需要IP、解析时间、反向解析结果、同IP域名列表。
- 风险牵连评估：需要同IP站点数量、站点类型、是否有明显违规内容。
- 迁移规划：需要当前IP、目标IP、解析商、TTL、切换窗口。
如果清单同时想覆盖以上全部目标，字段会膨胀到没人愿意填。建议一份清单只对应一个决策，其他内容作为附录引用。
用“可能原因”和“已定位原因”分开记录
同一现象往往有多种解释。例如某域名解析到与另一个站点相同的IP，可能原因包括：确实共用同一台服务器、共用同一CDN节点、共用同一反向代理、解析缓存未更新。这些解释在证据不足时不能合并成一个结论。
清单里应设置两栏：一栏写“观察到的现象”，一栏写“已确认的原因”。只有拿到可复核证据后才把内容从前者移到后者。例如：
- 现象：
example-a.com与example-b.com解析到同一IP。 - 待验证：该IP是否为共享主机、CDN入口或负载均衡地址。
- 已确认：通过反向解析与同IP域名列表，确认该IP下存在多个独立站点。
这样写的好处是，后来者能看出哪些是事实、哪些是推测，不会把推测当结论继续传播。
给出可执行的最小检查步骤
以下步骤可以直接放进清单模板，每步都要求留下证据：
- 查询目标域名的A记录或AAAA记录，记录IP与查询时间。
- 对该IP做反向解析，记录返回的主机名。
- 查询同IP域名列表，记录来源和查询时间。
- 抽查其中2至3个域名，确认它们是否为独立站点，而非同一站点的不同子域。
- 检查是否存在CDN或反向代理特征，例如响应头中的服务标识。
- 填写结论栏，注明“已确认”“待验证”或“无法判断”。
判断结果时注意：同IP域名数量多，不等于这些站点一定互相影响；但若其中存在被搜索引擎明确处理的违规站点，才需要进一步评估牵连风险。这个判断依赖具体搜索引擎的处理规则，应分别核查，不能一概而论。
把复核条件写进清单
可复用的关键在复核。清单应规定：什么情况下必须重查、由谁复核、多久过期。
- IP发生变化时，必须重查同IP域名列表。
- 查询时间超过约定周期时，结论标记为过期。
- 结论涉及风险判断时，需第二人复核证据链。
- 使用第三方查询结果时，记录来源与查询时间，不直接当作最终结论。
另外，robots.txt 的抓取限制不等于可靠的索引移除，站点地图不保证收录，HTTPS 也不保证安全无漏洞或排名。这些结论不能因为同服务器查询结果而改变，清单里不应把它们混入同一判断。
下一步：拿现有的一次查询记录，按“输入、证据、结论、复核”四段重写成模板，先在一个小项目里试用，再根据返工点增删字段。
