SEO项目交付怎么做？乙方撤场甲方接手不掉量实战

SEO乙方做完撤场后3-9个月甲方流量崩盘的情况很常见，根因不是甲方不专业，是交付时把"文档资产"交了却没把"判断能力"也搬过去。完整的SEO项目交付包应有5大模块（站点资产清单、SEO资产清单、工具账号清单、变更日志、决策框架文档）+ 30/60/90/180天分阶段陪伴节奏 + 知识资产显隐双层移交（显性文件vs隐性决策日志）+ 第一年禁动红线清单。本文给到SEO从业者、外贸运营、独立站主可直接套用的完整交付清单 + 后续维护合同决策框架 + 北美SaaS客户撤场后6个月流量翻倍真实复盘 + 三类不适合做完整交付的反例。

为什么SEO项目"交付完就走"是双输局面？

SEO项目结束的标准动作通常是：乙方写一份《项目总结报告》、附一堆Excel表、把账号密码发给甲方、开个30分钟的"交接会议"——然后双方各自散场。3-6个月后甲方往往会发现流量开始悄悄掉、询盘减少、某些核心词排名跌了，再回来问乙方"是不是哪里出了问题"——这时候乙方多半已经在做新项目，没精力回头看；甲方也没有能力自己诊断；流量继续衰减，最后双方互相埋怨：乙方说"项目交完不归我管了"、甲方说"你们做的东西根本不持久"。

这是SEO行业最常见的双输局面。从过去十几年帮甲乙双方做诊断、做项目复盘、做交付方案的经验看，多数翻车不是因为乙方做的工作有问题，是交付动作本身设计得太简陋——把SEO项目当成一次性的开发工程来交付（"代码写完就归你"），但SEO本质是持续运营资产，需要的不是"代码归属转移"而是"能力转移 + 决策转移 + 监控转移"。

乙方做完拿钱走人vs甲方接手懵了：交接断层的真实场景

真实场景比想象的更糟。乙方做了6个月SEO项目，期间做了200+ 个动作：改了30个页面title、新写12篇文章、建了8条对照对比页、配了4个GSC自定义维度、发了25条外链、调整了3次sitemap结构、把robots.txt改过2次、修了一次面包屑路径——每个动作背后都有当时的判断逻辑。甲方接手时只看到"做了什么"的清单，看不到"为什么这么做"的判断。3个月后甲方公司IT部说要换CDN，按常规流程换了——结果GSC立刻爆出5000条抓取错误，因为之前乙方做的sitemap路径与CDN的某个nginx重写规则有微妙耦合，换CDN时没人记得这个细节。等甲方意识到时，已经掉了30% 自然流量。

另一个典型场景：乙方做了一个精心设计的内链网络，把核心PLP集合页的入度优化到6-8条相关内链。甲方运营换了人后，新人觉得"页面底部相关推荐占地方"，把全站底部的相关链接删了——结果核心PLP集合页的内链入度从8降到2，3个月后核心词排名跌出前10。新人不知道之前内链是经过严格设计的，乙方也没在交付时留下"哪些内链千万不能动"的清单。

流量崩盘的常见3-9个月时间线

SEO项目交付后流量崩盘不是一次性发生的，是一个3-9个月的渐进过程。第30-60天：流量基本稳定，看起来没事，甲方信心满满；第60-120天：开始出现零星异常（某个核心词排名掉一两位、某个cluster流量轻微下滑），但因为整体数据还行，没人重视；第120-180天：异常变多，出现一两次"突发掉量"，甲方开始紧张，回头问乙方但乙方多半已无暇深查；第180-270天：累积异常导致整体流量出现明显跌幅（10-30%），到这一步基本来不及救——前面错过的修复窗口都过了，多数变化已经被Google算入"站点新基线"。

这种渐进过程恰恰是最难防的——前30天看一切正常，让甲方误以为"乙方做的工作很扎实"，等到流量真的崩了，原因已经混在过去3-6个月的各种改动里，分不清是哪一步出了问题。所以好的SEO交付，必须把"未来6-12个月里哪些动作可能引发崩盘"提前写清楚，而不是只交一份"过去做了什么"的总结。

