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

如何选择域名，改版或迁移时应核对什么

改版或迁移时，域名本身通常不需要更换，真正要核对的是：旧域名是否继续保留、新旧域名之间是否建立对应关系、原先分散在不同域名上的权重与流量是否被正确归拢。如果只是站内改版，应优先保留原域名，把核对重点放在URL映射和抓取路径上；如果确实要换域名，则必须逐项确认跳转、验证、站点地图和外部链接的指向，缺一项都可能造成可观察的流量损失。

先观察：迁移前把现状记录清楚

动手之前，先用可核对的方式记录旧站现状，避免改完后无法对比：

• 导出旧域名下所有可访问URL，包含带参数和大小写不同的版本。
• 记录哪些URL有自然搜索流量、外链或转化，这些是迁移中优先级最高的页面。
• 确认旧域名的HTTPS证书、DNS解析和服务器响应是否正常。
• 检查旧站robots.txt是否屏蔽了某些目录，以及是否存在旧版站点地图。

这一步的交付物是一份URL清单和一份优先级标记。多人协作时，这份清单就是后续分工的依据，谁负责哪批URL的映射、谁负责验证，写清楚能明显减少返工。

判断：哪些域名结构需要调整

常见情况有三种，处理方式不同：

1. 仅站内改版，域名不变。不需要做域名级跳转，但要保证旧URL能通过301指向新URL，不能全部跳到首页。
2. 换主域名，例如从旧域名换到新域名。需要逐条建立旧URL到新URL的301映射，并保留旧域名一段时间。
3. 合并多个域名。要判断哪个作为主域名，其余域名的内容与链接统一指向主域名，避免同一内容在多域名重复出现。

判断依据不是主观偏好，而是看旧域名是否还有独立流量和外部链接。如果有，就不能简单停用，否则这些入口会直接失效。

处理：跳转、抓取与验证的具体操作

按以下顺序执行，每一步都留下可复查的记录：

• 建立映射表。用两列记录旧URL和新URL，一行一条，避免批量规则误伤。假设旧站有/old-page，新站对应/new-page，就写一条301规则，而不是把所有旧页面都指向首页。
• 配置301跳转。确认跳转是永久性的，且不经过多次跳转链。跳转链越长，抓取和用户体验越差。
• 更新内部链接。新站内的导航、正文链接、站点地图都直接指向新URL，不要依赖跳转。
• 提交新的站点地图。站点地图能帮助发现URL，但不保证收录，仍需结合抓取情况观察。
• 核对robots.txt。确认新域名没有误屏蔽重要目录。要注意，robots.txt的抓取限制不等于可靠的索引移除，若旧页面需要从索引中消失，应使用合适的移除方式并验证结果。
• 验证域名所有权。如果使用搜索平台的站长工具，新旧域名都要完成验证，便于分别观察数据。

多人协作时，建议把映射表、跳转配置和验证结果放在同一份交付文档里，标注负责人和完成时间。这样复查时不必重新翻找。

复查：迁移后看什么、看多久

迁移完成后不能只看首页是否打开，要按检查项逐条确认：

• 随机抽取若干旧URL，确认返回301并落到内容对应的新页面。
• 确认新URL返回200，且页面内容与旧页面主题一致。
• 检查是否存在跳转循环或跳转到404的情况。
• 观察新域名的抓取与索引情况，不同搜索引擎的支持和反馈周期不同，须分别核查。
• 检查外部链接是否仍指向旧域名，必要时联系对方更新，但不强求。

复查周期取决于站点规模，小站几天内就能看出明显异常，大站需要更长时间。判断标准是：旧URL能正确到达新内容，新URL能被正常抓取，且没有大面积404或跳转错误。

下一步建议先完成旧URL清单和映射表，再开始配置跳转。清单没整理清楚就动手，是迁移返工最常见的原因。