best practices for rss
Last month I had a chat with Tim about his RSS feed only serving his sixteen most recent posts, as I thought this might be a bug and not a feature. I stood corrected as it was meant to be, since it is usual to have a limited amount there.
This got me intrigued as I had no clue about there being some sort of RSS etiquette for us webmasters. That was until I found the RSS Advisory Board, which has a subpage on Really Simple Syndication Best Practices Profile that “covers a set of recommendations for how to create RSS documents that work best in the wide and diverse audience of client software that supports the format”.
Without going into the nittygritty I wanted to cover the top-level best practices that’s easy to implement and follow. Most of these are covered by standard implementation anyways, but I’ve seen some here and there missing them, even myself.
Date
When it comes to the date for your posts, all date-time values should use a four-digit year and each post should always include a publication time. The publication time should never be changed, as an entry can only be published once.
An important reminder here is that both Atom and RSS differentiate between time of publication (the time the entry first appeared in the feed) and the time of last update (the last time the entry was changed). Be sure to handle these correctly, e.g.:
- Update time should
- be greater than or equal to the publication time. New entries should have these two be the same.
- only change on significant updates. Slight formatting changes or typo fixes probably shouldn’t change the last update time
- Publication time should
- roughly match when the entry appeared on the feed. Some readers will ignore entries that were published in the far past.
- avoid having future publication times. If a publication time is too far in the future many readers will ignore it as a bug.
Avoid having entries start appearing in the feed in a different order than their publication time suggests.
Also, don’t reorder old entries. The newest items hsould always stay at the top of your feed. Republishing old content by changing dates can annoy your subscribers.
Discovery
Metadata is an important thing for your website, you know the <link rel=..../>-thingy in your HTML head. Having this set on all your blog posts, and every page of your website, it’ll allow readers and search engines to subscribe and become aware of new content. It’s like a way to advertise your feed(s).
The simplest way to add this is adding a link-tag to your HTML head, like for example <link rel="alternate" type="application/rss+xml" title="sidski" href="https://kjelsrud.dev/rss.xml">.
You can also add multiple feeds if you have that, just add more like the snippet above. But, you should prefer to put the “most important” feed at the top.
Full Content
This was actually something I came over before researching more about RSS etiquette, and I implemented it as soon as I finished Neil’s blogpost - “Please consider publishing a full-text RSS feed for your website or blog”.
Like Neil says, please consider making a full-text feed available. This is also generelly recommended as it’s a way to provide the full content of your post in the feed, giving your readers an easy way to enjoy what you write.
You do this by simply adding the <content>-element that contains the full article.
Many news-outlets / publications / etc. actually see it as unacceptable to provide the full content in feeds. This is mostly due to the difficulty of monetizing the views, but this will have the negative effect of missing readers who leave because they can’t view the full content.
Reasonably sized feed / pagination
Going back to my chat with Tim, as I mentioned at the start, keeping your feed reasonably sized (e.g. 20-30 items) will save bandwidth and keep the feed readers fast. Having a feed exposing all your posts, like 100+ posts, will do the opposite.
I also found that pagination is possible, as seen in RFC 5005, even though not all clients support this - it’s a nice way to keep the feed size appropiate.
Here’s an example of an Atom-formatted paged feed by RFC 5005:
<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
<title>Example Feed</title>
<link href="http://example.org/"/>
<link rel="self" href="http://example.org/index.atom"/>
<link rel="next" href="http://example.org/index.atom?page=2"/>
<updated>2003-12-13T18:30:02Z</updated>
<author>
<name>John Doe</name>
</author>
<id>urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6</id>
<entry>
<title>Atom-Powered Robots Run Amok</title>
<link href="http://example.org/2003/12/13/atom03"/>
<id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
<updated>2003-12-13T18:30:02Z</updated>
<summary>Some text.</summary>
</entry>
</feed>
Various other etiquettes to follow
- The title of your feed is likely used by default in the user’s reader, and should therefore be included in your RSS file.
- The recommended format for e-mail addresses in RSS elements is
username@hostname.tld (Real Name). - Every URL in your feed should be absolute. Avoid changing article URLs after publication. Broken links amke feeds much less useful.
endnote
Now I know Atom is probably the go-to nowadays, but good old RSS still lives to its name and I’ll keep on using it. I probably don’t follow all these as well, but I’ll try my best to implement them one-by-one in the near future.
Either way, I learnt a lot from researching this and hope you also did by reading this. Here’s my RSS-feed if you want to subscribe, and here’s the JS-file that creates my feed for this website.