交付不只是给个文档，是把"决策能力"也搬过去

SEO是判断密集型工作，每天的工作里80% 是判断（这个词值不值得做、这条外链质量够不够、这个内容要不要发、这个改动会不会引起波动），20% 是执行。乙方在项目期内积累了大量判断经验，但传统交付只交了"过去做了什么"，没把"以后遇到X该怎么判断"也交过去。结果甲方接手后遇到任何新情况——一次算法更新、一个竞品的新动作、自家产品要改个分类结构——都缺乏判断框架，要么不动（错过窗口）、要么乱动（捅出篓子）。

好的交付应该把"决策能力"也搬过去：包括决策框架文档（每类决定该按什么思路想）、决策日志（项目期内每个重要决定的"为什么"）、5类典型问题清单（"如果发生X你应该想到Y"）、应急响应剧本（"流量突然掉30% 第一周做什么"）。这些内容比静态的项目总结报告价值大10倍。

一个完整的SEO项目交付包到底应该装什么？

把交付包按5大模块拆开，每个模块都要有显式owner、显式更新责任、显式过期机制。

模块1：站点资产清单（域名 / SSL / CDN / 服务器 / CMS / 插件 / 账号密码）

这是最基础也最容易被忽视的部分。常见漏项：①域名注册商账号 + 续费日（很多甲方拿到的清单里没写续费日，结果几个月后域名到期没续过期掉）；②SSL证书签发机构 + 到期日 + 续期流程；③CDN/WAF后台账号 + 当前生效的规则集（包括cache key、purge token、edge rule）；④源站服务器SSH密钥 + 当前生效的nginx/apache配置 + cron任务清单；⑤CMS后台账号 + 已装插件清单 + 各插件的配置截图；⑥常用第三方插件账号（如Cloudflare、Calendly、Intercom、Mailchimp，如果与站点功能耦合）；⑦DNS配置（A/AAAA/MX/TXT/CNAME完整记录截图）。每项都要有"如果丢失怎么找回"的备选路径。

这部分应该用密码管理器共享空间交付（如1Password、Bitwarden的团队空间），不要发Excel或邮件——明文密码邮件交付是合规事故的常见来源。

模块2：SEO资产清单（关键词台账 / 内链网络图 / 内容资产分级 / 外链档案 / 竞品库）

这是SEO项目最核心的交付物：

①关键词台账：每个目标词的当前排名、3个月历史排名曲线、对应落地页、商业价值评分、竞争密度评分、优先级；②内链网络图：核心枢纽页（hub page）有哪些、每个枢纽页的入度与出度、关键内链关系不能动的清单；③内容资产分级：把站内所有内容按价值 × 当前表现分四象限（高价值高表现 / 高价值低表现 / 低价值高表现 / 低价值低表现），每象限对应不同的维护策略；④外链档案：所有已获取的外链（来源、获取方式、anchor text、获取时间、当前状态），尤其要标出"风险链"和"非续约就掉"的链；⑤竞品库：3-8个核心竞品的基本信息（域名、品牌、定位、流量量级、关键差异）+ 每个竞品的关键监测指标（DR趋势、新增页面频率、关键新发文）。

这部分用结构化数据库 + 可视化看板交付（如Notion数据库 + Looker / Airtable + 图表），不要用扁平Excel——交付半年后数据需要更新时，扁平Excel没人会去维护，结构化库可以批量更新。

模块3：工具账号清单（GSC / GA4 / Ahrefs / Semrush / Looker / 排名监测 / 邮件outreach工具）

