How to Create UI, Themes and Templates in Sitecore and Render Backend Fields in the Frontend
One of the first questions developers ask when learning Sitecore is:
How do I actually build the frontend?
If we already have a website design in HTML, CSS, or React, how do we convert that design into Sitecore? How do we create backend fields for editors, connect them to components, and finally render those fields in the UI?
The answer depends partly on whether we are working with:
- Traditional Sitecore MVC
- Sitecore SXA
- Modern Sitecore headless architecture
- Sitecore XM Cloud with Next.js and JSS
The underlying concept, however, is very similar in all of them.
The frontend contains the visual presentation.
Sitecore contains the structured content.
The two are connected through templates, fields, datasources, renderings and components.
1. Understanding the Sitecore Frontend Model
In a traditional CMS, we might think of a page as one template containing all its data.
Modern Sitecore development is much more component-oriented.
A page might look like:
Homepage
│
├── Header
├── Hero
├── Introduction
├── Services
├── Statistics
├── Projects
├── Testimonials
├── CTA
└── Footer
Rather than creating one huge homepage template, we can build individual components.
For example:
Hero Component
Services Component
Projects Component
Testimonials Component
CTA Component
Each component can have:
- Its own content structure
- Its own frontend UI
- Its own datasource
- Its own editing experience
This makes the system significantly more reusable.
2. The Complete Sitecore UI Flow
A modern Sitecore component generally follows this architecture:
CONTENT EDITOR
│
▼
Sitecore Fields
│
▼
Datasource Item
│
▼
Rendering
│
▼
Sitecore Layout Data
│
▼
Next.js / React Component
│
▼
HTML + CSS
│
▼
USER
This is the core idea behind Sitecore frontend development.
3. Start with the UI
Suppose we need this Hero section:
----------------------------------------------------
Engineering solutions for a better future
Delivering innovative solutions worldwide.
[ Explore Services ]
[ Hero Image ]
----------------------------------------------------
We can first build it as a normal React component.
const Hero = () => {
return (
<section className="hero">
<div className="hero__content">
<h1>
Engineering solutions for a better future
</h1>
<p>
Delivering innovative solutions worldwide.
</p>
<a href="/services">
Explore Services
</a>
</div>
</section>
);
};
export default Hero;
At this point, there is nothing specific to Sitecore.
It is simply frontend development.
We can build the entire design using:
React
Next.js
HTML
CSS
JavaScript / TypeScript
The next step is making that content editable from Sitecore.
4. Create a Sitecore Template
In Sitecore, a template defines the structure of content.
For the Hero component, we could create:
Hero Template
│
├── Heading
├── Description
├── CTA Text
├── CTA Link
└── Hero Image
Possible field types might be:
| Field | Sitecore Field Type |
|---|---|
| Heading | Single-Line Text |
| Description | Rich Text |
| CTA Text | Single-Line Text |
| CTA Link | General Link |
| Hero Image | Image |
Conceptually, this is similar to creating an ACF Field Group in WordPress.
For example:
WordPress
ACF Field Group
│
├── hero_heading
├── hero_description
├── hero_cta
└── hero_image
versus:
Sitecore
Hero Template
│
├── Heading
├── Description
├── CTA
└── Hero Image
The implementation is different, but the idea is familiar.
5. Templates Are Content Schemas
A Sitecore template is essentially a schema describing what an item contains.
For example:
Service Template
General
├── Service Name
├── Short Description
└── Icon
Content
├── Introduction
├── Main Content
└── Benefits
Media
├── Hero Image
└── Gallery
SEO
├── Meta Title
├── Meta Description
└── Canonical URL
Content editors can then create multiple items from the same template.
For example:
Services
│
├── Building Surveying
├── Structural Engineering
├── Infrastructure Engineering
├── RICS Valuation
└── Planning Support
Every one of these items follows the same content model.
6. What Is a Rendering?
A template tells Sitecore:
What data does this component contain?
A rendering tells Sitecore:
Which frontend component displays this data?
For example:
Hero Template
│
▼
Hero Datasource
│
▼
Hero Rendering
│
▼
Hero.tsx
This separation is very important.
The template is the data model.
The rendering is the presentation component.
7. Create a Datasource
A datasource is another fundamental Sitecore concept.
Suppose the homepage has a Hero component.
Instead of storing the Hero content directly on the Home item, we can create a separate content item:
Home
│
└── Data
│
└── Homepage Hero
Homepage Hero might contain:
Heading:
Engineering solutions for a better future
Description:
Delivering innovative solutions worldwide.
CTA:
Explore Services
Image:
hero.jpg
The Hero rendering points to this item.
So the architecture becomes:
Homepage
│
▼
Hero Rendering
│
▼
Homepage Hero Datasource
│
├── Heading
├── Description
├── CTA
└── Image
This gives us a clean separation between content and presentation.
8. Why Datasources Matter
Imagine the same Hero component is used on five pages.
We only need one frontend component:
Hero.tsx
But we can create many datasources:
Hero.tsx
│
├── Homepage Hero
├── About Hero
├── Services Hero
├── Careers Hero
└── Contact Hero
The frontend component remains identical.
Only the content changes.
This is one of Sitecore’s strongest reusable-content patterns.
9. Sitecore Sends Data to the Frontend
In a headless Sitecore implementation, Sitecore provides component data to the frontend.
Conceptually, the frontend may receive something like:
{
"componentName": "Hero",
"fields": {
"Heading": {
"value": "Engineering solutions for a better future"
},
"Description": {
"value": "Delivering innovative solutions worldwide."
},
"HeroImage": {
"value": {
"src": "/images/hero.jpg"
}
},
"CTA": {
"value": {
"href": "/services",
"text": "Explore Services"
}
}
}
}
The Next.js component receives those fields as properties.
10. Render Sitecore Fields in React
This is where backend content finally reaches the UI.
We first define the component fields.
import {
Field,
Text,
RichText,
Link,
LinkField,
Image,
ImageField,
} from '@sitecore-jss/sitecore-jss-nextjs';
type HeroProps = {
fields: {
Heading: Field<string>;
Description: Field<string>;
CTA: LinkField;
HeroImage: ImageField;
};
};
Then use them inside the component.
const Hero = ({ fields }: HeroProps) => {
return (
<section className="hero">
<div className="hero__content">
<h1>
<Text field={fields.Heading} />
</h1>
<RichText field={fields.Description} />
<Link field={fields.CTA} />
</div>
<div className="hero__image">
<Image field={fields.HeroImage} />
</div>
</section>
);
};
export default Hero;
Now Sitecore controls the content.
React controls the presentation.
11. Sitecore Field Rendering Components
JSS provides frontend components for common Sitecore field types.
Some frequently used examples include:
<Text />
<RichText />
<Image />
<Link />
<Date />
<File />
For example:
<Text field={fields.Title} />
renders a text field.
<RichText field={fields.Description} />
renders rich text.
<Image field={fields.Image} />
renders a Sitecore image.
<Link field={fields.CTA} />
renders a Sitecore link.
This approach is preferable to simply reading the raw value in many cases because Sitecore can also provide editing information.
12. Why Not Just Use .value?
Technically, we could write:
<h1>
{fields.Heading.value}
</h1>
But we will commonly see:
<h1>
<Text field={fields.Heading} />
</h1>
The Sitecore field component understands additional Sitecore metadata and can support inline editing.
That allows a content editor to edit content directly through Sitecore’s page editing experience.
Conceptually:
SITECORE PAGE EDITOR
Engineering solutions for a better future
↑
click and edit
while the actual frontend is still React.
13. From Static UI to Dynamic Sitecore UI
Suppose our original frontend contains:
<h1>
Engineering solutions for a better future
</h1>
We convert it into:
<h1>
<Text field={fields.Heading} />
</h1>
Static:
<p>
Delivering innovative solutions worldwide.
</p>
Dynamic:
<RichText field={fields.Description} />
Static:
<img src="/images/hero.jpg" />
Dynamic:
<Image field={fields.HeroImage} />
Static:
<a href="/services">
Explore Services
</a>
Dynamic:
<Link field={fields.CTA} />
This is essentially the Sitecore conversion process.
14. What Is the Sitecore Equivalent of a Theme?
WordPress developers normally think in terms of:
/wp-content/themes/my-theme/
containing:
header.php
footer.php
page.php
single.php
style.css
functions.php
Modern headless Sitecore does not necessarily have a single “theme” in exactly this sense.
The presentation layer is normally a frontend application.
For example:
Next.js Application
│
├── src
│ ├── components
│ ├── layouts
│ ├── pages
│ ├── styles
│ └── lib
│
├── public
└── package.json
Sitecore itself contains:
Sitecore
│
├── Templates
├── Renderings
├── Placeholder Settings
├── Content
├── Datasources
└── Media
Together they form the complete implementation.
15. A Typical Component Folder
A practical frontend project might contain:
src/
│
├── components/
│ │
│ ├── Header.tsx
│ ├── Hero.tsx
│ ├── ServicesGrid.tsx
│ ├── ServiceCard.tsx
│ ├── Projects.tsx
│ ├── Testimonials.tsx
│ ├── CTA.tsx
│ └── Footer.tsx
│
├── layouts/
│ └── DefaultLayout.tsx
│
└── styles/
├── globals.css
├── hero.css
├── services.css
└── footer.css
Your CSS remains normal CSS.
For example:
.hero {
min-height: 700px;
display: flex;
align-items: center;
}
.hero__content {
max-width: 760px;
}
.hero__content h1 {
font-size: clamp(3rem, 6vw, 6rem);
line-height: 1;
}
.hero__image img {
width: 100%;
height: auto;
}
Sitecore does not control how visually creative the frontend can be.
16. Layouts and Placeholders
Pages are assembled through layouts and placeholders.
A page structure might be:
Default Layout
│
├── Header
│
├── Main
│
└── Footer
Inside the Main area we can create a placeholder.
Conceptually:
<main>
<Placeholder
name="main"
rendering={props.rendering}
/>
</main>
Sitecore can then insert components into that placeholder.
Main Placeholder
│
├── Hero
├── Intro
├── Services
├── Projects
├── Testimonials
└── CTA
This gives content editors a component-based page-building experience.
17. Components Can Be Rearranged
Imagine this homepage:
Hero
Services
Projects
Testimonials
CTA
An editor might change it to:
Hero
Projects
Services
CTA
Testimonials
without changing the React implementation of the individual components.
The page composition lives in Sitecore.
This is one of the main reasons Sitecore separates:
CONTENT
COMPONENTS
LAYOUT
18. Nested Placeholders
Placeholders can also be nested.
For example:
Main
│
├── Hero
│
├── Two Column Layout
│ │
│ ├── Left
│ │ ├── Heading
│ │ └── Text
│ │
│ └── Right
│ └── Image
│
├── Services
└── CTA
This allows sophisticated page-building systems.
We can create layout components such as:
Container
Two Column
Three Column
Tabs
Accordion
Grid
and then place other Sitecore components inside them.
19. Creating a Service Card Component
Let’s build a complete example.
Suppose the design contains:
--------------------------------
[ IMAGE ]
Structural Engineering
Specialist structural engineering
solutions for complex projects.
Learn More →
--------------------------------
Create a Sitecore template:
Service Card
├── Title
├── Description
├── Image
└── Link
Create a datasource:
Structural Engineering
Title:
Structural Engineering
Description:
Specialist structural engineering solutions...
Image:
structural-engineering.jpg
Link:
/services/structural-engineering
Then build the React component:
const ServiceCard = ({ fields }: ServiceCardProps) => {
return (
<article className="service-card">
<Image field={fields.Image} />
<div className="service-card__content">
<h3>
<Text field={fields.Title} />
</h3>
<RichText field={fields.Description} />
<Link field={fields.Link} />
</div>
</article>
);
};
We now have one reusable component capable of displaying many services.
20. What About Repeater Fields?
WordPress developers commonly use ACF Repeaters.
For example:
Services Repeater
Row 1
Building Surveying
Row 2
Structural Engineering
Row 3
Valuation
Sitecore often models this differently.
Instead, we might create:
Services
│
├── Building Surveying
├── Structural Engineering
├── RICS Valuation
└── Infrastructure Engineering
Each service is an individual Sitecore item.
The frontend can then loop through the data.
{services.map((service) => (
<ServiceCard
key={service.id}
fields={service.fields}
/>
))}
This is often more appropriate for enterprise content because each item can also have:
- Versions
- Languages
- Workflow
- Permissions
- SEO
- Relationships
- Publishing
21. Creating Page Templates
Suppose we need a Service Detail page.
The page might contain:
Service Page
│
├── Hero
├── Introduction
├── Benefits
├── Capabilities
├── Case Studies
├── Related Services
└── CTA
There are two broad approaches.
We could create structured page fields:
Service Page Template
├── Title
├── Intro
├── Hero Image
└── SEO
and use Sitecore components for the rest.
Or we could make much of the page composition component-driven.
A common architecture could be:
Service Page Item
│
├── Core Page Fields
│
└── Presentation
│
├── Service Hero
├── Rich Text
├── Benefits
├── Case Studies
└── CTA
This gives editors structure while still allowing flexibility.
22. Shared Components vs Page-Specific Components
A good Sitecore implementation avoids creating unique components unnecessarily.
Instead of:
Homepage Hero
Services Hero
About Hero
Careers Hero
we might create:
Hero
with configurable fields:
Eyebrow
Heading
Description
Image
CTA
Alignment
Theme
The same component can then be reused throughout the website.
Similarly:
CTA
Card Grid
Statistics
Accordion
Image + Content
Logo Grid
Testimonials
can be reusable components.
23. Rendering Variants
In SXA-based implementations, the same component may support multiple visual variants.
For example:
Service Card
│
├── Default
├── Horizontal
├── Compact
└── Featured
The content can remain the same.
The presentation changes.
Conceptually:
Same Data
│
├── Card View
├── List View
└── Featured View
This reduces duplicate component development.
24. How Header and Footer Usually Work
Global components such as Header and Footer often use shared Sitecore content.
For example:
Global
│
├── Header
│ ├── Logo
│ ├── Navigation
│ └── CTA
│
└── Footer
├── Logo
├── Contact
├── Navigation
└── Social Links
The frontend then renders those items through reusable components.
This means editors do not need to update every page when the footer changes.
25. Navigation in Sitecore
Navigation can be built in several ways.
One approach is deriving navigation from the content tree.
For example:
Home
├── About
├── Services
│ ├── Service A
│ ├── Service B
│ └── Service C
├── Projects
└── Contact
The frontend can retrieve navigation items and render:
<nav>
{navigationItems.map((item) => (
<Link
key={item.id}
field={item.link}
/>
))}
</nav>
More complex sites may use dedicated navigation data structures.
26. Backend Editing vs Frontend Rendering
An important architectural separation is:
Sitecore Backend
Content
Templates
Fields
Media
Navigation
Datasources
Presentation Configuration
versus:
Frontend
HTML
CSS
React
Animations
Responsive Layout
JavaScript Behaviour
Accessibility
Frontend Performance
The frontend developer should not need to hardcode business content.
The editor should not need to modify frontend code.
27. Converting Existing HTML into Sitecore
Suppose we receive an existing HTML website.
Our workflow could be:
Existing HTML Website
│
▼
Identify Components
│
├── Header
├── Hero
├── Services
├── Projects
├── CTA
└── Footer
│
▼
Convert HTML to React
│
▼
Create Sitecore Templates
│
▼
Create Datasources
│
▼
Create Renderings
│
▼
Map Sitecore Fields
│
▼
Add Components to Placeholders
│
▼
Sitecore Editable Website
This is one of the most common frontend migration workflows.
28. WordPress + ACF vs Sitecore
For developers coming from WordPress, this mental mapping is extremely useful.
| WordPress | Sitecore |
|---|---|
| WordPress Theme | Next.js frontend / Sitecore solution |
page.php |
Layout / Page Composition |
| ACF Field Group | Sitecore Template |
| ACF Field | Sitecore Field |
the_field() |
Sitecore JSS Field Component |
get_field() |
props.fields |
| ACF Image | Sitecore Image Field |
| ACF Link | General Link |
| ACF Flexible Content | Renderings + Placeholders |
| Gutenberg Block | Sitecore Rendering / Component |
| Custom Post Type | Template-based content structure |
| Repeater | Child Items / Related Items |
| WordPress Media Library | Sitecore Media Library |
| Menu | Navigation Items / Navigation Component |
The comparison isn’t technically one-to-one, but it provides an excellent learning bridge.
29. Traditional Sitecore MVC
Not every Sitecore project uses Next.js.
Many existing enterprise projects still use traditional Sitecore MVC.
In that model, the flow can look like:
Sitecore Template
│
▼
Datasource
│
▼
Controller Rendering
│
▼
Controller
│
▼
View Model
│
▼
Razor View
│
▼
HTML
A field could be rendered inside a .cshtml file.
For example:
<h1>
@Html.Sitecore().Field("Heading")
</h1>
This is roughly the older Sitecore equivalent of:
<Text field={fields.Heading} />
in JSS.
30. Traditional MVC vs Modern Headless
Traditional architecture:
Browser
│
▼
Sitecore Server
│
▼
MVC Controller
│
▼
Razor
│
▼
HTML
Modern headless architecture:
Browser
│
▼
Next.js
│
▼
Experience Edge / Layout API
│
▼
Sitecore
The second architecture gives frontend developers more independence.
31. Sitecore XM Cloud Frontend Architecture
A modern XM Cloud implementation could look like:
Content Editor
│
▼
XM Cloud
│
▼
Experience Edge
│
GraphQL
│
▼
Next.js
│
▼
Vercel / CDN
│
▼
Visitor
Sitecore manages:
Templates
Fields
Content
Pages
Components
Publishing
Next.js manages:
UI
CSS
Responsive Design
Animations
Frontend Logic
Rendering
This separation is one of the major advantages of headless Sitecore.
32. Where Does GraphQL Fit?
For more advanced components, we may need content beyond the direct datasource fields.
For example, a Related Projects component might need:
Current Service
│
▼
Find Related Projects
│
▼
GraphQL Query
│
▼
Sitecore Content
The frontend can then render the returned items.
Conceptually:
projects.map(project => (
<ProjectCard
key={project.id}
project={project}
/>
))
This becomes useful for:
- Related content
- Product listings
- Search
- Complex relationships
- Navigation
- Multi-item components
33. What Developers Actually Build
A Sitecore frontend developer may spend time working on:
React Components
Next.js
TypeScript
CSS / SCSS
HTML
JSS
Sitecore Fields
Datasources
Placeholder Configuration
GraphQL
Responsive Design
Accessibility
Performance
while Sitecore backend developers may focus more on:
Templates
Sitecore configuration
Custom pipelines
APIs
Search
Solr
Serialization
.NET
Integrations
Deployment
In many teams these responsibilities overlap.
34. Recommended Development Workflow
A practical component workflow is:
1. Build HTML / React UI
2. Identify editable content
3. Create Sitecore template
4. Create fields
5. Create rendering
6. Configure datasource template
7. Create datasource item
8. Receive Sitecore data
9. Map fields to React
10. Add component to placeholder
11. Test inline editing
12. Test responsive UI
13. Serialize Sitecore definitions
14. Commit everything to Git
This is much easier than trying to learn the entire Sitecore ecosystem at once.
35. A Full Hero Example
Backend:
Hero Template
├── Eyebrow
├── Heading
├── Description
├── CTA
└── Image
Datasource:
Homepage Hero
Eyebrow:
Engineering Consultancy
Heading:
Independent expertise for complex projects
Description:
Providing structural, surveying and technical
consultancy services throughout the UK.
CTA:
Explore Our Services
Image:
hero-engineering.jpg
Frontend:
const Hero = ({ fields }: HeroProps) => {
return (
<section className="hero">
<div className="container">
<div className="hero__content">
<span className="hero__eyebrow">
<Text field={fields.Eyebrow} />
</span>
<h1>
<Text field={fields.Heading} />
</h1>
<RichText field={fields.Description} />
<Link
field={fields.CTA}
className="btn btn-primary"
/>
</div>
<div className="hero__media">
<Image field={fields.Image} />
</div>
</div>
</section>
);
};
The final UI is completely dynamic.
36. The Most Important Concept to Remember
A Sitecore frontend is essentially the meeting point between:
DATA
and:
PRESENTATION
Sitecore provides:
Templates
Fields
Content
Datasources
Media
Relationships
The frontend provides:
React
Next.js
HTML
CSS
Animations
Responsive UI
They meet here:
Sitecore Data
│
▼
props.fields
│
▼
React Component
│
▼
Final UI
Conclusion
Creating a Sitecore UI becomes much easier once we stop thinking of Sitecore as a tool that generates our design.
Sitecore manages the content architecture.
The frontend application manages the visual architecture.
A typical process looks like:
Design
│
▼
HTML / React
│
▼
Split into Components
│
▼
Create Sitecore Templates
│
▼
Create Fields
│
▼
Create Datasources
│
▼
Create Renderings
│
▼
Map Fields to React
│
▼
Place Components on Pages
│
▼
Editable Sitecore Website
For developers already familiar with WordPress and ACF, the learning curve becomes much easier when we translate the concepts:
ACF Field
↓
Sitecore Field
ACF Field Group
↓
Sitecore Template
PHP Template
↓
React Component / Rendering
Flexible Content
↓
Placeholders + Renderings
get_field()
↓
props.fields
Once this pattern is understood, creating a Sitecore frontend is no longer mysterious.
We are still building normal user interfaces with HTML, CSS, React and Next.js.
Sitecore simply supplies the enterprise content model, editing experience and structured data behind those interfaces.