网站项目交付交接怎么做：账号、源码与文档清单
网站做完、验收通过，很多项目到这一步就收尾了。但真正决定网站能不能长期稳定运行的，往往是紧接着的那轮交接：域名在谁名下、服务器账号谁持有、源码能不能拿到、后台出问题先找谁。交接没做完，验收单签得再完整，半年后也可能因为一次续费提醒没看到而停站。
下面按实际交接的先后顺序展开。顺序本身有讲究：先确定归属，再移交账号，最后交文档；反过来做，容易在权限还没理清时就把密码改乱，反而增加排查成本。
一、先确认“东西在谁名下”，再谈交账号
域名注册人、ICP备案主体、云平台实名认证、小程序或公众号的主体信息，这几项最好都落在企业自己名下。常见的情况是：域名由服务商代为注册，账号绑的是对方的工作邮箱，续费提醒发到对方那里，合作一旦变化，转移域名需要双方配合，节奏就不在自己手上了。
这一层要核对的细节包括：域名到期时间、有没有开自动续费、DNS 解析托管在哪家服务商、备案号与主体名称是否一致。备案主体的变更需要重新提交审核，不是改个名字就完事，所以交接时发现主体不符，要预留出处理时间。
二、按系统分层清点账号，逐项当场登录验证
账号交接最容易出问题的地方，是“给了一个账号，但登录后发现权限不够”。比较稳妥的做法是按层清点，每交一项就当场登录一次：
- 域名注册商账号，以及转移密码（如需转出）
- DNS 解析权限，和解析记录的当前状态
- 服务器或云主机控制台，含快照与镜像权限
- 数据库账号与连接信息
- 网站后台的超级管理员账号
- CDN、SSL 证书的管理入口与到期时间
- 统计工具、站长平台验证
- 短信、地图、支付、邮件推送等第三方接口的账号与密钥
只给账号不给改密权限，基本等于没交接。交接完成后应立即修改密码，并确认原持有人的账号已被移除或降权，尤其是能登录服务器和后台的账号。
如果项目里含小程序，还要单独核对小程序的 AppID、开发者权限成员、服务器域名配置；含 APP 的，则要核对应用市场的开发者账号、安卓签名证书文件和推送证书——签名文件丢失会导致后续无法正常更新版本，这类资料经常没人主动提。
三、源码要和部署方式一起交
拿到一个压缩包，和拿到能重新部署起来的完整资料，是两件不同的事。前者只能证明“东西在这”，后者才能让另一个技术团队接手继续做。
- 代码仓库地址与访问权限，确认账号是加到项目里而不是临时分享
- 分支说明：哪个是生产分支，哪个用于日常开发
- 运行环境与依赖版本，包括语言版本和主要依赖包
- 配置文件与环境变量：数据库地址、密钥、第三方接口凭证分别存在哪里
- 构建与部署步骤，写清楚命令和顺序
- 部署目标：发布到哪台服务器、哪个目录、由谁触发
如果用的是第三方建站平台或带授权加密的系统，源码本身可能拿不到。这种情况下要确认的是另一组问题：内容数据能否导出、导出成什么格式、离开平台后栏目和文章还能不能复用。这一点在签约前就该问清楚，等到交接阶段再提，通常已经没有调整空间了。
四、设计文件与素材的授权范围
要交的是分层设计源文件，不是导出的图片。此外还有字体授权、购买的图片素材、图标库的许可范围。字体是最容易被忽略的一项：设计阶段用了未授权的商用字体，风险会随网站上线的同时转移到企业身上，事后替换又要重新调整版式。
五、文档不必厚，但要能让没参与开发的人操作一次
- 后台操作说明：怎么新增栏目、发布内容、分配编辑权限
- 定时任务在哪配置，执行频率如何
- 日志文件位置，以及常见故障的处理顺序
- 备份策略：备份什么、多久一次、存在哪、怎么恢复
- 维护期的起止时间、响应方式和联系人
判断文档够不够用有个简单办法：让一位没参与项目的同事，只照文档做一次“发布一篇带图的文章”，全程不提问。做不下来，说明文档还需要补。
六、把结果整理成可核对的东西
交接结束时至少留三样：一份逐项标注“已交／未交／不适用”的清单、双方确认的时间点、以及交接后修改密码的记录。笼统写一句“已完成交接”，在出问题时帮不上忙。
执行顺序建议是：先在原持有人状态下核对一遍，确认每项都能登录、能打开；再统一改密码；最后做一次完整自查——前台能否访问、后台能否登录、表单能否提交、手机端能否正常打开。如果先改密码再核对，一旦某个服务用的是旧账号，排查会绕很多弯路。
七、几处容易被模糊掉的边界
源码归属：定制开发通常约定交付源码，使用第三方系统可能只有使用权，两种情况的交接内容完全不同，需要按合同逐条对。维护期起算：从验收通过起算还是从正式上线起算，中间可能差几周，写清楚能避免后续争议。交接也不等于长期免费支持：操作培训一般有约定次数，超出部分按新需求另行安排。
这些条款不必在交接当天讨论，但应该在项目启动时写进合同，交接时只做核对。交接这件事的价值不在于走完流程，而在于一年后接手的人还能看懂、还能改、还能恢复。