所有项目期内用过的工具都要列入清单：①GSC：所有properties的所有权 + 用户权限分布 + 自定义维度配置 + 自动导出设置；②GA4：账号 + 属性 + 数据流 + 自定义事件 + 转化目标 + 受众；③Ahrefs / Semrush等订阅类工具：账号归属 + 当前订阅级别 + 续费日 + 项目期内积累的项目数据；④Looker Studio / Power BI看板：所有看板的URL + 数据源 + 权限；⑤排名监测工具：所有正在追踪的关键词 + 当前订阅成本 + 替代方案；⑥邮件outreach工具：模板库 + 联系人库 + 已发出的outreach历史。

这部分的关键是所有权转移——很多时候乙方在自己账号下做项目（图省事），交付时要么搬不出来要么搬过去后历史数据丢失。理想做法是项目启动时所有工具就开在甲方账号下，乙方只拿协作权限。

模块4：变更日志（项目期间所有改动的时间线 + 原因 + 效果）

这是甲方接手后最频繁查阅的部分。结构：日期 / 改动类型 / 改动详情 / 当时原因 / 预期效果 / 实际效果 / 后续影响。每条改动都应单独成行，包括：①URL改动（新增、删除、301）；②内容改动（新文、改写、合并、删除）；③技术改动（robots、sitemap、schema、CDN规则、nginx配置、JS渲染）；④外链改动（新增、disavow）；⑤工具配置改动（GSC维度、GA4事件）。

变更日志的价值在日后排查异常时倒推因果——半年后流量突然掉，第一件事就是查变更日志最近3个月做了什么动作。如果日志缺失，等于在迷雾里诊断。详细机制可看 SEO技术债务审计与数字资产化管理 那篇——把每个改动当成资产来管理而不是临时操作。

模块5：决策框架文档（为什么这么做vs为什么不这么做的判断逻辑）

这是交付包里最难写也最值钱的部分。结构按"决策类型"分章：①新文章决策（哪些主题该写哪些不该写）；②已有内容决策（哪些保留哪些合并哪些删）；③外链决策（哪些类型的链要做哪些不要、单链ROI怎么算）；④技术决策（什么情况下改sitemap、什么情况下改robots）；⑤工具决策（什么KPI用什么工具看、不同工具数据冲突时信谁）。

每章不只写"我们做了什么决定"，更要写"我们当时考虑了ABC三种方案、选A是因为X原因、B和C各自的劣势是Y和Z"。这样甲方未来遇到类似决策时，可以按同样的判断框架自己思考，而不是只能照抄乙方做过的事。

知识资产移交比文件移交难十倍：怎么把"判断能力"也交过去？

把文件交给甲方很容易，把判断能力交过去极难。后者要靠机制设计。

显性知识vs隐性知识：文件能记录的与文件无法记录的

显性知识=可以被写下来的（如"这个词的排名是8"、"这条外链是从X站拿的"）；隐性知识=只能在脑里的（如"这个词排名波动是正常的、不用紧张"、"X站的外链虽然权威但他们半年不更新页面，新内容很难拿到"）。显性知识用文档交付就行；隐性知识必须通过"陪伴 + 实操问答 + 共同决策"才能转移。

实操上：交付前最后4周，把甲方接手负责人拉进项目所有重要会议（即便他暂时只听不发言），让他听到原因、看到讨论、感受决策的犹豫与判断；交付后30天内，遇到任何SEO决策都让甲方先说"如果是你你会怎么想"，乙方再补充自己的判断——这种"先让接手者表态、再补充"的方式比单向讲解效果好3-5倍。

决策日志：每个重要决定的"为什么"

决策日志不是流水账，是结构化的决策档案。每条决策包括：①决策时间；②决策事项；③候选方案ABC；④最终选择；⑤当时考虑的关键因素；⑥放弃其他方案的核心原因；⑦预期效果；⑧后期验证（这个决定回头看是对是错）。一份6个月项目的决策日志通常有20-50条核心决策——这些决策构成乙方的核心IP输出，把它结构化交给甲方等于把判断框架打包给对方。

真实做法：决策日志要在决策当下就写、不要等项目末尾回忆补——回忆补的日志不完整、不准确、缺乏当时的犹豫感（而那种"犹豫感"恰恰是判断能力的关键）。

