源码、域名与后台：昆山建站合同里要写清的交付项

验收会上对方演示完后台发文章的功能，说「网站已经交付了」。甲方问源码在哪、域名在谁的账号下、以后换服务商能不能把数据带走，会议室安静了几秒。合同正文写的是「完成网站开发并上线」，附件只有一页功能模块表，没提源码、数据库和账号归属。昆山网站建设这类纠纷，多半不是开发没做完，而是「交付」这两个字没拆开写。能拆成清单的东西，就别留成一句形容词。下面按六块列，每一块都给可以抄进附件的字段和判定口径。

本文要点

• 交付清单写到文件级：源码、依赖清单、数据库结构、设计源文件与部署文档各占一行
• 域名注册人写委托方企业全称，管理邮箱与转移码随交付一并移交
• 验收项带齐测试环境、工具与阈值三件套，否则「页面打开正常」无法判定

交付清单逐项列

网站建设合同交付清单的价值在于「写到文件级」。只写「提供网站一套」，验收时双方对「一套」的理解可以差出十样东西。建议按交付物、具体内容、格式、验收方式四列编表，逐行签收。源码这一行要写明是否包含前后端代码、构建脚本、依赖清单（package.json 或 composer.json）、README 与环境变量样例；node_modules 这类可还原的依赖目录通常不随包交付，靠依赖清单重装即可，这一点写清楚能省掉一次争论。

数据库单独一行，别混在源码里：结构 .sql、初始化数据、字符集与排序规则（常见是 utf8mb4）、一份可导入的备份文件。设计源文件（Figma、PSD、AI）、未压缩原图、字体授权文件、静态资源原片也要各占一行。域名与服务器相关的账号、SSL 证书与私钥、DNS 记录清单、第三方平台 Key（统计、地图、短信、支付、企业邮箱）容易被当成「附带的」，其实是交付里尤其该点收的部分。

遇到过的一类情况是：合同写「提供源代码」，交付时给了一个压缩后的前端静态包，后端代码与数据库结构都不在里面。后来把「后端源码 + 结构 SQL + 依赖清单」逐项列进附件，边界才说清。清单还有个附带好处——换服务商时，新团队照着这张表就能判断接手要补哪些东西，不用从头翻聊天记录。

所有权与账号归属

昆山网站建设里，交付不等于转让。按委托开发的一般规则，合同没有明确约定时，委托作品的著作权归受托人所有，所以「源码归属」要写成一句能执行的话：例如约定著作权及源代码财产权自款项结清之日起转让给委托方，或者明确写清授权范围、期限与是否允许二次开发。只把源码压缩包交过去，不等于权利跟着走；后续要改版、要交给另一家做，都会卡在这一句上。

第三方组件的许可证也要列。把用到的开源库与许可证（MIT、Apache-2.0、BSD 一般可商用，GPL 系列有传染性，需单独评估）做成一张表，注明哪些代码受对应条款约束。字体与图库的商用授权范围要分开写：网页嵌入、印刷物料、随站点再分发是三种不同的授权，图库图能不能用作产品主图也得看具体条目。文案与图片由哪一方提供、侵权责任由谁承担，同样写进这一段，别等收到投诉再分。

域名所有权是另一处高频争议。注册人（Registrant）一栏必须是委托方企业全称，管理邮箱用企业邮箱而非个人邮箱，注册商账号、到期日与转移码（Auth-Code）随交付移交，续费责任方单独写明。常见情形是域名挂在建站方账号下代持，平时看不出问题，等要换服务商或做备案主体变更时，每一步都得看对方配合。这一项在开工头一天就该定，比验收时再补容易得多。

数据归属与退出机制一并约定：业务数据、询盘记录、用户上传文件归委托方；合作终止时按 CSV 或 SQL 导出，写明导出范围与完成期限。ICP 备案主体须为委托方，接入信息、主体名称变更时双方的配合义务也在这里写清楚，避免站点因为备案信息不一致被要求整改。

后台权限与培训

后台账号不能只给一个。角色建议分四级：超级管理员、内容编辑、审核、只读；至少两个超管账号归甲方，双方各留一个便于排查，避免「谁离职谁把密码带走」。禁止多人共用一个账号，密码策略与二次验证（系统支持时）写成条款，登录日志与操作日志的保留期也写进去——出问题时能查到是哪次改动把栏目结构改坏了。

