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

域名查询_改版或迁移时应核对什么

改版或迁移时做域名查询，核心不是查一次“域名是否注册”，而是核对域名在DNS、HTTPS证书、robots.txt、站点地图和站内链接中的实际状态。判断标准很简单：旧域名和新域名都要能按预期解析、访问、被抓取，并且页面级跳转关系与你的迁移方案一致。任何一项对不上，都可能导致流量在迁移后走错路径。

先观察：域名查询要看的四类结果

做域名查询时，把结果分成四类，不要只看一个页面能不能打开。

• DNS解析：用nslookup或dig查A、AAAA、CNAME记录，确认新旧域名分别指向哪里。若新域名还没解析，迁移就无从谈起。
• HTTP响应：用curl -I查看状态码。旧域名应返回301到新域名对应页面，而不是302、meta refresh或直接404。
• 证书覆盖：查HTTPS证书的SAN列表，确认新域名和需要保留的旧域名都在证书覆盖范围内。HTTPS不保证安全无漏洞或排名，但证书不匹配会直接中断访问。
• 抓取规则：分别请求新旧域名的/robots.txt，确认没有误屏蔽整站。robots.txt的抓取限制不等于可靠的索引移除，它只控制抓取，不控制已收录页面如何退出。

判断：哪些差异属于必须处理的问题

观察结果出来后，按影响面判断优先级。

1. 旧域名整站返回404或无法解析：迁移后旧链接全部断掉，必须优先修复跳转。
2. 旧域名跳转到新域名首页，而不是对应内容页：用户和搜索引擎都到不了原内容，应改成页面级301。
3. 新域名robots.txt屏蔽了整站：抓取被阻断，先解除屏蔽再提交站点地图。站点地图不保证收录，但屏蔽状态下连被抓取的机会都没有。
4. 证书只覆盖新域名、不覆盖旧域名：旧域名HTTPS访问会报错，需要补全证书或调整跳转链路。
5. 站内链接、canonical、hreflang仍指向旧域名：页面会持续把信号指向旧地址，应统一改为新域名。

如果只是新域名解析生效、旧域名也能打开，但跳转关系混乱，这属于“已经定位的原因”，可以直接按上表处理；如果只是某个地区访问异常，则可能是DNS传播或CDN节点问题，需要分地区复查，不要直接断定是迁移配置错误。

处理：按顺序执行可落地的核对步骤

下面是一组可以直接执行的检查动作，适用于已有页面或项目在原有基础上改版、换域名的场景。

1. 列出需要保留的旧URL清单，逐条确定对应的新URL。没有对应页面的，明确是301到上级栏目还是410。
2. 在新域名服务器上配置页面级301规则，用curl -I抽查至少20条代表性URL，确认状态码和Location头正确。
3. 检查新域名robots.txt，确认没有Disallow: /这类整站屏蔽；同时确认站点地图地址可访问。
4. 检查页面源码中的canonical、og:url、站内导航链接，全部指向新域名。
5. 确认HTTPS证书覆盖新旧域名，且新旧域名都不会出现混合内容警告。
6. 保留旧域名解析和跳转至少一个完整的观察周期，不要迁移当天就停掉旧域名。

假设某项目把old.example迁到new.example，抽查发现old.example/page-a返回301到new.example首页，而new.example/page-a本身可正常访问。这说明跳转规则写成了整站跳首页，应改为按路径映射。这个例子只说明判断方法，不代表任何真实项目结果。

复查：迁移后要回看哪些域名查询结果

处理完成后，隔一段时间重新做一轮域名查询和抓取核对。

• 重新查DNS，确认没有残留的旧解析指向已下线服务器。
• 重新抽查301链路，确认没有出现跳转链过长或循环跳转。
• 在新域名的站点地图和重要页面之间做一次抓取测试，确认可正常访问。
• 检查旧域名是否还有页面返回200而不是跳转，这类页面会和新域名形成重复内容。
• 不同搜索引擎对301、站点地图和索引移除的支持与处理节奏需要分别核查，不要用一家的表现推断另一家。

复查时如果发现旧域名仍有大量页面可直接访问，优先补跳转，而不是先提交索引移除。索引移除不能替代迁移跳转，跳转才是把旧地址价值传递到新地址的主要方式。

下一步：把你当前项目的旧URL清单和新URL映射表整理出来，逐条用curl -I跑一遍状态码，先修掉返回404或跳首页的条目，再处理robots.txt和证书覆盖问题。