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

WordPress主机迁移，怎样处理重复或冲突信号

迁移后出现重复或冲突信号，通常指同一内容在新旧主机、不同协议或不同域名路径下都能访问，导致搜索引擎和浏览器收到互相矛盾的信息。处理顺序是：先确认重复或冲突的具体表现，再收集可复现的证据，最后按证据逐项消除冲突源。不要急着提交新站点地图或批量改链接，那可能让问题更难定位。

先确认冲突发生在哪一层

迁移后的冲突可能出现在四个层面，每一层的证据和修法都不同：

• DNS 与解析层：旧主机 IP 仍被解析，或 CDN 缓存仍指向旧源站。查法是用 dig 或在线 DNS 查询工具查 A 记录和 CNAME，并在不同网络环境下重复查。若解析结果不一致，说明 DNS 传播或缓存未统一。
• Web 服务器层：新旧主机同时响应同一域名。查法是直接请求新主机 IP 并带上 Host 头，例如 curl -I -H "Host: example.com" http://新IP/，再请求旧主机 IP 做同样操作。若两边都返回 200，说明旧主机仍在对外服务。
• 应用层：WordPress 站点地址、主页地址或数据库中的旧域名未替换。查法是进入后台查看“设置—常规”中的两个地址，再用 wp-config.php 确认数据库连接指向新库。若前台页面仍加载旧域名的资源，说明序列化数据未正确替换。
• 索引层：新旧 URL 同时可访问且都返回 200，搜索引擎可能分别抓取。查法是用 site: 查询或搜索引擎的 URL 检查工具，看同一内容是否有两个可访问地址。注意 robots.txt 的抓取限制不等于可靠的索引移除，屏蔽抓取和移除索引是两件事。

用一份清单逐项收集证据

下面每项都写明查什么、怎么查、结果说明什么。按顺序执行，不要跳步。

1. 查 HTTP 状态与重定向链。用 curl -IL 跟踪完整跳转，分别请求旧域名、新域名、带 www 和不带 www 的版本。若出现 301 到旧地址、或 200 与 301 混用，说明重定向规则不完整或方向反了。理想结果是所有变体最终 301 到唯一规范地址。
2. 查 HTTPS 与 HTTP 是否都能打开。分别访问 http:// 和 https:// 版本。若两者都返回 200 且内容相同，说明缺少强制跳转。HTTPS 不保证安全无漏洞或排名，它只解决传输加密和协议统一问题。
3. 查数据库中的残留旧域名。用 wp search-replace 的 dry-run 模式先预览，例如 wp search-replace 'old.com' 'new.com' --dry-run。若输出大量待替换项，说明迁移时未做完整替换。注意序列化数据必须用支持序列化的工具处理，直接 SQL 替换可能破坏数据。
4. 查站点地图与 canonical。打开新站点的 sitemap，确认其中列出的 URL 全部是新域名且可访问。再查看页面源代码中的 canonical 标签，确认指向自身而非旧域名。站点地图不保证收录，它只是提交候选 URL 的渠道。
5. 查旧主机是否仍可访问。在 DNS 已切换后，直接请求旧 IP。若仍返回完整站点，说明旧主机未下线或未设置拒绝规则。此时搜索引擎仍可能通过历史链接抓到旧内容。
6. 查 CDN 与缓存层。若使用了 CDN，查看缓存命中情况和回源地址。若回源仍指向旧主机，说明 CDN 配置未更新。清除缓存后重新请求，观察返回的源站标识。

根据证据判断冲突类型

收集完证据后，对照以下判断：

• 若新旧域名都返回 200 且内容相同，属于重复内容冲突，需要设置 301 或 canonical 指定规范版本。
• 若重定向链中出现循环或跳转到错误地址，属于重定向冲突，需要检查 .htaccess、Nginx 配置和 WordPress 插件中的跳转规则是否叠加。
• 若页面能打开但资源加载失败或后台地址错乱，属于域名替换不完整，需要重新处理数据库中的序列化数据。
• 若 DNS 查询结果在不同地区不一致，属于解析未统一，需要等待 TTL 过期或检查权威 DNS 配置。

假设一个场景：迁移后旧域名仍能打开，新域名也能打开，两者内容一样。此时先查旧域名的 HTTP 头，若返回 200，说明旧站未下线；若返回 301 到新域名，说明重定向已生效，问题可能只是缓存未更新。这是假设示例，用于说明判断路径，不代表任何真实项目结果。

消除冲突后的验证动作

处理完成后，用同一组检查项复验：所有域名变体最终 301 到唯一规范地址；curl -IL 不再出现旧地址；页面源代码中 canonical 指向自身；站点地图只包含新域名 URL；旧主机 IP 不再返回完整站点。若某项仍不通过，回到对应层面继续查，不要同时改动多个层面。

下一步：选定一个受影响最明显的 URL，按上面的清单完整走一遍，记录每一步的返回结果，再决定改 DNS、改服务器配置还是改数据库。