Template .html (also .css, after a small rewrite to catch up with latest good practice) defined in one place. Had bits like "%TITLE%", "%NAVBAR%" and "%CONTENTS%" in appropriate parts of that template. A page 'directory' (.csv) defined and pointed at various Content pages in basic sub-<BODY> HTML, but with a few more %TAGGED% imperatives for special uses (like embedded images, intending to make it that part foolproof for others).
My basic Perl script backend thus served all pages asked ofnthe site by checking the actual called URI for the page the user thought she was getting staticly (could also handle the differentiation necessary if I had multiple domains pointing at the same hosting space for different purposes, but never did use that in anger), and ensuring a valid Directory entry (or custom 404ed/adjusted/30whatevered the reply), followed the Directory details to load in the appropriate Content, thenrecursively resolving all %TAG%s along the way until there were no such directives left to follow.
i. e. as well as putting the obviously dynamic 'centre page' option, it added the perfectly accurate Navbar (expanded with details of all Directory-listed pages indicated in there as permanently visible, plus the branch containing the potentially obscure page we were now on and any sub-pages of our current page that were available and not counterindicated as to be kept hidden) in its own Tag area. Then there was the "now and upcoming" calendar array (a custom-markuped page was the source for that mimi version and the full calendar page) on the opposite margin that got created upon the fly to show this and the next two months of events, and it also grabbed weather data from an external site to <MARQUEE> along the bottom (tacky and retro, I know, but it did the job as long).
For Gallery pages (marked specially in the Directory list) it sought all images (e.g. image.jpg) appropriate to that version of the page, presented the (separately created, rather than automatic on-server as is done these days) image.thumb.jpg as a minilink to the main image file, subtitled that with the comment and date info stored in the image.txt (and the actual size ofnthe destination file, for the sake of Dial-Up users), sorted and arrayed howsoever the called page saw fit (e.g. "by date, descending, four columns, second page of twenty images"). Though that's done so much easier, apparently, these days with Reactive HTML methods, I hear..
The News Items pages did something similar with 'news snippets' filelets (ordering, annotating, summarising, adding 'source' info, but I did that with a %TAG(foo)% thing rather than Directory guided, because I'd hacked that feature in first and come at the galleries from a different direction later on. Still, worked Ok and the code for both was brief enough, so if it aint broke...
I ended up doing most of the administration myself, in the end, manually uploading the added/altered filegsnippets straight into their homes with FTP (and also any updates to the backend script that I'd tested on my home machine), so the 'live' editing feature never really got used enough to refine it into anything useful, like a Wiki-editing engine. Realistically, I could just have just scripted the creation of all the static pages, offline, then uploaded these as a regular static site (at least before the image-sorting, possibly the calendar could have been <IFRAME>ed from a mini CGI, and the weather-marquee definitely would have been) with consistent and accurate sidebar because they'd all been created from scratch even after each page-tree alteration had been made necessary. But the dream was always to let several others add bits and pieces. With me at hand just to keep the look basic and clean, not YvettesBridalFormal-like..