In addition to the recommendations and guidelines published in the Sites Implementation Guide, recommends that you follow these practices to get the best experience out of Sites:

Control Access to Information recommends setting the sharing to private for the objects on which you grant "Read" access for your site. This ensures that users accessing your site can view and edit only the data related to your site. also recommends securing the visibility of all list views. Set the visibility of your list views to Visible to certain groups of users, and specify the groups to share to. List views whose visibility is set to Visible to all users may be visible to public users of your site. To share a list view with public users, create a new public group for those users and give them visibility. If the object's sharing is set to private, public users will not be able to see those records, regardless of list view visibility.

Set cache control on Static Resources to Public. Any static resource - for example, favorite icons, stylesheets, images, etc - you want to expose to your site must be set to public. Remember: static resources are auto-cached for a period of 1 day. So, changes will be reflected on your site one day after you make them.

Carefully manage the pages exposed to your site. If you select a Visualforce page for any of the lookup fields on the Site Detail page, any of the error pages, or the Change Password Page under login settings, that page is automatically enabled for your site. If you remove a page from your site, but it is still selected in one of these places, public users can access that page. To completely remove pages from your site, disable them on your site AND make sure they are not selected in any lookup fields for your site.

Generally speaking, take care to expose only the information you DO want to make public.

Testing Considerations for Sites

Allow sufficient time in project plans for thorough testing. Insufficient testing time can introduce significant risk to the success of your projects.

Be sure to include testing of your site across multiple browser platforms and versions. It is reported that some 10% of internet users still use Internet Explorer 6. So, be sure to test a wide variety of platforms to make sure visitors to your site have a positive experience. recommends that you use a Developer Sandbox environment to build and test your sites prior to deploying to production. When you are ready to deploy, you will need to manually re-create your site on production. However, all of the supporting assets, e.g., Visualforce Pages, Apex Classes, and Static Resources, can be deployed to production with the IDE, using the Migration Tool, or the Metadata API call deploy.

Caching, Performance, and Daily Limits Sites imposes two daily limits, i.e., 24 hour rolling limits. These limits depend on the organization type as follows:

Organization Type Bandwidth Limit (per day) Service Request Time (per day)
Developer Edition 500 MB 10 minutes
Sandbox 1 GB 30 minutes
Production 40 GB 60 hours

The limits govern

  1. Volume: Total number of bytes of data in and out of your site, and
  2. Request time: Total amount of time spent to generate pages on the server side.

When a site reaches one of these limits the site will display the Limit Exceeded error page. Even though these limits are set very high for active orgs, high traffic or pages requiring heavy bandwidth or long processing time may cause a site to reach one of these limits within a given 24 hour period. However, you can virtually increase these limits by leveraging the caching functionalities provided for you. Sites seamlessly integrates with one of the leading Content Delivery Network (CDN) vendors to allow you to cache your pages all around the world for a duration that you can set. CDN integration not only improves your global reach (more than 40,000 servers all around the world) but it also provides your customers satisfaction by serving content to your end users from the closest location to them.

You can simply decide which pages will be cached and for how long. When a page in cache expires, the CDN system will retrieve the latest version of the page from your organization via the fastest route by leveraging its special traffic optimization logic. To enable a Visualforce page for caching, use the following page declaration:

<apex:page cache="true" expires="600">

The following table explains the cache related parameters and the default system behavior:

Attribute Name Description
cache A Boolean value that specifies whether the browser should cache this page. If set to true, the browser caches the page. If not specified, this value defaults to false.
expires An Integer value that specifies the period of cache in seconds.

By default, caching is set to false so each request counts against request time limit and bandwidth limit.

Warning.png Note that the CDN integration is only valid for active, production orgs. Sandbox orgs, Prerelease orgs, and Developer Edition orgs do not have CDN integration.

Warning.png To protect the integrity of sensitive information, SSL (secure) sessions and pages requested after authentication (login) are not cached via CDN.

Warning.png In order to use static resource on public sites you need to set the Static Resource “Cache Control” attribute to “Public”. Public static resources are auto-cached for a period of one day. However, when you update a static resource the URL for the static resource will have a new time stamp so the new version will be picked up and cached automatically.

Proper schema design is one of the key factors on performance of high traffic Web sites. recommends that you

  • index the fields you intend to use for search, and
  • avoid the use of long text fields in your schema because these fields are stored in a separate table and therefore negatively impact performance.

Additionally, recommends that you consider storing large audio and video files you want to access on your public sites on a 3rd-party system to avoid daily bandwidth limit restrictions.

Governor Limits

Be mindful of governor limits for Apex classes associated with your public sites. An Apex class confined to an internal application may experience considerably less load than one exposed on a public Web site. Test your code thoroughly and with realistic numbers of records and queries to make sure it does not exceed any of the limits.

Limit query results and avoid the use of count queries to keep your Apex scripts within limits.

You may want to employ governor limit email warnings for your site to get a warning any time an end-user invokes an Apex script that surpasses more than 50% of any governor limit. To enable email warnings:

  1. Log in to Salesforce as an administrator user.
  2. Click Setup | Manage Users | Users.
  3. Click Edit next to the name of the user who should receive the email notifications.
  4. Select the Send Apex Warning Emails option.
  5. Click Save.

Site Security recommends that you use CAPTCHA for public form submissions to avoid spam. The code sample is available on the Developer Community.

Custom Web Addresses

You can map your standard company URL to your Sites Domain Name with a 3rd-party domain name registrar.

Use the Custom Web Address field to set the alias to your address.

To enable a custom Web address, create a CNAME record with a registrar like Network Solutions or Go Daddy. The CNAME record that you provide to that registrar must be your domain name and not the site URL. For example, if you entered "mycompany" when registering your domain, the CNAME must be, not the full value of the site URL.

If you have not registered this address with a registrar, entering a value in the Custom Web Address field has no effect.

Warning.png Remember: you must create a CNAME record with a 3rd-party registrar AND populate the Custom Web address field in order for this feature to take effect.

Warning.png CNAME mapping to your domain may take up to 24 hours to take effect.

Warning.png Custom Web addresses are not available in Developer Edition or Sandboxes.

Availability During the Maintenance Windows

Because Sites are directly served from customers’ Salesforce organization, Sites availability is directly related to their Salesforce org’s availability and up time. For all major releases, customers’ Salesforce orgs and Sites will be unavailable during the org’s release maintenance window. During the maintenance window, Sites end users will see a branded maintenance page when they try to access the site via HTTP.

You should work with your customer to ensure they have a communication strategy for informing end users, as well as any other Salesforce stakeholders, of the release maintenance windows and related Sites unavailability.

Visit to understand the specific maintenance windows by instance.