重庆云主机改版或迁移时应核对什么 - 准备、实施、验证与维护清单
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /79122b5d35ec.html
📄
重庆云主机改版或迁移时应核对什么 - 准备、实施、验证与维护清单
对重庆云主机上的站点做改版或迁移，真正要核对的不是“新机器能不能打开”，而是旧地址、解析、证书、抓取规则、页面内容与数据是否在切换前后保持一致。最关键的一步是：在正式切换前，用一份可回滚的核对清单，把每个URL的旧状态和新状态逐一比对，确认无误后再改DNS或切流量。
准备阶段：先盘点，不要先动服务器
准备阶段的目标是形成一份可执行的对照表，而不是急着购买或重装重庆云主机。多人协作时，建议由一人负责整理，另一人复核。
- 导出旧站全部可访问URL，包括首页、栏目页、内容页、标签页和分页。
- 记录每个URL的当前HTTP状态码、页面标题、主要正文特征、 canonical 设置。
- 确认旧站是否依赖特定运行环境，例如PHP版本、数据库版本、伪静态规则、计划任务。
- 确认新重庆云主机的公网IP、内网IP、带宽、系统盘与数据盘挂载方式。
- 列出所有需要改动的域名解析记录，区分A记录、CNAME记录和邮件相关记录。
这里最关键的是URL对照表。改版常伴随路径变化，例如把 /old/page.html 改成 /new/page/。如果这一步没有记录，实施阶段就只能凭记忆补规则，返工概率很高。
实施阶段：迁移顺序与抓取规则
实施时建议按“先数据、再程序、后流量”的顺序推进。先在重庆云主机上部署完整环境，导入数据库和文件，确认本地或内网可以正常访问，再考虑对外解析。
如果路径发生变化，需要在新站配置301跳转。301表示永久跳转，适合改版后不再保留的旧地址；302表示临时跳转，适合短期维护。不要把所有旧URL都跳转到首页，这会让搜索引擎无法判断新页面对应关系。
robots.txt 的抓取限制不等于可靠的索引移除。若旧站曾用 robots.txt 屏蔽某些目录，迁移后要重新检查：新站是否仍误屏蔽了需要被抓取的资源。站点地图不保证收录，它只是提交URL的辅助方式，不能替代可访问性和内容质量。
HTTPS 不保证安全无漏洞或排名。证书要覆盖所有实际使用的域名，包括带 www 和不带 www 的版本。若新旧域名同时启用，应确定一个主域名，另一个做跳转，避免同一内容出现多个可访问地址。
验证阶段：切换后必须逐项检查
切换DNS后，不要只看首页。验证阶段应覆盖以下检查项：
- 用不同网络环境访问主要URL，确认返回200状态码，而不是502、403或跳转循环。
- 检查旧URL是否按预期返回301，且跳转目标与对照表一致。
- 检查页面内链、图片、CSS、JS是否仍指向旧域名或旧IP。
- 检查表单提交、登录、支付、搜索等动态功能是否正常。
- 检查数据库连接、缓存、计划任务和日志写入是否正常。
- 分别核查不同搜索引擎的抓取情况，因为各家对跳转、站点地图和抓取规则的支持与处理并不完全相同。
假设一个例子：某内容页旧地址为 /article/100，新地址为 /posts/100。切换后访问旧地址，若返回200且内容与旧页相同，说明跳转未生效；若返回301且目标为新地址，说明跳转生效；若返回404，说明规则缺失或匹配顺序有误。这个判断只针对该URL，其他URL仍需逐一验证。
维护阶段：观察、回滚与协作交接
切换完成后至少持续观察一段时间。重点看服务器错误日志、访问日志、抓取频率和页面状态码变化。若发现大量404或跳转异常，应优先修复规则，而不是反复改DNS。
多人协作时，交付清楚比“口头说没问题”更重要。建议保留三样东西：URL对照表、跳转规则文件、切换与回滚步骤。回滚条件要提前写清楚，例如“主要页面连续返回5xx超过设定阈值”或“核心功能不可用”，并指定谁有权执行回滚。
维护阶段还要注意：旧重庆云主机不要立即释放。保留一段时间，用于比对数据、回滚或排查遗漏。确认新环境稳定后，再按计划处理旧资源。
下一步，建议先把旧站URL导出并与新站路径做一次完整比对，生成跳转对照表，再安排切换窗口。
