RSS Feed Best Practices (2022)

Posted on 2022-05-06

Last updated on 2024-03-13

These are several technical tips for publishing a blog. These have nothing to do alongside fine content, fair how to portion that content. The recommendations are approximately in command of importance and have rationale for why they are that important.

Formats

People mostly call feeds “RSS Feeds” but normally they aren’t specifically talking concerning RSS. RSS isn’t the only, or equal the finest format. Using a standardized format is crucial to your nourish being understood by the widest assortment of readers and hunt engines.

You should use RSS 2 or Atom. These formats are extremely extensively supported. Other average formats are before RSS standards and JSON Feed or Microformats h-feed. I would evade using these—or equal small average formats—as they are small extensively supported.

If you don’t have a nourish yet I would extremely propose Atom. The specification has much small ambiguity, so you are small apt to have compatibility issues alongside the broad assortment of clients in use. The specification is additionally simpler and additional apparent overall. If you already have an RSS 2 nourish there is small logic to upgrade.

A minimal Atom template is below. For complete particulars see the spec. If you need an example you can appearance at my feed.

<?xml version="1.0" encoding="UTF-8"?> <feed xmlns="http://www.w3.org/2005/Atom"> <title>{{FEED_NAME}}</title> <id>{{HOMEPAGE_URL}}</id> <link rel="alternate" href="{{HOMEPAGE_URL}}"/> <link rel="self" href="{{FEED_URL}}"/> <updated>{{LAST_UPDATE_TIME in RFC3339 format}}</updated> <author> <name>{{AUTHOR_NAME}}</name> </author> <entry> <title>{{ENTRY.TITLE}}</title> <link rel="alternate" type="text/html" href="{{ENTRY.HTML_URL}}"/> <id>{{ENTRY.PERMALINK}}</id> <published>{{ENTRY.FIRST_POST_TIME in RFC3339 format}}</published> <updated>{{ENTRY.LAST_UPDATE_TIME in RFC3339 format}}</updated> <content type="html">{{ENTRY.HTML}}</content> </entry> </feed> 

There is extremely small logic to provision feeds in multiple formats. If you have an Atom nourish you don’t need to provision an RSS nourish as well.

Changing nourish format is safe. Very few readers volition be confused if a nourish switches between Atom and RSS. This can be done either by changing the nourish at the identical URL or by redirecting new a new URL. (Just be certain to update the content type)

Content Type

Be certain to set the Content-Type header properly.

• Atom: Content-Type: application/atom+xml
• RSS: Content-Type: application/rss+xml
• JSON Feed: Content-Type: application/feed+json

You volition see another values used in the wild, but these are the norm values and have the widest support.

Absolute URLs

