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

做网站优化 - 网站迁移应准备哪些记录：一份可执行的迁移留档清单

网站迁移前最该准备的记录，不是一份笼统的“备份”，而是一组能让你在出问题时对照、回滚和验证的清单：迁移前抓取并保存旧站关键页面的状态，迁移中记录每一条重定向和配置改动，迁移后保留新旧URL对照表与监控数据。判断标准很简单——如果迁移后某个页面流量掉了，你能凭记录在十分钟内说清它原来是什么URL、现在指向哪里、中间改过什么。

迁移前：先把“旧状态”固定下来

很多迁移事故的根源是旧站已经关掉，才发现没人记得原来有哪些页面、哪些页面有外链。迁移前要做的记录包括：

• URL清单：用站点地图、服务器日志或爬虫工具导出全部可访问URL，标注哪些是内容页、栏目页、分页、标签页。日志比站点地图更接近真实，因为它包含未被链接的页面。
• 页面状态快照：对重点页面保存标题、H1、主要正文片段、canonical标签值。迁移后逐项比对，能快速发现模板替换导致的标题丢失或canonical指向错误。
• 收录与流量基线：记录迁移前一段时间的自然搜索落地页、点击量、展现量。这份基线是迁移后判断“是否正常波动”的唯一参照，没有它就只能凭感觉。
• 外链来源记录：导出指向站内的外部链接及其目标URL。这些URL一旦失效，损失的是最难恢复的权重。

如果站点规模很小，手动整理一张表格即可；如果页面上千，用爬虫工具导出后按目录归类。适用条件是：只要迁移会改变URL结构或域名，这一步就不能省。判断结果是——清单越完整，后续重定向规则越不容易漏。

迁移中：记录每一次改动，而不是只记录结果

迁移过程中的记录要能回答“谁在什么时候改了什么”。具体包括：

1. 新旧URL映射表：一行一条，旧URL对应新URL，标注是301、302还是无跳转。这是迁移留档里最核心的一份文件，重定向规则直接从它生成。
2. 重定向规则本身：保存配置文件或服务器规则的原文，而不是只记“已配置”。出问题时能直接比对哪条规则被覆盖。
3. robots.txt与meta robots的变更记录：迁移期间常有人临时加Disallow或noindex防止新站被提前收录，却忘了删。记录下每次改动的时间和值，上线后逐条核对。
4. DNS与服务器配置变更时间点：记录解析切换、证书更换、CDN回源调整的时间。多个变更叠加时，只有时间线能帮你定位是哪一步引发的异常。

这里要区分“可能原因”和“已经定位的原因”。迁移后出现404，可能来自重定向缺失、服务器规则未生效、或大小写不一致，不要在没有日志证据时就断定是某一条。记录的价值正是把猜测变成可验证的线索。

迁移后：用对照表验证，而不是等流量自己恢复

上线后要按固定节奏做检查，并把每次检查结果留档：

• 抽样验证重定向：从映射表里随机抽20到50条旧URL，实际访问，确认返回301且落到正确新页面。抽到异常就扩大范围。
• 比对canonical与标题：把迁移前的快照和当前页面逐项对照，重点看首页、栏目页和高流量内容页。
• 检查站点地图与robots：确认新站点地图可访问、内容为最新URL，robots没有误屏蔽重要目录。
• 记录收录与流量变化：按周记录自然搜索落地页数量和点击量，与迁移前基线对比。波动是正常的，但持续下降且落地页数量减少，说明有页面没被正确接续。

适用条件是：迁移后至少观察一个完整的抓取周期再下结论。判断结果是——如果对照表里每条旧URL都能找到对应新URL且返回正常，剩下的多数是时间问题；如果对照表本身有缺口，就要先补映射再谈优化。

小站与大站的记录取舍

不是所有站点都需要同等颗粒度。几百个页面以内，一张映射表加一份基线截图就够；上万页面、多语言或多子域时，映射表要按目录拆分，并额外记录参数处理规则（比如带?id=的URL是保留、合并还是丢弃）。代价是整理时间，收益是迁移后排查成本大幅下降。如果团队没有人力做全量映射，至少把有外链、有流量、有转化的页面优先覆盖，其余页面用规则批量处理并记录规则逻辑。

下一步：先导出当前站点的URL清单和自然搜索落地页报告，按是否有外链、是否有流量分成三档，再从第一档开始建新旧URL映射表——这张表就是整套迁移记录的起点。