培训要写成可交付的东西，而不是「教会为止」。内容至少覆盖：发布与撤回文章、更换首页 Banner、上传产品与改参数、导出询盘记录、执行备份与恢复、查看统计入口。写清场次、每场时长、参与人数、是否提供录屏与操作手册，以及交接后一段答疑期（常见是 7 个工作日内）的工单渠道。培训结束让甲方人员当场独立完成一次「新增产品并发布」，比在演示里看一遍更能确认能不能接手。

下面这份培训交付物清单可以直接抄进附件：

• 角色与权限分级说明表，含每个账号的归属人
• 操作手册一份，覆盖发布、改图、备份、恢复、导出五类动作
• 培训录屏与签到记录
• 一次现场实操确认：甲方独立完成新增产品并发布
• 答疑期的工单渠道、响应时段与联系人

可量化的验收项

昆山网站建设合同里容易扯皮的一段是验收，因为多数条款写成「页面打开正常」「速度较快」，没有判定口径。可量化的写法是给每一项配齐三件套：测试环境、测试工具、判定阈值。缺任何一件，验收都只能靠感觉。比如性能项要写明在哪个机型、哪档网络条件下、用哪个工具测，得到的 LCP 与 CLS 作为验收阈值，而不是作为对外的效果承诺。

验收流程也要写：甲方在收到完整交付物后若干工作日内书面提出异议，逾期未提出且站点已上线运行的，约定视为验收通过；整改轮次、复验方式一并写明。没有这条，项目可能因为一句「再看看」长期悬着。备份恢复演练至少做一次并留记录——备份文件存在不等于能恢复，这一步比多写十条功能描述实在。

售后范围与响应约定

先把边界划开：缺陷修复与新增需求是两回事。页面报错、表单收不到信、移动端撑屏，属于前一类的处理范围；加一个栏目、换一套视觉、接一个新接口，通常按新增需求另立补充协议。内容录入、图片更换算不算日常维护、每月包含多少条，也要写数量而不是写「适量」。第三方平台政策变化导致的功能失效（比如地图 Key 规则调整、短信通道停用）由谁跟进，建议单独写一句。

分级响应比一句「及时响应」可执行：

免费维护期要写起算日，建议以验收签字日而非上线日计，并写明覆盖范围与到期后的计价方式（按工时或另立协议）。备份频率、保留份数、域名与证书续费由谁提醒、超出范围需求的报价流程、配合数据导出的义务，都归在这一段。所有沟通走带工单号的渠道，处理过程留痕，比在群里@一下清楚。响应时段与处理节奏是服务约定，不是对结果作出的承诺，措辞上按「约定动作」写，别写成效果承诺式表述。

常见争议点

把可能出现分歧的地方提前列出来，比事后各执一词省事：

• 「源码」是否包含构建环境、第三方库与部署脚本
• 设计源文件、切图原片、字体授权文件是否随包交付
• 域名、主机、证书续费由谁承担，到期前多久提醒
• 「长期维护」「后续都包了」这类口头表述如何界定范围与期限
• 备案主体变更、接入商更换时双方的配合义务与时限
• 服务器或证书到期导致站点下线，责任如何划分
• 后台只给一个超管账号，或账号归属未写明
• 内容录入、产品上传算不算交付范围内的工作
• 移动端适配、多语言版本是否另计费
• 甲方迟迟不签字验收，如何认定通过
• CDN、统计、短信等第三方账号归属与费用口径

常见情形是，口头说过「以后改内容都包了」，附件里没写，半年后双方对维护边界各执一词。把「每次内容录入不超过约定条数、超出按补充协议」写成一行字，比靠记忆稳。交付边界这件事，也可以对照 服务与解决方案 里的范围一起核；更多按栏目拆开的建站笔记在 行业动态栏目，需要有人帮忙把附件条款顺一遍，可以走 免费咨询。

小结

六块内容合起来，合同要写清的无非三件事：交什么、归谁、怎么算验收通过。明天就能做的一件事，是打开现有附件，把「源码」「域名」「后台账号」「部署文档」四行补进交付清单，每行后面跟一个可点收的验收动作；补完这四行，剩下的争议点会自己浮出来。昆山网站建设的项目里，交付边界写得细，双方反而少争执。本文为行业经验与技术分享，不构成效果承诺；具体交付范围、周期与资费以书面方案为准。