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

二级域名与主域名区别：怎样安排最小修复试验 - 用交付结果倒推分工与验收

安排最小修复试验的关键，是先把“要交付什么”写清楚，再倒推需要哪些资料、谁来做、做到什么程度算通过。就二级域名与主域名区别而言，最小试验不是改一堆设置，而是选一个可观察的差异点，例如同一路径下主域名与二级域名的可访问性、抓取限制或索引表现，只动一处变量，并约定验收口径。多人协作时，返工往往来自责任不清和验收标准含糊，而不是技术本身复杂。

先定义交付物：一份能判定的对照结果

交付物不应写成“排查二级域名问题”，而应写成可核对的结果。建议包含三部分：对照对象、观察指标、判定结论。对照对象要明确到具体主机名与路径，例如主域名下的 /a/ 与二级域名下的 /a/；观察指标可以是返回状态码、是否被 robots.txt 限制、是否出现在站点地图、是否被搜索引擎收录。判定结论只写三种：一致、不一致、无法判定。无法判定同样是有价值的交付结果，说明资料不足，而不是含糊收尾。

倒推必需资料：谁提供、缺了会卡在哪

从上面的交付物倒推，通常需要以下资料。缺少任何一项，都要在任务开始前标注为风险，而不是等到验收时才发现。

• 域名与子域名的解析记录，由负责 DNS 的人提供，用于确认两者指向是否一致。
• 服务器或 CDN 的站点配置，由运维提供，用于确认两个主机名是否走同一套规则。
• robots.txt 的完整内容与所在位置，由站点负责人提供，用于判断抓取限制是否只作用于其中一个。
• 站点地图文件及其包含的主机名，由负责生成地图的人提供，用于确认收录引导是否覆盖二级域名。
• 可复现的访问记录，由执行人提供，用于让验收人独立复核。

这里要区分两件事：robots.txt 的抓取限制不等于可靠的索引移除，站点地图也不保证收录。因此资料只能用于判断“是否存在差异”，不能直接推出“改完就会收录”。

任务拆分与责任：一次只动一个变量

最小修复试验的核心是控制变量。多人协作时，建议按下面顺序拆分，每步指定唯一责任人，并在完成后留下可复核的记录。

1. 责任人 A 冻结现状：记录主域名与二级域名在相同路径下的状态码与响应头，作为基线。
2. 责任人 B 只改一处，例如仅调整二级域名的 robots.txt 规则，或仅统一站点地图中的主机名，不要同时改多项。
3. 责任人 C 在改动后按同一方法复测，确认变化只出现在预期位置。
4. 责任人 D 做验收：对照基线，判断结果是改善、无变化还是引入了新问题。

如果一次改了 robots 规则、站点地图和跳转，即使结果变好，也无法判断是哪一项起作用，下次遇到同类问题仍要重新试，这就是返工的主要来源。

验收标准与判断结果：写清通过条件

验收标准要在动手前写好，避免事后解释。可以按下面的检查项执行，每项给出明确结论。

• 检查项一：两个主机名在相同路径下是否返回相同状态码。结果记为一致或不一致。
• 检查项二：robots.txt 是否对两者施加了不同限制。若不同，说明抓取层面存在差异。
• 检查项三：站点地图是否只包含其中一个主机名。若是，说明收录引导未覆盖另一个。
• 检查项四：搜索引擎实际收录情况是否与预期一致。不同搜索引擎支持情况须分别核查，不能用一家的结果推断另一家。

假设某个站点的二级域名在 robots.txt 中被整体禁止抓取，而主域名没有，那么修复试验可以只放开二级域名的对应规则，其他不动。适用条件是：确认差异确实来自该规则，且没有其他配置同时限制。判断结果是：复测后抓取限制消失，但收录是否变化仍需另行观察，不能提前下结论。

协作交付：让记录本身可被接手

为减少返工，交付记录应包含基线数据、改动内容、复测数据和结论四段，并注明执行时间与执行人。这样下一位接手的人不必重新问一遍背景。若涉及 HTTPS，要单独核查证书与配置，HTTPS 本身不保证安全无漏洞，也不保证排名。把“已验证”和“待验证”分开写，是多人协作中最省成本的约定。

下一步，选一个具体路径，按上面的检查项记录主域名与二级域名的基线数据，再决定是否值得发起最小修复试验；如果基线本身无法复现，先补齐资料，不要进入改动环节。