网站设计流程：网站迁移应准备哪些记录
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /af2467b621c7.html
📄
网站设计流程：网站迁移应准备哪些记录
网站迁移前最该准备的不是服务器账号，而是一份能对照回滚的迁移记录。它至少包含原站页面清单、URL 映射、重定向规则、DNS 与解析记录、数据库和文件备份位置、验证结果。缺少这份记录，迁移后一旦出现 404、样式错乱或收录异常，很难判断是漏传文件、规则写错还是解析未生效。最关键的一步是提前建立“旧 URL → 新 URL”一一对应的映射表，并在迁移前用爬虫或站点地图导出全部可访问地址。
准备阶段：先盘点，再动手
迁移前把现有站点当作一个待交接的项目来记录，而不是直接覆盖文件。建议整理以下内容：
- 页面与资源清单：从站点地图、
sitemap.xml或爬虫工具导出所有 HTML 页面，同时记录图片、CSS、JS、字体、下载文件的路径。 - URL 映射表：逐条写明旧地址与新地址。若新站结构不变，映射可一一对应；若栏目调整，需人工确认每条旧地址的落点。
- 技术环境记录：原站使用的服务器类型、程序版本、数据库类型与版本、伪静态规则、SSL 证书到期时间。
- DNS 与域名记录：当前 A 记录、CNAME、MX、TXT 等解析值，以及域名注册商和 DNS 服务商。迁移前截图或导出，避免改错后无法还原。
- 备份位置：完整文件备份与数据库备份存放在哪里，备份时间点是什么，恢复命令或恢复入口写清楚。
这一步的判断标准很简单：假设新站上线后首页打不开，你能否只靠这份记录在半小时内定位到是解析、程序还是文件权限问题。如果不能，记录还不完整。
实施阶段：按记录执行，不凭记忆操作
实施时对照准备阶段的清单逐项打勾，重点记录每次改动的时间和内容。例如修改 DNS 前先记下原解析值，再写入新 IP；上传文件后记录目标目录和权限设置；导入数据库后记录字符集和表前缀是否一致。
重定向规则是实施中最容易出错的部分。每条规则应写明来源地址、目标地址、状态码。永久迁移用 301，临时调整用 302，不要混用。假设旧站有 200 个页面，映射表就应有 200 条对应关系；若只写一条泛匹配规则，需确认它不会把本应保留的页面也重定向走。
如果迁移涉及换域名，还要记录新域名是否已解析、证书是否已签发、程序内写死的旧域名是否已替换。常见写死位置包括配置文件、数据库中的站点地址字段、页面内的绝对链接。这些位置应在实施记录中单独列出，逐项核对。
验证阶段：用记录逐条检查结果
迁移完成后不要只看首页。按页面清单抽样访问，至少覆盖首页、栏目页、内容页、搜索页、表单页和 404 页面。验证项包括：
- 旧 URL 是否按映射表跳转到正确的新 URL，状态码是否为 301。
- 页面样式、图片、脚本是否正常加载，控制台有无报错。
- 表单提交、登录、支付等交互功能是否可用。
- 移动端与桌面端显示是否一致。
- 站点地图和 robots 文件是否指向新地址。
若某项不通过，回到实施记录查找对应改动。例如图片不显示，先看文件是否上传到记录中的目标目录，再看路径是否仍指向旧域名。验证结果也应写回记录，形成“问题—原因—处理”的闭环，方便后续复查。
维护阶段：保留记录并持续观察
迁移上线后至少保留原备份和映射表一段时间，不要立即删除旧站文件或旧解析记录。观察服务器访问日志和搜索平台提供的抓取数据，确认旧地址的请求是否被正确重定向、新地址是否被正常访问。若发现大量 404，说明映射表有遗漏，应补充规则并记录补充时间。
维护记录还应包含证书续期时间、备份周期和下次检查日期。这样即使迁移由不同人员接手，也能依据记录判断当前状态，而不是重新猜测。
下一步可以做的具体动作：打开现有站点地图或爬虫导出文件，新建一张表格，填入旧 URL、新 URL、状态码三列，先完成前 20 条的映射核对。这张表就是后续迁移和回滚的基础。
