Sites and Domains
Sites and Domains is the centralized Setup area in Salesforce for managing every custom domain, hostname, and site configuration the org exposes to the public internet.
Definition
Sites and Domains is the centralized Setup area in Salesforce for managing every custom domain, hostname, and site configuration the org exposes to the public internet. It consolidates the configuration that used to live across multiple separate Setup pages (Sites, Domains, My Domain, Custom URLs, Site.com) into a single management surface where admins can register custom domains, attach them to Experience Cloud sites or Salesforce Sites, configure SSL certificates, and manage URL redirects.
The page is the gateway for any work that exposes a Salesforce-hosted asset on a customer-branded URL: a community at community.acme.com instead of acme.force.com, a self-service portal at help.acme.com, or a public website built on Salesforce Sites at www.acme.com/products. Each domain registered here participates in the org's overall domain hierarchy with Distinct DNS, SSL, and routing configuration. Misconfigured domains are the single most common cause of broken sites in Salesforce.
How Sites and Domains organizes web-facing configuration
The domain hierarchy: My Domain, custom domains, and subdomains
Every Salesforce org has a My Domain (something like acme.my.salesforce.com), which is the customer-branded subdomain on the standard Salesforce hostname. From My Domain, admins can register additional custom domains they own (acme.com, partners.acme.com, help.acme.com) and map each to specific sites and content. The domains form a hierarchy: a top-level custom domain can have subdomains that each point at different sites or paths. Admins configure how each domain resolves, which site loads at which path, and what happens when a request hits a path that does not match any configuration.
SSL certificates and HTTPS
Every domain registered through Sites and Domains needs an SSL certificate for HTTPS access. Salesforce supports two modes: Salesforce-managed certificates (free, automatically renewed, provided by Salesforce's certificate authority partnership) or Bring-Your-Own certificates (uploaded by the customer, typically purchased from a third-party CA). Salesforce-managed certificates are the right choice for most orgs because they renew automatically without admin intervention. BYO certificates are necessary when the customer has specific certificate authority requirements (an internal CA for intranet domains, an EV certificate for high-trust customer-facing sites). The Sites and Domains page shows certificate expiration dates and surfaces warnings as renewals approach.
DNS configuration and verification
For each custom domain, the customer must own the domain and configure DNS records pointing the domain at Salesforce's infrastructure. The Sites and Domains setup walks through the required DNS configuration: a CNAME record pointing to the Salesforce edge endpoint plus a verification TXT record proving ownership of the domain. After DNS propagation (which can take 5 minutes to 48 hours depending on the customer's DNS provider), Salesforce verifies the configuration and activates the domain. Misconfigured DNS is the single most common reason domains fail to activate; double-check the CNAME target and the TXT record before raising a support case.
Site routing and path-based mapping
Once a domain is active, it routes incoming requests to one or more Salesforce-hosted sites based on path-based rules. Requests to acme.com might serve a public marketing site built on Salesforce Sites, while acme.com/community routes to an Experience Cloud customer community, and acme.com/api routes to a custom Apex REST endpoint. The routing rules are configured per domain in the Sites and Domains page. Each rule maps a URL pattern to a target site or page, with optional redirects and fallbacks. For complex sites with many paths, the routing configuration becomes the architectural backbone.
Salesforce Sites versus Experience Cloud
Two distinct site types share the Sites and Domains configuration. Salesforce Sites (the older offering) hosts public pages built in Visualforce or Apex, useful for forms, signup flows, lightweight informational pages, and Apex REST endpoints. Experience Cloud sites (the modern offering) hosts richer experiences with Lightning Web Components, authenticated and unauthenticated content, and integration with CMS workspaces. Most new development uses Experience Cloud; Salesforce Sites remains for legacy use cases and lightweight scenarios. Both types share the same domain management, SSL configuration, and routing rules, but they have different page-authoring and runtime characteristics.
Cookies, CSP, and frame ancestors
Sites hosted at custom domains need careful security header configuration. Cookies set at acme.com need the right SameSite and Secure attributes to flow correctly between subdomains. Content Security Policy headers control what scripts, fonts, and frame sources the site can load. Frame-ancestor directives control whether the site can be embedded in iframes on other domains. The Sites and Domains setup includes configuration options for these headers per domain, and getting them right is essential for both security (preventing XSS, clickjacking, CSRF) and functionality (allowing legitimate cross-domain interactions). Audit the headers after each major change to the site to confirm nothing regressed.
Redirects and SEO considerations
Sites and Domains supports redirect rules that map old URLs to new ones, returning HTTP 301 (permanent) or 302 (temporary) responses. Redirects are critical when migrating from a legacy domain (the company's old website on a different platform) to the new Salesforce-hosted site. Configuring 301 redirects from every old URL to its new counterpart preserves the SEO value built up on the old URLs and prevents broken links from external sources. The redirect configuration is per domain and supports both exact-match and pattern-based rules. For sites with hundreds of old URLs, the redirect map is a meaningful artifact that should be reviewed by the SEO team before going live.
Multi-domain strategies for enterprises
Large enterprises rarely operate a single custom domain. The typical pattern includes a marketing domain (www.acme.com), a partner portal domain (partners.acme.com), a customer support domain (help.acme.com), an internal applications domain (apps.acme.com), and several regional variants (eu.acme.com, apac.acme.com). Managing this multi-domain footprint requires a clear strategy: which domains serve which audiences, which sites live behind each domain, and how to maintain consistency across them. The Sites and Domains page is the operational surface, but the strategic decisions happen at the architecture level. Common pitfalls include subdomain sprawl (creating a new subdomain for every small project), inconsistent branding across domains (different SSL certs, different headers, different SEO meta), and lifecycle gaps (sites that no one owns anymore but the domain still resolves). Establishing a domain governance group with quarterly review meetings is the standard answer.
When the Sites and Domains setup is not the right answer
Sites and Domains handles the customer-branded URL story for Salesforce-hosted content. It is not the right answer for every scenario. Salesforce-hosted content that customers only access internally (admin tools, Apex jobs) does not need a custom domain. Heritage applications that the customer is migrating off Salesforce should not have new domains pointed at them. Static marketing pages with no Salesforce data integration are often better served by a dedicated CMS or static-site generator hosted outside Salesforce. The right way to evaluate is to ask whether the site needs Salesforce data, authentication, or business logic. If yes, Sites and Domains is the right setup. If no, the customer-branded URL probably belongs somewhere else in the architecture stack and can save Salesforce-side licensing and operational overhead.
Configure a custom domain end-to-end
Configuring a custom domain in Sites and Domains spans Salesforce-side setup, DNS configuration on the customer's domain provider, SSL certificate provisioning, and final site routing. The workflow below covers a typical Experience Cloud site deployment at a customer-branded URL.
- Register the custom domain in Setup
From Setup, navigate to Sites and Domains and click Add a Custom URL. Enter the full domain name (community.acme.com or whatever the target URL is). Save. The page generates the DNS configuration values you will need: the CNAME target (typically a long Salesforce-specific hostname) and the verification TXT record. Note them down before leaving the page.
- Configure DNS at your domain provider
Log into the domain provider where the org's DNS is managed (Cloudflare, AWS Route 53, GoDaddy, etc.). Create the CNAME record pointing the custom domain to the Salesforce-provided target. Create the TXT verification record at the indicated host name. Save the DNS changes and wait for propagation. Verify propagation using dig or an online DNS lookup tool from multiple geographic locations.
- Provision SSL and verify the domain
Return to Sites and Domains in Setup. Click Verify on the domain. Salesforce queries DNS, confirms the CNAME and TXT records, and provisions the Salesforce-managed SSL certificate. For BYO certificates, upload the certificate file and intermediate chain through the Certificate Manager. Wait for the domain status to show Active. SSL provisioning typically completes within minutes of successful DNS verification.
- Map the domain to the target Experience Cloud site and test
On the Sites and Domains page, attach the new domain to the target Experience Cloud site or Salesforce Sites page. Configure any path-based routing rules. Save. Test the new URL in an incognito browser: confirm HTTPS loads cleanly, no certificate warnings, the right site content appears, and authentication flows work. Test from multiple browsers and devices. Communicate the new URL to the relevant audience (customers, partners, internal users) once everything is verified.
- DNS propagation can take up to 48 hours. Verifying the domain too early returns errors that resolve themselves once propagation completes.
- Salesforce-managed SSL certificates are best-effort renewal. Monitor expiration warnings in the Sites and Domains page anyway.
- Cookies and CSP headers configured on the parent domain do not always inherit to subdomains. Test header behavior explicitly per subdomain.
- Removing a custom domain immediately breaks any URL using it. Coordinate the removal with a redirect or fallback plan to preserve user access.
- Salesforce Sites and Experience Cloud sites have different feature sets despite sharing domain configuration. Pick the right site type for the use case before configuring the domain.
Trust & references
Straight from the source - Salesforce's reference material on Sites and Domains.
- Sites and DomainsSalesforce Help
- Manage CertificatesSalesforce Help
Hands-on resources to go deeper on Sites and Domains.
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 architecture concept is Sites and Domains an example of?
Q2. How does Salesforce's multi-tenant model affect Sites and Domains?
Q3. What does Sites and Domains represent in the Salesforce Platform?
Discussion
Loading discussion…