把接口设计成“文档交付包+可执行验收脚本”的分离结构,是继续合作的前提;如果供应商拒绝在文档之外提供任何可运行的最小动作,保留还是退出取决于你能否自行补齐权限和执行环节。缺少完整数据或权限时,仍可要求对方交付一份能在他方环境复现的配置说明和一组可验证的输入输出样例,但由此不能推出优化效果或排名会如何变化。
供应商只交文档不实施,通常有两种性质完全不同的原因。一种是权限或数据确实不在他手上,比如服务器、CMS后台、统计账号由你方掌握,他只能写建议;另一种是他有能力执行却把实施排除在合同范围外。前者属于接口问题,后者属于范围问题,处理方式不同。
判断依据可以看文档里是否包含三类内容:可复现的输入(例如某个URL、某条模板规则、某组关键词对应的页面类型)、可观察的中间结果(例如改动前后的页面结构差异、日志字段变化)、可回退的操作步骤。三者齐全,说明文档本身具备实施接口;缺中间结果,说明你拿到的是方向而不是方案。
假设一个场景:对方交付了“标题标签优化建议”文档,列出了若干页面应改的标题写法,但没给页面清单的获取方式,也没说明改完后用什么字段核对。此时你无法判断改动是否落地,也无法判断落地后是否被正确抓取。这不是效果问题,是接口没闭合。
如果选择保留,不要停留在“请补充实施”这种笼统要求上,而要把接口拆成可分配的动作。一个可用的接口表至少包含:动作、执行方、所需权限、交付物、验收方式。缺少数据或权限时,可以把动作降级为“可在他方环境执行的说明”,但验收方式不能省。
实际动作上,你可以先要求对方针对一个最小页面集合给出完整接口样例,包括改动位置和核对字段。拿到样例后,你方按文档执行一次,记录哪一步卡住。卡住的位置就是下一轮要谈的接口边界,而不是继续扩大文档篇幅。这个动作的结果会直接决定后续是补充权限、补充执行方,还是终止合作。
如果对方坚持只交文档,但文档质量尚可,可以把合作改写成“文档+远程指导+你方执行”的模式。适用前提是你方有能接触模板、服务器或CMS的人,并且愿意承担执行风险。这种模式下,供应商的交付物要从建议书变成操作单,每一步都注明预期结果和回退方式。
改写时要注意一个反常现象:文档越厚,不一定越可执行。大量泛泛而谈的优化条目会掩盖缺少输入输出定义的问题。你可以用一个小测试区分:随机挑文档中的三条建议,要求对方写出执行后第一个可观察的变化出现在哪里。如果三条都答不出具体字段或页面位置,说明文档不具备实施接口,改写合作方式的意义有限。
假设你方只有只读权限,无法改动模板。此时可执行的最小动作是:让供应商提供一份字段对照说明,你方用只读方式核对现状与文档描述是否一致。能核对上的部分可以进入下一步;核对不上的部分,不能仅凭文档断言现状有误,因为也可能是文档基于旧版本或假设环境写成。
退出适用于一种情况:你方缺少执行所需的数据或权限,而供应商既不愿提供可复现的最小动作,也不愿把实施纳入范围。此时继续持有文档不会自动产生可验收的结果,只会累积无法核对的建议。
但要注意,请求量、抓取量或某项统计归零,不能单独证明供应商处理错误,也不能单独证明退出正确。这些现象还可能有其他解释:统计代码未部署、抓取被robots规则限制、页面本身没有可索引内容、数据口径变化等。把统计变化直接归因于某一方,属于把相关当因果。
更稳妥的退出依据是接口层面的:你方按文档执行后,无法在约定字段上观察到任何可区分的变化,且对方无法解释差异来自权限、环境还是文档本身。到这一步,保留和改写都缺少继续推进的支点,退出才是合理选择。退出时保留文档和核对记录,用于后续供应商评估,而不是用于断言对方一定做错了什么。
在没有完整数据或权限的情况下,你仍然可以做几件不依赖实施权限的事,用来决定保留、改写还是退出:
这些动作的结论有明确边界:它们能告诉你文档是否具备实施接口,不能告诉你优化后会不会带来流量或排名变化。接口闭合是继续合作的条件,效果判断需要另外的验证周期和权限支持。把这两件事分开,才不会因为文档看起来完整就默认实施已经到位。