I too often find myself in the technical weeds when talking about headless architectures and Sitecore Headless Services. Talking about things like GraphQL and Search, Proxy Architectures to support gradual migration, and about Rendering Host options and edge functions. What I don’t think I’ve done a great job is bringing the conversation up a level, and helping technical stakeholders justify their headless journeys to business and marketing stakeholders.

With that in mind, here are some common questions about headless and answers that are hopefully helpful in bridging the gap.

 

What is a headless CMS?

Most content management systems (CMS) offer a variety of tools for creating, organizing, and managing content. These systems typically include tools for modeling content, creating templates and components for displaying that content to users, and providing the web server infrastructure needed to deliver the completed pages to visitors. This approach is referred to as a “coupled” architecture because both the back end (content and data) and the front end (pages, templates, and components) are managed by the same system.

However, a headless CMS takes a different approach by separating the back end and the front end. Instead of providing templates and components for creating and displaying content, a headless CMS exposes APIs (Application Programming Interfaces) that allow developers to access and retrieve content from the back end. This means that the front end is decoupled from the CMS, and developers are free to use any technology they choose to build custom front-end experiences and deliver content to users. This approach is known as a “headless” architecture.

 

What are the benefits of a headless approach to content management?

There are several benefits to using a headless architecture for content management:

Greater flexibility: Since the front end is decoupled from the back end in a headless CMS, developers have greater flexibility in how they build and deliver content. This means that content can be delivered to users on a wide range of platforms and devices, and the user experience can be tailored to meet the specific needs of different audiences.

Better separation of concerns: With a traditional CMS, the back end and front end are closely tied together, which can make it difficult to make changes to one without affecting the other. In a headless architecture, the back end and front end are separate, which allows for better separation of concerns and makes it easier to make changes to one without affecting the other.

Improved scalability: A headless CMS can be more scalable than a traditional CMS because it is not limited by the performance of the front end. This makes it easier to handle large amounts of traffic and deliver content to users quickly and efficiently.

Easier integration with other systems: Since a headless CMS exposes APIs for accessing content, it can be easily integrated with other systems and applications. This allows for more seamless integration with other tools and platforms and enables developers to build more powerful and sophisticated content delivery experiences.

Improved performance: Because a headless CMS does not have to render templates and assemble pages on the server, it can often deliver content to users more quickly and efficiently. This can lead to improved performance and a better user experience. This can also lead to better Google Lighthouse score, lower Core Web Vital scores and better SEO rankings.

Improved security: Since a headless CMS does not have a front end, it is less vulnerable to certain types of attacks that target the front end. This can improve security and reduce the risk of data breaches or other security incidents.

Greater content reuse: With a headless CMS, content is stored in a structured and reusable format, which makes it easier to reuse and repurpose content across different channels and platforms. This can save time and effort and help organizations to get more value out of their content.

Better team efficiency: In a headless CMS, the back end and front end can be managed by separate teams, which can improve efficiency and allow each team to focus on their own areas of expertise. This can lead to more efficient and effective development processes and enable organizations to deliver better content experiences to their users.

 

How does Sitecore support a headless architecture?

Sitecore offers several APIs that can be used to support a headless architecture, but when most people discuss headless and Sitecore, they are typically referring to Sitecore Headless Services, formerly known as JavaScript Services (JSS).

Sitecore Headless Services provides two APIs that can be consumed to create websites: the layout service and the GraphQL service. The layout service is usually called for each page of your website and returns all the details of that page, including the template to use, the components to be placed on the page, and the placeholders they belong in. It also includes all the content that is bound to the page and the components on the page.

The layout service also supports “Editing Mode,” which provides additional data to enable your website to work with the Experience Editor (and Horizon/Sitecore Pages editing as well). This allows your content authors to edit your website, whose templates and components are not built in Sitecore, using a What You See Is What You Get (WYSIWYG) approach.

The other API, the GraphQL service, supports a query syntax that allows developers to search for content across items in the content tree. What makes GraphQL so powerful is that the standardized query language allows clients to specify exactly the data they need, and the server responds with only the requested data, rather than a fixed set of data as with a traditional REST API. Another benefit of GraphQL is that it allows for more efficient data fetching, as clients can make multiple queries in a single request, rather than having to make multiple round trips to the server. This can improve the performance and user experience of applications.

While these two services can be run from Sitecore’s content delivery (CD) servers, Sitecore also offers a service called “Experience Edge” which moves these services and your content and layout details to Sitecore’s content delivery network, optimizing their performance.

It’s important to note that when using Experience Edge, your CD servers are not involved at all when rendering pages, which helps with server utilization, but also means that you cannot leverage any of the XP marketing features like personalization and testing. These features can still be supported if you are running your headless services on your CD servers.

Another consideration is that Sitecore’s SaaS (Software as a Service) CMS, XM Cloud, does not have any CD servers and only supports headless architectures by allowing content and layout details to be published to Experience Edge. When using Experience Edge, content authors publish their content in the same way they used to publish it to the “web” database. Instead of updating a SQL database that your CD servers connect to, it updates the content stored in Sitecore’s content delivery network.

