好的 B2B 网站改版 RFP 是决策文件，不是功能愿望清单。它应让供应商理解买家问题、约束、范围、所有权和验收证据，并让团队能比较方案，而不只是比较报价。

如果 RFP 只写“现代、快速、SEO 友好”，每家供应商都会用不同假设报价，范围、风险和交付物无法比较。先完成发现与内部对齐，再要求解决方案。

先写清楚买家问题

  • 哪些买家角色在什么阶段访问网站？
  • 他们需要理解、比较或验证什么？
  • 现有页面在哪一步失效，有什么证据？
  • 销售、营销、产品和技术团队各自需要什么？
  • 哪些内容、系统或合规约束不能改变？

GOV.UK 服务手册建议从用户需求开始，并用发现阶段理解问题而不是提前锁定方案。B2B 网站同样如此：供应商应看到已知证据、未知项与需要验证的假设。

区分结果、需求与方案

层级示例
结果技术买家能找到并验证实施方法
需求方法页具备明确归属、证据、更新机制和可测 CTA
方案某种 CMS、模板、组件或集成实现

除非技术选择已经确认且有约束理由，不要把方案写成结果。允许供应商解释替代方案、依赖、风险和验收方法。

建立可核验的范围清单

  • 域名、语言、地区、站点与环境
  • 页面类型、模板、组件、文章、案例和表单
  • 内容盘点、编辑、迁移、重定向和归档
  • CMS、权限、工作流、集成和数据来源
  • 设计系统、响应式状态和浏览器范围
  • SEO、Schema、分析、Cookie、隐私和无障碍要求
  • 培训、文档、支持、保修与移交
  • 明确排除项、客户依赖和第三方成本

把内容与搜索迁移列为独立工作流

迁移前应保存 URL、canonical、标题、描述、H1、状态码、内链、结构化数据、媒体、语言关系和性能基线；建立旧到新的逐 URL 映射，并为保留、更新、合并、重定向或下线写明理由。Google 的站点迁移指南强调 URL 映射、服务器端永久重定向、内部链接与 Sitemap 更新及迁移后监测。

要求供应商说明谁负责内容决定、谁实施重定向、如何避免重定向链、何时验证 canonical，以及上线后如何比较索引、搜索和业务信号。不能以“SEO 迁移包含在内”一句带过。

明确 CMS 所有权与运营权限

  • 客户拥有域名、托管、CMS 管理账号、分析和搜索平台账号。
  • 列出管理员、编辑、作者等角色及最小权限。
  • 说明插件、主题、字体、图片、代码和第三方许可归属。
  • 定义发布审批、回滚、备份、更新和安全责任。
  • 交付可编辑组件、源文件、文档和凭据移交清单。

WordPress 官方的角色与权限说明可作为起点，但项目仍需明确谁能做什么，以及离场后如何撤销访问。

让无障碍、性能与测量可测试

无障碍

写明目标标准与版本、页面和组件样本、自动与人工测试、键盘和辅助技术范围、问题严重级别、修复责任及验收证据。参考 W3C WCAG 与 WCAG-EM；不要把工具零报错当成合规证明。

性能

明确关键模板、设备/网络条件、实验室与真实用户数据、第三方脚本边界和验收时间。避免只写一个脱离条件的分数。

测量

定义事件名称、触发条件、参数、同意状态、调试方法、测试账号或排除规则、上线前后验证和数据负责人。表单成功页、邮件送达和 CRM 记录是不同验收层。

把交付物写成证据包

  • 批准的站点结构、页面清单和内容决定
  • 设计系统、组件状态与响应式规格
  • URL 映射、重定向、canonical 与 Sitemap 证据
  • CMS 角色、编辑指南和培训记录
  • 分析事件表与调试证据
  • 无障碍、性能、浏览器和设备测试记录
  • 上线清单、回滚方案、已知问题和责任人
  • 账号、许可、源文件与支持安排

让供应商方案可比较

  1. 对问题与目标的理解。
  2. 建议方法、阶段和关键决定。
  3. 团队角色、实际参与者和分工。
  4. 范围、排除项、客户依赖和假设。
  5. 时间、里程碑、变更控制和风险。
  6. 逐项成本、第三方费用和后续成本。
  7. 相关案例及其可核验边界。
  8. 每项要求的验收方式。

评分表应在发出 RFP 前确定，可包括问题理解、内容与迁移能力、技术方案、运营所有权、证据质量、团队、风险和总成本。不要在看到提案后改变标准来迎合偏好。

可直接复制的 RFP 结构

  • 组织、产品、受众与背景
  • 已知问题、证据与未知项
  • 目标、非目标与成功边界
  • 站点、内容、模板和系统范围
  • 用户与买家任务
  • 内容、SEO 和迁移要求
  • CMS、权限、集成和所有权
  • 设计、无障碍、性能和测量
  • 交付物与验收标准
  • 时间、预算、采购流程和提案格式
  • 评分标准、合同假设和支持

常见问题

RFP 应该指定 CMS 吗？

若已有经过验证的安全、运营、集成或采购约束，可以指定并解释原因；否则描述能力、所有权和验收要求，让供应商说明方案。

如何避免改版后 SEO 下滑？

无法保证不波动，但可以降低风险：保存基线、逐 URL 决策、服务器端重定向、内链和 Sitemap 更新、canonical 验证，以及上线后分层监测。

是否应要求无障碍“完全合规”？

应写清适用标准、测试范围、证据、修复和验收责任，并由合适的法律或无障碍专业人员确认要求；不要接受没有范围的保证。

来源与边界

本页依据 GOV.UK 关于用户需求和发现阶段的指导、Google 站点迁移文档、W3C WCAG/WCAG-EM 以及 WordPress 角色与权限文档。RFP 分层、证据包和比较框架是 CHCZ 的项目方法，不构成法律或合规意见。

如果你希望在发标前校准范围、迁移责任和验收证据，可以联系 CHCZ。