5类问题清单：交付前必须帮甲方想清楚

交付前要主动列出"未来12个月里你最可能遇到的5类典型问题 + 各自的应对思路"。例如：①核心更新即将到来怎么办；②竞品突然推出新策略怎么应对；③公司IT要换CDN / 重构站点结构怎么沟通；④流量突然异常（涨或跌）第一周做什么；⑤年度预算评审怎么向老板讲清楚SEO价值（可看 SEO预算编制与ROI测算模型）。每类给一个"标准应对剧本 + 关键判断点 + 紧急escalation路径"。

30/60/90/180天交付节奏怎么排？

不要"交完就走"。按时间窗设计陪伴节奏，渐进降低乙方介入度。

前30天：高频陪伴 + 实时答疑 + KPI一起看

第一个月是接手者建立心理安全感的关键期。乙方应做到：①每周1-2次30-60分钟会议（共同看KPI、共同审视新出现的异常）；②实时答疑渠道（Slack / 微信群，承诺24小时内回应）；③共同执行1-2个SEO动作（让接手者真的动手，乙方陪着看）；④每周一份"上周观察 + 这周建议"小报告。

这阶段的目标不是教知识，是让接手者建立"我能handle这个站"的内心信念。一旦这个信念建立起来，后续陪伴可以快速降级。

31-60天：低频陪伴 + 异常报警 + 双向决策

第二个月降到每两周1次会议，但保留异常报警机制——一旦核心指标偏离预设阈值（如自然流量周环比 ＞±15%、核心词排名跌 ＞5位、GSC抓取错误激增），乙方主动ping接手者一起诊断。重要决策仍走"接手者先表态、乙方补充"的双向流程。

61-90天：观察期 + 月度审计 + 流量稳定性

第三个月降到每月1次会议，主要任务是月度审计（流量、排名、抓取、转化、外链五维度）+ 流量稳定性确认。这阶段乙方更多是"被动咨询"——接手者提问、乙方回答，不主动提建议。

91-180天：脱离期 + 季度复盘 + 关键变更不再陪

第四到第六个月只在季度复盘时碰一次（90分钟深度会议），其他时间不主动介入。如果接手者在这阶段还频繁来问基础问题，说明交付质量不够，要回头补强决策框架文档与典型问题清单——这是预警信号不是常态。

退出回访：6个月后 + 12个月后

项目交付半年和一年后各做一次60分钟回访：①看流量长期趋势；②看接手者独立处理新情况的质量；③看哪些交付物被用上了、哪些没用上（没用上的下次精简）；④收集"如果时间倒回来你希望乙方多做什么"的反馈。这两次回访对乙方建立长期口碑极重要——多数B2B SaaS客户的二次合作机会都是从这种主动回访来的。

流量稳定性保障：哪些是必须由乙方在最后一个月稳住的？

交付前最后30天，乙方有5类工作必须确认稳定，不能留给甲方接手第一个月再发现问题。

监控告警：流量异常的早期识别

项目交付前必须搭好两层监控：①日级监控（GA4 + GSC关键指标日报，含周环比同比）；②阈值告警（核心指标偏离时自动邮件 / Slack通知，阈值如周环比 ＞±15%、核心词排名跌 ＞5位、GSC抓取错误激增 ＞50%）。告警要直接发到接手者邮箱 + Slack，不要走乙方中转。

告警频率要平衡——太敏感会让接手者疲劳（"狼来了"），太迟钝会错过修复窗口。实操经验：从GA4 / GSC历史90天数据算出"正常波动带"，告警阈值设在1.5-2倍正常波动以上。

索引健康度：sitemap提交、抓取错误、覆盖率

交付前最后30天要把索引健康度跑稳：①sitemap全部成功提交、lastmod都是合理日期；②GSC抓取错误清零或者每个错误都有书面解释；③索引覆盖率（已索引 / 总页数）在合理区间（通常60-90% 是健康范围，过高过低都要解释）；④robots.txt与noindex配置最后一次复核没有意外阻挡。

