Generating RSS feeds for Feedly

Update: I switched from Feedly to Miniflux in 2023, but feeds generated using the guidelines described here are still working well for me.

When Google Reader was "retired" in 2013, I looked around for a paid replacement in the hope that having an income source would increase the chances that it would stick around. After a brief stint with The Old Reader and a longer run with the now-discontinued goread.io, I eventually settled on Feedly. I've been very happy with their Pro plan ($6/month): I've only noticed one afternoon of downtime (caused by scheduled maintenance that took longer than expected), the UI is snappy and uncluttered, feeds are typically fetched twice per hour, and their support team is friendly and responsive when I need help, often putting me directly in touch with their developers to help debug things.

I generate various RSS feeds (well, technically ATOM or JSON Feed) for sites that I want to follow. This page collects various tips in case you're trying to do the same thing.

Supported HTML

Inline style attributes appear to get stripped entirely by Feedly. In my case, this meant not being able to set border, border-radius, margin, or padding CSS properties on elements. Per support, "we do not preserve any CSS style or properties."

I tried inserting <hr> elements to separate blocks of text. These showed up in the web interface but not in the Android client. When I asked, support didn't have a list of supported elements. From my own experimentation, I think you're best off sticking to <a>, <b>, <i>, <s>, <u>, <br>, <img>, and <p>. If you use <hr>, consider adding a <br> after it so you'll at least get some vertical space on Android.

Mangled UTF-8 characters

In feeds using the JSON Feed format, I was sometimes seeing UTF-8 characters get mangled. For example, ó (C3 B3, the UTF-8 representation of "LATIN SMALL LETTER O WITH ACUTE") would be rendered as ó (C3 83 C2 B3, "LATIN CAPITAL LETTER A WITH TILDE" followed by "SUPERSCRIPT THREE") in the Feedly web and Android clients. Similarly, é (C3 A9, "LATIN SMALL LETTER E WITH ACUTE") was converted to é (C3 83 C2 A9). It looked to me like the text might be getting double-encoded.

After some discussion with Feedly, it sounded like the problem might be my web server not specifying a character set in the Content-Type HTTP header, and the Feedly fetcher misdetecting the encoding as something other than UTF-8 as a result. After configuring the server to send Content-Type: application/json; charset=UTF-8 for files with .json extensions (no small feat in lighttpd!), I haven't seen the problem again.

Changing a feed's format

After rewriting some feed-generation code, I noticed that new items weren't showing up in Feedly. This was weird, since I could see from the web server's logs that Feedly was still fetching the feeds, and Feedly wasn't reporting any errors in the feed listing. I tried unsubscribing and resubscribing to the feeds, and while Feedly would show some old items, it still wouldn't show new items.

Eventually, I think I figured out what was happening: I briefly served the feeds using the ATOM format before switching them to JSON Feed. While Feedly is able to parse both formats, it doesn't seem to be able to handle a feed switching formats after it's been added to Feedly. After I moved the feeds and added their new locations to Feedly, new items started showing up as expected.