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

优化建站_网站迁移应准备哪些记录：从旧站观察到新站复查的完整清单

网站迁移前，最该准备的是一份能对照旧站与新站的记录清单。它至少包括页面清单、URL 映射、重定向规则、内容与元数据备份、技术配置、统计与站长平台验证记录，以及迁移后的复查结果。没有这些记录，迁移后一旦流量或收录异常，很难判断是遗漏、配置错误还是正常波动。

先记录旧站现状：迁移前必须留档的内容

迁移不是复制文件，而是把旧站可观察到的状态固定下来。建议在动手前导出以下记录：

• 页面清单：用爬虫工具或站点地图导出所有可访问 URL，标注哪些是栏目页、详情页、标签页、分页。
• URL 映射表：每一条旧 URL 对应哪一条新 URL。没有对应页面的，要写明是删除、合并还是跳转到上级栏目。
• 内容与元数据备份：标题、描述、正文、图片文件名、内链关系。数据库导出和静态文件备份要分别留存。
• 技术配置：服务器环境、伪静态规则、robots.txt、站点地图、HTTPS 证书、CDN 缓存规则。
• 统计与验证记录：统计代码、站长平台验证文件、历史收录量、主要入口页面。

这些记录的作用是迁移后逐项对照。若只备份数据库，不记录 URL 和重定向关系，新站上线后大量旧链接会直接 404，而你可能几天后才发现。

判断哪些页面必须保留原 URL 或做重定向

并非所有旧页面都值得保留。判断依据可以按以下顺序：

1. 有自然搜索流量的页面：优先保留原路径，或做 301 重定向到内容最接近的新页面。
2. 有外部链接的页面：用外链查询工具找出被引用的 URL，这些页面迁移后必须可访问。
3. 有转化价值的页面：产品页、服务页、联系页，即使流量低也应保留或重定向。
4. 纯功能页和重复页：如旧版搜索结果页、打印页，可以删除并跳转到相关栏目，但要记录处理方式。

假设一个旧站有 500 个 URL，其中 80 个有搜索点击，30 个有外链。迁移记录里应把这 110 个列为高优先级，逐一确认新 URL 和重定向状态码。其余页面可以批量跳转到首页或栏目页，但不能全部跳首页，否则会被视为软 404。

迁移中要同步记录的操作与配置

迁移执行阶段，记录重点从“旧站有什么”转为“新站改了什么”。建议边操作边填写：

• 重定向规则文件：记录规则条数、生效范围、测试结果。用 curl -I 检查返回状态码。
• robots.txt 与站点地图：新站上线后是否允许抓取，站点地图是否更新为新的 URL 结构。
• 内链替换记录：旧域名内链是否全部替换为新域名，避免跳转链过多。
• 统计代码与验证文件：确认新站已安装统计代码，站长平台已验证新域名。
• 服务器与 CDN 配置：记录缓存刷新时间、HTTPS 强制跳转是否生效。

技术示例中，若旧站使用 <h2> 作为栏目标题，新站模板也应保持相同层级，不要迁移后改成 <div>。这类结构变化不影响排名保证，但会影响页面语义和后续维护。

迁移后复查：用记录逐项核对，而不是凭感觉

上线后 24 小时内，按迁移前准备的清单做第一轮复查：

1. 随机抽取 20 条旧 URL，检查是否 301 到正确新页，状态码是否为 200。
2. 检查新站站点地图是否可访问，是否包含主要页面。
3. 在站长平台提交新站点地图，查看抓取异常和 404 报告。
4. 对比迁移前后一周的搜索点击、展现和入口页面变化，区分正常波动与断崖式下跌。
5. 检查统计代码是否正常记录，避免数据断层导致后续判断失准。

如果发现某类页面流量下降，先查该类页面的重定向记录，再查 robots.txt 和 canonical 标签。不要一看到下降就改标题或堆内容，迁移问题通常出在 URL 和可访问性上。

下一步：把记录变成可复查的表格

现在就可以建一张迁移记录表，列包括：旧 URL、新 URL、页面类型、是否有流量、是否有外链、重定向状态码、复查结果、备注。每迁移一批就填一批，上线后按表复查。这样即使迁移周期拉长，也能清楚知道哪些页面已处理、哪些还没验证。