WordPress源码交付清单包括哪些：交付物、权限与验收

为什么源码交付不是“给个压缩包”

很多合同里“源码交付”只有四个字。真到交付那天，企业拿到的往往是一组后台账号加一个压缩包，压缩包里到底是什么，要等到半年后第一次想改版、第一次想换服务商时才会知道。

先澄清一个最常见的误解：能登录 WordPress 后台，不等于拿到了源码。后台给你的是“使用”权限——发文章、换图片、装插件；但站点怎么部署、数据库什么结构、某个功能是哪个插件实现的、主题被谁改过，这些都不在后台里。等到要把站点迁到自己的服务器，或者找第二家服务商接手，对方第一句话一定是“代码在哪”，答不上来，项目就只能停在原地。

源码归属也不只是法律条款，它直接决定日常运营的自由度。展会前临时加一个产品页，大客户验厂要补一个认证下载区，旺季前想换掉一个拖慢速度的插件——这些都不该每次都开一次工单、等一轮排期。判断标准很朴素：不通知原开发商，你的团队能不能自己把这件事做完。

更现实的是边界问题。交付不完整时，部署算不算交付、环境搭不起来算谁的责任、上线后发现某个功能没做算不算增项，最后都会变成扯皮。把源码交付当成一项正式验收内容，逐项打勾、留记录，比事后讲道理有效得多。

源码交付清单：交付物到底有哪些

把“源码”拆开看，一个 WordPress 外贸站至少涉及四层东西，缺一层都不算完整。

内容资产要单独说一句：产品图原始文件、目录册 PDF、多语言文案，这些不在“代码”里，但换人重建时没有它们等于重做一遍。另外要区分两样东西——后台导出的 XML 是内容，不是源码；数据库导出的 SQL 才是站点结构和配置的载体，两样都要。

商业组件的授权必须单独确认。Elementor Pro、ACF Pro、WPML 这类插件买的是站点授权，交付时通常能转移的是“由谁持有这份授权”，不是版权本身。所以要写清楚：授权谁购买、续费谁负责、到期不续会怎样（一般是不能更新但站点仍可运行，风险落在安全补丁上）。这一条不写，第二年很容易出现“插件过期了没人管、被扫出漏洞才发现”。

还有两个技术细节最容易被跳过。一是子主题：如果定制改动直接改了父主题文件，主题一升级，改动全部丢失。二是自研区块与定制功能，只交编译后的产物，后续没人能改得动。这两点直接决定站点还能不能被二次开发，也是WordPress定制建站服务：从获客策划到上线交付在交付环节会明确写进清单的部分。

判断“可独立部署”有个简单测试：找一台与原服务商完全无关的服务器，只用手上的交付物和部署文档，把站点重装一遍。能跑起来，才叫交付完成；跑不起来，缺的那部分就是清单上的漏洞。

权限交接：域名、服务器、后台与第三方账号怎么给

域名要拆成两件事看：注册商账号在哪，DNS 解析托管在哪。国内建站最常见的情况是域名登记在服务商名下代持，客户只有使用权——这是风险最高的一种。合理做法是把域名过户到企业主体名下；短期做不到的，至少要拿到注册商账号的登录权、解析修改权和域名转移码，并确认域名到期时间与续费由谁负责。

服务器要看你拿到的是哪一层。云服务器账号（能登录控制台、能重装系统、能开快照）是一层，主机面板账号是另一层，只给一个 FTP 或宝塔面板又是另一层。只给面板不给云账号，等于服务器仍然不在你手上。WordPress 后台则要核对超级管理员是谁、有几个管理员、有没有残留的开发者账号、账号绑定的邮箱是不是你的企业邮箱。

第三方服务账号最容易被漏掉，也最容易在换人时出问题：GA4 与 Search Console、在线客服、表单与邮件发送服务、CDN、SSL 证书、CRM 或邮件营销工具。两个实操建议：GA4 让服务商把你的邮箱加为管理员，而不是把他们的账号交给你——历史数据在账号里，账号不要等于数据没了；Search Console 用“添加用户”把企业邮箱加进去，避免所有权验证卡在别人手上。表单插件、SMTP 这类带密钥的服务，还要确认密钥归属与计费账户。

交接完成后不要拖，24 小时内把该做的事做完：修改全部密码、开启两步验证、检查管理员列表、确认服务器与域名的账单绑定的是企业自己的支付方式。最后这条不是小事——服务器到期没续费导致站点直接下线，在外贸站里是频率很高的真实事故。安全设置的完整做法可以参考WordPress 安全加固：清单、配置项与被黑应急，交接当天的检查项可以直接对照。

部署与上线：从测试环境到正式环境怎么核

迁移不是把文件拷过去就完事。上线前先核对正式环境：PHP 版本、MySQL 版本、内存与上传限制、目录权限、定时任务是否正常触发。测试站跑得动、正式站跑不动，多数是版本和限制不一致造成的，这类问题在上线当天排查成本极高。

