Raivo Laanemets. Software consultant.

Losing your readers with a migration to a static blog generator


I read lots of blogs and I have noticed that many of them have migrated to a static site generator recently. The most popular static site generator seems to be Jekyll which also powers GitHub Pages. Static site and blog generators have many benefits, however, they do not come without downsides.

Advantages

  • Security - SQL injection/XSS/remote code execution/etc is not possible.
  • Reliability - file serving is less likely to break with server upgrades than a PHP/WordPress/Ghost/etc application that depends on installed binaries and databases.
  • Maintainability - you can let HTML files stay on the server without having to upgrade any binaries or application code on the server.
  • Performance - serving plain files is optimized to death.
  • Simpler deploy - static files can be uploaded using rsync or even FTP.
  • Simpler backup of the site - files can just be copied, there is no database to worry about.
  • Use of Git or similar version control software for tracking changes. When using Git, pushing to a remote repository could be also used for deploying.

Disadvantages

  • Editing and tooling complexity is pushed to the writer's computer.
  • Harder backup of the source files - you need to take care of regularly backing up your computer's hard drive unless you upload your original files along with the generated HTML files.
  • Support for comments requires a third-party service such as Disqus.
  • Every change requires deploying.
  • HTTP-level static and dynamic redirects might not be supported.
  • RSS or Atom feed support might not be provided out-the-box.

The last two disadvantages affect your readers who subscribe using the RSS or Atom feed. In the case of blog migration, without support for redirects you would lose readers who cannot retrieve any new posts by the old feed URL.

Some static site generators do not support feeds at all. For Jekyll it depends on the site template whether it is supported or not.

How to properly redirect feeds

There is the RSS Autodiscovery mechanism to indicate the feed URL in the page's <head> element. However, in most (all?) feed readers it is only used for finding the feed URL when the site is added to the reader. The feed URL is then stored and not updated later. When the feed URL actually changes, a redirect must be provided.

Redirects must be done using the HTTP Location header or by rewriting the URL internally on the server. An Refresh meta tag cannot be used. Neither will work JavaScript-based redirects. I have seen a JavaScript-based used on one of the blogs that I read. In that case the redirect was later properly implemented by using the HTTP redirect after letting the blog owner know about it. A good guide for implementing redirects on an Apache or an Nginx web server is here.

GitHub Pages

GitHub recommends to use the jekyll-redirect-from plugin. This will not work for feeds as it uses the Refresh meta tag. A more clever solution has to be created for GH Pages, possibly by saving the feed file into a path that mimics the original feed URL.

FeedBurner/FeedProxy users

FeedBurner and FeedProxy provide statistics about your feed readers by having the feed proxied through their system (your blog then needs to refer the URL on their server). These services used to be quite popular some years ago and I currently have 3 out of 10 blogs using these in my subscription list. I'm still not exactly sure what happens with feeds served through these services once the original source goes down or starts returning 404 errors. I'm afraid that you will only get the last state of the feed before the source went down. This means the reader won't even get an error message indicating that something is wrong with the feed. I do not know whether you can update the original feed URL on these services but if you can then it provides a transparent switchover to the new URL.

No effective RSS or Atom alternative

While RSS/Atom newsfeeds are an old technology (RSS 0.91 is from 1999), there are no viable alternatives. RSS/Atom are provider-neutral and do not require you to have Tumblr/WordPress/Blogger/Medium/etc accounts just to receive updates from the blogs you find interesting. It is also insanely more scalable than checking updates manually on hundreds of blogs. Checking 1000 blogs once per week would take 16 hours assuming you spend about 1 minute per blog. I follow about 700 blogs and like to receive updates more frequently than just once per week. Please keep the feeds working :)


Comments

No comments have been added so far.

Email is not displayed anywhere.
URLs (max 3) starting with http:// or https:// can be used. Use @Name to mention someone.