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.