Site.com
Site.com was a Salesforce drag-and-drop web content management system used to build branded, dynamic websites hosted on the Salesforce platform without writing code. It targeted marketing teams and…
Definition
Site.com was a Salesforce drag-and-drop web content management system used to build branded, dynamic websites hosted on the Salesforce platform without writing code. It targeted marketing teams and admins who needed public-facing pages tied to Salesforce data but did not have web developers on hand.
Salesforce retired Site.com as an actively developed product line and folded its core capabilities into Experience Cloud (formerly Community Cloud). Sites built on the original Site.com runtime are still supported on existing orgs, but no new investment goes into the platform. New public-facing site projects should be built on Experience Cloud's LWR (Lightning Web Runtime) or Aura template, not on Site.com.
Site.com in 2026: history, migration, and where the platform still appears
What Site.com was originally built to do
Site.com launched as Salesforce answer to the standalone CMS market in the early 2010s. The pitch was a drag-and-drop visual page builder that let marketing teams build landing pages, microsites, and public pages bound to Salesforce data without involving the IT team or external web developers. Pages were composed by dragging components onto a canvas, binding them to data sources (Custom Objects, Reports, Knowledge Articles), and publishing to a Salesforce-hosted domain. The original Site.com aimed at the lightweight microsite use case rather than full enterprise web properties, so the feature set focused on speed of authoring rather than deep customization.
The shift to Experience Cloud and what changed
Salesforce rebranded Community Cloud as Experience Cloud and over several releases consolidated the Site.com page builder, the Communities builder, and the standalone microsite builder into a single Experience Builder experience. The motivation was to give customers one product to learn rather than three overlapping ones. Site.com pages did not move automatically; existing Site.com sites continue to run on the legacy runtime, but new builds go to Experience Cloud. The visual builder, the component model, and the publishing flow are similar enough that the learning curve is small, but the underlying metadata is different and Site.com configurations cannot be exported into Experience Cloud directly.
The Site.com runtime and where it still appears
Sites built on the original Site.com runtime continue to serve on the Salesforce platform. Each site is associated with a Site.com record in Setup, has a custom domain or salesforce.com subdomain, and uses the original Site.com page builder for any edits. Salesforce continues to apply security patches and platform-level fixes, but no new components, design improvements, or UX changes ship to the Site.com runtime. If you are inheriting an org that still has live Site.com pages, treat them as a known migration target rather than an active platform to invest in.
Migration path to Experience Cloud
There is no automated migration tool from Site.com to Experience Cloud. Migrating a Site.com site means rebuilding it in Experience Builder using the equivalent LWR or Aura template. The work breaks down into four pieces: rebuild the page structure in Experience Builder, recreate the data bindings against the same Salesforce records, rebuild any custom Visualforce pages or components as Lightning Web Components, and remap the URL paths so external links do not break. Plan a Site.com to Experience Cloud migration as a quarter-long project, scoped per site, with a freeze window for both old and new while you run a parallel test under a different domain.
Hosting, DNS, and what stays on the Salesforce side
Site.com sites are hosted on Salesforce-managed infrastructure with a default subdomain (sitename.secure.force.com or similar). Custom domains require a CNAME pointing to the Salesforce domain along with a Salesforce-managed TLS certificate. Migrating to Experience Cloud lets you keep the same custom domain by repointing the CNAME at the new Experience Cloud endpoint. SEO and link equity transfer if the new URL paths match the old ones; if they do not, set up server-side 301 redirects through a Salesforce Site redirect rule or through the Experience Cloud URL routing configuration. Plan the DNS cutover for a low-traffic window to minimize the risk of partial propagation issues during the swap.
When you still encounter Site.com knowledge in 2026
Most large orgs that adopted Site.com in the 2014 to 2017 wave have either migrated or are in mid-migration. You still see Site.com in three contexts. First, mature orgs with low-traffic microsites that nobody has prioritized for migration. Second, ISV-supplied managed packages that bundled Site.com pages, which require the ISV to publish an Experience Cloud equivalent before customers can move off. Third, certification material: the Platform App Builder and System Architect exams still include Site.com questions for historical context. Treat the term as legacy knowledge: useful for understanding existing orgs and for the cert exam, but not a target for any new build in 2026 or beyond.
Migrating a legacy Site.com site to Experience Cloud
Building new Site.com sites is no longer the right path; the actual operational task in 2026 is migrating an existing Site.com site to Experience Cloud. The migration is a rebuild rather than an export-import: you recreate the site in Experience Builder, point your custom domain at the new endpoint, and set up redirects for any URL paths that change. The work is mostly straightforward but the scope is per-site, so plan it as a sequence of quarter-long projects rather than one big-bang cutover across every site at once, and stage the order by traffic, business risk, and dependency on ISV-shipped components.
- Inventory the existing Site.com site
Document every page in the existing Site.com site: page title, URL path, page-level components, data bindings (which Salesforce objects feed the page), custom Visualforce or Apex extensions, and any external integrations. Capture screenshots of each page in the existing branding so the rebuild has a visual reference. Also note the current SEO performance, any tracked KPIs, and the user populations who depend on the site. This inventory is the source of truth for the migration scope and the comparison baseline you use to confirm the rebuild matches the original before cutover.
- Build the equivalent site in Experience Cloud
From Setup, All Sites, click New, pick the LWR template for a modern microsite or the Aura template if you need legacy customization. Set the site name, the URL prefix, and the timezone. In Experience Builder, recreate the page structure from the inventory, drag in equivalent Lightning Web Components for each Site.com component, and bind them to the same Salesforce records. Use the design tokens to match the original branding. Build the pages in order of traffic so the highest-value pages get the most QA time before cutover.
- Set up redirects for changed URL paths
Every URL that changes between Site.com and Experience Cloud needs a 301 redirect. List the old paths and the new paths in a spreadsheet, then implement the redirects either through Salesforce Site redirect rules or through Experience Cloud URL routing configuration. Test each redirect manually before going live. SEO link equity depends on these redirects staying in place for at least a year, so document them in the org knowledge base. Search Console will report any 404s that show up after cutover, so monitor it daily for the first two weeks post-migration.
- Cut over DNS and decommission Site.com
On the day of cutover, repoint the CNAME from the Site.com endpoint to the Experience Cloud endpoint, confirm the TLS certificate validates against the new domain, and run smoke tests across all pages. Keep the old Site.com site live for 30 to 60 days as a fallback in case rollback is needed. Once the new site has been stable for a quarter and SEO traffic has normalized, deactivate the Site.com site through Setup and archive the metadata. Update internal documentation and any third-party integrations that referenced the old URL.
- There is no automated Site.com to Experience Cloud migration tool. The migration is a manual rebuild; budget for it as a quarter-long project per site, not a weekend cutover.
- Site.com is in maintenance mode. Security patches still ship; new components and design improvements do not. Building new functionality on Site.com is a dead end you will have to redo on Experience Cloud later.
- Custom Visualforce pages and Apex extensions used by Site.com pages have to be rewritten as Lightning Web Components for Experience Cloud, since Aura and LWR do not embed Visualforce the same way.
- DNS cutover is the riskiest step. Schedule it for a low-traffic window, validate the TLS certificate before flipping the CNAME, and keep the old endpoint live for 30 to 60 days as a fallback for rollback.
- ISV-supplied managed packages may include Site.com pages. You cannot migrate those pieces yourself; wait for the ISV to publish an Experience Cloud equivalent or replace the package entirely.
Trust & references
Straight from the source - Salesforce's reference material on Site.com.
- Experience Cloud OverviewSalesforce Help
- Experience Builder OverviewSalesforce Help
- Lightning Web Runtime TemplateSalesforce Help
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 was Site.com?
Q2. What replaces it?
Q3. Should you use Site.com for new work?
Discussion
Loading discussion…