An Argument for Blog Portability

Wednesday, August 17, 2022

Last week, I published a micro post about my thoughts after reading Matt Birchler admonish his readers against switching blogging platforms. Birchler's main point was that switching platforms made it harder on readers and, therefore, more difficult to retain consistent readership. It's a solid point and one that really resonated with me. I have a tendency to tinker with different tools, some of which are blogging engines. That means I sometimes use different services to publish my posts.

For a while, I've realized moving between domains or services can be confusing for my readers, but I haven't been able to settle on one platform (although I definitely use Micro.blog the most). I've used alternate domains and subdomains to experiment with a variety of different tools.

It's harder than ever to decide on a blogging service because being able to post in a chronological order on a well-designed, easy-to-read site is no longer the only criteria with which to evaluate the service. The situation has been complicated by the arrival of newsletters. While newsletters and blogs used to live separately, they have now merged in a way that makes sense (see Substack as the most popular example of this). As I detailed in this post about writing online, readers now want to be able to receive your writing in different mediums. One of those primary mediums is through email. The others are RSS, the web and social media. It's now an expectation that your work be accessible through all of those channels. Among those delivery mechanisms, Birchler's post seems to only consider the web and RSS. His point is mainly that you should never change your URL or your RSS feed, if you can avoid it. As he says, your readers couldn't care less what service you're using, as long as the experience doesn't change substantially for them.

An email list

Now that I've acknowledged that Birchler's post made a good point and caused me to think, let me play a bit of devil's advocate. When you factor in newsletters, you introduce a delivery mechanism where, theoretically, the service you are using matters even less. In contrast to the web and RSS, where your reader is fetching from your site, with email and newsletters, you are pushing your output to them. This puts less of a strain on your readers to follow you wherever you go. Instead of them having to take action to go with you, they just need to be there for the journey. It takes the burden off the reader and puts it on you to migrate their email addresses to your new location. You're doing all the heavy lifting. The reader may see a different UI, but they should be set up to receive the new content, from wherever it may come.

When I first set up the current iteration of my newsletter, I read this post from Austin Kleon about why you should have an email list of your followers. I gained a few followers just by posting about it. That list is with me, regardless of what service I choose to use, as long as I can import email addresses, like most services allow (ahem, Micro.blog). Since the readers have entrusted me with their email address, if I switch services, the most they will have to do is click on an email that gets autogenerated to consent to be part of a different newsletter provider. If your newsletters include pointers to your blog posts, your readers will have easy access to those posts.

Should I stay or should I go?

Even as I think about the difficulty in getting readers to follow you and then make a change, I realize that there are ways to make it easier on that group of people. It's possible now to put the hard work in the writer's corner, and leave the decision about return on investment up to them. It's empowering, but it takes an explicit call to your followers to trust you enough to share their email and allow you access to their inbox. Hopefully, you have earned that trust through your writing. If so, you should be able to carry your readers along for the ride. Let an email list be the bridge over which you cross to a different blogging platform.