网站建设推广-网站迁移应准备哪些记录：多人协作交付清单
📍 WDQWDWQD987AAAAA:216.73.216.85
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /6cb1c2cf3d20.html
📄
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /6cb1c2cf3d20.html
📄
网站建设推广-网站迁移应准备哪些记录：多人协作交付清单
网站迁移前最该准备的是一份可交接的记录清单：谁改了DNS、旧服务器上还有哪些定时任务、哪些页面做了301、哪些推广链接不能断。记录的目的不是存档，而是让接手的人不用猜、不用返工。下面按迁移顺序给出可执行清单，每项都说明查什么、怎么查、结果说明什么。
迁移前：先把现状盘清楚
迁移前最容易漏的是“隐性依赖”，比如定时脚本、第三方回调、CDN回源配置。建议逐项记录并让至少两人复核。
- 域名与DNS记录：查什么——A记录、CNAME、MX、TXT（含SPF、DKIM、验证记录）。怎么查——在域名注册商或DNS服务商后台导出记录，再用
dig或nslookup从外部验证一遍。结果说明——如果MX和TXT记录没跟着迁移，邮件会中断，这不是网站本身的问题，但常被误判为“迁移失败”。 - 服务器环境清单：查什么——Web服务器类型与版本、PHP/Node/Python运行时版本、扩展模块、系统级定时任务（crontab）。怎么查——登录旧服务器执行
crontab -l、查看Web服务器配置文件、列出已安装扩展。结果说明——版本差异会导致页面报错或功能失效，记录里要写清“旧环境是什么”，而不是只写“能跑”。 - 数据库与文件依赖：查什么——数据库版本、字符集、表前缀、上传目录、缓存目录、日志目录的绝对路径。怎么查——在数据库执行
SELECT VERSION();和SHOW VARIABLES LIKE 'character_set%';，在服务器上确认目录实际位置。结果说明——路径写错会导致图片404或缓存失效，这类问题在迁移后往往延迟出现。 - 第三方服务与回调地址：查什么——支付回调、短信、对象存储、统计代码、地图API的域名白名单和回调URL。怎么查——登录各服务商后台查看已配置的域名和回调地址，逐条截图或导出。结果说明——如果回调地址仍指向旧域名，支付或表单提交会失败，且报错信息通常不指向真正原因。
迁移中：URL与推广链接的对应记录
网站建设推广积累的外部链接和推广链接是迁移中最容易断的资产。需要记录旧URL到新URL的映射，而不是只记录“首页迁移完成”。
- URL映射表：查什么——旧站所有可访问URL及其对应的新URL。怎么查——用爬虫工具抓取旧站内链，结合服务器访问日志提取被访问过的URL。结果说明——映射表里要区分“内容页”“栏目页”“带参数页”，带参数的推广链接（如
?from=）如果直接跳首页，推广数据会失真。 - 301跳转规则：查什么——每条旧URL跳转到哪个新URL、用301还是302。怎么查——在服务器或CDN配置中逐条核对，再用
curl -I请求旧URL查看返回状态码和Location头。结果说明——301表示永久迁移，适合内容对应关系稳定的页面；302是临时跳转，不适合长期迁移。跳转链超过一层会增加加载时间，也容易被判断为配置错误。 - 推广渠道链接记录：查什么——各推广渠道（搜索广告、信息流、合作方）使用的落地页URL、UTM参数、短链。怎么查——从各渠道后台导出已投放链接，与URL映射表比对。结果说明——如果短链服务不支持修改目标地址，迁移前就要准备新短链并通知渠道方替换，否则点击会打到旧地址。
- 站点地图与robots记录：查什么——旧sitemap地址、robots.txt中是否屏蔽了重要目录。怎么查——直接访问旧站
/sitemap.xml和/robots.txt，记录内容。结果说明——迁移后新站要提交新sitemap；如果旧robots屏蔽了某个目录而新站忘了放开，该目录不会被抓取，但页面本身能正常访问，问题隐蔽。
迁移后：验证记录与交接确认
迁移完成不等于交付完成。验证记录要能回答“哪些检查过了、结果是什么、谁确认的”。
- 核心页面状态码检查：抽查首页、栏目页、内容页、推广落地页各若干条，用
curl -I或浏览器开发者工具确认返回200而非404或500。结果说明——出现404说明映射遗漏，出现500说明环境或数据库配置有问题。 - 跳转链检查：对旧URL发起请求，确认最终到达的页面与预期一致，且跳转次数不超过一次。结果说明——多次跳转或跳到无关页面，说明规则写错或规则顺序冲突。
- 表单与支付回调测试：用测试数据提交表单、发起一笔测试支付（如果适用），确认回调能到达新服务器。结果说明——回调失败通常因为白名单未更新，需要回到第三方后台修改。
- 推广链接抽查：从每个推广渠道取一条实际投放链接，点击后确认落地页正确、参数未丢失。结果说明——参数丢失会导致统计归因错误，但页面看起来正常，属于“看起来没问题”的故障。
- 交接确认记录：记录迁移日期、执行人、复核人、已知未解决问题及负责人。结果说明——这份记录让后续维护者知道哪些是遗留问题、哪些是预期行为，减少重复排查。
多人协作时的记录格式建议
清单要能直接交接，建议用表格或结构化文本，每行至少包含：项目、旧值、新值、检查方法、检查结果、确认人。假设一个场景：旧站栏目页/news/迁移到新站/zixun/，记录中应写明旧URL、新URL、跳转类型301、检查命令curl -I 旧URL、预期结果“返回301且Location为新URL”、实际结果、确认人。这样即使执行人离职，接手的人也能按记录复现检查，而不是重新猜一遍。
下一步：把上面清单转成一份实际表格，在迁移前先填“旧值”和“检查方法”两列，迁移中填“新值”，迁移后填“检查结果”和“确认人”。填不出来的项，就是迁移前还需要补查的项。
