The point here is NOT to have the site-generator (SSG) create complete index/overview pages that would then include all the titles+summaries, but instead to understand a <!--#include ...>, parse the document it points to, and be able to use the metadata for generating its indexes, tag clouds, or whatever BUT not include the document itself.
So the SSG will understand and use the per-page metadata to generate index-type pages but actual inclusion of content is delayed until it is requested from the web-server.
Because I have covered a huge number of categories over the years and many pages will be included in multiple indexes/overviews/tag-clouds, I do not want multiple index pages with copies of the same text.
One way is to maintain 2 sets of files: a normalized one with no redundancies and just references, and another one with everything fully rendered and expanded. That second set is what you serve (bonus: it will be fully static); the first set is what you edit/maintain/search.
This is essentially a handmade caching system for your content.
Once you approach the problem that way, you can also consider other forms of caching, like having a dynamic, server-side generated site and a cache store sitting in front of it. That cache store can be some fancy caching system or it can be the output of a crawler than runs once a day against your dynamic site and outputs to a set of static html files that get served by your webserver.
Thanks - that may be a way to deal with my hybrid requirements; I have to make the solution work with a 30 year legacy of existing pages that make use of apache functionality in various ways.
Whatever I do has to apply incrementally as I (slowly) transfer everything into the new SSG controlled repository.
Normalised is definitely where I want to be for the canonical representation.
I guess there'd be two canonical representations actually; the SSG 'source' and the normalised hybrid HTML+SSI.
Yes; initially that was what I was, and still am, considering.
I hesitate because some of my existing content uses mod-include and other apache httpd functionality in different ways for different purposes.
I considered segmenting the site so some parts are cached/proxied using SSR (Server Side Rendering for those that wonder) but then I'm introducing artificial barriers that in the future I may forget are there and trip over whilst trying to throw some quick PoC or demo up.
So the SSG will understand and use the per-page metadata to generate index-type pages but actual inclusion of content is delayed until it is requested from the web-server.
Because I have covered a huge number of categories over the years and many pages will be included in multiple indexes/overviews/tag-clouds, I do not want multiple index pages with copies of the same text.