.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
SSI (Server Side Includes) is the old Apache trick where the web server assembles a page from fragments before sending it: one shared header file, one footer, included into every page with a single comment-looking tag. It predates every framework you've heard of and it still works on any cPanel server, which is exactly why people keep searching for how to enable SSI on a cPanel domain. Two minutes of setup, no build step, no PHP. Here's the whole thing.
Is SSI the right tool in 2026? For a plain HTML site where you're tired of pasting the same nav into 40 pages, yes, honestly. It's zero-maintenance and fast. For anything bigger I'd point you at a static site generator instead, but I have client sites running SSI for a decade with no complaints, so I won't pretend it's obsolete.
Option 1: Enable SSI in .htaccess
Open cPanel » File Manager, go to public_html and edit the .htaccess file (Settings » Show Hidden Files if it's invisible; create the file if it doesn't exist). Add these lines:
AddType text/html .shtml
AddHandler server-parsed .shtml
Options +IncludesLine by line: the first tells Apache to serve .shtml files as normal HTML, the second sends .shtml files through the SSI parser and the third switches the includes feature on for this directory and everything under it. Save the file. That's the entire installation.
Precision matters in .htaccess; a stray character in this file throws a 500 error across the whole site. If the site dies the moment you save, you'll know exactly which file to fix. Misplaced PHP overrides in the same file fail the same way, a trap covered in the guide to increasing the max upload size in cPanel.
One host-specific note: some servers refuse Options +Includes in .htaccess (you'll get a 500 with "Options not allowed here" in the error log). That means the server admin restricted overrides, and on shared hosting your move is a support ticket. On your own VPS you'd loosen AllowOverride for the vhost instead.
Option 2: Use the Apache Handlers screen in cPanel
cPanel has a small UI for the same handler under Advanced » Apache Handlers. Add a handler with:
Handler: server-parsed
Extension(s): .shtmlThis writes the equivalent AddHandler line for you. You may still need Options +Includes in .htaccess depending on the server's defaults, so if includes don't parse after adding the handler, add that one line manually. I use the .htaccess route anyway because everything sits in one visible file instead of being split between a UI and a dotfile.
Write your first include
Make a folder for the fragments, say public_html/includes/, and drop a header.shtml in it containing your nav markup. Then in any page, include it like this:
<!--#include virtual="/includes/header.shtml" -->The syntax is picky in two famous ways. There's no space between <!-- and #include, and the space before the closing --> is required. Get either wrong and the directive is treated as an ordinary HTML comment: no error, no output, just silence.
Rename the pages that use includes from .html to .shtml, since that's the extension we registered. Update your internal links accordingly. SSI also gives you a few small dynamic goodies beyond includes:
<!--#echo var="LAST_MODIFIED" -->
<!--#config timefmt="%d %B %Y" -->
<!--#echo var="DATE_LOCAL" -->Last-modified stamps and dates cover most of what people used SSI for beyond layout. The full directive list is in the Apache SSI howto, and the module reference lives at mod_include.
Parsing .html files without renaming (and why I don't)
You can point the handler at .html itself:
AddHandler server-parsed .htmlNow every HTML file on the domain goes through the parser, renames avoided. The cost is that Apache parses everything, including the hundreds of pages with no directives in them. On a small site the overhead is real but tolerable; on a busy one it's waste. Apache's XBitHack directive offers a middle path (parse only .html files with the execute bit set) but it confuses everyone who inherits the site later. Renaming to .shtml is the boring answer and boring wins here. If you already have inbound links to .html URLs, add redirects in .htaccess rather than losing them.
Verify it worked
Create test.shtml in public_html containing a text line plus <!--#echo var="DATE_LOCAL" --> and load it in the browser. Server date rendered: SSI is live, delete the test file. Raw directive text visible in the page source: the handler isn't registered for that extension (check spelling of "server-parsed" and the file's extension). The literal message [an error occurred while processing this directive]: SSI is working but your include path is wrong; the virtual path is relative to the document root, so /includes/header.shtml means public_html/includes/header.shtml.
Two security notes worth thirty seconds. Keep #exec cgi out of your pages (most hosts block it with IncludesNOEXEC anyway); if a page needs to run programs you've outgrown SSI. And don't let visitors upload files into a directory where includes are enabled, because an uploaded .shtml executes directives with your site's permissions.
Modest as it is, SSI plus AutoSSL plus a basic web hosting VPS is a complete stack for the brochure-site tier. We still see plenty of these on cPanel VPS accounts, quietly outliving several JavaScript frameworks apiece.
