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

主域名选择：怎样检查前后环节的依赖

检查主域名选择的前后环节依赖，核心是画出一条从域名注册、DNS解析、服务器配置、HTTPS证书到站内链接与外部引用的完整链路，然后逐项确认每个环节是否硬编码了旧域名或旧协议。判断标准很简单：如果只改域名而不动其他环节，用户访问、搜索引擎抓取和页面资源加载是否还能正常完成。只要有一处仍指向旧域名，就存在依赖。

先观察：哪些地方会留下旧域名的痕迹

依赖通常不会集中在同一个地方，而是分散在几个层面。可以按下面的顺序观察：

• DNS层：A记录、AAAA记录、CNAME记录是否指向新主机的地址，TTL是否已经过期。
• 服务层：Web服务器配置里的server_name、虚拟主机绑定、CDN回源地址是否包含新域名。
• 证书层：HTTPS证书的SAN字段是否覆盖新域名，证书链是否完整。
• 页面层：页面里的绝对URL、canonical标签、og:url、结构化数据中的url字段是否还是旧域名。
• 引用层：站点地图、robots.txt中的Sitemap指令、RSS、外部友情链接和搜索结果中的链接是否指向旧域名。

观察时不要只看首页。至少抽查首页、一个栏目页、一个详情页和一个带查询参数的页面，因为不同模板可能写死了不同的域名。

判断：区分硬依赖和软依赖

发现旧域名后，先判断它属于哪一类。硬依赖指不改就会直接导致功能失败，例如DNS仍指向旧服务器、证书不包含新域名、表单提交地址写死旧域名。软依赖指不改不会立刻报错，但会分散权重或造成重复内容，例如canonical仍指向旧域名、内链仍用旧域名绝对地址。

判断方法可以借助命令行核对，而不是凭印象。例如用dig或nslookup查看解析结果，用curl -I查看响应头和重定向链，用浏览器开发者工具的Network面板查看资源请求的实际域名。如果响应中出现301或302跳转到旧域名，说明重定向方向可能写反了，这属于硬依赖。

需要特别注意的是，robots.txt的抓取限制不等于索引移除，站点地图也不保证收录。因此即使站点地图已经更新为新域名，也不能据此认为旧域名的索引问题已经解决，这两件事要分开检查。

处理：按链路顺序逐项替换

处理依赖时，建议从最底层往上改，避免上层改完下层又出问题：

1. 先确认新域名的DNS解析已经生效，TTL建议在切换前调低，便于回退。
2. 在服务器和CDN上绑定新域名，保留旧域名的虚拟主机配置用于接收跳转。
3. 为新域名签发或更新证书，确认证书覆盖所有需要使用的子域名。
4. 在服务器或CDN层配置旧域名到新域名的301跳转，方向必须是旧指向新。
5. 批量替换页面模板中的绝对URL、canonical、og:url和结构化数据字段。
6. 更新站点地图、robots.txt中的Sitemap地址，并重新提交。

假设一个场景：某站点把主域名从old.example换成new.example，但canonical标签仍写着old.example。此时搜索引擎可能仍把旧域名当作规范版本，新域名的页面难以独立获得评价。处理方式是把canonical统一改为新域名的对应URL，并确认新旧URL之间是301而不是302或JavaScript跳转。

复查：确认依赖已经解除

改完之后要复查，而不是改完就结束。复查项包括：

• 用curl -I请求旧域名，确认返回301且Location指向新域名对应路径。
• 用curl -I请求新域名，确认返回200，且没有再次跳回旧域名。
• 抽查页面源代码，确认canonical、og:url和主要内链都使用新域名。
• 确认HTTPS访问不报证书错误。HTTPS不保证安全无漏洞或排名，但证书不匹配会直接中断访问。
• 在不同搜索引擎中分别核查收录情况，因为各搜索引擎对跳转和站点地图的支持与处理节奏并不一致。

如果复查中发现某个环节仍然返回旧域名，回到对应层级重新处理，不要只在页面层反复修改。下一步可以建立一份域名依赖清单，把DNS、证书、服务器配置、模板变量和外部引用分别列出负责人和复查日期，这样下次再调整主域名时可以直接按清单核对。