马鞍山建站：网站迁移应准备哪些记录，两种做法怎么选
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /090f36b6b3d0.html
📄
马鞍山建站：网站迁移应准备哪些记录，两种做法怎么选
网站迁移前最该准备的记录，是一份能独立核对、可回滚的迁移台账：域名与DNS解析、源站文件与数据库、URL清单与跳转规则、服务器环境参数、账号权限、备份位置、迁移前后的验证结果。没有这份台账，迁移就只能靠记忆和临时排查，一旦出现页面丢失或解析异常，很难判断问题出在哪一步。下面按“先记录、再迁移、后验收”的顺序说明。
迁移台账应包含哪些具体记录
台账不是简单列几个文件名，而是要让另一个人拿着它也能复现迁移过程。建议至少覆盖以下几类：
- 域名与解析记录：域名注册商、DNS服务商、当前A记录/CNAME/MX记录值、TTL、解析生效时间。迁移前后对比这些值，能快速判断是否解析未切换。
- 源站内容记录：网站根目录、数据库名称与版本、上传附件目录、伪静态或重写规则文件。记录这些是为了在新服务器上还原一致的环境。
- URL清单：迁移前抓取所有可访问页面，形成列表。迁移后逐条比对返回状态码，发现404或301错误。
- 账号与权限：服务器SSH账号、数据库账号、CMS后台管理员、FTP账号。迁移期间应临时记录，完成后及时更换密码。
- 备份记录：备份时间、备份文件存放位置、备份是否可解压。迁移前必须有一份完整备份，且验证过能恢复。
两种迁移做法：整站打包迁移与逐项重建
实际处理时通常有两种选择，适用条件不同。
整站打包迁移：把源站文件、数据库、配置整体打包，在新服务器解压还原。适合源站结构清晰、CMS版本一致、附件与数据库关联紧密的情况。优点是速度快、URL结构容易保持一致；缺点是如果源站本身有冗余文件或错误配置，会一并带过去。
逐项重建：在新服务器重新安装环境，按台账逐项导入内容、重建栏目和页面。适合源站技术栈老旧、需要顺便清理冗余、或目标环境与源环境差异较大的情况。优点是环境干净可控；缺点是耗时长，容易漏掉附件或自定义页面。
判断依据可以看三点：源站是否还能正常导出完整数据；新服务器环境是否与源站兼容；迁移窗口内能否接受较长时间的内容不同步。三项都满足时，整站打包更省事；其中一项不满足，逐项重建更稳妥。
迁移前必须完成的检查项
- 确认域名解析的TTL已调低，便于切换后快速生效和回退。
- 完整备份源站文件和数据库，并在本地或另一台机器上试解压一次。
- 导出全部URL清单，标注哪些是栏目页、内容页、附件地址。
- 记录当前服务器的运行环境：Web服务器类型、程序版本、数据库版本。
- 确认新服务器的目录权限、磁盘空间和数据库连接方式。
迁移后的验收信号
迁移完成不等于结束，要按台账逐项核对。可以执行的检查包括：随机抽取若干URL，确认返回200状态码；访问后台，确认内容、附件、栏目结构完整；检查旧URL是否按规则跳转到新地址；查看数据库连接是否正常，表单提交能否写入。若出现页面空白，可能原因包括程序版本不兼容、伪静态规则未生效、数据库连接信息错误，需要逐项排除，不能直接断定是单一原因。
对于马鞍山建站场景，如果迁移涉及本地服务商提供的服务器或托管环境，验收时还应确认新环境的备案信息、访问速度和续费方式是否与预期一致。这些属于服务条件核对，不是技术迁移本身，但会影响迁移后的可用性。
下一步可以做什么
先按上面的清单整理一份属于你自己网站的迁移台账，把域名解析、文件、数据库、URL和备份五项记录填完整。填完后，用一台测试环境按台账走一遍还原流程，验证记录是否够用。这样正式迁移时，你手里就有一份可对照、可回退的依据，而不是边迁移边猜。
