WordPress主机迁移：改版或迁移时应核对什么
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /58b476b9c9b6.html
📄
WordPress主机迁移：改版或迁移时应核对什么
改版或迁移时最该核对的不是“网站能不能打开”，而是旧地址能否按预期转到新地址、新主机能否稳定响应、搜索引擎看到的页面是否与旧站一致。建议在正式切换前，用一份核对清单逐项验证，再决定是保留旧主机并行一段时间，还是直接切换 DNS。
先看现象：迁移后常见问题出在哪
迁移完成后，常见现象有三类：一是首页正常但内页 404；二是旧链接全部跳到首页，而不是对应新页面；三是页面能打开但样式、图片或表单失效。这些现象可能来自不同原因，不能一律归为“主机问题”。
- 内页 404：可能是固定链接未刷新、伪静态规则未随主机环境调整，或数据库未完整导入。
- 全部跳首页：可能是重定向规则写得过于宽泛，把未匹配路径统一指向首页。
- 资源加载失败：可能是站点地址仍指向旧域名，或混合内容（HTTPS 页面加载 HTTP 资源）未处理。
判断时先区分“可能原因”和“已经定位的原因”。例如内页 404 既可能是伪静态规则问题，也可能是文件未上传完整，需要逐项排除，而不是直接断定是某一种。
核对旧链接与新链接的对应关系
迁移和改版往往同时改变 URL 结构，这时要建立一张旧地址到新地址的映射表。映射表不是给搜索引擎看的，而是给你自己检查重定向是否覆盖完整。
可执行步骤：
- 导出旧站的主要 URL，至少覆盖栏目页、文章页和带参数的页面。
- 为每个旧 URL 指定一个新 URL，能一一对应的用 301 跳转。
- 确实没有对应内容的旧 URL，返回 404 或 410，不要全部跳首页。
- 用浏览器或命令行请求旧 URL，确认返回状态码和最终落点。
示例（假设旧站为 example.com/old-post，新站对应 example.com/new-post）：请求旧地址后应返回 301，并最终落到新地址；如果落到首页，说明规则需要收窄。适用条件是旧内容在新站有对应页面；若内容已删除，保留 404 比强行跳转更合理。
检查抓取与索引相关设置
迁移期间容易忽略 robots.txt 和站点地图。需要明确两点：robots.txt 的抓取限制不等于可靠的索引移除，它只影响抓取，不保证页面从索引中消失；站点地图提交也不保证收录，它只是帮助发现 URL。
- 确认新站
robots.txt没有误屏蔽整站或关键目录。 - 确认站点地图中的 URL 是新站地址，而不是旧域名。
- 如果迁移期间需要临时禁止抓取，要清楚这只减少抓取，不等于移除已有索引。
- 不同搜索引擎对站点地图和抓取指令的支持与处理方式不同，需分别核查。
复查方式：直接访问 你的域名/robots.txt 和站点地图地址，确认内容与预期一致，再用抓取测试工具查看关键页面是否可抓取。
验证主机环境与访问稳定性
主机迁移后，环境差异会直接影响页面表现。需要核对 PHP 版本、数据库版本、伪静态规则、SSL 证书和默认首页配置是否与新站要求一致。HTTPS 能加密传输，但不保证站点没有安全漏洞，也不直接保证排名。
对比两种处理方案的适用条件：
- 直接切换 DNS：适合新旧主机环境一致、已充分测试、可接受短暂波动的情况。切换后要持续观察状态码和错误日志。
- 旧主机并行一段时间：适合改版幅度大、URL 变化多、需要逐步验证重定向的情况。并行期间要确保两个环境不会同时产生重复内容，必要时用规范标签或重定向指向新站。
判断结果的方法：切换后连续检查首页、栏目页、文章页和表单提交，确认返回 200、资源加载正常、无混合内容报错。若出现大面积 5xx，先回退 DNS 或恢复旧环境，再排查主机配置。
复查清单与下一步
切换完成后，按以下顺序复查：旧 URL 是否正确跳转；新 URL 是否可正常访问；robots.txt 和站点地图是否指向新站；主机错误日志是否有异常；表单和搜索功能是否可用。若发现问题，先判断是重定向、环境配置还是数据导入导致，再决定修复还是回退。
下一步建议：先在一台测试环境完成上述核对，再执行正式切换；切换后保留旧主机至少数天，便于快速回退和对比。
