Deploy Your Experience Cloud Site with the Metadata API

Depending on the site framework, the following metadata types combine to define the site. To successfully migrate a site, use the Metadata API retrieve call to retrieve XML file representations of your org’s components.

Network

Represents an Experience Cloud site. Contains administration settings, such as page override, email, and membership configurations.

CustomSite

Contains the domain and page setting information, including indexPage, siteAdmin, and URL definitions.

DigitalExperienceBundle and DigitalExperienceConfig or ExperienceBundle or SiteDotCom

The metadata type you require varies depending on the site type. Represents the different settings and components, such as pages, branding sets, and themes, that make up a site.

For enhanced LWR sites, introduced in Winter ’23 (API version 56.0), DigitalExperienceBundle and DigitalExperienceConfig combine to provide text-based representations of your site elements and settings, but reimagined in a more content-focused structure. You can retrieve editable site metadata, and quickly create, update, publish, and deploy sites programmatically. You can also partially deploy enhanced LWR sites.

For non-enhanced LWR sites, ExperienceBundle provides text-based representations of the site’s settings, pages, and components. You can retrieve editable site metadata, and quickly create, update, publish, and partially deploy sites programmatically.

For Aura sites, you can choose to use either ExperienceBundle or SiteDotCom but we recommend using ExperienceBundle. Before Summer ’19 (API version 45.0 and earlier), the Network, CustomSite, and SiteDotCom metadata types combined to define an Aura site. However, retrieving the SiteDotCom type produces a binary .site file that isn’t human readable. See ExperienceBundle for Experience Builder Sites.

For Visualforce sites, Network represents the site.

For additional information on these metadata types and instructions on migrating data, see the Metadata API Developer Guide and the Salesforce CLI Command Reference.

Required Metadata Types at a Glance

The metadata types that you use to deploy a site vary depending on the site type.

Required Metadata Type	Enhanced LWR Site	LWR Site	Aura Site	Visualforce Site
Network
CustomSite
DigitalExperienceBundle
DigitalExperienceConfig
ExperienceBundle			ExperienceBundle or SiteDotCom
SiteDotCom

Tips and Considerations

• Before migrating data to another org, enable digital experiences in the destination org and enter the same domain name that you used in your sandbox org to avoid getting an error.
• For each Experience Cloud site, the network component has a unique name and URL path prefix. When you retrieve the network component, the generated XML file name is based on the name of the network. When migrating, the API looks at the file name and, if it exists, updates the site. If it doesn’t exist, the API creates a site. If someone changes the site name in the sandbox and then tries to migrate, they see an error. The API is trying to create a site with the existing path prefix.
• Examine the XML file for CustomSite to make sure that all dependencies are brought over. If any are missing, explicitly state them in the XML file.
• In addition to the required components described previously, include all the other components required by your site. Components can include such items as custom objects, custom fields, custom Lightning components, and Apex classes.
• To deploy the Network and Profile components using unlocked packages, create a separate unlocked package for each component and deploy them individually.
• When deploying an Aura site with ExperienceBundle, ensure that the SiteDotCom type isn’t included in the manifest file.
• If you rename a site in Administration | Settings, make sure that the source and target sites have matching values for the picassoSite and site attributes in the Network component.
• If there are any changes to the guest user profile, include the profile as part of the site migration.
• When you migrate user profiles, users are added to the site in the production org. Emails are then sent to members in the same way as for any new site.
• During deployment, make sure that the NavigationMenu developer name in the target org is the same as the developer name in the source org.
• If the containerType is CommunityTemplateDefinition, you can’t update an existing NavigationMenu via Metadata API.
• Deploying the navigation menu with additional menu items deletes any translations applied to existing menu items in the target environment.
• To include navigation menus when you move your site, use the NavigationMenu metadata type.
• You can’t deploy to a target org that’s using an earlier release version. For example, if your source org is on Summer ’19 (API version 46.0), you can’t deploy to a target org on Spring ’19 (API version 45.0).
• NavigationLinkSet was deprecated in Winter ’20 (API version 47.0) and replaced by NavigationMenu.
• ExperienceBundle doesn’t support retrieving and deploying across different API versions. If you’re trying to upgrade ExperienceBundle metadata from an earlier API version to a later one—for example, from API version 48.0 to 49.0—take the following steps:
  1. Set the API version in the package.xml manifest file to 48.0 and deploy the package.
  2. Then, set the API version in package.xml to 49.0.
  3. To get the latest ExperienceBundle updates, retrieve the package .

Sample Template

