This is necessary because some RSS clients don't support adding an RSS feed from a webpage URL. For example, on Thunderbird, you can't add Thunderbird's blog RSS feed with the URL https://blog.thunderbird.net/, you must use https://blog.thunderbird.net/feed/. Some RSS clients, like Akregator, do support adding them from the webpage URL.
Method 1: Copying the Link from an RSS Logo Icon
Some websites that support RSS make this clear to their visitors by displaying an RSS logo icon that acts as a link pointing the RSS feed URL. This is by convention: if you see the RSS logo icon on a website, it's most likely a link, and it most likely goes to the RSS feed URL.
If you see the RSS logo icon, then, you can right click on it in your web browser to show the link's context menu, where you can find the option to copy the link's address (the URL of the RSS feed).
Then all you need to do is paste that URL in your RSS client.
Some websites may not display the RSS logo icon even if they support the RSS functionality. In particular, a lot of websites on the Internet are made with WordPress, and WordPress creates feeds by default that the website owner may not even be aware of. This means a website can support RSS even if the owner doesn't know what RSS is! WordPress creates a separate RSS feed for every category and tag as well, so even if a website tells you the RSS feed for the whole website, it may not tell that it also supports feeds for every category and tag in the website.
On the other hand, some websites may support RSS and not have a logo, but an entire webpage dedicate to it. For example:
Method 2: Conventional URLs
By default, WordPress creates a feed in the URL path /feed/. If a website was made with WordPress (and that's very likely), you can replace the URL path with /feed/ to access the RSS feed.
For example, Thunderbird's blog is (currently) made with WordPress. Its homepage URL is:
https://blog.thunderbird.net/Because it's made with WordPress, that means, by default, there's an RSS feed for all articles that is found at:
https://blog.thunderbird.net/feed/As mentioned previously, WordPress also creates a feed at every category and tag. This means if there's a webpage for a category with a URL such as:
https://blog.thunderbird.net/category/tips-and-guides/We can suffix it with feed/ to get an RSS feed that only contains articles posted in that specific category.
https://blog.thunderbird.net/category/tips-and-guides/feed/Not every website in the world is made with WordPress. It could be that some feeds are found at the URL path /rss/ instead. Complex websites may have some more complex setups. For some examples:
- How to Use RSS to Subscribe to Search Results on Bing
- How to Use RSS to Subscribe to Subreddits on Reddit
Method 3: Using an Extension
If there is no RSS link in the webpage, the simplest method would be to just find an extension for your web browser that tells you the associated RSS feed of a webpage. Vivaldi is a web browser that comes with this functionality built-in, for example.
Method 4: Searching the HTML Code
If you're sure that a website supports RSS, you might be able to find the URL in the source code of its homepage. To do this, follow the following steps:
1: open the homepage of the website, e.g. https://blog.thunderbird.net/.
2: open the page's source code. How to do this varies from web browser to web browser. On Google Chrome, you can right click on the page and select "View page source" to view it (keyboard shortcut: Ctrl+U).
3: in the source code's tab, click somewhere in the source code text and then press Ctrl+F to initiate a text search.
RSS feed declarations look like this in HTML code:
<link
rel="alternate"
type="application/rss+xml"
title="The Thunderbird Blog » Feed"
href="https://blog.thunderbird.net/feed/"
>The reason for this is that RSS feeds are actually just files containing XML code.
The URL you want to copy is found in the href attribute.
It's possible that a website uses the modern Atom format instead of the old RSS format. In that case, type will be application/atom+xml instead of application/rss+xml.
It's worth noting that rel=alternate, without double quotes, is valid HTML code.
4: search for alternate and press enter to go to the next match until you find a <link> that is either application/rss or application/atom.
Method 5: Using the Javascript Console
We can automate the process above with a simple Javascript snippet.
For this, you'll need to open the developer tools in your web browser and run the following code in the console:
document.querySelectorAll(
'[rel~=alternate]:is([type^="application/rss"],[type^="application/atom"])'
).forEach(
(e) => console.log(e.title || "Untitled", '\n', e.href)
);This Javascript will find and print all RSS feeds URLs for you and their associated titles.
Observations
Why is there no RSS scheme?: It's worth noting that in many cases where a link in a web browser has to open a different application, there is a special scheme for it. For example, irc: opens IRC clients. One wonders why is there no rss: scheme for RSS clients.
It turns out that there was a proposal for feed:, but it never became successful. One argument against it is that this is better handled by MIME types (e.g. application/rss+xml). Ideally, the web browser would see this MIME type and send the URL to an RSS client. I'm not aware of any web browser that does this, however.
The reason given for creating this new standard is that modern applications (eg, browsers) lack sufficient support for feed MIME types. This is entirely too true, but adding a feed scheme will only further confuse the issue. Arguing that we need a feed scheme because browsers don't support the MIME types is like arguing that we need a new way mark up documents on the web because XHTML-2.0 support is virtually non-existant. I know it sucks--I can't wait for XHTML-2.0 and CSS3--but you're just going to have to wait. Creating a new mark-up language would only split resources and extend the time it will take to adopt both.
On the feed:// URI scheme [https://web.archive.org/web/20060614182102/http://www.coeus-group.com/en/archives/187-On-the-feed-URI-scheme.html] "Friday, September 10. 2004" (accessed 2024-10-23)
Although this is very sensible, I have my own counter-arguments against this counter-argument.
Normally, when the web browser can't display a file, it will just download the file, and you may try to open it with the default application associated to its file type. However, Windows uses the file extension to determine the the file type and which application it should open the file with. There is no way for the web browser to store MIME type if received in the HTTP header from the web server into file. This information is simply lost when the file is downloaded.
This means that if you have a feed.xml file that the server reports as application/rss+xml, after it downloads it's just an .xml file and a web server serving it could even naively report it's MIME type is just text/xml. In most cases you don't even have a feed.xml file, you just have file with the filename feed, without extension, so Windows wouldn't even know what to do with it.
To my knowledge, this is the only way it has ever worked. For example, on Linux, you have to download a .flatpakref file and then open it just to add a reference to a flatpak. If MIME types ever truly worked the way they were supposed to work, this wouldn't be necessary because the web browser could automatically open the application that handles the .flatpakref without me having to open it as a separate action. Presumably the reason why web browsers don't just randomly open applications like that is because it would be a security nightmare.
On top of that, the idea of using MIME types for this just doesn't make a lot of sense, in my opinion.
Although there could be a MIME type on the link, when the browser accesses a URL, the web server can respond with a completely different MIME type, so the link MIME type isn't necessarily the actual MIME type of the URL.
If you click on a link that goes to an RSS feed, in order to get the MIME type of the URL, the browser must send a HEAD or GET HTTP request. Most likely the browser will just try to download the data. It would make a bit of sense if the browser downloaded the content and then passed the downloaded data directly to the RSS client without saving it to a file (although I doubt it would do that since it's easier to just save it to a file). It makes absolutely no sense that the browser will download the data and then pass only the URL to the RSS client after the data is already downloaded.
The RSS client needs the URL, not the data of the XML file, in order to subscribe to the RSS feed, because it needs to keep fetching that URL over and over again.
In essence, the problem is that the RSS link needs to communicate the intent of subscribing rather than just pointing at some URL on the web. I genuinely don't see why this couldn't have been a scheme. Note that tel: is a scheme for telephones but nobody uses that to just cite a telephone, it's used with the clear intent of opening the phone app to make a call to the linked phone number, similarly mailto: isn't a scheme for linking to e-mail addresses, it's a scheme for opening some app to send an e-mail to the specified address.
Leave a Reply