📍 WDQWDWQD987AAAAA:216.73.216.23
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /a9927035cb9c.html
📄

关键词优化外包 - 维护范围怎样约定才不扯皮

维护范围要在合同里写成“可核对的动作清单”，而不是“负责排名维护”这类模糊承诺。具体做法是：把外包方在合作期内需要做的操作、频率、交付物、响应时限逐条列出，同时写明哪些事项属于额外计费、哪些现象不构成违约。判断标准很简单——出现争议时，双方能否只靠合同文本和后台记录确认对方是否履约。能确认，范围就算约定清楚；只能靠口头解释，就一定会扯皮。

先观察：维护范围模糊通常卡在三个地方

翻一遍现有合同或报价单，重点看这几处：

• 动作缺失：只写了“持续优化”，没写每月改几篇标题、发几篇内容、做不做内链。
• 口径不一：对方说“维护”指技术巡检，你理解成继续做新词，双方对同一个词的定义不同。
• 边界空白：网站改版、服务器迁移、被算法调整影响流量，这些算谁的活、要不要加钱，都没写。

把这三处标出来，就是后面要逐条补齐的位置。

再判断：哪些内容必须写进维护范围

维护范围可以按“固定动作 + 触发动作”两层来写。固定动作是周期性的，触发动作是有条件才发生的。

固定动作建议至少约定：

1. 已有页面的标题、描述、正文结构复查与微调频率，例如每季度覆盖一批。
2. 内容更新或新增的数量与节奏，例如每月几篇，是否包含选题、撰写、发布。
3. 站内链接、死链、失效页面的检查周期。
4. 数据报表的交付时间与指标口径，例如每月几号给一份含展现、点击、转化路径的报告。

触发动作要写清触发条件和责任方：

• 网站改版、换域名、换服务器时，谁负责迁移后的检查与提交。
• 页面被删除或下架时，由谁确认并做相应处理。
• 流量出现明显下滑时，外包方在多长时间内给出原因分析和处理建议。

这些动作写得越具体，后期越不容易被“这不在服务范围内”挡回来。适用条件是：项目已经上线、有稳定页面结构，维护重点是保持和微调，而不是从零搭建。

处理：把范围写成可验收的条款

把上面判断出的动作转成合同语言，每条都带上“动作 + 频率 + 交付物 + 验收方式”。例如：

每月对不少于 10 个已有页面完成标题与描述复查，输出一份变更记录表，含页面地址、修改前后内容、修改日期。

这样写的好处是：验收时不需要争论“有没有认真做”，直接看记录表即可。同时要单独写一段除外事项，明确以下情况不属于基础维护、需要另行报价：

• 网站整体重构、模板重做。
• 新增独立站或大批量新页面。
• 付费广告投放与账户操作。
• 因外部平台规则调整导致的流量变化，只提供分析，不承诺恢复原有水平。

这里要区分“可能原因”和“已经定位的原因”。流量下滑可能来自算法调整、竞争对手变化、技术故障或季节波动，合同里不宜写成“由外包方负责恢复”，而应写成“负责排查并给出结论，处理动作另行确认”。

复查：用三个检查项确认范围没有漏洞

条款定稿前，用下面三项过一遍：

1. 换人测试：假设明天换一个执行人员，只看合同能不能知道这个月该做什么。不能，就是动作写得太虚。
2. 争议测试：假设双方对“有没有维护”产生分歧，能否用后台记录或交付文档证明。不能，就是缺少交付物约定。
3. 加钱测试：假设出现改版、迁移、批量新增页面，合同能否直接判断是否额外计费。不能，就是除外事项没写全。

三项都通过，维护范围基本可用；任何一项不通过，回到对应段落补充具体动作或交付物。

下一步：拿现有合同或报价单，对照上面的固定动作和触发动作逐条打勾，把缺失项补成带频率和交付物的条款，再和对方确认除外事项与响应时限。