网站建完以后，每年还要交一笔维护费。
老板问：“这笔钱具体维护什么？”
回答通常很有安全感：“服务器、备份、安全、技术支持，都会管。”
听上去，网站已经住进了全天候托管中心。可真遇到表单收不到、页面打不开的时候，才发现“都会管”这三个字，解释空间比网站首页还大。
我的建议是：续费之前，把维护拆成能检查的交付。谁负责、检查什么、出了问题怎么处理，都应该说清楚。
这篇面向已经有B2B外贸网站、需要验收维护服务的老板。下面的八项是我建议的核对框架，具体范围和频率仍要双方约定。
先把“维护”这只口袋打开
上一篇聊PHP漏洞，我最后把问题落到了网站上线之后谁来维护。
这次往前走一步：老板不必亲自升级PHP，但需要知道，谁会识别影响、安排修复，并在修复后确认网站还能正常接收需求。
把维护费想成汽车保养费就容易理解了。收费可以按套餐，交付应该有项目：检查了什么，发现了什么，换了什么，哪些还没处理。
只收到一句“一切正常”，这笔费用就很难验收。
第一项：有人知道这个网站由什么组成
网站用了哪个主机、什么内容管理系统、哪些主题和插件？表单、邮件、多语言和数据统计又依赖谁？
这些信息可以整理成一份资产清单。老板不用背版本号，但应当知道维护方是否掌握它们，哪些服务需要续费，哪些存在依赖。
如果每次出问题，都要先从“你的网站是谁做的”问起，排查时间就先花在了考古上。
第二项：备份覆盖了真正需要恢复的东西
WordPress官方备份文档说明，典型站点的完整恢复需要数据库和文件两部分。
因此，验收时可以问：备份包含哪些内容、最近一次成功是什么时候、保留多久、由谁取得备份？
例如，只保存主题代码，未必包含产品资料、图片和数据库；只看见“自动备份已开启”，也还不知道最近一次是否成功。
备份频率应该结合更新频率与能接受的数据损失来约定。每天更新产品的网站，和半年才改一次介绍页的网站，需求可能不同。
第三项：恢复流程经过实际验证
我建议把“有备份”和“验证过恢复”分别记录。
验收可以要求一份恢复演练记录：使用哪个备份、在什么隔离环境操作、恢复了哪些功能、还有什么限制。
没有约定演练的套餐，不应假装已经交付过。可以把它作为下一次续费时补充的服务项目。
老板要知道的是：真出事以后，团队从哪里开始恢复业务。
第四项：更新有范围，也有验证
WordPress官方安全文档把保持软件更新列为安全维护的重要工作。[2]
但更新完成之后，还需要结合网站功能做检查。我建议更新记录至少说明涉及什么组件，以及检查了哪些关键页面和功能。
产品页是否正常、语言切换是否正常、询盘表单是否还能提交，这些比后台显示多少个绿色勾更接近业务。
具体更新频率、紧急漏洞处理方式和回退安排，应当写入服务约定。不能从“提供维护”四个字，推导出所有工作都包含在内。
第五项：询盘链路真的走通过
网站首页能打开，和客户能顺利联系你，是两项检查。
可以约定定期用测试信息走一遍：打开目标页面、提交表单、确认系统记录、检查邮件到达、确认负责人知道怎么接手。
测试记录需要标识为测试，避免混进真实询盘。表单提交成功也不等于邮件已经进入指定收件箱。
对于以海外询盘为目标的网站，这条链路值得单独列出来。门面再漂亮，门铃没接电，客人还是找不到人。
第六项：关键服务不会悄悄到期
域名、托管、证书、插件授权、表单或邮件服务，谁负责续费？通知会发到哪里？
老板可以要求一份续费与责任清单，不必收集一堆明文密码。需要的是企业能识别资产、管理权限，并在人员变化时接续工作。
我建议同时写清哪些费用已经包含，哪些由企业另付，避免到了续费日才开始猜套餐内容。
第七项：故障发生后找得到负责人
把“随时联系”改成具体约定：通过哪个渠道报障、什么情况下升级处理、多久响应、谁告知进展。
响应时间和恢复时间也要分别约定。收到消息，不代表已经修复。
如果服务只覆盖工作时间，就按实际范围写；需要紧急支持时，再谈对应的安排和费用。
第八项：每次维护留下可读的记录
记录不用写成毕业论文。老板需要看清楚：做了什么、发现什么、还欠什么、下一步由谁处理。
把遗留问题写出来，比每个月复制一句“运行良好”更有用。
这张清单，可以在续费前直接核对
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
这些项目不是统一定价依据。网站功能、责任范围、检查频率和支持要求不同，工作量也不同。
先把交付和责任说清楚，再讨论维护费是否合适。 这样即使更换服务方，也知道自己要接手什么。
你目前的网站维护里，最难确认的是这八项中的哪一项？ 欢迎留言或公众号私信入口说说你的情况，不需要提供网站密码或客户资料。
2026年了，我发现SEO最该优化的，居然不是关键词！
为什么我用的AI总是废话连篇？试试这几种方法让你的AI变强！