先画内容工作流，再比较技术
同一个页面在三种架构里都能被做出来，差异主要发生在发布、权限、集成和维护。
先列出内容类型、数量、语言、更新频率、编辑人员、审批步骤和预览需求。再确认是否需要把同一内容分发到网站、应用、邮件或其他渠道，以及是否连接 CRM、PIM、搜索或内部系统。
技术选型会议应邀请实际编辑者和未来维护者。开发体验很重要，但如果发布流程与团队不匹配，网站会在交付后迅速变成新的维护负担。
- 谁能创建、编辑、审核和发布内容
- 哪些内容每天、每周、每月或几乎不更新
- 是否需要多语言、版本、定时发布与预览
- 是否有表单、搜索、会员、目录或第三方数据
- 故障、升级、备份和安全由谁负责
- 迁移时哪些 URL、媒体和历史内容必须保留
静态架构：把复杂度留在构建阶段
页面在部署前生成，适合内容相对稳定、重视速度、安全面和可预测托管的项目。
静态不等于手写每一页，也不等于无法更新。内容可以来自结构化文件、Markdown 或外部 CMS，构建完成后输出可直接分发的页面。访客访问时不必为每个页面请求数据库和模板渲染。
它的主要限制是更新通常需要触发构建和部署。编辑者若不适合直接维护内容文件，就需要增加友好的 CMS、预览和发布流程。搜索、表单、个性化或实时数据也可能依赖额外服务。
更适合
企业官网、品牌站、Landing Page、文档和更新节奏可控的内容网站。
需要警惕
大量非技术编辑、分钟级发布、复杂权限、实时个性化和高度动态数据。
维护重点
构建依赖、内容预览、部署权限、表单服务、重定向和定期版本升级。
Headless CMS：内容与呈现分开演进
当结构化内容需要多人管理、被多个前端使用，或前端体验需要高度定制时，它才真正体现价值。
Headless CMS 把内容模型、编辑和 API 与网站前端分开。它可以让同一组内容服务网站、应用或其他渠道，也能保留独立的前端设计与部署节奏。
分离也会增加系统边界：内容模型、预览、Webhook、缓存、权限、API 配额和故障处理都需要被设计。若只有少量稳定页面，额外平台可能带来比收益更大的长期成本。
更适合
多语言内容库、多个编辑角色、结构化目录、多个前端渠道或需要定制前端的团队。
需要警惕
内容模型未确定、团队无人负责 CMS、预算只覆盖首版页面而不覆盖长期平台维护。
维护重点
Schema 变更、API 版本、预览与发布、缓存失效、权限、备份和供应商迁移路径。
WordPress：成熟编辑生态，也需要持续治理
当现有编辑习惯、插件能力和内容历史有价值时，优化 WordPress 可能比迁移更合理。
WordPress 的优势在于成熟的内容编辑、主题与插件生态，以及许多团队已经掌握的工作方式。标准企业网站、内容站和常见营销需求可以在一套系统内完成。
风险通常来自缺少治理，而不是 WordPress 这个名称本身：插件重复、主题锁定、权限过宽、无人升级、备份不可恢复，以及把所有需求都交给插件。保留 WordPress 时，应同时明确插件白名单、更新、备份、安全和性能责任。
更适合
依赖后台可视化编辑、已有大量内容、团队熟悉流程，或确实需要成熟插件能力的项目。
需要警惕
无人维护更新、插件来源不清、页面构建器造成严重锁定，或托管和备份责任模糊。
维护重点
核心与插件更新、权限、备份恢复演练、缓存、媒体、数据库清理和安全监测。
用最小可维护方案做最终选择
不是选择功能最多的架构，而是选择能满足真实需求、且团队有能力长期运行的最小方案。
可以先给每项需求标记“现在必须、下一阶段、可能不会做”，再比较三种方案的实施和维护责任。若两个方案都能满足当前需求，优先选择依赖更少、团队更熟悉、退出路径更清楚的一个。
迁移旧站前先抓取 URL、盘点页面、媒体、表单、Metadata、内部链接与现有重定向。不要因为更换框架就删除仍有业务价值的内容或 URL。上线应包含重定向、表单、分析、索引和回退检查。
- 内容与 URL 清单已经导出并分类
- 新旧页面映射和 301 重定向已确认
- 编辑、预览、审核和发布流程有人实际试用
- 表单、搜索、媒体和第三方接口有失败处理
- 备份、权限、升级、监测和回退责任已指定
- 技术选择可以用业务和维护语言解释，而不只是一串框架名称
带走这四点。
- 01
静态、Headless 和 WordPress 都是工具，没有一种天然适合所有网站。
- 02
选择应由内容、编辑、集成、权限和维护责任共同决定。
- 03
Headless 带来灵活性，也增加 API、预览和平台治理成本。
- 04
迁移时先保护内容、URL 和业务流程，再讨论框架升级。