If you're deploying a brand new community to an org that doesn't have communities enabled, then you must first set
NetworksEnabled as a part of the
OrgPreference Settings metadata.
When you create a community for the first time Salesforce will generate some Apex classes, EmailTemplates, and Visualforce pages automatically. These are used to facilitate self-registration, logging in, and notifying community members.
To deploy Communities, there are a few necessary pieces of metadata:
Network - The core Community/Experience settings
CustomSite - Settings for a Site like whether it's Active or has a URL Prefix.
ExperienceBundle - this is a newer metadata type that replaces the cumbersome
SiteDotCom metadata. See Experience Bundles below.
SiteDotCom - this is a binary file that contains most of a Community's content (pages, assigned layouts, components on the page and their set values). Note that you can't really compare this because it's binary and in order to deploy this to a target the source must be on the same API version as the target otherwise your deployment is dead on arrival because the only solution is to wait for the target to upgrade. Also note that simply fetching this metadata from the Salesforce Metadata API can generate a brand new MD5 hash so it's difficult to tell if there are differences between two communities. I recommend not dealing with this metadata type.
If you have ExperienceBundle enabled for your community (under Setup > Digital Experiences > Settings), then the
ExperienceBundle metadata consolidates branding and unreadable content of the SiteDotCom metadata into a folder of JSON files.
If you have ExperienceBundles enabled (you can verify this by checking for the ExperienceBundle.settings-meta.xml file and that
enableExperienceBundleMetadata is true) then the only types of metadata that need be included in a manifest file are:
<?xml version="1.0" encoding="UTF-8"?>
The metadata for branding & page configurations are included under the ExperienceBundle experiences directory. An example bundle directory will look like:
│ ├─ brandingSets/
│ ├─ config/
│ ├─ routes/
│ │ ├─ home.json
│ ├─ themes/
│ ├─ variations/
│ ├─ views/
SiteDotCom (Legacy method)
If you are not using Experience Bundles, then the metadata for branding includes (look and feel):
NetworkBranding - core community branding, such as the login page colors and background
BrandingSet - for branding themes (colors, fonts, brand image)
ContentAsset - asset file metadata, like a logo image
Finally there are a few optional pieces of metadata related to Communities:
Audience - if you're using audience targeting, this is the ruleset
CSPTrustedSite - allowed external sites used if you are embedding outsides scripts, images, or frames into your community.
Community (Zone) - Used for Ideas and Chatter Answers
KeywordList - a list of banned words in a community
Using any tools that access the Metadata API (ANT & Gearset come to mind, but pick your preferred tool) should allow you to compare all of these pieces of metadata together to spot differences with the exception of
SiteDotCom. With differences in the source and target, you'll probably need to either construct a unique deployment file (to merge changes from both into one) or align all the changes in QA and then deploy to production.