I keep seeing this pattern. You need a content site, and tools designed for blogging are a straightforward way to create a content site. So, you start a blog, except most posts are evergreen content. Content that you are going to update. Before long, you are updating old blog posts and finding they aren’t very visible, due to how a blog archive is typically structured. You also post some news, and the blog becomes a list of content, some ephemera, and some evergreen; your visitors have no idea which is which. Ultimately you can’t identify which is which.
Rewriting history
News and ephemeral blog posts are valuable. They capture a snapshot in time. I work primarily on technical content, and it’s useful to maintain the paper trail of how a new web platform feature came into being, via the blog posts detailing it. However, what happens instead is people go back and destroy that paper trail by updating the old blog posts because the spec has changed—rewriting history without so much as a note to say what has happened.
If we stop rewriting history, will people then be confused by this old information? Not if news is very obviously news, and other content very clearly not news. The need to update old news posts starts with a technical decision to treat all of your content like a blog.
“News” is the current state of things
Your site can only cover some things fully. You want to be able to comment on things as they are today without committing to keeping that coverage up to date. If it’s unclear whether your content is evergreen or news, you’ll get people pointing out that some commentary needs to be updated. It was valid when you posted it, and important to share, but you don’t have any skin in the game of keeping that information updated. That’s fine if it’s obviously news; it makes you look behind the curve if it appears evergreen.
Identify your content types
If I need to publish content about an emerging API, I need a couple of things. I need reference documentation so that people who want to try it out understand how to use it. This reference is evergreen content, and I will update it as the API changes. It is helpful to have, right up front, information about the last time we updated the content and the version of the spec, or browser to use for testing. I also want to let people know that we’ve shipped this experiment, so I need a news post pointing to my reference material, explaining that this thing is here, and asking people to try it out and give us some feedback. I will not update the news post; what I might do, however, is write another news post when the spec and implementation changes to let people know the progress. These news posts are my paper trail.
If you are concerned that people might happen across those news posts and think they detail the latest version, you can do a few things there. Firstly, if you are treating news as news, you can make sure the blog post page is designed as such to make it clear it’s dated news. Sites that mix news and evergreen content tend to be a bit shy about their dates as it makes the evergreen content look old. If you also have reference documentation or other evergreen content, then you can call that out on each news post. Or, you can link to a tag that will show all news posts about this feature in date order so folk can see the newest one.
Your information architecture should not be defined by how you publish
As an ex-CMS developer, I’m confident that this state of affairs is due to it being technically straightforward to publish a list of blog posts. As a writer, this makes me sad. How we present content to readers should never be defined by the publication tool. Today, most blog tools allow you to publish content other than blog posts. Use that capability. It will mean putting a bit more thought into the information architecture at first. You will, however, see the benefits in terms of clarity to your readers, and in the way you can use your different styles of content.