数据迁移要盯住三处：站点地址配置、媒体文件路径、以及旧域名在主题选项和数据库里的残留。直接用文本替换处理序列化数据会写坏配置，这一点在迁移时必须有意识地规避。同时确认旧站的 URL 有没有做 301 重定向，避免已经收录的页面直接变 404。

HTTPS 与基础访问是上线第一道关：证书是否有效、是否强制跳转、页面里有没有混合内容报警。然后是那个经典的翻车点——测试站为了防止被收录，通常在设置里勾了“阻止搜索引擎索引”，上线时忘了取消。所以上线后第一件事是看 robots.txt 和页面源码里的 robots 标签，再确认 sitemap 能正常访问。

对外贸站来说，询盘表单是唯一不能出错的环节。要实测：提交后能否收到邮件、收件人是谁、有没有进垃圾箱、失败时有没有提示。发信依赖 SMTP 和域名的 SPF、DKIM 记录，这三样缺一样，邮件就可能静默丢失。上线后一周建议每天自查一次表单，或者接一个第三方监测，因为表单挂掉几周无人发现是行业里的常见情况。

部署文档要写到“换人也能照做”的程度：环境要求、安装步骤、备份与恢复的具体命令或操作路径、更新 WordPress 核心与插件时的注意事项、出问题先看哪里。文档写得糙，等于前面所有交付都打了折扣。

验收标准与自检表：交付后怎么确认能用

验收不是看一眼首页觉得“挺好看”，而是拿清单逐项对。下面这张表可以直接拿去用，每一项都要有明确的通过标准。

功能之外还要验“可维护性”，方法很简单：找一个没参与项目的同事，只给他文档，让他完成三件事——改一段首页文案、新增一个产品、恢复一次备份。三件事都能独立完成，说明站点真的在你手上；有一件卡住，就回去补对应的文档或权限。

检查页面展示时不要只看桌面端。外贸站的询盘有很大比例来自手机，移动端的导航、表单、产品图加载要单独过一遍。基础 SEO 与 GEO 规范也属于验收范围：URL 是否简洁可读、每页是否有独立的标题与描述、结构化数据是否输出、内容是否以可被引用的段落组织——这些如果在建设期没做，上线后补的成本会高很多。

最后是记录。逐项打勾、遗留项单独列出并写明关闭时间、双方签字或用邮件确认。这份记录既是尾款依据，也是日后判断“这是 bug 还是新需求”的原始凭据。没有它，三个月后没人说得清当初约定了什么。

合同与售后边界：源码归属、增项与维护怎么约定

合同里最不该出现的写法是“提供源码”四个字。正确的做法是把交付物清单作为合同附件，逐项列明主题、插件、数据库、配置、文档、账号的范围，并写明源码归客户所有、客户及其指定的第三方有权修改和二次开发。归属和授权要分开写：代码归你，商业插件的授权归谁、续费谁负责，是另一件事。

增项要提前定义清楚，否则验收当天必然扯皮。通常分三类：交付范围内的缺陷修复，属于免费；原需求范围内的合理调整，看合同约定；超出原需求的新功能、新页面、新语言版本、新接口对接，属于增项。模糊地带集中在页面数量、语言版本数、内容录入量和“上线后再改一版设计”，这几项最好在合同里写死数量或计价方式。

售后要写三个数字和一条界线：响应时限、免费范围、收费范围，以及维护责任归谁。谁负责更新 WordPress 核心与插件、谁负责定期备份、备份保留多久、被攻击或误操作后谁能恢复，这些都要落到条款里。具体的分档方式可以参考WordPress 售后服务：响应时限、免费范围与收费边界，验收完成后是自主维护还是转入托管，也应当在这个阶段定下来，托管的分档与责任范围见WordPress 网站维护与托管服务：三档套餐与价格。

一个务实的判断：如果一家服务商不愿意把交付物清单写进合同附件，只肯口头承诺“源码都给你”，那这份承诺在验收时大概率会缩水。愿意写清楚的，反而是对自己的交付有底气的。

照着做：

1. 把本文第二部分的四层交付物表复制进合同附件，逐项确认范围。
2. 单独确认商业插件授权归属与续费责任，写进条款。
3. 交接当天改全部密码、开两步验证、清点管理员账号。
4. 找一台无关服务器，用交付物和文档做一次独立部署测试。
5. 上线后 24 小时内检查 robots、HTTPS、sitemap 与询盘表单收信。
6. 让未参与项目的同事按文档完成“改文案、加产品、恢复备份”三件事。
7. 验收清单打勾并留书面记录，遗留项写明关闭时间，再走尾款。

需要核对源码交付范围，可获取源码交付清单与上线验收自检表，或直接咨询你的项目情况。