A headless CMS is a content management system that allows to manage content independently from the front-end, i.e. from the style and layout layer of the content. Taking a web page as an example, the content (text, pictures, ...) are separated (or decoupled) from the layout (the HTML).
The head is the layout, and the body is the content only. This allows a great flexibility at the head (front-end) level.
Unlike a classic CMS where all the content is put in the same package, headless CMS have an approach where the content is managed independently. By "content", we do not mean the layout of a web page (the "head" part), but the "pure" content and possibly for some headless CMS the references where this content will be displayed.
The first generation CMS, also called monolithic CMS, have an organization where the content is not decoupled from the front-end. Everything is stored in a database in which the content and the HTML that encompasses it are found. These files are edited via an administration console and displayed to the end user with a call to the database.
On the other hand, the headless CMS calls the content via an API, injects it into a page structure which is then rendered to the end user who visits the web page. Decoupling interfaces from content, offers many advantages :
use content with multiple interfaces with potentially different technologies (e.g. web and mobile)
standardize interfaces thanks to a repository or a library of visual blocks
facilitate layout or style updates
improve collaboration between content editors
have the freedom of the technology used in the front-end (for some CMS only)
facilitate technology migrations on the front-end, since the content can be called from a new front-end framework
allows a better scaling by hosting the content in cloud hosting services like Vercel or Netlify.
Having a CMS that dissociates the back-end from the front-end removes many vulnerabilities. Wordpress in particular receives a lot of criticism on the vulnerability criterion (partly because of the plugins).
Headless CMS are numerous, but there are important disparities on the functionalities, the compatible technologies and the user experience of content editors. Among the headless CMS that are very "technology agnostic" but not very rendering oriented, we can mention :
Other headless CMS have developed more the notion of immediate visual rendering, are not as flexible on the front-end technology used. We can quote :
Suncel.io (for Next.js)
Open source headless CMS require a larger infrastructure installation than a non-open source headless CMS. Among the most used open source headless CMS, we can list :
The Jamstack site offers a more extensive list of headless CMS, including open source headless CMS.
You have to separate the "front" part which calls the headless CMS via an API and the headless CMS service providing an interface to manage your content.
You have control over the front end and you can host it wherever you want. However, it is wise to choose a hosting that allows you to use all the features of your choice of technology. For example, if your front end uses Next.js, it would be wise to host it on Vercel.
In some cases, like with the Suncel headless CMS, the content management interface can be grafted to your front-end, which can be convenient to avoid multiplying interfaces.
Initially, Wordpress is not designed to be a headless CMS, but it is possible to divert its use for this purpose. The goal is to use Wordpress to manage its content but cutting the head, ie removing the possibility to manage interfaces.
This decoupling allows us to free ourselves from the use of PHP in favor of more modern and more efficient technologies. It also allows you to stop using themes or plugins that are frequently entry points for security vulnerabilities. To go further, you can access the documentation of the API of Wordpress.