Sites
Salesforce Sites (originally Force.com Sites) is a platform feature for building public web pages that anyone on the internet can open without logging in. The pages are hosted on Salesforce itself,…
Definition
Salesforce Sites (originally Force.com Sites) is a platform feature for building public web pages that anyone on the internet can open without logging in. The pages are hosted on Salesforce itself, run on a branded company domain, and can read and write the org data you choose to expose.
Sites serve unauthenticated visitors through a guest user. You decide exactly what that guest user can see and do, then publish pages built with Visualforce and Apex. Common uses include lead capture forms, event registration, knowledge lookups, and simple landing pages that feed information straight into your org.
How Salesforce Sites exposes org data to the public
Public pages hosted on your own platform
A Site is a set of web pages served directly from your Salesforce org, with no separate web server to maintain. You register one Salesforce Sites domain for the whole org, then create individual sites under that domain. Each site gets its own default web address, a home page, and optional error pages for situations like authorization failures or inactive sites. Because the pages live on the platform, they can query and update the same records your internal users work with, subject to the access you grant. You can point a custom branded domain at a site so visitors see your company name rather than a Salesforce URL. Sites also support requiring secure connections over HTTPS, which you should keep on for any page that collects input. The pages themselves are usually Visualforce pages backed by Apex controllers, so anything you can build in Visualforce you can publish publicly. This makes Sites a fit for forms, public catalogs, status lookups, and lightweight microsites that need live org data without standing up external infrastructure.
The guest user is the whole security model
Every visitor who has not logged in shares a single guest user per site. That guest user has a profile, and the profile decides which objects, fields, Apex classes, and Visualforce pages the public can reach. There is one guest user record per site, so all anonymous traffic to that site carries the same access level. This design is powerful and easy to get wrong. If you grant the guest profile read access to an object and the sharing settings expose records, every anonymous visitor can see those records. Salesforce sets guest defaults to the most restrictive values on purpose, and you open access deliberately rather than by accident. Treat the guest user like an account that the entire internet can sign into. Grant Read where a page genuinely needs it, deny everything else, and remove access to any object the public pages do not use. Field-level security on the guest profile matters just as much, since a field left visible can leak through a query even when no page displays it directly.
Secure guest user record access and sharing rules
Salesforce enforces a setting called Secure guest user record access that you cannot turn off. With it on, the external org-wide default for every object is forced to Private for guest users, and you cannot loosen that baseline. Guest users cannot join public groups or queues, and you cannot grant them record access through manual sharing or Apex managed sharing. The only supported way to give a guest user visibility into records is a guest user sharing rule. These are a special kind of criteria-based sharing rule, and they can grant Read Only access at most. They also count toward the limit of criteria-based sharing rules per object, so plan them carefully. A guest user sharing rule hands immediate access to every record that matches its criteria, to anyone on the internet, with no login. Before you create one, check the sensitivity of the data and confirm the criteria are tight. This layered model exists because earlier, looser configurations led to real data exposure, and Salesforce tightened the defaults to prevent it.
Enforce CRUD and field-level security in your Apex
Profile permissions are necessary but not sufficient. When a Visualforce page on a Site runs an Apex controller, that controller can query and modify data based on the running guest user context, but Salesforce expects you to enforce object and field permissions in your own code. Standard markup like apex:inputField may not render for the guest user the way it does for internal users, so forms often need explicit field handling. Apex classes used as Visualforce controllers do not require separate access grants, yet the logic inside them still needs to check what the guest user is allowed to touch. Use stripInaccessible, WITH SECURITY_ENFORCED, or explicit Schema describe checks so a public page cannot read or write fields the visitor should never reach. The risk is that without enforcement, a controller method can act with more authority than the page surface suggests. Apps and components enabled for guest access can also bypass the object and field security you set on the guest profile, which is another reason to put the real guardrails in your server-side code rather than trusting the UI alone.
Sites, Site.com, and Experience Cloud
The word Sites covers a few related things, and the naming has shifted over the years. Salesforce Sites (Force.com Sites) is the classic Visualforce-based public site feature described here. Site.com was a separate drag and drop site builder with its own user licenses. Experience Cloud, formerly Communities, is the modern platform for building authenticated and public sites, usually with Experience Builder and Lightning components rather than hand-coded Visualforce. The guest user concept carries across all of them, which is why guidance about guest profiles and sharing applies whether you build with classic Sites or Experience Builder. For a brand-new public site today, most teams reach for Experience Cloud because it offers a richer builder, templates, and stronger guest user controls out of the box. Classic Salesforce Sites still has a place for lightweight Visualforce pages and for orgs that already run on it. Knowing which one a project uses tells you where to configure pages, which licenses apply, and which security settings you are working with.
Licenses, limits, and what to watch
Public traffic is metered, so Sites comes with usage allocations rather than unlimited capacity. Guest user access is governed by guest user licenses, and the number included depends on your Salesforce edition. Developer Edition includes a small allocation suited to building and testing, while paid editions include more for production traffic. Sites usage is measured against page views and bandwidth over a rolling 24-hour period, plus a cap on service request time, and traffic beyond your allocation can lead to pages being temporarily unavailable or to billing for overage. This matters when a public form goes viral or a campaign sends a spike of visitors. Cache pages where you can, keep controllers efficient, and avoid heavy queries on high-traffic pages. Set the Site Contact so notifications about the site reach the right person. Use the inactive home page and authorization error page to give visitors a clean experience when something is misconfigured. Monitoring usage early prevents a surprise outage right when public interest is highest.
Stand up a public Salesforce Site
Create a basic public Salesforce Site that serves a Visualforce page to unauthenticated visitors. You register a domain once, then create and activate the site and grant the guest user only the access its pages need.
- Register your Sites domain
In Setup, open Sites and register a single Salesforce Sites domain for the org. Every site you create lives under this domain, and you can later attach a custom branded domain on top of it.
- Create the site
Click New, then fill in the Site Label, Site Name, and Site Contact. Choose the default web address path, pick the Active Site Home Page (a Visualforce page), and keep Require Secure Connections (HTTPS) on.
- Enable the pages
In Site Visualforce Pages, add every Visualforce page the site should serve. A page that is not on this list returns an authorization error even if the guest profile allows the underlying data.
- Lock down the guest profile
Open the site guest user profile. Grant Read on only the objects a page needs, set field-level security tightly, and remove access to everything else. Add a guest user sharing rule only if a page must read specific records.
- Activate and test
Set the site to Active and open its URL in a private browser window with no Salesforce session. Confirm the page renders, forms submit, and no object or field you did not intend is reachable.
The Visualforce page shown at the site root. Visitors land here first, so it usually carries your main form or content.
Forces traffic over HTTPS. Keep this on for any page that collects visitor input or exposes data.
Controls whether your site pages can be framed by other domains. Tighten it to reduce clickjacking risk on public pages.
A criteria-based rule that grants the guest user Read Only access to matching records. The only supported way to expose records beyond the Private baseline.
- The guest user is shared by every anonymous visitor, so any access you grant is effectively granted to the entire internet.
- Profile permissions alone do not protect data; enforce CRUD and field-level security in your Apex controllers with stripInaccessible or WITH SECURITY_ENFORCED.
- A Visualforce page must be added to the site before guests can load it, regardless of profile access.
- Sites usage is capped by page views, bandwidth, and service request time over a rolling 24-hour window, so plan for traffic spikes.
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Sites.
Hands-on resources to go deeper on Sites.
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 are Salesforce Sites?
Q2. What's critical for Sites security?
Q3. What can Sites display?
Discussion
Loading discussion…