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

黄山网站制作 - 网站迁移应准备哪些记录：一份可执行证据清单

网站迁移前最该准备的，不是一句“备份好了”，而是一组能还原现状、验证结果、定位故障的记录。对黄山网站制作项目来说，迁移可能发生在换主机、换域名、换CMS或调整栏目结构时。你需要留下迁移前基线、迁移中操作、迁移后核验三类记录，才能在出现404、收录波动或表单失效时判断问题出在哪一步。

迁移前：先记录现状基线

没有迁移前记录，迁移后就没有对比依据。以下四项建议在动手前完成。

• 页面清单：用爬虫工具或sitemap.xml导出全部URL，记录每个URL的标题、状态码、所属栏目。结果说明哪些页面必须保留原路径，哪些可以合并。
• 域名与DNS记录：记录当前A记录、CNAME、MX记录、TXT记录及TTL值。迁移后若邮件或子域失效，可对照判断是哪条解析被改动。
• 服务器环境：记录PHP或Node版本、数据库版本、伪静态规则、SSL证书到期时间。结果用于判断新环境是否具备同等运行条件。
• 流量与转化基线：记录近30天主要入口页、搜索点击量、表单提交量或订单量。迁移后若数据下滑，可区分是整体故障还是个别页面问题。

迁移中：保留操作与变更记录

迁移过程本身要留下可追溯的痕迹，重点记录“改了什么”和“何时改的”。

• 文件与数据库备份：记录备份时间、存放位置、校验值（如MD5）。若恢复后发现数据缺失，可确认备份是否完整。
• URL映射表：逐条列出旧URL与新URL，标记是301跳转、410删除还是保持不变。结果说明跳转规则是否覆盖全部旧链接。
• 配置变更日志：记录DNS修改时间、服务器切换时间、伪静态规则调整内容。出现解析未生效或规则冲突时，可按时间线排查。
• 账号与权限：记录后台管理员、数据库用户、FTP或SSH账号的变更。若迁移后无法登录，可判断是权限未同步还是密码错误。

迁移后：用检查项验证结果

迁移完成不等于迁移成功。以下检查项要逐条执行并记录结果。

1. 状态码抽查：随机抽取旧URL访问，确认返回301而非404或500。若返回404，说明映射表遗漏或服务器未加载跳转规则。
2. 核心页面功能：测试首页、栏目页、详情页、搜索页、表单提交。若表单无响应，可能是邮件服务、接口地址或跨域配置未同步。
3. 资源加载：检查图片、CSS、JS是否仍指向旧域名。若控制台报混合内容错误，说明部分资源未替换为新地址。
4. 收录与索引状态：在搜索资源平台提交新sitemap，观察已收录页面是否逐步替换。注意收录变化需要时间，短期波动不能直接判定失败。
5. 日志与错误：查看服务器错误日志和访问日志，记录404集中出现的路径。结果用于补充跳转规则或修正内链。

出现问题时，如何用记录定位原因

同一现象可能有多个解释，记录的作用是缩小范围。例如迁移后部分页面打不开：先查URL映射表，确认该页面是否在清单内；再查服务器日志，看请求是否到达新主机；最后查伪静态规则，判断是否被重写拦截。如果日志显示请求已到达但返回404，问题多在程序路由或文件路径；如果日志没有记录，问题多在DNS或CDN层。每一步都应有对应记录支撑，而不是凭感觉反复修改。

下一步建议

把上述清单整理成一张迁移检查表，每完成一项就填写实际结果和负责人。迁移后至少观察一个完整的流量周期，再根据记录决定是否需要补充跳转或回滚个别配置。