The Problem: "Just add some content"

A lot of product sites eventually need an SEO boost in the form of rich content like articles. For people already running on a CMS-style system, that's no big deal...but what if you have a bespoke CRM or SASS? The higher ups might assume that "adding a blog" is no big deal (and it isn't), but there's caveats.

First, you can't just throw it on a subdomain. Sorry, but there's a marketing / SEO penalty for that! Also, that means extra overhead -- now you need a blog system, which means actually updating that blog system. Unless you want insecure software riding on a subdomain, that means added engineering overhead...and for platforms like Wordpress, that can translate to a lot of annoyance.

What's frustrating is that this it isn't like you really need a full-on-blog...we're talking about a few simple articles a month. Or maybe we're talking about a scrappy startup or personal project that really can't afford extra hosting costs. We also don't want to install a full on blogging system side-by-side with our actual software...that would be a mess, and we don't want our main app's resources being drained by a freakin' blog.

We can use the static blogger project to easily add this content. In other words, we'll just serve .html files and call it a day.

Fetching via API and Saving to Disk

Using this simple system, we can use our existing WYSIWYG interface to create some articles, then save them to a separate "site" so that my app can fetch them via API. This lets me take advantage of my existing development without all the silly CRUD of a blog system.

It's also fairly primitive. This isn't great for complex blogs that would benefit from a richer set of features. We can deploy it to an endpoint or run it locally, fetching articles from the blogger like this:

const response = await fetch(process.env.BLOG_API_URL);
const articles = await response.json();

Don't screw around with Axios if you don't need to...we'll fetch the articles as JSON, then iterate each article. We can pass the article data to our view engine and save the rendered view to a file. This way, all our customizations and layouts for articles live where they should, specific to the project. I can add as many sites as I want.

// Write each article detail as a file
articles.forEach(async (article) => {
    res.app.render("articles/view", {
        title: article.title,
        data: article
    }, async(err, html) => {                
        const articleFilePath = path.join(__dirname, '../articles', `${article.slug}`);
        await fs.promises.writeFile(articleFilePath, html);
    });
});

Easy enough, yeah? I can use this same idea to also write an "index.html" file to my "articles" folder. I'll need to do that if I want a list of articles. It's also easy to add my site-specific layout or header/footer since all this lives in my project.

Serving the Static Content

The last step is to actually serve the static content. Since we have a specific folder ("articles" at the project root), we can simply do this (in our app.js):

app.use('/articles', express.static(path.join(__dirname, 'articles')));

Now requests to "articles" will resolve.

If you were running the blog system on a public endpoint, you can set up a scheduled job to periodically refresh and publish new content. Or you can simply do this manually.

It's a simple, simple system. Deleting an article requires deleting the actual file, changes are tracked and deployed as code, and there's no dynamic systems like comments (you can use a system powered via client-side JS if you wanted).

Still, for a lot of use cases, it's good enough...and it takes all of a few minutes to integrate.

Why Does Spinning up a Blog Suck...?

Why is it "good enough", though, when it's such a basic system...? Isn't it still better to use something like Wordpress, Drupal, or a Tumblr...?

As I mentioned earlier, the first problem is security, at least for self-hosted solutions like Wordpress. Securing Wordpress is notoriously difficult because of the nature of the plugin ecosystem and because of the fact that WP powers a vast swath of the Internet. Especially if you need to have your blog sharing a root domain with a your app, installing Wordpress is a non-starter.

It's also a performance nightmare, because WP was designed to be flexible, not to scale. You don't want shared compute or database resources afflicting your core business! Throwing it onto a subdomain is usually not a good option, at least that's what SEMs keep telling me.

That said, "headless Wordpress" is a great option if you need a more robust and full-featured system while still having all the advantages of static generation. Headless Wordpress might be something I dive into in more detail soon!

Spinning up a blog on hosted or social media sites is a different beast, and plenty of firms opt for doing that instead of hosting their own content. Not only does this look a little less professional, it doesn't yield the same SEO benefits. Arguably more importantly...you're also authoring content that you no longer own.

AI Will Make Blogging Suck More

As generative AI continues to proliferate, this last point will be more and more critical. It used to be common wisdom that organizations could spin up a blog and write informative articles for SEO, which was mutually beneficial. It contributed some knowledge back to the developer ecosystem and can help surface skilled agencies to potential clients.

People don't write these articles just so Google or GPT can come along, ingest the information, and spit it back out in queries. As we slide deeper into the generative AI era, one big part of why spinning up a blog will "suck" is because the value of that blog is no longer certain. This mutual benefit that came from sharing information and SEO may erode or vanish as more and more information is consolidated around LLMs.

It's already the case that everything written on Reddit now belongs to Google's AI, so this isn't some paranoid stretch of imagination. In a way, this whole article may be destined to become out of date as firms move away from authoring online content in general.

This will become especially true if Google folds more and more AI results into their primary search product, enabling users to "skip" the middlemen and get content directly -- at that point, the SEO benefit for a blog is essentially negative value, since bots can just read your content and spit it back to users without ever seeing the work you did to give this AI the knowledge to begin with. This is one of the many horrible feedback loops that can make AI as a concept slowly implode, dragging down the spirit of the Internet as we know it.

When no one feels there's a vested interest in authoring content to share online, the Internet becomes a lot closer to traditional mass-media where you only get exposure if you're massive...and AI will quickly stagnate as it depends on vacuuming up massive amounts of (pilfered) data.