1<?xml version="1.0" encoding="UTF-8"?>
2<Network xmlns="http://soap.sforce.com/2006/04/metadata">
3    <allowInternalUserLogin>true</allowInternalUserLogin>
4    <allowMembersToFlag>true</allowMembersToFlag>
5    <allowedExtensions>txt,png,jpg,jpeg,pdf,doc,csv</allowedExtensions>
6    <caseCommentEmailTemplate>unfiled$public/ContactFollowUpSAMPLE</caseCommentEmailTemplate>
7    <changePasswordTemplate>unfiled$public/CommunityChangePasswordEmailTemplate</changePasswordTemplate>
8    </communityRoles>
9    <disableReputationRecordConversations>true</disableReputationRecordConversations>
10    <emailSenderAddress>admin@myorg.com</emailSenderAddress>
11    <emailSenderName>MyCommunity</emailSenderName>
12    <enableCustomVFErrorPageOverrides>true</enableCustomVFErrorPageOverrides>
13    <enableDirectMessages>true</enableDirectMessages>
14    <enableGuestChatter>true</enableGuestChatter>
15    <enableGuestFileAccess>false</enableGuestFileAccess>
16    <enableInvitation>false</enableInvitation>
17    <enableKnowledgeable>true</enableKnowledgeable>
18    <enableNicknameDisplay>true</enableNicknameDisplay>
19    <enablePrivateMessages>false</enablePrivateMessages>
20    <enableReputation>true</enableReputation>
21    <enableShowAllNetworkSettings>true</enableShowAllNetworkSettings>
22    <enableSiteAsContainer>true</enableSiteAsContainer>
23    <enableTalkingAboutStats>true</enableTalkingAboutStats>
24    <enableTopicAssignmentRules>true</enableTopicAssignmentRules>
25    <enableTopicSuggestions>true</enableTopicSuggestions>
26    <enableUpDownVote>true</enableUpDownVote>
27    <forgotPasswordTemplate>unfiled$public/CommunityForgotPasswordEmailTemplate</forgotPasswordTemplate>
28    <gatherCustomerSentimentData>false</gatherCustomerSentimentData>
29    <lockoutTemplate>unfiled$public/CommunityLockoutEmailTemplate</lockoutTemplate>
30    <maxFileSizeKb>51200</maxFileSizeKb>
31    <networkMemberGroups>
32        <permissionSet>MyCommunity_Permissions</permissionSet>
33        <profile>Admin</profile>
34    </networkMemberGroups>
35    <networkPageOverrides>
36        <changePasswordPageOverrideSetting>VisualForce</changePasswordPageOverrideSetting>
37        <forgotPasswordPageOverrideSetting>Designer</forgotPasswordPageOverrideSetting>
38        <homePageOverrideSetting>Designer</homePageOverrideSetting>
39        <loginPageOverrideSetting>Designer</loginPageOverrideSetting>
40        <selfRegProfilePageOverrideSetting>Designer</selfRegProfilePageOverrideSetting>
41    </networkPageOverrides>
42    <picassoSite>MyCommunity1</picassoSite>
43    <selfRegistration>true</selfRegistration>
44    <sendWelcomeEmail>true</sendWelcomeEmail>
45    <site>MyCommunity</site>
46    <status>Live</status>
47    <tabs>
48        <defaultTab>home</defaultTab>
49        <standardTab>Chatter</standardTab>
50    </tabs>
51    <urlPathPrefix>mycommunity</urlPathPrefix>
52    <welcomeTemplate>unfiled$public/CommunityWelcomeEmailTemplate</welcomeTemplate>
53</Network>

Sample package.xml Manifest File

A manifest file defines the components that you’re trying to retrieve. The following sample shows a package.xml manifest file for retrieving all the components of an Experience Builder site.

1<?xml version="1.0" encoding="UTF-8"?>
2<Package xmlns="http://soap.sforce.com/2006/04/metadata">
3    <types>
4        <members>*</members>
5        <name>Network</name>
6    </types>
7    <types>
8        <members>*</members>
9        <name>CustomSite</name>
10    </types>
11    <types>
12        <members>*</members>
13        <name>ExperienceBundle</name>
14    </types>
15    <types>
16        <members>*</members>
17        <name>CustomTab</name>
18    </types>
19    <types>
20        <members>*</members>
21        <name>CustomObject</name>
22    </types>
23    <types>
24        <members>*</members>
25        <name>ApexClass</name>
26    </types>
27    <types>
28        <members>*</members>
29        <name>ApexPage</name>
30    </types>
31    <types>
32        <members>*</members>
33        <name>ApexComponent</name>
34    </types>
35    <types>
36        <members>*</members>
37        <name>Portal</name>
38    </types>
39    <types>
40        <members>*</members>
41        <name>Profile</name>
42    </types>
43    <types>
44        <members>*</members>
45        <name>Document</name>
46    </types>
47    <version>46.0</version>
48</Package>