To actually build your website, you can use any technology you like to consume both the layout service and GraphQL endpoints. To make it easier to build, Sitecore provides several SDKs that provide a foundation for integrating these services into your website, handling tasks such as invoking the layout service when a specific page is requested and other foundational needs that most websites have.

Sitecore initially published SDKs for popular JavaScript User Interface libraries including Angular, Vue, and React. They later added an SDK for .Net Core and more recently added an SDK for Next.js, which is particularly noteworthy.

Next.js is a framework that is built on top of React and is designed to make it easy to build server-rendered or statically-exported React applications. It offers a range of features and tools to help developers build and deploy React-based applications, including server-side rendering, automatic code splitting, and built-in optimization.

Sitecore has been actively innovating with Next.js, building its headless Sitecore Experience Accelerator (SXA) on top of Next.js. Sitecore has also established a strategic partnership with Vercel, the creator and maintainer of Next.js, who also provides hosting services for Next.js applications.

Given the capabilities and support for this framework, we generally recommend Next.js for front-end applications consuming Sitecore’s headless services .

 

How does headless on Sitecore compare to other headless CMS platforms?

Sitecore is not the only CMS vendor promoting the benefits of a headless architecture. Other providers, such as Contentful, ContentStack, Bloomreach, and Sitecore’s own Content Hub One, offer headless CMS options as well. However, Sitecore’s approach to separating layout from content details and providing APIs for both delivery and editing set it apart from many other headless CMS options on the market.

In contrast to Sitecore, most other headless CMS platforms treat layout as just another type of content. This means that when designing a solution, you have to create content types for different types of pages, each with its own fields for sections and components that reference other content types that hold the actual content and data to be displayed. The front-end application you build must be able to understand this structure and assemble the right components to retrieve the necessary content and data to display the page. Making changes to these content types requires careful planning and testing to avoid breaking anything by removing or changing elements that the front-end application is expecting.

While most headless CMS platforms offer a form-based editing experience, they do not allow you to edit the content as it will be viewed by users. Some platforms may provide additional tools or frameworks to enable a WYSIWYG interface, but these are often just abstractions over the layout-as-content-type paradigm and may have limitations on flexibility as the front-end application needs to be built in a specific way to support their use.

Sitecore’s separation of content from layout, as well as its dynamic placeholder implementation, offer more flexibility than other headless platforms because they allow you to truly separate layout from content, making it easier to reuse that content for various purposes. This also gives content authors more control over how components are used to assemble a page.

Sitecore’s layout service and support for visual editing also distinguish it from its competitors. In Experience Editor mode, the layout service provides the necessary details to not only render and view the page, but also additional data that makes the fields of the content editable. The Experience Editor and Sitecore pages use this data to provide a robust content authoring experience. For authors already familiar with Sitecore’s authoring tools, there is no learning curve as the same tools work and behave in the same way as they did with the traditional Sitecore MVC implementation.

In addition to the benefits of its headless implementation, Sitecore also offers proven content management capabilities such as localization, versioning, workflow, PowerShell automation, a robust security model and many other proven features. While transitioning to a headless architecture may require a rebuild and the consideration of other platform options, you will not find a more capable platform and architecture than Sitecore.

 

When should I move to headless?

Headless architecture can bring many benefits to your organization, including increased flexibility, better performance, and easier integration with third-party systems. However, moving to headless also involves time, risk, and cost. To get started on your headless journey, it’s often best to tie it to another initiative. Here are some opportunities to make a business case for going headless:

New site build or redesign: If you’re building a new website or redesigning an existing one, headless architecture can provide a strong foundation. This is especially true if you’re creating a microsite, or if you need to access existing content through a new channel.

Alternative to a platform upgrade: If you’re considering upgrading your CMS platform, it may be worth considering whether you should instead migrate your solution to headless. Sitecore upgrades, for example, can be challenging due to deprecated code, changing architectures, and compatibility issues between versions. Instead of spending budget on a risky upgrade, you might consider setting up a new foundation for your headless journey.

Performance or SEO improvement initiative: If you’re working to improve performance and SEO, a headless architecture may offer significant benefits beyond what you could achieve with traditional CMS architecture. Instead of focusing on micro-optimizations and additional caching strategies, consider the potential of headless architecture.

New or major enhancements to existing features: If you’re introducing new features or making significant enhancements to existing ones, headless architecture may be a good choice. You don’t have to rebuild everything at once – it’s possible to migrate certain features or functionality to a headless architecture over time.

These are just a few examples of how to make a business case for moving to headless. Each organization’s needs and readiness are unique, so it’s important to carefully plan and prepare for your headless journey.

 

Do you need help with your headless journey? We’d love to help. Reach out to me on LinkedIn, Twitter or fill out our contact form.