内链网络：交接后被破坏的常见场景

内链网络是最容易被无意破坏的资产。交付前必须：①画一张"核心枢纽页内链入度图"放进交付包，标出每个枢纽页关键内链不能动的清单；②在CMS后台对应位置加显式注释"此链由SEO项目维护、改动前请联系SEO负责人"；③把"内链改动"列入交付后90天的禁动清单。

外链管理：哪些链是长期资产，哪些会自然衰减

外链档案里要明确分类：①长期资产链（如权威媒体编辑链、政府 .gov、教育 .edu，这些链不会随时间衰减）；②有续约/维护需求的链（如付费目录、合作链，每年要续）；③自然衰减链（如新闻类链，发布后6-12个月会因为页面老化而权重衰减）；④风险链（PBN、低质目录、付费灰链，长期可能被SpamBrain标记）。每类对应不同处置策略。

内容更新：modified节奏与团队接续

内容资产的modified节奏（哪些页面多久应该更新一次）要写进交付包。交付前最后30天，把所有"超过12个月没更新的核心页"再过一遍小更新（不是全文重写，是事实校验 + 数据更新 + 链接复检），让接手者拿到的是一个"刚刚整体过完一遍"的健康站。

甲方接手后怎么自己稳住第一年？

甲方视角：接手后的第一年怎么不掉链子。

接手三件事：先读决策日志、再看变更台账、最后跑全站审计

接手第一周不要做任何动作。先做三件事：①把乙方留下的决策日志通读一遍（多数50-200页，需要8-15小时认真读完）；②把变更台账过一遍（按时间倒序读最近6个月的所有改动）；③用一个独立工具（不一定是乙方用过的）跑一次全站SEO审计，对比乙方留下的最近一次审计结果——找差异点（"这一项乙方那边显示绿，我这边显示黄，原因是什么"）。这三件事做完后再开始任何主动动作。

别动的红线：90天内禁止改URL / 重构信息架构 / 换CMS / 批量改meta

接手前90天禁动清单：①任何URL改动（含301、删除、合并）；②信息架构重构（导航、面包屑、URL结构）；③CMS升级或更换；④批量修改title / meta description（单页修改可以、批量必停）；⑤批量改sitemap结构；⑥CDN / WAF大规模规则改动。这些动作每一个都可能触发流量地震，新接手者还没建立判断能力时绝不能动。

该动的优化：选哪三类工作小步快跑积累自信

那接手后做什么？做三类风险低收益高的工作积累自信：①写新内容（按乙方留下的"内容缺口清单"补1-2篇）；②做单页优化（选1个表现一般但有提升空间的页面，按乙方留下的"诊断模板"诊断 + 优化）；③做关键词追踪（按乙方留下的台账每周更新排名、看趋势）。这三类工作做4-8周后，接手者会逐步形成自己的判断节奏。

后续维护合同vs一次性交付：哪种适合哪种甲方？

不是所有甲方都该签后续维护合同，看类型决定。

一次性交付的真实成本（隐性成本占30-60%）

一次性交付看起来便宜，但隐性成本极高：①甲方接手后多数会在6-18个月内出现10-30% 流量回落（折算成营收损失通常远超维护合同费用）；②内部需要至少0.5-1个全职SEO人力顶替乙方原本的工作（人力成本一年15-50万人民币）；③遇到突发状况（核心更新、流量地震）甲方独自应对，决策质量低；④长期与原乙方关系断绝、损失续约 / 推荐机会。把这些隐性成本算上，一次性交付的真实成本通常是合同费用的1.5-2倍。

月度维护合同的合理定价模型

月度维护合同的合理定价不是按工时算（工时模型激励乙方"拖工作"），而是按价值算：①基础维护包（监控、月报、答疑、应急响应）= 月费X；②季度审计包（季度全站审计 + 修复建议）= 季费Y；③专项工作包（按需启动的额外工作如新一轮外链投放、新主题内容生产）= 项目报价。基础包 + 季度包是固定retainer，专项包是灵活叠加。

