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

网站开发入门指南：网站迁移应准备哪些记录？一份可执行的迁移清单

网站迁移应准备的记录，核心是三类：迁移前的现状快照、迁移中的操作日志、迁移后的验证结果。缺少任何一类，出问题时都只能靠猜测。下面按“先记录什么、再比较什么、最后怎么验证”的顺序展开。

迁移前：先给旧站做一份可对比的现状快照

迁移最容易踩的坑，是旧站关掉之后才发现“原来那个页面本来是什么样”已经无从查证。所以第一步不是动手搬，而是把旧站的关键信息记录下来，作为日后对比的依据。

• URL 清单：把旧站所有可访问页面地址导出，包括栏目页、详情页、标签页、分页。可以用站点地图文件、爬虫工具或后台导出功能获得。
• 页面状态记录：每个 URL 对应的 HTTP 状态码、页面标题、主要关键词位置。状态码为 200 的是正常页，301/302 是跳转页，404 是失效页，这三类处理方式完全不同。
• 收录与流量基线：记录迁移前一段时间内，各页面在搜索中的展现与点击情况。这份基线是迁移后判断“有没有掉”的唯一参照，没有它就无法区分正常波动和迁移事故。
• 技术配置：服务器环境、程序版本、数据库结构、伪静态规则、SSL 证书信息。这些决定了新环境能否复现旧站行为。

这一步的代价是时间：一个几百页的站点，完整梳理通常需要数小时到一天。但相比迁移后花几周排查排名下滑，这个投入是划算的。

迁移中：把每一次改动写成可回溯的操作日志

迁移过程中的记录，重点不是“做了什么”，而是“什么时候做的、谁做的、做完后系统是什么状态”。因为一旦出问题，你需要知道是哪一步引入的。

建议记录以下内容：

1. 操作时间线：DNS 切换、数据库导入、文件上传、规则修改各自的时间点。
2. 变更内容：具体改了什么，比如“将 /old-path/ 重定向到 /new-path/”，而不是笼统写“做了跳转”。
3. 新旧 URL 映射表：这是迁移记录里最核心的一张表。每一行包含旧地址、新地址、跳转类型。映射表越完整，迁移后出现 404 的概率越低。
4. 测试结果：每次改动后抽查了哪些页面、返回什么状态码、页面内容是否正常显示。

判断映射表是否合格，有一个简单标准：随机抽 20 个旧 URL，逐个访问，看是否都能到达内容对应的新页面。如果超过两三个落空，说明映射表需要补全。

迁移后：用检查项确认结果，而不是凭感觉

迁移完成后，需要拿迁移前的快照逐项对照。以下是可直接执行的检查项：

• 旧 URL 是否全部返回 301 并指向内容对应的新地址，而不是统一跳首页。
• 新站的页面标题、描述、正文是否与旧站对应页面一致，有无遗漏或错位。
• 站点地图是否已更新为新地址，并提交给搜索引擎。
• 搜索中的展现与点击，是否在可接受范围内波动。波动幅度需要结合迁移前的基线判断，不能只看绝对值。
• 服务器日志中是否出现大量 404 或 500，这些是映射遗漏或环境配置问题的直接信号。

需要说明的是，迁移后短期内搜索表现出现波动是常见现象，搜索引擎需要重新抓取和评估新地址。判断是否属于正常波动，依据是：旧 URL 是否正确跳转、新页面是否可正常访问、映射表是否完整。这三项都通过，就应继续观察而非频繁改动。

什么情况下需要把记录做得更细

并非所有迁移都需要同等颗粒度的记录。以下情况建议提高记录标准：

• 站点规模大、层级深：URL 数量多、目录结构复杂时，映射表必须逐条对应，不能靠规则批量猜测。
• 更换域名而非仅换服务器：域名变更涉及全站地址重写，映射表是唯一能保证不丢页面的依据。
• 迁移同时改版：改版会改变页面结构和内容对应关系，此时需要额外记录“旧页面内容在新站去了哪里”，否则跳转目标容易指错。

如果只是同一域名下更换服务器、页面地址完全不变，记录可以简化，但仍需保留迁移前快照和迁移后的状态检查结果，用于确认服务正常。

下一步：先导出旧站 URL 清单

如果还没开始迁移，现在就可以做一件事：把旧站所有可访问 URL 导出成一份表格，加上状态码和页面标题两列。这份表格会成为后续映射、跳转和验证的共同底稿，也是判断迁移是否成功的起点。