建站推广一体化，网站迁移应准备哪些记录
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /3f84f5e4c912.html
📄
建站推广一体化，网站迁移应准备哪些记录
网站迁移前应准备的核心记录包括：原站URL清单与对应新URL、页面标题与描述、结构化数据、内链关系、外链来源、服务器与DNS配置、重定向规则、统计与站长平台验证信息、以及迁移前后的抓取与排名观察记录。准备这些记录的目的不是走形式，而是让迁移后能逐项比对，判断哪些流量和收录变化属于正常波动，哪些是配置遗漏造成的损失。
先观察：迁移前要留下原站的可核对快照
迁移一旦开始，原站状态就会改变，所以快照必须在动手前完成。建议至少记录以下内容：
- 用站点地图和爬虫工具导出全部可访问URL，标注每个URL的标题、状态码、是否被索引。
- 记录主要页面的自然流量入口词和落地页对应关系，来源可以是统计工具或站长平台，按页面而非按全站汇总。
- 保存首页、栏目页、详情页的模板结构，包括导航层级和面包屑路径。
- 记录服务器环境：域名解析记录、CDN配置、SSL证书类型与到期时间、robots.txt内容。
这份快照的用途是迁移后做逐项对照。没有它，只能凭感觉判断“流量好像掉了”，无法定位是哪个环节出了问题。
再判断：两种迁移处理方案的适用条件
迁移时常见的两种处理方式是“整站平移”和“分批迁移”，选择依据是站点规模和业务容忍度。
整站平移适合页面数量较少、结构清晰、外链集中在少数核心页面的站点。它的优点是重定向规则一次性配置完成，观察周期统一。风险是如果新站模板或URL规则有误，影响面是全局的。
分批迁移适合页面量大、栏目之间流量差异明显的站点。可以先迁移一个子目录或一类内容，观察两到四周的收录和流量变化，再决定是否继续。它的代价是迁移周期长，期间新旧两套URL并存，需要额外的重定向和规范化记录。
判断方法：如果站点核心流量集中在不到两成的页面上，且这些页面结构一致，整站平移更省事；如果各栏目流量分布均匀，或迁移涉及更换CMS导致URL规则大改，分批迁移更容易控制风险。
处理：迁移中必须建立的记录项
迁移执行阶段，记录的重点是“新旧对应关系”和“配置变更”。
- URL映射表：每一行包含旧URL、新URL、重定向类型（301或302）、是否已生效。301用于永久迁移，302只适合临时测试，长期使用302不会传递权重。
- 标题与描述对照：新页面如果改写了标题和描述，记录改动前后内容，便于判断流量变化是否由文案变化引起。
- 结构化数据记录：原站使用的结构化数据类型及对应页面，迁移后逐项验证是否仍然有效。注意，结构化数据本身不保证排名提升，它影响的是搜索结果中的展示形式。
- 内链检查记录：迁移后容易出现指向旧URL的内链。记录检查结果，把仍指向旧地址的链接改为新地址或确认重定向生效。
- 外链来源清单：列出主要外部链接指向的旧URL，迁移后确认这些链接能正常跳转到新页面。无法控制的外部链接只能依赖重定向。
- 统计与验证信息：统计代码是否已部署到新站、站长平台是否完成新域名验证、站点地图是否已提交。这些属于推广一体化的基础配置，迁移时容易遗漏。
技术示例：如果新站使用<link rel="canonical">指向自身，需确认它没有误指向旧域名。重定向规则建议写成旧路径 → 新路径的逐条记录，而不是只写“已配置重定向”。
复查：迁移后按时间节点核对什么
迁移完成后不要只看某一天的流量数字，应按节点复查。
- 24小时内：抽查主要页面的状态码，确认返回200而非404或500；确认重定向链不超过一跳。
- 一周内：查看站长平台的抓取错误和索引覆盖变化，对比迁移前的URL清单，找出未被收录的新页面。
- 两到四周：对比迁移前的入口词和落地页记录，判断流量变化是集中在少数页面还是全局。如果是全局下降，优先检查robots.txt、DNS和重定向；如果是局部下降，检查对应页面的标题、内容和内链。
复查记录应写明观察日期、指标名称、对比基线和初步结论。例如“迁移后第10天，栏目A自然流量较迁移前下降明显，检查发现该栏目重定向缺失，已补配”，这比“流量下降了”有用得多。
下一步可以做的事
如果你正准备迁移，先导出当前站点的URL清单和主要页面流量记录，再决定用整站平移还是分批迁移。把URL映射表作为迁移的核心文档，每完成一项就在表里标注状态，迁移后按24小时、一周、四周三个节点复查并记录结论。
