A headless CMS separates content management from the website or app that presents the content. It often provides an editorial interface and an API. “Headless” does not mean it has no graphical interface for editors.
Follow the content through the system
An editor writes a lesson in the CMS. A build process or application requests its title, body and media through an API. Your front end turns those fields into HTML. The content can serve several presentations without being tied to one theme.
Inspection exercise: draw that flow for a small article and identify where headings, links, alternative text and publication status are stored. Decide which step validates them.
Choose build time or request time deliberately
Fetching at build time can produce readable static HTML, but updates need another build. Fetching in the browser can show fresher content, but introduces loading, error, network and indexing considerations. Server rendering is another option. A headless CMS does not choose the right tradeoff for every page.
Keep the responsibilities visible
You still need accessible templates, media handling, preview rules, cache invalidation and protection for credentials. Do not expose a private management token in browser code. For a small reference site, source files and Jekyll may be simpler than an extra service.
Compare Jamstack and semantic HTML before choosing an architecture.
Sources
Reference 1 Reference 2 provide the technical details and current compatibility information.