网站建设与SEO网站迁移应准备哪些记录：先别急着导数据，先建一份可核对的迁移台账
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /304216ca57cd.html
📄
网站建设与SEO网站迁移应准备哪些记录：先别急着导数据，先建一份可核对的迁移台账
网站迁移应准备的记录，核心是一份能回答“迁移前是什么、迁移中改了什么、迁移后怎么核对”的台账。常见误解是：只要把数据库和文件复制过去，再提交一次新站点地图就算完成。实际上，真正让迁移可控的不是操作本身，而是操作前后留下的可核对记录。对时间和人手有限的团队，优先准备下面五类记录，其余工作可以后补。
先纠正一个误解：迁移记录不是备份清单
备份只解决“能不能恢复”，迁移记录解决“有没有漏、有没有变、变了之后是否被正确识别”。两者不能互相替代。一个只记录了备份路径的团队，迁移后往往说不清哪些 URL 变了、哪些页面标题被重写、哪些内链还指向旧地址。
判断标准很简单：如果迁移后出现流量或收录波动，你能否在半小时内拿出一份表，逐条说明某个旧地址现在对应哪个新地址、状态码是多少、是否做过跳转。能，就说明记录合格；不能，就说明记录还停留在备份层面。
迁移前必须固定的四类基线记录
这四类记录要在动手前完成，因为它们描述的是“原状”，一旦开始改动就很难还原。
- URL 清单：列出所有可访问页面地址，至少包含首页、栏目页、内容页、标签或分类页。字段建议为：旧 URL、页面类型、是否有自然流量、是否有外链、迁移后目标 URL。
- 页面要素快照：对重点页面记录标题、描述、H1、正文首段和主要内链指向。不必全站抓取，优先记录有流量或有外链的页面。
- 技术配置记录：记录当前 robots.txt 内容、站点地图地址、规范链接写法、首选域（带 www 或不带）、HTTPS 状态。这些是迁移后最容易被动改掉的部分。
- 流量与收录基线：记录迁移前一段时间的自然搜索点击、展示、主要落地页和已收录页面数量。它是迁移后判断“是否异常”的唯一参照。
人手有限时，URL 清单和流量基线优先做，页面要素快照可以只覆盖重点页面。适用条件是站点规模不大或时间紧张；如果站点有大量由参数生成的地址，先按目录归并，不要试图逐条穷举。
迁移中要记录的三件事
迁移过程本身也要留痕，否则出问题时无法区分“计划内变更”和“意外改动”。
- 变更日志：按时间记录每一步操作，例如“切换 DNS”“替换域名”“重写内链”“更新站点地图”。每条写清执行人、时间、影响范围。
- 跳转映射表：旧 URL 到新 URL 的对应关系，以及使用的跳转类型。永久迁移用 301，临时调整用 302，不要混用。
- 例外清单：明确哪些页面不迁移、哪些页面合并、哪些页面直接下线。下线页面应返回 404 或 410，而不是全部跳首页。
短例子（假设场景）：某站点把 /old-guide/ 迁移到 /guide/，映射表记录为“旧地址→新地址，301”。迁移后检查该旧地址返回 301 且最终落地页内容一致，即为通过；若返回 200 但内容为空，则说明跳转未生效或目标页缺失。
迁移后按记录逐项核对
核对不是凭感觉看首页能不能打开，而是拿迁移前的基线逐项比对。建议按以下顺序检查：
- 抽查跳转映射表中的地址，确认状态码和落地页正确；
- 检查 robots.txt 是否误屏蔽新站，站点地图是否指向新域名；
- 对比重点页面的标题、H1 和规范链接是否与快照一致；
- 查看新域名下的收录情况，与迁移前基线对照，判断是延迟还是遗漏；
- 检查站内链接是否仍指向旧域名，尤其是导航和页脚。
如果发现异常，先回到变更日志定位是哪一步引入的，再决定回滚还是修补。没有变更日志时，只能靠猜测，修复成本会明显上升。
时间有限时的处理顺序
先做 URL 清单、跳转映射表和流量基线这三项，它们覆盖了迁移中最容易出问题的环节。页面要素快照可以只记录有外链或有点击的页面。变更日志从第一次操作开始记，哪怕只写一行。这样即使人手不足，也能在迁移后快速判断问题出在哪一环，而不是全站重查。
下一步：打开一份表格，先填旧 URL、目标 URL、跳转类型三列，把首页和主要栏目填完，再逐步补充内容页。这份表就是后续所有核对工作的起点。