按结果付费vs按工时付费vs按月固定费

三种付费模式各有适用：①按结果付费（流量提升X% 抽成）—— 仅适合极少数甲方目标清晰、衡量口径透明、双方信任度高的场景；②按工时付费—— 适合短期咨询、紧急修复，长期合同不推荐（激励反向）；③按月固定费—— 最常见也最稳定，适合大多数中长期合作。详细决策可看 SEO公司怎么选不踩坑？8步外包代理评估实战 那篇。

真实案例：北美SaaS客户从乙方撤场后6个月流量翻倍的复盘

2023年带的一个北美B2B SaaS客户项目，从交付到甲方接手后6个月的完整过程。

交付前4周的知识打包做了什么

项目本身做了8个月，从0流量到月8000自然流量。交付前4周专门安排了"知识打包"：①周1：完成所有5大模块清单（站点资产、SEO资产、工具账号、变更日志、决策框架），合计180页文档 + 12个数据库表；②周2：与接手者每天60分钟"边做边讲"——把日常SEO工作（看GSC、监测排名、写内容、做外链outreach）从头到尾陪做一遍；③周3：模拟"3类典型异常处理"演练——人为制造异常场景（如假装"GSC显示昨天突然1000个新抓取错误"），让接手者按决策框架走一遍诊断流程；④周4：合同正式结束前最后一周，把所有账号所有权完全转移、做最后一次全站审计基线、签字交付。

30/60/90天陪伴期遇到的3类问题

陪伴期不是没有问题，是有问题但都被及时接住。第1类（第35天）：客户IT部要换CDN提供商（从Cloudflare换到AWS CloudFront），接手者按交付包里的"CDN切换checklist"逐项核对，发现要修改5处nginx重写规则，与乙方一起复核后顺利切换无掉量。第2类（第58天）：Google跑了一次未官宣的核心更新，客户站排名波动 ±3位，接手者按决策日志里"核心更新发生时的标准应对剧本"先观察14天不动手，14天后排名回稳，证明这次波动是正常重评不是中招。第3类（第76天）：竞品突然上线一组对比页，接手者用乙方留下的"竞品监测看板"看到、与乙方讨论后决定"按计划上自己的2篇对比页"而不是慌乱跟随竞品全套——3个月后自己的对比页流量超过竞品。

甲方接手后6个月做对的事 + 做错的事

做对的事：①严守90天禁动红线，期间不做任何URL / 信息架构改动；②按modified节奏老老实实更新核心内容（每月4-6篇新文 + 8-12篇旧文更新）；③在第4个月主动启动一轮外链outreach（按交付包里的"outreach模板库 + 联系人库"），3个月内拿到18条新链；④坚持每周一次决策日志（自己也开始写新决策档案）。

做错的事：①在第5个月经不住销售压力，临时大改了一个核心PLP页面的title和H1，结果该页排名跌4位，3周后才意识到回滚；②没有及时复盘第2类问题（核心更新），错过了在更新后做"哪些页面意外受益、应该乘胜追击"的优化窗口；③在第6个月把月度维护合同先暂停（"想自己再试试")，结果第7-8个月遇到一次更复杂的算法波动时缺乏外部参谋，独自处理多花了2周。

6个月后数据：月自然流量从8000涨到17500（+118%），月询盘从22条涨到51条（+131%），核心词集合排名平均提升4.8位。其中乙方贡献占比估算60%（含交付包里的资产 + 陪伴期决策支持）、甲方独立贡献40%。这个比例说明一件事：好的交付不是"全部交完"，是让甲方在前期建立40% 自有贡献的能力。

不适合做完整交付流程的3类项目

不是所有项目都要按5模块 + 4阶段陪伴的标准流程交付。三类项目不适合。

项目周期 ＜3个月的短期咨询