Every URL in your nourish have to be absolute. While Atom has plainly stated how to determine related URLs they are rarely implemented correctly. In command to justify that your nourish can be understood by all readers use lone complete URLs (starting alongside https://).

This includes all <link> elements and the summary and build of posts (including in the HTML).

Discovery

On all of your blog pages and apt all leaf of your location you should contain metadata to advertise you feed. This volition authorize readers and hunt engines to subscribe and rotate into conscious of your new content. This is as uncomplicated as providing the following in your HTML:

<link rel=alternate title="Blog Posts" type=application/atom+xml href="/feed.atom"> 

If you have multiple feeds you can advertise them all alongside suitable titles.

<link rel=alternate title="All Posts" type=application/atom+xml href="/feed.atom"> <link rel=alternate title='Posts in the "Social" category' type=application/atom+xml href="/feeds/social.atom"> <link rel=alternate title="Comments on this Post" type=application/atom+xml href="/post/hello-world/comments.atom"> 

Make certain that you use the accurate category for your feed. The examples provided are for Atom feeds.

Prefer to put the “most important” nourish at the top. Many clients volition maintain the command whenever presenting feeds to the user. This is subjective but typically would be a whole-site feed, afterward category feeds, afterward a comment nourish for the particular page. If you recommendation your feeds in multiple formats I propose lone promotion one (either Atom or RSS 2). Including multiple links to the identical satisfied in multiple formats may confuse possible subscribers or depart them in inspection paralysis. (How do they cognize that the satisfied is the same?)

You can validate that this is operating correctly by putting your website URL into the W3C Feed Validation Service. If your links are set up correctly it should detect and validate your feed. Try out a few distinct pages to create certain that you have finding operating everywhere. Try your homepage, article lists leaf and an idiosyncratic article page.

If it is difficult to modify the HTML a Link header in the HTTP reply can be used. However, this isn’t as extensively supported. Using HTML <link> tags is preferred for wider compatibility.

Link: /feed.atom; rel="alternate"; type="application/atom+xml" 

You should additionally contain a nexus alongside an RSS logo for users without another nourish indicator.

HTTPS

HTTPS is key to safety and privacy on the internet. Providing feeds complete HTTPS ensures person privacy and ensures that your nourish is not modified by a malicious actor.

1. Reference all embedded media (such as images) complete HTTPS. Many readers volition run in a safe environment anywhere HTTP requests are not allowed.
2. Provide the nourish complete HTTPS.
3. Ensure that your self link is HTTPS.
4. Redirect HTTP requests to HTTPS.
5. Consider using Strict-Transport-Security.

Full Content

It is mostly recommended to provision the complete satisfied of your posts in the feed. This is what most readers prefer. For RSS and Atom the <content> component should merge the complete article. Atom additionally has a <summary> component in which to contain a shorter summary for readers who favor it.

Of way sharing complete satisfied in feeds is unacceptable to several publications because of the difficulty of monetizing these views. First, regard that several readers may depart if they can’t perspective the complete satisfied in their nourish reader. Even if they don’t see your ads they may portion your satisfied alongside allies or on news aggregators. Likely it is motionless additional precious for you to have this audience than to endure them.

If your satisfied is paid regard allowing users to create personal links by providing an auth token. For example /feed.atom?user=peruserauthtoken. You can additionally use basic auth akin https://fred:[email protected]/feed.atom nevertheless this is supported by small readers than providing a token in the URL way or query string.

Entry IDs

Entry IDs are the chief way to acknowledge and differentiate entries in your feed. If your admission IDs alter or repeat, readers volition obtain duplicates or young female entries.

1. Never alter the ID of an existing article.
   • If you alter your ID scheme, justify that it lone applies to new entries.
2. Never reuse Entry IDs for distinct articles.
3. Prefer to use part permalinks for Entry IDs.
4. Prefer to create your Entry IDs globally distinctive throughout all feeds in existence.
   • Some readers volition merge feeds together, distinctive IDs assistance justify there are no issues.
   • The easiest way to accomplish this is to use a URL on a domain that you control. If that isn’t imaginable you can use a UUID specified as urn:uuid:f4a3ca5b-5799-44e8-aaaa-e40728f037d3.

Dates

Both Atom and RSS differentiate between period of publish (the period the admission archetypal appeared in the feed) and the period of final update (the final period the admission was changed). Be certain to grip these correctly.

1. Include a publish time.
2. The publish period should never change. An admission can lone be published once.
3. Prefer making the publish period approximately equivalent whenever the admission appeared on the feed. Some readers volition disregard entries that were published in the far past.
4. Strongly evade having entries commencement appearing in the nourish in a distinct command than their publish period suggests. (For example evade having an item alongside a published period of 14:00 commencement appearing in the nourish at 14:00 afterward have an item alongside the published period of 13:00 commencement appearing in the nourish at 15:00. Some clients volition be doubtful that they already cognize concerning the 14:00 item but don’t yet cognize concerning the “earlier” 13:00 item.) Another way of viewing this is that all new item that appears in a nourish should have a published period that is afterward than all items earlier in the feed. Some clients volition disregard these “backdated” entries equal if the published period is fairly recent.
5. Avoid forthcoming publish times. If a publish period is too far in the forthcoming many readers volition disregard it as a bug.
6. Update period have to be greater than or equal to the publish time. New entries should have these two be the same.
7. Update period should lone alter on significant updates. Slight formatting changes or typo fixes likely shouldn’t alter the final update time. Most readers disregard the update time, several volition resurface your part as “updated”.

Feed Title

The heading of your nourish is apt used by default in the user’s reader. Many readers have options to override the title, but it is additional activity for the person and not universally supported. Try to choice a fine heading for your feed.

1. Include context. The heading is apt one of many feeds in their reader. For example call it “Kevin Cox’s Blog” fairly than “Blog Posts”.
2. Keep it succinct. The person is already subscribed, no need to advertise more. For example “John Smith” or “John Smith’s Photography Blog”. Not “John Smith — Ramblings on Photography all Tuesday and Friday, Cameras, Film and Development — Exclusive Content”.
3. Avoid HTML particular characters specified as < > and &. In RSS it isn’t entirely apparent if you can contain styling akin <b> tags in your nourish title. Very few readers volition parse HTML and volition nearly continually treat the heading literally.

You can update your nourish heading at any time, but it may be confusing to users if it changes too frequently.

Styling

Feel liberated to use CSS in your feed! However, keep in intellect that many nourish readers don’t use contemporary browser engines and may be constricted in what they can render. Additionally, many nourish readers volition sanitize your nourish so rare elements and tradition CSS may be partially or entirely stripped. But don’t let that halt you! Using HTML and CSS can greatly enhance the cognition for users alongside fine readers. Consider the following tips:

1. Consider what volition happen if any CSS doesn’t apply. For example if you set background: black; color: pale and among the two rules is stripped you volition have unreadable text. In broad favor to create small adjustments fairly than relying on CSS for theatrical changes.
2. Prefer inline CSS manner attributes to distinct <style> blocks. They have wider compatibility.
3. Prefer semantic elements specified as <p>, <h1>, <pre> and <code> complete emulating their manner on <div>s and <span>s.
4. Don’t depend on JavaScript, nearly no readers assistance it.
5. Provide fallbacks for <audio>, <video> and <iframe> tags. Support isn’t common.
6. Avoid form and input elements. Support is rare and incompatible.

Unfortunately there is no substitute for evaluation in assorted readers to see what works.

Self Link

Ensure that the self-link for your nourish is accurate.

<link rel="self" href="https://kevincox.ca/feed.atom"/> 

This provides the following benefits:

1. Allows you to move your feed. Some readers volition update the nourish URL if they get a imperishable redirect and the redirect mark contains a oneself nexus that points to itself.
2. Improve cache hits. It is average for users to discover minor variations of your nourish URL. For example http: alternatively of https:, /feed vs /feed/, www.example.com vs example.com, feed.atom?tracker=lookatme or ?category=rant&content=full vs ?content=full&category=rant. By providing a canonicalized oneself nexus you can merge these to decrease variance and addition you cache hit rate.
3. Required for WebSub.
4. If the person has a copy of the nourish document they can subscribe to it. For example several nourish readers volition act as document handlers for feeds. If the document contains a oneself nexus afterward they can use that URL to subscribe and fetch updates. If the document doesn’t have a oneself nexus it isn’t imaginable to do that.

Caching

Feeds are followed by changeless polling. This can create a decent amount of burden on your server. Setting cache headers can assistance authority the readers. If you don’t provision any direction all client volition choice their own value, which may be too accelerated or dilatory for your feed. If you create a recommendation several volition prosecute it. Try to choice a sensible value according to whenever you post. If your blog updates monthly afterward caching for an hr would create sense. However, if you are posting many times a day, a five infinitesimal cache may be additional suitable.

Example cache headers:

• 5 min: Cache-Control: max-age=300
• 15 min: Cache-Control: max-age=900
• 1 h: Cache-Control: max-age=3600

If you use scheduled posts and desire to get extremely fancy you can change the cache period according to whenever the next article volition go live. But a fixed cache period is sufficient.

Conditional Requests

Support conditional requests on your feed. This makes polling additional productive for the two you and your users.

Return an ETag and/or Last-Modified header. Then come back a 304 reply if the nourish hasn’t changed. See HTTP conditional requests on MDN for additional details.

WebSub

WebSub is a norm for real-time nourish updates. Not lone does it shove your updates out faster, but it additionally reduces burden on your server.

You can use a public hub or run your own. Note that a hub can modify or inject satisfied into your feed, so be certain you rely the hub you pick.

I can’t discover fine generic setup instructions but the Google hub has essential instructions on their homepage. Maybe I’ll compose a guide one day…

Bot Access

If you use any bot-blocking innovation be certain to rotate it off (or rotate it way down) for your feeds. They are intended to be consumed by bots! Otherwise users volition have difficulty accessing your nourish and volition not cognize concerning your new content.

Many popular sites have problems here. I’ve written concerning this in the past. Make certain that you aren’t hurt by defaults of assorted services.

Categories

Categories are a dependable way to display items in feeds. It is far improved to let person subscribe for one category—or all categories but one—than to endure a subscriber since they were annoyed by a subset of your content.

For Atom feeds adding categories is as uncomplicated as one element. For example this article contains the following markup in my feed:

<category term="RSS"/> <category term="Guide"/> 

For RSS 2 the syntax is fair slightly different:

<category>Rant</category> 

Some readers don’t assistance categories, so you may desire to regard generating distinct feeds for distinct categories or providing a URL indicator to your nourish to display by category. Personally I wouldn’t concern concerning this.

Changing URL

As much as imaginable you should evade changing your feed’s URL. But if you need to do it current is how to do it without losing many subscribers.

1. Make the nourish accessible at the new URL in supplement to the old URL.
2. Make certain the oneself nexus of the new nourish points at the new URL.
3. If you use WebSub, commencement pinging your hub for the two URLs whenever you post.
4. Redirect the old URL to the new one alongside a 308 Permanent Redirect.
5. If you use WebSub you should continue pinging the old URL for at smallest 3 months or the max subscription life of your hub (whichever is greater).

Remember that that several subscribers volition not move. Try to keep the redirect living as lengthy as possible. After an extended duration of period you may regard replacing the redirect alongside a nourish that has an admission notifying readers of the new location. But an ounce of safety is value a lb of cure, try picking a fine URL (that you control) from the start.

CORS

CORS or Cross-Origin Resource Sharing is a kludge to fix several holes in the first web safety model. It adds restrictions to what requests web pages can create and controls what they can see concerning the response.

This is applicable for feeds as without opting-out of CORS browser-based readers that fetch feeds client flank volition not be capable to admission your feed.

For feeds the following headers are adequate and safe for all feeds:

Access-Control-Allow-Origin: * 

This method that your nourish can be requested as a community asset (notably no cookies volition be sent).

To test it out you can navigate to any third-party webpage (such as https://example.com) afterward run the following Javascript in the developer console:

fetch("https://YOUR_FEED_HERE").then(r => r.text()).then(console.log, console.error) 

If the satisfied of your nourish gets logged than you are all set. If you get an error afterward item has gone wrong.

Performance

While small and local nourish readers lean to use uncomplicated study rates many larger services use a assortment of heuristics to decide whenever to inspect your feed. If you don’t assistance WebSub you should aim to react to nourish requests in small than 1s. If your nourish is slower, particularly if it is slower than 3 s polling volition apt be slowed downward and you readers volition get updates slower.

---

The items below this item are comparatively unimportant. They are a fine idea if you are creating a merchandise or nourish generator but apt not value the period if you are fair making a nourish for your own blog.

Summaries

Some readers volition display abbreviated snippets as an part preview. Providing a summary in your nourish gives them elevated norm satisfied for a fine person experience. If you don’t provision an definitive summary they volition apt use your archetypal paragraph or archetypal brace of sentences of your chief content.

Pagination is a helpful tool for keeping your nourish archive accessible during keeping the size of your latest items small. It is stated in RFC 5005: Feed Paging and Archiving. Unfortunately, few clients have support. However, adding assistance in your nourish doesn’t have any downsides, so it is motionless a fine idea.

Pagination is extremely easy. Just add the following nexus to your feed.

<link href="https://kevincox.ca/feed/2022-03-05.atom" rel="next"/> 

Then on consequent pages additionally contain a prev link. Of way the final leaf won’t have a next link.

<link href="https://kevincox.ca/feed.atom" rel="prev"/> <link href="https://kevincox.ca/feed/2022-01-21.atom" rel="next"/> 

When deciding how ample to create your pages recall that not all clients volition assistance pagination, so you don’t desire to move new entries off your archetypal leaf too quickly. I provision the following recommendations. Note that these are fair broad rules and have to be applied judiciously. For example if you article 20 times a day you likely don’t need to keep 7 days of satisfied in your feed. Similarly, if your posts are lone a paragraph or two you can likely keep a few additional on the archetypal page.

1. Ensure your newest items are on the archetypal page.
2. Try to keep items in the nourish for at smallest a day. Some clients inspect fairly infrequently. If reasonable, keep items for at smallest a week.
3. Avoid making the nourish too large, fine under a megabyte is recommended.

---