答案是把接口从“交付物”改成“可执行输入输出”:文档只作为说明,验收以对方能否按约定格式提交数据、我方能否按约定动作上线为准。若供应商只交文档,你仍可要求其提供结构化清单、字段映射和变更记录;接口设计的目标是让下一步实施不依赖口头解释。
把手里那份文档按用途拆成三类,分别决定接口形态。第一类是现状说明,例如站点结构、模板逻辑、已有关键词分布;第二类是操作指令,例如标题改写规则、内链插入位置、页面合并建议;第三类是验证依据,例如改前改后对照的页面清单、抓取日志字段、索引状态记录。只交文档通常意味着第一类齐全、第二类模糊、第三类缺失。此时不要急着让对方“再写详细点”,而是把第二、三类转成可提交的接口。
假设你拿到一份 PDF,里面写“建议优化栏目页标题,增加地域词”。这属于操作指令,但缺少可执行字段。你可将其转为一张 CSV,要求列名固定为:页面 URL、当前标题、建议标题、修改原因、优先级、期望上线日期。供应商只需填表,不需要登录后台。你收到表后自行或交第三方实施。这个动作的结果是:文档从阅读材料变成待办队列,下一步可以按优先级排期,而不是反复追问“具体改哪几页”。
双方接口可以拆成四个最小单元,每个单元都写明输入、输出和失败回退。以下清单不依赖具体公司或工具,只描述可核对的动作。
这套接口的关键是:供应商不实施,但仍要对“输入质量”负责。你拿到的是可执行输入,不是结论性文档。下一步实施者可以是内部编辑、建站人员或另一家服务方,接口不变。
以栏目页标题优化为例,文档写“标题应包含地域词和核心词”。这句话无法直接执行。转成字段后,供应商需为每个页面提交:页面 URL、当前标题、建议标题、目标词、标题长度、是否与现有页面重复、修改优先级。你收到后先做两项核对:建议标题是否与变更单一致,目标词是否与页面内容匹配。若匹配,进入实施;若不匹配,退回供应商补充依据。
这里有一个反直觉结果需要区分:有时供应商交来的文档很完整,但实施后流量没有变化。这不能单独证明文档无用,也不能单独证明实施错误。合理解释至少有三种:修改尚未被重新抓取;目标词本身搜索需求很低;页面改动未触及主要入口。要区分它们,可要求供应商在验证接口中提供修改前后同一批页面的抓取记录和索引状态记录。若抓取记录显示修改后页面未被重新访问,则下一步是等待或主动提交;若已被重新访问但索引状态未变,则需检查页面是否被其他规则覆盖;若索引正常而目标词无展现,则回到字段核对,确认目标词是否选错。这个判断动作直接影响下一步是继续等待、调整页面还是更换目标词。
假设你收到一份鞍山SEO服务供应商交来的文档,内含 40 个页面建议。你按上述接口要求其补交 CSV,字段为页面 URL、变更类型、修改前内容、修改后内容、验证方式。供应商补交后,你发现其中 12 个页面的“修改后内容”为空。此时不进入实施,退回补充。补充完成后,你按变更单逐条上线,并用同一份 CSV 核对上线结果。结果是:可执行条目从 28 条变为 40 条,下一步排期不再依赖文档阅读,而依赖变更单状态。
这个例子是假设的,数字只用于说明比较方法。实际使用时,字段数量和页面数量由你的站点规模决定。
若供应商只交文档且不愿补交结构化字段,你仍可自行从文档中提取字段,但需承担解释偏差。适用条件是:文档描述足够具体,且你方有实施能力。若文档本身模糊,则优先要求补充字段,而不是先实施再返工。另一种取舍是:把验证责任完全交给供应商,还是保留在自己手中。若你保留验证接口,供应商只需提交预期结果对照表;若你交给供应商验证,则需约定验证记录的可核对格式,否则无法区分“未生效”和“未实施”。两种选择都成立,区别在于你方是否具备核对能力。没有核对能力时,先建立最小核对清单,再谈实施排期。
最后,接口设计不承诺任何收录或排名结果。它只保证:文档中的建议被转成可执行条目,实施动作可追溯,验证依据可区分不同解释。做到这一点,供应商交不交实施就不再是阻塞点。