线上推广公司，技术改动由谁负责
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /a2b8a2d91f59.html
📄
线上推广公司，技术改动由谁负责
结论先说：技术改动通常由线上推广公司提出需求并验收，由企业自己的技术或建站方执行；如果推广公司同时承接建站，则执行也归它。判断标准只有一条——改动落在谁的账号、服务器和代码库里，谁就承担执行责任，推广方承担效果责任。
先分清三类技术改动
不是所有改动都该找同一拨人。把需求按性质分类，责任自然清楚：
- 内容层：标题、描述、正文、内链、图片替换。这类改动在后台就能完成，通常由推广公司直接操作，不需要技术介入。
- 结构层：页面模板、导航层级、URL 规则、结构化数据、站点地图。这类改动会动到代码或建站系统，需要技术或建站方执行，推广方给出明确规格。
- 基础设施层：服务器响应、域名解析、HTTPS、CDN、抓取与索引设置。这类改动的权限一般在企业 IT 或主机服务商手里，推广方只能提出问题和验证结果。
如果企业把这三层都交给同一家线上推广公司，那执行责任就集中在它身上，但仍要在合同里写清哪些操作需要企业提供账号或服务器权限，否则会出现“答应了却做不了”的情况。
人手有限时，先安排什么
时间和人手都紧张时，不要按“重要性”排，按“谁卡住谁”排。下面这个顺序可以直接执行：
- 先列出所有待改项，每项标注它属于内容层、结构层还是基础设施层。
- 把基础设施层里影响抓取的问题排在最前，例如页面返回错误状态、重要页面被禁止抓取、域名解析异常。
- 结构层中影响全站的模板改动排第二，因为一次改动覆盖大量页面。
- 内容层可以并行推进，不占用技术排期。
判断依据是：一个改动影响的页面数量越多、越靠底层，越应该先做。反过来，只改一个页面的标题，即使效果明显，也不该占用技术资源排在前面。
用一份改动单把责任钉住
口头沟通最容易出现“我以为你会做”。给每个改动项写清四件事，责任就不会模糊：
- 改什么：具体到页面地址或模板文件，不写“优化一下结构”这种描述。
- 谁执行：写人名或岗位，不写部门。
- 验收信号：怎么算做完。例如页面源码里出现指定标签、指定地址返回正常状态、后台能看到新配置。
- 完成时间：给一个具体日期，不给“尽快”。
举个假设例子：某页面需要加入结构化数据。推广方在改动单里写明目标页面、需要输出的字段、验收方式是查看页面源码是否包含对应标签；执行方是建站技术。技术完成后，推广方核对源码，确认字段与内容一致，这一项才算关闭。如果只写“加上结构化数据”，双方对“加了没有”的判断标准可能完全不同。
验收时看什么信号
改动做完不等于生效。区分两件事：执行完成和效果出现。
执行完成的验收信号是可以当场核对的：页面源码、后台配置、服务器返回状态、账号权限变更记录。这些不依赖时间，做完就能查。
效果出现的信号需要等待，而且受抓取频率、页面数量、竞争情况影响，无法承诺固定时间。可以观察的是：目标页面是否被正常抓取、索引状态是否变化、相关查询的展现是否出现波动。这些是趋势判断，不是保证结果。
如果执行方说“已经改了”，但你查源码看不到变化，先排查缓存和发布流程，而不是直接判定对方没做。缓存未刷新、发布未生效、改在了测试环境，都会造成这种现象。确认原因之后再决定是否需要返工。
合同里值得写清的两句话
不需要长篇条款，但有两句能省掉大量扯皮：一是“涉及代码、服务器、域名解析的改动，由甲方指定执行人或由乙方在获得权限后执行”；二是“乙方负责提出改动规格并验收，甲方负责提供必要权限”。
这两句把“提需求”和“动手改”分开，也把权限依赖写在了明面上。人手有限时，最怕的不是改得慢，而是改到一半发现没有权限、没人认领。
下一步：把你手上待办的改动逐条标上内容层、结构层或基础设施层，再填上执行人和验收信号。填不出来的那一项，就是现在最该先确认的事。
