# jekyll-feed: an Atom feed generated by a plugin, not a template > jekyll-feed is an MIT licensed Jekyll plugin that generates an Atom feed of your posts without asking you to write a feed template, and adds per category, per collection and per author metadata on top. The judgement is that it is the shortest path to a working feed for a Jekyll site, and that the feed path it takes over is the one decision you cannot undo quietly. **jekyll/jekyll-feed** — :memo: A Jekyll plugin to generate an Atom (RSS-like) feed of your Jekyll posts - Repository: https://github.com/jekyll/jekyll-feed - Stars: 881 · Forks: 212 - Language: Ruby - License: MIT - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/jekyll-jekyll-feed ## A feed with no template to write jekyll-feed is a Jekyll plugin that generates an Atom feed of your posts, and the important word is generates. The plugin will automatically generate an Atom feed at /feed.xml, which means the feed exists as a consequence of adding the plugin rather than as a Liquid template you maintain. That is the entire value proposition, and it is a real one, because a feed template is the classic place where a static site quietly rots, since the template is only exercised when a reader requests the feed. The project is a Ruby gem published under the Jekyll organisation, it is MIT licensed, and the repository carries the usual Ruby project furniture, a gemspec, a Gemfile, a Rakefile, a rubocop configuration with a todo file, an rspec configuration, a script directory, a lib directory and a spec directory. The topic tags describe the scope precisely: atom, jekyll-plugin, rss and ruby. ## Two edits to a Jekyll site and you have a feed Installation is a gem declaration and a plugin entry. The Gemfile line is: ```ruby gem 'jekyll-feed' ``` And the site configuration needs the plugin listed: ```yml plugins: - jekyll-feed ``` There is a version caveat that catches people on older sites. If you are using Jekyll below 3.5.0 you use the gems key instead of the plugins key. The README also says the plugin will automatically use any of the configuration variables listed below if they are present in your _config.yml, so the feed inherits your site settings rather than duplicating them. The continuous integration badge points at a ruby.yml workflow, and the gem version badge comes from the RubyGems index, so the packaging is checked on every change and the published version is the one you get from bundler. ## What the feed borrows from your site configuration The plugin reads a specific set of keys, and each one has a fallback that explains a lot about how it behaves. The feed title comes from title or name, so a site that only sets name still gets a titled feed. The description key supplies the longer text. The url key gives the site address, and the README is explicit that if none is provided the plugin will try to use site.github.url, which is why a feed on a GitHub Pages site works without extra configuration. The author key is the global author, which the per post front matter can override. Two keys are specific to the feed namespace, feed.icon for a square icon and feed.logo for a wide one, and both are documented as not supported by all readers and often overridden by a favicon or site icon, so they are worth setting only if your reader base needs them. ```yml feed: icon: /images/icon.png logo: /images/logo.png ``` ## Four places an author can be defined, in a fixed order Author metadata is where most feed plugins get complicated, and this one resolves it with a documented priority list that is worth reading in full before you write anything. The first source is an author object in the document front matter. The second is an author object in the site _config.yml. The third is site.data.authors[author], which means a plain name in the front matter can be looked up in a central file, and the README shows the shape of that file, a key per author with a picture and a twitter entry. The fourth is a plain author name in the document front matter, and the fifth is a plain author name in the site _config.yml. There is also a pro tip, that if authors is present in the front matter as an array, and author is not, the plugin uses the first author listed. The practical consequence is that a multi author site can centralise everything in a single _data/authors file and keep the per post front matter to a name. ## Category feeds, collection feeds and a limit of ten Three configuration blocks decide how much of your site the feed covers. The first is categories, where you list the categories you want feeds for, and the plugin then generates a feed for each of them. The second is posts_limit, which defaults to 10 posts in the feed and can be raised. The third is collections, which lets the plugin generate feeds for collections other than Posts, and the README notes this works best for chronological collections, which in practice means collections whose filenames carry dates. By default a collection feed is written to /feed/.xml, but a collection can be given its own path. Collections can also have their own category feeds, written to /feed//.xml. ```yml feed: categories: - news - updates ``` ```yml feed: collections: changes: path: "/changes.atom" ``` ## feed_meta, typographic punctuation and XSLT Three small features handle discovery and presentation. The plugin exposes a helper tag, feed_meta, which you place in the head section of your template to output the metadata that lets feed readers discover your feed automatically, so the plugin generates the file and also links to it from the pages. Separately, the plugin uses Jekyll's smartify filter on the site title and post titles, which converts plain ASCII punctuation into typographic punctuation, and it does not render or strip Markdown in a title. Since smartify runs through kramdown, you can turn that behaviour off for the feed by disabling the corresponding kramdown options in _config.yml. Finally, when a XSLT stylesheet named feed.xslt.xml exists at the root of the repository, a link to that stylesheet is added to the generated feed, which is how you control how the feed looks when opened in a browser rather than in a reader. ## The feed path is the decision you cannot undo quietly Two parts of the README deserve a warning label, because they are the ones that bite. The first is what happens when you already publish a feed somewhere other than /feed.xml. The README explains that if you simply swap out jekyll-feed for your existing template, your existing subscribers will not continue to get updates, and it names the reason, hosts like GitHub Pages that do not support machine-friendly redirects. The fix is to set a non default path in your configuration, and the README is careful to say that you should not have to do this unless you already have a feed you are using and you cannot or do not want to redirect existing subscribers. The second is the format itself. The README answers the question of why Atom and not RSS in one line, calling Atom a better format and comparing it to RSS 3.0, with a link to the longer discussion in the sibling repository. In other words, the alternative to this plugin is your own feed template, which gives you full control over the shape of the output and puts the maintenance back on you. ## Conclusion jekyll-feed suits a Jekyll site that needs a standards compliant Atom feed today, especially one that already has authors, categories or dated collections that need to be represented in the feed without hand written templates. It is the wrong choice if you need a feed shape the plugin does not produce, such as a full content feed with pagination controls, or if you are migrating an existing site, because the path of the feed becomes part of your public contract with subscribers. Before you add it, check the feed path of the feed you already publish, set feed.path in your config to match it if you have existing subscribers, and confirm that the author metadata your posts rely on resolves, since the plugin falls back through four different sources in a fixed order. ## FAQ ### How do I install jekyll-feed on a Jekyll site? Add gem 'jekyll-feed' to your site's Gemfile and list the plugin under plugins in your _config.yml. If you are using Jekyll below 3.5.0, the README says to use the gems key instead of the plugins key. ### Where does jekyll-feed put the generated feed? The main feed is generated at /feed.xml. You can move it with the feed.path option, for instance /blog/feed.atom, and collection feeds are written to /feed/.xml by default, with category feeds for a collection at /feed//.xml. ### How does jekyll-feed resolve author details? In priority order: an author object in the document front matter, an author object in the site _config.yml, site.data.authors[author] looked up from a central data file, a plain author name in the document front matter, and finally a plain author name in _config.yml. If authors is an array in the front matter and author is not, the first listed author is used. ## Sources - [Issues](https://github.com/jekyll/jekyll-feed/issues) - [jekyll/jekyll-feed on GitHub](https://github.com/jekyll/jekyll-feed) - [License: MIT](https://github.com/jekyll/jekyll-feed/blob/master/LICENSE) - [README](https://github.com/jekyll/jekyll-feed/blob/master/README.md) - [Releases](https://github.com/jekyll/jekyll-feed/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/jekyll-jekyll-feed