Headless CMS 不是云端的 CMS
让我们从基础开始。Headless CMS 和传统 CMS 只有一个共同点 - 它们都用于管理内容。Headless CMS 不是传统 CMS 的改版；它不是新版本，也不是升级。它服务于不同的目的。
为什么目的不同？毕竟，我们仍在创建网站，不是吗？
没错。但网站真的是客户所需要的吗？如今 通辽电话号码数据 我们正大力投资 SEO、机器可读内容、生成式 AI、在线营销、外部商务平台、社交网络和其他渠道，以确保我们的内容能够满足客户的需求。有多少次 Google 无需您访问第三方网站就能给您答案？
Google 搜索直接在搜索页面上显示结果，无需访问第三方网站。
我们正在付出巨大努力，使我们的网站尽可能地机器可读。在构建网站时，我们实际上也在集成 Google、Facebook、Instagram、Amazon、Twitter、LinkedIn、ERP、PIM、DAM 等等。甚至在我们的客户决定探索移动应用、智能手表应用、语音助手、AI 等之前，我们所做的一切就已经完成了。
不同之处就在这里。Headless CMS 的设计初衷是为了帮助我们构建内容。我们需要在所有提到的渠道上提供这些内容。对于 Headless CMS 来说，正如我的朋友Mike Wills所说，内容为王。
另一方面，传统 CMS 旨在构建网站。它们通常为内容编辑者提供很大的自由，因为他们希望实现最佳的网站构建体验。
那么，对于您的客户来说，内容和网站哪个更重要？答案从来都不是简单的，而且很大程度上取决于客户的数字成熟度。但从一开始就选择错误的方法不可避免地会在未来造成巨大的（不仅仅是）技术债务。
为什么我们会让技术债务出现？
在本文的其余部分，我假设您的客户已准备好使用无头架构，并希望为其前端使用可组合方法。让我们列出导致技术债务增加的最常见方法：
低估内容建模
低估维护
低估微服务的开发速度
先用代码处理问题
坚持网站默认设置
我将更详细地解释每一个。
1. 低估内容建模
内容建模在 CMS 中并不新鲜，但当我们将内容置于一切的中心时，它确实变得至关重要。让我们从开发人员开始：
内容模型通常由开发人员创建和维护
当您注册无头 CMS 时，您需要创建的第一件事就是内容模型。通常由开发人员或其他技术人员执行此步骤。问题是——他们总是将自己的技术技能投射到内容模型中。我将举例说明。
Kontent.ai 自己的网站最初是由一位前端开发人员创建的，他希望为编辑器提供充分的灵活性，并不断为每个新页面创建新的内容类型。这种方法使他能够根据需要使每个页面的每个方面都动态化，但也造成了网站和 CMS 之间的紧密耦合。总是需要开发人员来创建新页面，而且内容没有结构化，因此不可重复使用，导致大量重复。对于习惯于传统 CMS 和结构的人来说，这是一种非常常见的架构。
紧密耦合的内容类型与其视觉表现形式（网站页面）的概述。
随着项目的发展，情况变得难以忍受，导致一半的登陆页面需要昂贵的改造。直到今天，我们仍然有一些内容类型-网站页面组合正在努力消除。
经验教训：内容模型应该反映现实生活中的对象，而不是页面。您是否在网站上列出活动？为活动建模，而不是为活动页面建模。
您的前端可能需要例外情况，或者您至少需要允许某些编辑撰写登录页面。在这些情况下，请为不包含数据但仅包含视觉元素的视觉组件创建特殊内容类型并链接结构化内容项。这样，您就不会失去内容之间的可重用性和一致性。
在一个频道（网站）上展示用于单一目的的视觉组件。
注意：在此屏幕截图中，标题纯粹是视觉元素。它仅供网站使用，不代表任何可重复使用的价值。另一方面，人是现实生活中的实体，必须可在多个渠道中重复使用。
另一个例子来自BlueModus 的技术副总裁Mike Wills，他的任务是为他的财富 500 强客户创建内容模型。作为一名开发人员，他希望保持每部分内容的可重复使用性，并将内容类型分解为对他的代码有意义的部分。他一直只测试小部件和组件，直到后来才发现复杂的结构导致了糟糕的编辑器体验。编辑必须为网站的每个页面、选项卡和其他小部分创建内容项。
不要让你的开发人员忘记，如果代码给用户带来了糟糕的体验，那么即使是最漂亮的代码也是毫无意义的。
麦克·威尔斯
BlueModus 技术副总裁
他的团队发现，实际上，很多内容都是单一用途的，坚持每次都可以重复使用所有内容是行不通的。对于他的客户公司来说，关键资产是作者，因此优先考虑的是让他们使用内容时感到舒适。
经验教训：优先考虑作者的可用性。我们开发人员喜欢优雅的代码，但事实是代码必须服务于项目的目的。不要为了简化代码而牺牲编辑者的体验。
注：Mike Wills 撰写的完整文章“保证完美内容模型的唯一方法”由内容营销协会在此处发布。
第一次就获得正确的内容模型几乎是不可能的
我们技术人员往往将内容模型视为数据库。我们自然会尝试第一次就正确建模，因为我们相信，一旦发生变更，我们引入得越晚，成本就越高。
事实并非如此。内容模型是一种活机制，初稿的好坏取决于客户解释业务问题的能力和你理解业务问题的能力。所以通常不会很好。而且别忘了，客户的要求总是会发生变化。
经验教训：尽量不要对内容模型的初稿想得太多。无论如何，您以后都需要对其进行调整。从小处着手，不断迭代构建，同时检查编辑器和开发人员的体验。如果可能，请使用允许您从代码 (CLI) 管理内容模型的工具。
每个项目的可重用性和编辑器体验之间的界限是不同的
之前，我提到，可组合架构只有在您的客户在数字方面足够成熟的情况下才会起作用。但并非所有客户都如此，因此无头 CMS 供应商正在尝试实现可视化网站编辑等功能，以保持与传统 CMS 类似的内容管理体验。但它们是有代价的——您必须调整内容模型以允许使用可视化和非结构化数据。
