Skeleton Template
A Skeleton Template in Salesforce is a bare page structure that supplies only the outer framework of a page, such as the HTML, head, and body tags, with no built-in Salesforce header, sidebar, navigation, or default styling.
Definition
A Skeleton Template in Salesforce is a bare page structure that supplies only the outer framework of a page, such as the HTML, head, and body tags, with no built-in Salesforce header, sidebar, navigation, or default styling. Developers reach for it when they want full control over the markup and design of a page rather than inheriting the standard Salesforce chrome.
The idea shows up in two older places. In Visualforce, you build a skeleton by turning off the platform UI and stylesheets on the apex:page tag. In the legacy Site.com builder, a page template defined the reusable shell, and a near-empty template acted as the skeleton starting point. Both approaches predate Lightning Web Runtime and Experience Builder, so the term is treated as legacy today.
How a skeleton page is built and where it fits
What "skeleton" means on the platform
A skeleton template is the opposite of a fully themed page. Instead of inheriting the Salesforce header, the left sidebar, the global search bar, and the standard stylesheets, a skeleton page gives you a clean shell and nothing else. You decide every tag, every class, and every line of CSS. The point is total control, which matters when a design has to match an external brand or a pixel-perfect mockup that the standard chrome would fight. In Visualforce, the skeleton is not a separate file type you pick from a list. You create an ordinary Visualforce page and then strip the platform UI off it using attributes on the apex:page tag. The result still runs on the same Visualforce engine, with the same controllers and expression syntax, but it renders almost like a hand-written HTML page. This pattern was common for public-facing pages, custom login flows, print views, and embedded widgets where the Salesforce look and feel was a liability rather than a help. The trade is effort. A skeleton hands you a blank canvas, so you also own accessibility, responsive behavior, and cross-browser quirks that a themed template would have handled for you.
The Visualforce attributes that strip the chrome
You turn a normal Visualforce page into a skeleton with five attributes on apex:page. showHeader controls the Salesforce tab header and defaults to true, so you set it to false. sidebar controls the left navigation column and also defaults to true. standardStylesheets decides whether the standard Salesforce CSS is added, and it defaults to true even when showHeader is false, which surprises people. To get a truly bare page you set standardStylesheets to false as well. Two more attributes go further. applyHtmlTag and applyBodyTag both default to true and tell Visualforce to generate the outer html and body tags for you. Set them to false when you want to write those tags yourself, which is the most skeletal form of all. A fully stripped page often looks like apex:page with showHeader, sidebar, standardStylesheets, applyHtmlTag, and applyBodyTag all set to false. The official Visualforce guide warns that the standard Salesforce stylesheets can change between releases. So a page that leans on platform CSS may shift in appearance after an upgrade, which is one more reason a skeleton page provides its own styles instead.
Skeleton versus apex:composition templates
Visualforce has a second, related sense of the word template that is easy to confuse with a skeleton. The apex:composition component lets one page define reusable layout regions with apex:insert, while consuming pages fill those regions with apex:define. That is a content templating model, closer to inheritance, and it is great for sharing a common header and footer across many pages. A skeleton template is a different goal. It is about removing structure, not sharing it. You can absolutely combine the two: a stripped-down apex:composition template with no Salesforce chrome becomes a skeleton shell that child pages extend. But the two ideas answer different questions. Composition asks how do I avoid repeating layout markup. The skeleton asks how do I get the platform out of my way entirely. In practice, teams often started with a skeleton page for a one-off custom screen, then graduated to apex:composition once several pages needed to share the same bare shell. Understanding that split keeps the vocabulary straight when you read older Visualforce code or design docs that mention both.
The Site.com and Experience Cloud lineage
The other home of the skeleton idea was Site.com, the older site-building tool that became the foundation for early Salesforce Communities. In Site.com you created page templates that defined the reusable shell of a site, including header, footer, navigation, and named layout regions. A template with almost nothing in it served as the skeleton: a structural starting point that individual pages inherited and then filled with panels and content blocks. That model carried into the first generation of Community and Experience Cloud sites. When you build a site in Experience Builder today, the equivalent move is choosing New Blank Page and picking a fixed or flexible layout instead of a preconfigured page. The blank page is the modern descendant of the skeleton template idea, even though the underlying technology is now Lightning Web Runtime or Aura rather than Site.com. Because Site.com page templates and Visualforce-based community containers are older approaches, anyone maintaining them should plan a path toward Experience Builder and component-based theme layouts, which receive new features each release.
When a skeleton is the right call
A skeleton page earns its keep when the standard Salesforce UI actively gets in the way. Public knowledge pages, branded microsites, custom guest-user flows, print-friendly invoices, and pages embedded in an iframe inside another product all benefit from a clean shell. In those cases the header and sidebar are dead weight, and the standard stylesheets clash with the design you actually want. It is the wrong call when an existing template would do. If you only need a custom screen inside Salesforce that looks native, keeping showHeader and the standard styles on is far less work and stays consistent with the rest of the org. Building from a blank shell means you re-create spacing, fonts, focus states, and mobile breakpoints by hand, and you own every accessibility detail. Seasoned teams use skeletons sparingly and document why. A good rule is to default to a themed page or a preconfigured Experience Builder layout, and only drop to a skeleton when a concrete requirement, like external branding or an embed, forces the issue.
A worked example: a bare public page
Picture a company that wants a standalone status page hosted on a Salesforce Site, with its own logo and colors and no hint of the Salesforce interface. A developer creates a Visualforce page and sets showHeader, sidebar, and standardStylesheets to false so the platform chrome and CSS disappear. To control the outer document precisely, they also set applyHtmlTag and applyBodyTag to false and write their own html, head, and body tags. Inside that shell they pull in a static resource for the brand CSS and a custom controller that queries the latest status records. The page now renders as a clean, branded document that happens to run on Visualforce. Nothing about it looks like Salesforce, which is exactly the requirement. If a second and third page need the same bare frame, the team refactors the shell into an apex:composition template and has each page define its own body content. The skeleton concept scales from a single custom page into a small framework, all without ever inheriting the standard Salesforce header or stylesheets that the brief ruled out.
How to build a skeleton Visualforce page
There is no "Skeleton Template" object to create. You build a skeleton by turning off the platform UI and styles on a Visualforce page. These steps produce a bare page you fully control.
- Create a Visualforce page
In Setup, open Visualforce Pages and click New, or use the Developer Console. Give the page a name and start with a single apex:page tag. At this point it still shows the Salesforce header and standard styles.
- Turn off the header, sidebar, and standard stylesheets
On the apex:page tag set showHeader to false, sidebar to false, and standardStylesheets to false. Setting standardStylesheets to false matters because the standard CSS is still added when only showHeader is false.
- Take over the outer html and body tags
For a fully bare shell, set applyHtmlTag and applyBodyTag to false, then write your own html, head, and body markup inside the page so you control the document head and language attributes.
- Add your own styling and logic
Reference a static resource for your CSS, and wire up a custom controller or controller extension for data. Test the page as the audience that will use it, including guest users on a Salesforce Site if it is public.
Set to false to remove the Salesforce tab header. Defaults to true.
Set to false to remove the left navigation column. Defaults to true.
Set to false so the standard Salesforce CSS is not injected. Defaults to true even when showHeader is false.
Set both to false to write the outer html and body tags yourself for a truly minimal shell. Both default to true.
- Setting only showHeader to false still pulls in the standard stylesheets. You must also set standardStylesheets to false for a clean page.
- The Visualforce guide warns that standard Salesforce CSS can change between releases, so a page that depends on it may look different after an upgrade.
- A blank shell means you own accessibility, responsive layout, and cross-browser behavior that a themed template would have handled.
- For new public sites, prefer an Experience Builder blank page or theme layout over a Visualforce skeleton, since the component model gets new features each release.
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Skeleton Template.
Hands-on resources to go deeper on Skeleton Template.
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 is a Skeleton Template?
Q2. When should you use one?
Q3. What's the trade-off?
Discussion
Loading discussion…