Sitecore Presentation Details Explained: Legacy vs Headless

If you have been using Sitecore for some time now, then you are surely aware of what Presentation Details is. However, due to the changes brought about by new trends, such as the move towards the cloud environment like XM Cloud, things have changed quite significantly.

Let's break it down without the jargon overload.

So, What Are Presentation Details Anyway?

Presentation Details is the concept used by Sitecore to determine what will be shown on a particular web page.

This can be likened to the manual that shows how a specific page should be built. In other words, this describes how elements such as components and data should be placed to form a particular page.

The Legacy Approach: MVC & Sitecore Layout Engine

In the traditional MVC approach (Sitecore 8.x to 10.x), Presentation Details are found right there on the item itself within the content tree.

How it all went down:

• Layout - Master template for the page (e.g., _Layout.cshtml)
• Renderings - The renderings themselves, dropped into designated places
• Data Sources - The content that powers the renderings
• Parameters - Customizations to the renderings themselves (CSS classes, visibility, etc.)

Each item had its own configuration. You could modify this on a per-item basis using the Experience Editor or through the basic "Presentation Details" interface.

Your rendering engine was completely integrated with the CMS. Your client-side and server-side code worked together in one package. Convenient, but bulky.

Shared vs Final Layout: A Common Confusion

This is where most developers are at a loss.

Sitecore offered two levels for layouts:

• Shared Layout: This would be applied to all versions and languages of an item
• Final Layout: This kept track of deltas, that is, only those differences between the shared layout and its modified version

If the editor personalised the layout or created a new version of the page layout, then it would go into the final layout layer.

Enter Headless: How XM Cloud Changes the Game

In XM Cloud, everything is turned upside down. It's no longer the CMS that renders your pages on the server side; rather, it acts as the content repository for structured data delivery through APIs.

All the rendering is done at the frontend (using Next.js together with Sitecore JSS SDK). That is the headless, or composable, model.

Then what about presentation elements in such a scenario?

• Firstly, Layout Service substitutes the usual rendering pipeline, outputting the JSON of the page layout.
• The definition of components remains in Sitecore, although they are rendered on the client side.
• Data sources and parameters also remain available; however, the decision regarding the visual representation is now made by the front-end application.
• Finally, Experience Editor is replaced by Pages, the new (What You See Is What You Get) WYSIWYG editor tailored for headless scenarios.

Key Differences at a Glance

Here's a brief comparison for clarity:

Legacy (MVC/SXA):

• Server-side rendering
• Close coupling between presentation and CMS items
• Use of Experience Editor for content authoring
• Delta model for shared/final layout
• Closely coupled front-end

XM Cloud (Headless/JSS):

• Client-side rendering / SSR/SSG
• JSON returned by Layout Service for front-end
• Visual authoring with Sitecore Pages
• Component definition managed by Sitecore
• Decoupled front-end stack

What Stays the Same

Even with the change in architecture, some basics remain:

• Placeholders determine where components can be placed
• Data Source items continue to supply data for rendering
• Rendering parameters can still be configured on a component basis
• The structure of the content tree is the same

The intent of the authoring process remains unchanged, with editors creating pages by placing components. The underlying technology has

Which One Should You Be Thinking About?

If you are involved in a greenfield project or moving towards cloud-native systems, the XM Cloud headless architecture is what Sitecore recommends. The decoupling architecture is going to make your system run faster and scale better.

In case your application relies on an existing implementation of the MVC architecture, understanding the legacy architecture is very important, especially for fixing problems related to customization and language support.

Wrapping Up

The presentation information, regardless of whether it’s in the traditional form or using the Layout Service, forms the foundation for making Sitecore pages functional.

Knowing both forms of presentations will mean that you’ll be more capable while making choices regarding page design, page movement, and problem-solving on the page. This concept is not dead; it just has a different form now.

Written by

Nishant Vaghasiya

Technical Architect

I'm Nishant Vaghasiya, a Technical Architect and Umbraco & Sitecore Certified Developer at Arroact Technologies. I specialise in building digital solutions with Umbraco and Sitecore that are practical, scalable, and built to last.

Over the years, I've learned that the best solutions aren't always the most complex ones, they're the ones that make a team's day-to-day work simpler and give them confidence that the system won't let them down.

That's what drives me writing code that performs well, stays reliable, and continues to create real impact long after it goes live.