Experience Cloud Site
An Experience Cloud Site is one branded digital destination built on the Salesforce Experience Cloud platform.
Definition
An Experience Cloud Site is one branded digital destination built on the Salesforce Experience Cloud platform. It is a single deployment with its own pages, theme, navigation, URL, login methods, and audience. The site runs inside a Salesforce org and reads from the same CRM data as the rest of the org, but it presents that data through its own configured experience. Customers, partners, or employees sign in to a site to get help, place orders, register deals, or read knowledge articles.
A Salesforce org can host many sites at once, up to a limit of 100 (active, inactive, preview, and Visualforce sites all count toward that number). You create and manage each one from Setup under Digital Experiences then All Sites. In the API, every site maps to a Network record, which is why SOQL such as SELECT Id, Name, Status FROM Network returns one row per site. Each site is activated and deactivated on its own, so taking one offline never affects the others.
How a site is structured, built, and run
One site is a self-contained configuration
A site bundles everything a visitor experiences into one configurable unit. That includes its pages (such as Home, a knowledge or article page, and Contact Us), the navigation menu, the theme (colors, fonts, and logo), the audiences and targeting rules, the login methods (username and password, single sign-on, or social login), the data sharing that decides which records flow in, and the URL the site lives at. All of this is held per site. A change you make to the partner portal does not touch the customer help center, even though both run in the same org. This isolation is what lets one team rebrand or restructure their site without a change-control conversation with every other site owner. It also means each site carries its own risk surface: a misconfigured sharing rule or guest profile is scoped to that one site rather than the whole org. When you plan a site, you are really planning a small product with its own audience, its own pages, and its own access model, all sitting on top of shared org data.
Many sites, one org, shared data
A single org commonly runs several sites at once. A typical enterprise pattern is a public help center on help.acme.com, a partner portal on partners.acme.com, and an employee learning site on learn.acme.com, plus the occasional marketing microsite for a campaign. The same Accounts, Contacts, Cases, and custom objects back all of them. A Contact who is also a registered partner can appear in the partner portal, while a Case raised in the help center writes to the same Case object an internal agent works from. The org-wide cap is 100 sites, and active, inactive, preview, and older Visualforce sites all count against it. Archived sites are the exception: archiving a site you no longer need frees a slot without deleting its data. Because data is shared but presentation is not, the design work splits cleanly. Object and field-level security, sharing rules, and record ownership are org concerns, while pages, themes, and navigation are site concerns. Getting that split right early keeps a growing portfolio of sites manageable.
The Network record behind every site
In the Salesforce data model, each Experience Cloud Site is represented by a Network record. Network is the API anchor for site-level metadata, and it carries fields such as Name, Status, and UrlPathPrefix. The UrlPathPrefix is the path segment that uniquely identifies the site under the org domain, so two sites in the same org cannot share one prefix. Querying SELECT Id, Name, Status, UrlPathPrefix FROM Network returns one row per site, which is handy for scripts that report on or audit a portfolio. The companion NetworkMember object links users to the sites they belong to, so you can see membership per site. The Network record also surfaces options that control behavior, including self-registration. Many integration and deployment patterns reference Network directly: the Metadata API uses a Network component to deploy site settings between a sandbox and production, and Apex exposes a Network class for site context at runtime. Treat the Network record as the canonical handle for a site whenever you work below the Experience Builder layer, whether in SOQL, Apex, or a metadata deployment.
Picking a template at creation time
You create a site from a wizard that opens when you click New on the All Sites page. The wizard leads with a template choice, and that choice shapes the starting pages and the runtime the site uses. Customer Account Portal suits a self-service experience where customers manage their own records. Partner Central targets channel sales with deal registration and lead distribution. Customer Service is a help-center style template built around Cases and Knowledge. The two Build Your Own options give you a near-blank canvas: the Aura version runs on the older Aura framework, while the LWR version runs on Lightning Web Runtime for faster, more standards-based pages. There is also a Microsite template for lightweight marketing pages. The template is not a permanent cage, since you keep editing in Experience Builder afterward, but the underlying runtime (Aura versus LWR) is a meaningful commitment. LWR sites load faster and use Lightning Web Components throughout, while Aura sites support a wider catalog of older standard components. Choosing the runtime that matches your component needs and performance goals at creation saves a rebuild later.
Building and theming in Experience Builder
After creation, you customize the site in Experience Builder, the drag-and-drop editor for Experience Cloud. Builder is where you add and arrange pages, drop components onto them, set the theme, and define navigation. You work without writing markup for the common cases, dragging standard components into regions and setting their properties in a side panel. Branding lives here too: colors, fonts, the logo, and image assets are set once and applied across the site through the theme. Audiences are configured in Builder as well, so you can show a component or a whole page variation only to a named segment, such as logged-in partners versus guest visitors. For anything the standard catalog does not cover, you build custom Lightning Web Components and expose them to Builder, where a site admin then configures them like any other component. This is the key to running many sites efficiently. You write a component once, then each site configures it differently through Builder properties rather than forking the code. The result is one codebase and many distinct, branded experiences drawing from it.
Activation, lifecycle, and going live
A site moves through clear lifecycle states. It starts under construction as a draft that only authorized internal users can preview. When you activate it, the site becomes reachable at its URL for its intended audience. Deactivating it takes it offline and serves a maintenance page instead. Activation is a per-site action, so several sites in one org can sit in different states at the same time, and one going offline leaves the rest untouched. Two pieces decide who can actually reach a live site. First is licensing: external user licenses such as Customer Community, Customer Community Plus, and Partner Community govern who can log in, and usage is tracked per site, so a fast-growing site can exhaust its license pool and force a procurement step. Second is the URL and domain setup, where a site uses either the default Salesforce-hosted URL or a custom domain configured through My Domain. Before going live, confirm the login methods work, the sharing model exposes the right records and no more, the guest user profile is locked down, and the analytics you care about (visits, page views, search queries, and logins via Network Member login history) are instrumented from day one.
How to create an Experience Cloud Site
Spin up a new Experience Cloud Site from Setup. You enable the feature once per org, then run the creation wizard for each site you need. Plan licensing and sharing before you start, because both are easier to get right up front than to retrofit.
- Enable Digital Experiences
From Setup, enter Digital Experiences in Quick Find, open Settings, and select Enable Digital Experiences. This is a one-time, org-level step that turns the platform on before any site can exist.
- Open the All Sites page
From Setup, enter Digital Experiences in Quick Find again and select All Sites. This page lists every site in the org and shows how many of your 100 slots are in use.
- Start the creation wizard
Click New. The wizard opens with a gallery of templates. Pick the one that matches your use case and runtime needs, then continue.
- Name the site and set its URL
Enter a Site Name and a URL path prefix. The prefix must be unique within the org and becomes part of the site address, so choose it deliberately because changing it later breaks bookmarks and links.
- Build, then activate
Open the site in Experience Builder to add pages, components, theme, and audiences. When it is ready, return to All Sites and activate it to make it reachable at its URL.
The internal name that identifies the site in Setup and in the Network record. Name it by purpose, not by sequence.
The unique path segment under the org domain that addresses the site. Stored as UrlPathPrefix on the Network record and unique per org.
The starting template, which sets the initial pages and the runtime (Aura or Lightning Web Runtime) the site uses.
- Active, inactive, preview, and Visualforce sites all count toward the org limit of 100; archive sites you no longer use to reclaim a slot.
- The Aura versus LWR runtime is set by the template and is not a casual switch later, so choose it against your component and performance needs.
- Lock down the guest user profile before activating; an open guest profile is scoped to that site but can still expose records you did not intend.
- External user licenses are consumed per named user and are tracked per site, so a popular site can run its license pool dry without warning.
Trust & references
Cross-checked against the following references.
- Create an Experience Cloud SiteSalesforce
- Experience CloudSalesforce
Straight from the source - Salesforce's reference material on Experience Cloud Site.
Hands-on resources to go deeper on Experience Cloud Site.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is an Experience Cloud Site?
Q2. What older Salesforce term does Experience Cloud Site replace?
Q3. What's a common type of Experience Cloud Site?
Discussion
Loading discussion…