二级域名设置，改版或迁移时应核对什么
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /2bf2a70742dc.html
📄
二级域名设置，改版或迁移时应核对什么
改版或迁移时，二级域名设置最需要核对的是三件事：每个二级域名是否仍然指向正确的站点、它的可抓取与索引状态是否被意外改变、以及新旧地址之间的跳转是否一一对应。二级域名在技术上常被当作独立站点处理，因此主站改版不会自动把二级域名的规则带过去，必须逐个确认。
先分清二级域名在本次改动中的角色
核对之前，先把现有二级域名按用途分类，不同用途的核对重点不同：
- 内容型（如
blog.example.com）：关心是否仍能被抓取、是否产生重复内容、站内链接是否还指向它。 - 功能型（如
api.example.com、static.example.com）：通常不需要被索引，重点是迁移后主站资源能否正常加载。 - 测试或历史遗留型：改版时最容易漏掉，应确认是否还需要保留、是否需要下线或做跳转。
分类之后列一张清单，写明每个二级域名的用途、负责人、是否允许被搜索引擎索引。这份清单是多人协作时减少返工的交付物，比口头交接可靠得多。
核对抓取与索引相关的设置
改版时常见的失误是把主站的 robots.txt 直接复制到二级域名，或者反过来把二级域名的限制规则误删。需要逐项确认：
- 访问每个二级域名的
/robots.txt，确认屏蔽规则是否符合预期。注意：robots.txt 只能限制抓取，不能可靠地把已经收录的页面从索引中移除，需要移除时应使用对应的移除工具或让页面返回合适的状态码。 - 检查页面
<meta name="robots">是否被模板统一改成了noindex。功能型二级域名设 noindex 合理，内容型被误设就会直接损失流量入口。 - 确认站点地图是否覆盖了二级域名下需要收录的地址。提交站点地图不保证收录，它只是帮助发现地址，最终是否收录由搜索引擎判断。
- 如果二级域名使用 HTTPS，确认证书覆盖了该主机名，且没有混合内容。HTTPS 是传输加密，不代表站点没有安全漏洞，也不直接保证排名。
这些检查要在改版后的预发布环境先跑一遍，再在上线后复查一次，因为模板和服务器配置可能在部署环节被覆盖。
跳转与链接的对应关系要逐条验证
如果改版涉及 URL 结构变化，二级域名上的旧地址需要跳到新地址。核对方法是抽样对比：从旧站导出二级域名下的 URL 列表，按规则映射到新地址，然后实际访问旧地址，确认返回 301 且落点正确。以下是一个假设例子，用来说明判断方式：
old.example.com/post/123 迁移后对应 www.example.com/blog/123，访问旧地址应返回 301 并跳到新地址；如果返回 302，搜索引擎会把跳转视为临时，传递效果与 301 不同；如果返回 404，说明映射规则漏掉了这一类地址。
同时检查主站和二级域名内部的链接是否还指向已下线的地址。链接检查工具能批量发现这类问题，但工具结果需要人工判断哪些是必须修的。
多人协作时的交付与验收方法
把上面的核对项整理成一张表，每行包含：二级域名、用途、robots 状态、索引状态、跳转规则、负责人、验收结果。交付时由执行人填写，验收人独立复核，避免同一人既做又查。
验收的通过条件可以设为：所有内容型二级域名可正常抓取、无意外 noindex、旧地址跳转落点正确率达到约定标准、功能型二级域名资源加载正常。不满足的行标注原因并回到对应负责人，而不是整体打回重做，这样能减少返工范围。
下一步：按上面的清单把当前所有二级域名列出来，先完成分类和状态记录，再决定哪些需要在本次改版中调整。清单没有确认之前，不要批量修改 robots 或跳转规则。