3个月以下的短期咨询（如"做一次全站审计 + 给修复建议"），不涉及长期SEO资产积累，做完整交付包反而是过度交付——把审计报告 + 修复roadmap + 工具账号3件套交清楚就够。但要在结尾给客户一份"如果未来要做长期SEO这5件事先做"的简短指南，作为咨询的延伸价值。

单一窄需求（如修个hreflang bug）

窄需求项目（如"修hreflang"、"加一组Schema"、"做一次Core Web Vitals优化"）只涉及单一技术动作，做完代码改动 + 验证 + 简短文档说明就够。完整交付包对这类项目是浪费。

甲方根本不打算继续做SEO（只是为了报告）

少数甲方做SEO不是因为真要做SEO，是为了拿一份"我做了SEO"的报告去应对老板、投资人、合规审计。这类项目交付时要明确"这不是要持续运营的资产"，简化所有不必要的交付动作，重点把"报告deliverable"做得专业即可。但要在合同里说清楚——后续这个站任何问题都不再回溯到本次项目。

常见问题解答

SEO项目交付包应该准备多少时间？

合理预算是项目总时长的8-15%。6个月项目至少留3-4周做交付打包；12个月项目留6-8周。低于这个比例的交付包多半草率、半年后甲方就要回头问问题；高于这个比例可能在浪费乙方时间，应该简化文档结构。

所有交付文档加起来通常多少页？

中等规模SEO项目（6-12个月、月流量万级）的交付包通常150-300页文档 + 8-15个结构化数据库表。再小的项目可能50-100页；超大型企业项目500-1000页都有。重点不是页数，是结构化与可查询性——300页能快速查到任何信息比50页搜索一遍都找不到强。

陪伴期的额外工作如何收费？

主流做法：项目合同里包含交付后30-60天免费陪伴期；超出部分按月度维护合同或按工时收费。免费陪伴是项目交付质量的延伸不是赠送——能减少交付后纠纷、提高续约率，乙方应主动提供。但要明确陪伴期的内容范围（答疑 + 决策支持 + 异常诊断），不包括新的SEO动作执行。

甲方接手前要不要先招一个SEO人？

强烈建议要。最理想是接手前2-3个月就招到位，让新人在乙方交付的最后阶段参与到决策与执行中，建立感性认知。临交付前才招的话，新人完全没参与过项目历史，接手后大概率懵——交付质量再高也救不回来。如果没法招SEO人，至少要有一个内部产品经理或运营负责人长期对接（不能是IT、HR）。

哪些情况要拒绝交付？

三种情况乙方应该拒绝按"完整交付"结束项目：①甲方明确表示不打算继续维护SEO（资产会被荒废，乙方花时间做完整交付包也浪费）；②项目期间核心数据访问权被甲方收回（无法做完整审计）；③合作过程中信任关系破裂（交付后纠纷概率极高）。这三种情况下宁可做简化交付 + 终止合同，不要硬做完整交付积累隐患。

已发布的内容资产甲方接手后能改吗？

能改但要按规则。已发布内容的modified节奏是SEO资产的核心维护动作之一，甲方接手后应该继续按节奏更新。但要遵守：①不改URL / slug / created时间；②正文实质性改动（不是只刷新modified）；③改动后清缓存 + 抽检线上；④把改动记入变更台账。详细机制可看 老博客内容更新 / 合并 / 删除SEO SOP 那篇——内容更新本身是有方法论的，不是随手改。

乙方交付后甲方流量崩盘，责任在谁？

看时间窗与崩盘原因。①交付后0-90天因为乙方留下的某个工程性问题（如代码bug、未配置好的告警、未交付的关键资产）导致的崩盘——乙方应承担主要责任，免费修复；②交付后90天以上的崩盘多数是甲方独立操作引发或外部因素（算法、竞品、行业），乙方没有主要责任但可以付费支援；③明确属于甲方违反交付包里"禁动红线"的操作引发的崩盘——甲方自负。合同里这些边界要写清楚，避免事后扯皮。