Sadly no, it won’t help in that way either (although that wasn’t the intent).

The lifecycle of a webpage in a browser is something like:

• download page - includes text content, and links to other resources like format, logic (javascript), and images
• start downloading other resources
• render text, and other resources as they arrive
• start manipulating page with javascript, which in this case includes a final step
• download lemmy post and render that, including the post, comments, and a link to the original post.

When google and others crawl the web looking for data to include in search they generally only index content from step 1, so it would only see the parameters passed to LBS (shown as “declaration” in the demo), and would not see anything rendered by LBS.

This is the “static” nature of static sites. The page downloaded by the browser is not built on request, rather it’s only built periodically by the author - usually whenever they have an update or another post. I haven’t posted anything on my blog in months so the pages wouldn’t have been re-built during that time. There are benefits to this strategy in that it’s very secure, very robust, very fast, and very easy to host, but the disadvantage is that any dynamic or “up to date content” (like comments from lemmy) need to be prepared by the client and thus can not be included in step one above and indexed in search.

There is a best of both worlds approach (SSR) where you could render all the comments when a page is originally built, and then update it when the client later renders the page. This means there’s at least something for search indexers to see even if it’s not up to date. The problem here is that there’s a plethora of different engines which people use to build pages and I can’t make a plugin for all or even a few of them.

With all that in mind, this is fantastic feedback, and why I posted this pre-alpha demo. Lots of commenters have said the same thing. I can re-factor to at least make SSR easier.