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

主域名选择 - 如何确认配置实际生效

确认主域名配置是否生效，核心看三件事：请求主域名时是否稳定返回目标页面，请求备选域名时是否按预期跳转到主域名，以及页面内指向自身的链接是否统一使用主域名。只改配置文件、只提交工单或只在本地浏览器试一次，都不算完成交付。

先约定验收前提，避免多人协作返工

多人协作时，返工往往不是技术问题，而是没有提前写清验收标准。动手前至少确认以下内容：

• 主域名是带 www 还是不带，是否包含协议和末尾斜杠的书写规范。
• 备选域名是全部跳转还是保留部分路径，跳转状态码用 301 还是 302。
• 由谁负责改 DNS、谁负责改服务器配置、谁负责在页面模板中替换链接。
• 验收在哪些网络环境、哪些设备、哪些入口下完成。

把这几项写进交付说明，后续检查才有统一依据，不同人不会各自用不同标准判断“生效”与否。

用请求结果判断跳转是否真正生效

最直接的检查方式是观察请求主域名和备选域名时返回的响应。可以用命令行工具，也可以用浏览器开发者工具的网络面板。重点看三项：状态码、跳转目标、最终落地页。

假设主域名定为 www.example.com，备选为 example.com，可以按下面的顺序检查：

1. 请求 http://example.com，观察是否跳转到 https://www.example.com，以及状态码是否为 301。
2. 请求 https://example.com，确认同样跳转到主域名，而不是停在备选域名上。
3. 请求 https://www.example.com，确认返回 200，并且页面内容就是目标页面。
4. 带一个具体路径再测一次，例如 https://example.com/page-a，确认跳转后路径没有丢失。

如果状态码是 302，说明这是临时跳转，搜索引擎可能仍把备选域名当作独立地址处理。如果跳转后路径变成首页，说明跳转规则写得太宽，需要补上路径保留逻辑。如果某个协议或某个子路径没有跳转，说明配置只覆盖了一部分入口，不能算整体生效。

检查页面内部链接是否统一指向主域名

服务器跳转生效，不代表页面内部链接已经改完。常见情况是：访问备选域名会被跳到主域名，但页面里的导航、分页、图片地址、结构化数据里仍然写着备选域名。这样用户和抓取工具仍会不断发现备选地址，主域名的统一性没有真正建立。

可以抽查以下位置：

• 首页和几个主要栏目的导航链接。
• 文章正文中的内链和“相关阅读”模块。
• 分页、面包屑、返回首页等模板级链接。
• 站点地图中列出的地址。
• 结构化数据或分享卡片中填写的地址。

判断标准很简单：在浏览器中打开主域名页面，查看页面源代码，搜索备选域名字符串。如果还能搜到，就说明模板或内容里仍有残留，需要继续替换。替换完成后重新抓取一次，确认搜索结果里不再出现备选域名。

区分“配置已改”与“已经生效”

配置文件和实际生效之间可能隔着缓存、CDN、DNS 传播和服务器重启。多人协作时，最容易出现的误会是：负责改配置的人说“我已经改好了”，负责验收的人却仍看到旧结果。为避免这种拉扯，交付时应附上可复现的检查记录。

建议记录以下内容：

• 检查时间与检查人。
• 请求的完整地址和返回的状态码。
• 跳转链的完整路径，例如从哪个地址跳到哪个地址，中间经过几次跳转。
• 页面源代码中是否还存在备选域名。

如果检查结果与预期不一致，先判断是配置问题还是缓存问题。可以在请求时加一个随机查询参数，绕过部分缓存；也可以换一个网络环境或设备再测一次。只有排除缓存因素后仍然不一致，才回到配置本身排查。

把验收信号写进交付说明

要让主域名选择这件事真正落地，交付说明里应写明可验证的结果，而不是只写“已完成配置”。例如：

• 备选域名在 HTTP 和 HTTPS 下均 301 跳转到主域名，路径保留。
• 主域名返回 200，页面内容正确。
• 页面源代码中不再出现备选域名。
• 站点地图和结构化数据中的地址均为主域名。

需要提醒的是，跳转配置正确并不等于搜索引擎一定会按预期处理，也不等于站点地图提交后就一定被收录。这两件事需要分别观察和核查，不能混在同一个验收项里。

下一步：把上面的检查项整理成一份固定清单，每次主域名调整后由不同的人按同一份清单复核一遍，确认结果一致后再关闭任务。