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

基木鱼建站网站迁移应准备哪些记录：先做一份可交接的迁移台账

基木鱼建站迁移前，最先要准备的不是页面素材，而是一份能让人接手、能逐项核对的迁移记录台账。台账至少应包含：原站点页面清单、内容与素材归属、表单和咨询入口配置、域名与解析信息、跳转对应关系、权限与账号交接、以及迁移后的检查结果。时间和人手有限时，优先整理页面清单和跳转对应表，这两项直接决定迁移后用户能否找到原内容、咨询入口是否还能用。

假设一个只有两人的迁移场景

假设某团队用基木鱼建站做了二十个页面，现在要迁到新站点，只有一名运营和一名设计，时间只有三天。合理的做法不是先改页面样式，而是先做记录：第一天导出页面清单和表单配置，第二天确定跳转对应关系，第三天只做抽查和补漏。常见错误是三个人同时改页面、没有人记录旧地址和新地址的对应关系，结果上线后发现部分旧链接打不开，表单提交也进了旧后台，排查时已经找不到原始配置。

迁移台账必须包含的记录项

• 页面清单：每个页面的标题、原路径、页面类型（首页、栏目页、详情页、表单页）。
• 内容归属：文字、图片、视频分别由谁提供，是否有外部授权素材。
• 表单与咨询入口：表单字段、提交后的接收方式、按钮跳转目标。
• 域名与解析：当前使用的域名、解析记录、是否启用HTTPS。
• 跳转对应表：旧地址与新地址一一对应，标注是永久跳转还是临时跳转。
• 权限交接：谁有编辑、发布、导出权限，迁移后是否需要回收。
• 检查记录：迁移后逐项打勾的结果，包括页面可访问、表单可提交、跳转生效。

记录项不必复杂，用一张表格即可。关键是每一项都能对应到具体的人和时间，而不是只写“已处理”。

最先处理的顺序与判断依据

人手有限时，按影响面排序：先处理有表单和咨询入口的页面，再处理有外部推广链接的页面，最后处理普通展示页。判断依据是“这个页面失效后是否直接损失咨询或流量”。如果一个页面只是企业介绍，短期打不开影响有限；如果是一个投放落地页，表单失效就意味着线索中断，必须优先核对。

跳转对应表要逐个填写，不能只写“旧站跳新站首页”。例如假设旧地址是 /contact，新地址是 /about-contact，就应写成一行明确对应；如果旧页面已经删除且没有替代内容，应记录为“无对应，返回404并说明原因”，而不是随意跳到首页。

迁移后的检查项与结果判断

1. 随机抽取五个旧地址，确认能打开目标页面或正确跳转。
2. 提交一次测试表单，确认接收方能看到记录。
3. 检查页面标题和描述是否随内容一起迁移，没有出现空白。
4. 确认移动端打开无横向滚动、按钮可点击。
5. 把检查结果写回台账，标注通过或待修复。

如果跳转后打开的是无关页面，说明对应关系填错；如果表单提交后没有记录，说明接收配置没有同步迁移。这两种情况都应在台账中单独标记，而不是笼统写“迁移完成”。

交接时最容易漏掉的三类记录

第一类是账号权限记录。迁移后旧账号是否还要保留、谁负责停用，需要写清楚。第二类是素材源文件位置。只记录“图片已上传”不够，应记录源文件在哪个文件夹，方便后续替换。第三类是变更记录。迁移过程中改了哪些标题、删了哪些页面，都要留一行说明，避免以后没人知道为什么少了一个页面。

下一步可以直接建一张三列表格：旧地址、新地址、检查结果。先把有表单的页面填进去，再补其他页面，边填边核对，比迁移完成后再回头找问题省力得多。