Recently I’ve noticed that some of the RSS feeds I subscribe to have become more and more restrictive. A post might contain just a title, or perhaps a short snippet or introductory paragraph, with the expectation that I then proceed to follow the link to visit the website itself in order to view the post in full.
I suppose in many ways that this is similar to distributing podcasts via RSS: the feed contains the podcast title, description, and other metadata, and then a link to download the podcast episode file itself. But this is because podcasts are in audio or video format and cannot be reasonably embedded directly into an XML file.
But blog posts and articles are primarily text, for which XML is perfect for transferring.
Most of the examples I’ve seen are commercial news outlets that probably still make (at least some) income through selling adverts. Although I still disagree with this (we all use ad-blockers anyway), in these cases they have a business objective to get you to their website for their own analytics and to drive their revenues.
However I have seen some personal text blogs and non-commercial outlets doing the same thing, and if this is intentional I just wonder what the motivation is. Maybe it’s for site analytics? Or maybe the author is worried about the size of the feed’s XML file getting too large?
If you need analytics of subscribers the author can simply log basic request info to their feed’s XML file download. To prevent the XML file from getting too big authors can simply limit the feed to the most recent n posts.
Either way, there are a number of good reasons for allowing your subscribers to retrieve entire post contents in their feeds.
Client familiarity
Many people use a familiar client to consume blog posts and articles. For example, I use Reeder, which has a fantastic interface that makes reading posts and content very enjoyable. It uses a great readable font, displays images beautifully, respects my system’s dark/light theme, and much more.
Other people might enjoy different clients, but the point is that this makes the experience consistent across feeds. Therefore, consuming the content is much quicker and feels more natural. If I have to visit your website to view the article then I have to find where the content starts on your particular site, deal with whatever font and colours you choose and have inconsistent layouts across my different subscriptions.
I often read posts on my phone, and if your website is non-responsive to smaller screen sizes then this is a massive pain. In general, reading your posts via a client is much less invasive on my time and I can concentrate on actually enjoying the content.
Clients can also make use of accessibility features (like screen readers) in order to make your post available to a wider audience.
Caching
When my client refreshes the feed it downloads all the latest unread posts (as well as storing previously-read ones). This means that if I am about to take a flight or get on the tube I know I will have lots of interesting content to read whilst my phone is out of the network’s reach.
However, if I have to visit your website to view the post then it simply can’t be read. By the time I’ve landed the title has probably been forgotten and I won’t remember to go back through and load it.
Protocol agnosticism
RSS is protocol-agnostic in the sense of accessing the content within. For podcasts this may be a link (usually using HTTP) to access the episode file.
For text feeds, it doesn’t matter what the “source” is: it could be a website, an FTP server, a gemini capsule, or anything else. Maybe, in some cases, there isn’t an explicit source and RSS is the primary means of distribution?
Either way, one shouldn’t assume that people always want to access via HTTP, and so including the text content directly in the feed helps to keep it pure and simple.
Trust
If I can read your content directly within my own client, it helps build trust. I know you aren’t trying to track my every move and that you care about my ability to read the content.
I know that you are sharing your content for the sake of the writing or piece itself (perhaps because you enjoy writing or want to share your thoughts), and not in order to drive sales or use patterns to manipulate me into carrying out an action that you want. It also shows you respect user privacy.
Lightweight
Distributing text-only versions of your posts is much lighter than having to transfer entire webpage files, CSS, JavaScript, and much more. In fact, if you pay for server space with per-MB billed traffic egress then this could help save you money.
More and more people in the tech community browse the web without JavaScript enabled anyway, so if your site relies on JS to load then they won’t be able to view your content. Think about the people in the intended audience of your post.
Conclusion
One can easily argue that “this is my site, and if I write the content then I want people to view it my way”. This is perfectly fine, and is entirely up to you. This post is more about explaining why these practices might convey quality-of-life enhancements to your readers, and is just my opinion and not a set of rules.
The web (and internet in general) is great in that it gives everyone a platform to distribute their content in the way they choose. However, since it’s up to others if they choose to read what you post, by making this easier and more accessible to them you can make sure you reach a wider audience.