Hugo, Jekyll, and Eleventy don’t work like WordPress or Ghost. There’s no dashboard toggle for RSS, no plugin marketplace you can browse from a settings screen, and no guarantee that what worked in the starter template you cloned two years ago still generates a valid feed today. If you’re running a static site generator, the RSS feed either lives in your build output or it doesn’t — and the only way to know for sure is to check the generated files yourself.
This matters more than it might seem, especially if you’re trying to auto-post new articles to X, LinkedIn, Bluesky, or Facebook. Static site generators are popular precisely because they’re fast, cheap to host, and free of runtime dependencies — but that same simplicity means RSS isn’t always turned on by default, and when it is, small configuration mistakes can silently break it. A feed that returns a 404, serves relative URLs, or reuses the same GUID for every post will cause your auto-posting tool to either post nothing or post the same three articles over and over.
Below is a practical walkthrough for Hugo, Jekyll, and Eleventy: whether each one ships RSS by default, how to find and verify your feed URL, how to add a feed if one doesn’t exist, the gotchas that trip up static-site RSS specifically, and how to wire the finished feed into PostRSS so new posts get auto-published to your social accounts the moment you deploy.
Short answer: it depends which one you’re using, and in Jekyll’s case, which template you started from.
Hugo generates an RSS 2.0 feed automatically for every site, every section, and every taxonomy term, with zero configuration required. This has been true since early Hugo versions and remains true in current releases. Out of the box you’ll get:
/index.xml/posts/index.xml veya /blog/index.xml/tags/hugo/index.xmlHugo builds these from its built-in rss.xml template (the output format is literally named RSS in hugo.toml/config.toml‘s outputs section). You don’t need a plugin, a module, or a shortcode. If you’ve done nothing special to your Hugo config, your feed almost certainly already exists — you just need to confirm it’s pointing at the right content and not accidentally disabled.
Jekyll itself does not generate RSS natively. What makes Jekyll “yes by default” in practice is that GitHub Pages — historically Jekyll’s most common host — auto-includes the jekyll-feed plugin, and most modern Jekyll starter themes (Minima being the default theme scaffolded by jekyll new) ship with it pre-configured in the Gemfile and _config.yml.
jekyll-feed generates an Atom feed (not RSS 2.0 — this distinction matters less to social auto-posting tools since both are XML feed formats they can parse, but it’s worth knowing) at /feed.xml by default. If your Jekyll site was built from Minima, from the Jekyll quick-start guide, or from most theme templates on jekyllthemes.io, you likely already have this plugin. If you built your Jekyll site from a bare-bones layout or stripped out the default gems to speed up your build, you may not.
Eleventy (11ty) is intentionally minimal — it doesn’t assume you want a blog, a feed, or even HTML output by default. There is no built-in RSS generation. To get a feed you need one of two things:
@11ty/eleventy-plugin-rss plugin, which provides Nunjucks/Liquid filters (dateToRfc3339, dateToRfc822, getNewestCollectionItemDate, absoluteUrl) that you use inside a feed template you still have to write yourself, orfeed.njk, feed.liquid, or rss.njk — placed in your input directory that loops over your posts collection and outputs valid XML.In other words, the plugin doesn’t generate a feed on its own — it gives you the date-formatting and URL-formatting helpers so the feed template you write doesn’t get the RFC dates or absolute URLs wrong. Most Eleventy starter kits (the official eleventy-base-blog being the most common) include a working feed.njk already, so if you scaffolded your site from that starter, you likely have RSS. If you built your Eleventy site from scratch or from a minimal starter, you probably don’t, and you’ll need to add one.
| Generator | RSS by default? | Config file | Default feed output path | Plugin/template needed? |
|---|---|---|---|---|
| Hugo | Yes — built in | hugo.toml / config.toml / config.yaml | /index.xml (site-wide); /section/index.xml per section | None — native RSS output format |
| Jekyll | Usually — depends on theme/host | _config.yml | /feed.xml | jekyll-feed gem (bundled with GitHub Pages and Minima) |
| Eleventy | No — must be added | .eleventy.js / eleventy.config.js | Wherever your template outputs it — commonly /feed.xml veya /feed/feed.xml | @11ty/eleventy-plugin-rss + a manual feed.njk/feed.liquid template |
Whichever generator you’re on, don’t take the “default path” in the table above on faith — config changes, custom base URLs, and theme overrides can all move it. Verify with these steps.
Nearly every well-built theme, on all three generators, injects a <link rel="alternate" type="application/rss+xml"> veya type="application/atom+xml" tag into the page <head>. View source on your homepage (or open dev tools and inspect the head) and search for rss+xml veya atom+xml. The href attribute is your feed URL. This is the fastest and most reliable check because it reflects what your theme actually generated, not what the docs say it should generate.
If there’s no link tag, try loading these directly in a browser, replacing yourdomain.com with your actual domain:
yourdomain.com/index.xmlyourdomain.com/feed.xmlyourdomain.com/feed.xml (if using eleventy-base-blog’s convention) or check your feed.njk template’s front matter for a custom permalinkA valid feed will render as XML (or your browser will offer to display it as a feed/RSS reader view). If you get a 404, the feed either isn’t being generated or lives at a different path.
If neither of the above works, go straight to the source:
hugo.toml for an [outputs] section — if home doesn’t list "RSS", it’s been explicitly disabled and you’ll need to add it back.Gemfile ve _config.yml for jekyll-feed under plugins: (or the older gems: key). If it’s missing from both, the plugin isn’t installed.src/) for a file with RSS/Atom XML front matter — look for filenames like feed.njk, feed.liquid, or rss.xml.njk, and check .eleventy.js for addPlugin(pluginRss).A feed that loads isn’t necessarily a feed that will work for auto-posting. Run the URL through the W3C Feed Validator and confirm three things specifically:
<item> (or Atom <entry>) has a unique <guid> veya <id><link> is a full absolute URL, not a relative pathThese three checks map directly to the gotchas covered next, and they’re the difference between a feed that quietly breaks your auto-posting and one that just works.
If your hugo.toml has an [outputs] block that omits RSS, add it back:
[outputs]
home = ["HTML", "RSS"]
section = ["HTML", "RSS"]
If there’s no [outputs] block at all, Hugo is using its defaults, which already include RSS for the homepage — so if your feed is missing, check the layouts directory for a custom _default/rss.xml that might have been broken or emptied by a theme override, and check that disableKinds in your config doesn’t list "RSS".
Add the gem to your Gemfile:
group :jekyll_plugins do
gem "jekyll-feed"
end
Then add it to _config.yml:
plugins:
- jekyll-feed
Run bundle install, rebuild, and check /feed.xml. If you’re hosting on GitHub Pages, jekyll-feed is already part of the supported gem whitelist, so no extra installation approval is needed on their end.
Install the official plugin:
npm install @11ty/eleventy-plugin-rssRegister it in your config file:
const pluginRss = require("@11ty/eleventy-plugin-rss");
module.exports = function (eleventyConfig) {
eleventyConfig.addPlugin(pluginRss);
};
Then create a feed template — feed.njk is the standard convention, borrowed from the official eleventy-base-blog starter — that sets its own permalink to /feed.xml, loops through your posts collection sorted newest-first, and uses the plugin’s absoluteUrl ve dateToRfc822/dateToRfc3339 filters for every link and date field. If you’d rather not write this from scratch, copying the feed.njk file from the official eleventy-base-blog GitHub repository and adjusting the collection name and site metadata is the fastest path to a working, spec-correct feed.
Static site RSS feeds fail in ways that dynamic CMS feeds usually don’t, mostly because the feed is a build artifact rather than something generated live on each request. These four issues account for most of the auto-posting problems people run into.
This is the single most common static-site RSS failure. Because the feed is generated at build time, if your deploy pipeline caches the build output, serves a stale CDN copy, or only rebuilds pages that changed (some incremental build setups do this), your feed.xml or index.xml can silently stop updating even though your site’s HTML looks current. Confirm your CI/CD pipeline (GitHub Actions, Netlify, Vercel, Cloudflare Pages) runs a full hugo, jekyll build, or eleventy command on every publish, and check your CDN/host cache headers aren’t serving an old copy of the XML file specifically — it’s easy to invalidate the HTML cache and forget the feed.
All three generators can produce relative URLs in feed items if the base URL isn’t set correctly:
baseURL in hugo.toml is a full absolute URL (https://example.com/), not blank or relative — Hugo’s RSS template uses it to construct every <link>.jekyll-feed relies on the url value in _config.yml being set correctly (and matching your actual production domain, not localhost) to build absolute links.absoluteUrl filter on a link and ship a relative path by accident. Every URL in the feed should be run through it.A feed with relative URLs will often display fine in a browser (which resolves relative paths against the current page) but will break when a social auto-posting tool tries to pull the article URL to build a post — you’ll get broken links in your tweets and posts, or the tool may reject the item entirely.
Auto-posting tools track which feed items they’ve already posted using each item’s GUID (RSS) or id (Atom) — not the title or content. If your feed template doesn’t set a unique, stable GUID per item — or worse, sets the same GUID for every item, or regenerates a new GUID on every build — the auto-poster can’t tell old posts from new ones. The two failure modes are opposite but equally annoying: a static/duplicate GUID means new posts never get detected as new, while a GUID that changes on every rebuild means the same post gets flagged as “new” and republished every time you deploy.
Hugo and jekyll-feed both handle this correctly by default, using the post’s permalink as a stable GUID. If you’re hand-rolling an Eleventy feed template, explicitly set <guid>{{ post.url | absoluteUrl(metadata.url) }}</guid> (or the Atom <id> equivalent) using each post’s permanent URL, not its title or a random value — the permalink is stable across rebuilds as long as your URL structure doesn’t change.
Some feed templates only output a truncated excerpt or, in stripped-down configurations, nothing but the title and link. That’s usually fine for auto-posting purposes since most tools just need the title, link, and publish date to build a social post — but if you’re relying on the feed’s description field to populate your post caption automatically, verify it’s actually populated with meaningful text and not an empty tag.
Once your feed URL loads correctly, validates cleanly, uses absolute URLs, and carries stable GUIDs, the rest of the setup is generator-agnostic — PostRSS doesn’t care whether the XML came from Hugo, Jekyll, Eleventy, or anything else, because it’s reading standard RSS/Atom output either way.
/index.xml, /feed.xml, or your custom path).Because static site feeds are rebuilt from scratch on every deploy rather than updated incrementally like a database-backed CMS, it’s worth double-checking the GUID stability point above before you turn on RSS feed automation for a static site — a template misconfiguration that regenerates GUIDs on every build is the single most common cause of a Hugo or Eleventy site suddenly re-posting its entire archive to social media after a routine deploy. If you catch that happening, pause the connected feed in PostRSS, fix the GUID logic in your template, redeploy, and confirm the feed’s GUIDs are now stable before resuming.
Beyond the initial setup, tools built around RSS automation are particularly well suited to the static-site workflow, since your publishing process is already git-based and CI-driven — the feed becomes just another build artifact that your existing deploy pipeline produces automatically, and PostRSS simply polls it on a schedule and posts whatever’s new. There’s no webhook to configure on the CMS side and no API integration to maintain, which is exactly the kind of low-maintenance setup that fits a JAMstack site’s philosophy in the first place. If you’re new to the platform, the getting started with PostRSS resources walk through account setup and first-feed configuration in more detail than the summary above.
Don’t connect a freshly fixed feed to your live social accounts and walk away. Before enabling automatic posting on a schedule, run through this checklist:
Yes. While Hugo’s default output format is named “RSS” and produces RSS 2.0 by default, you can add a custom Atom output format in your outputFormats configuration and write your own Atom template if a specific downstream tool requires Atom specifically. In practice this is rarely necessary — RSS 2.0 is universally supported by auto-posting tools, including PostRSS.
This is almost always a caching or deploy issue rather than a jekyll-feed problem. Check that your host actually rebuilt the site after your last commit (look at your GitHub Pages build log or your CI pipeline’s most recent run) and that no CDN or browser cache is serving a stale copy of feed.xml specifically. Also confirm the new post’s front matter has a date that isn’t in the future — Jekyll excludes future-dated posts from the build by default unless you’ve set future: true in _config.yml.
Yes, and it’s common — you can create multiple feed templates for different collections (e.g., one for blog posts, another for a changelog or podcast episodes), each with its own permalink. Just make sure each one has a distinct filename and permalink so they don’t overwrite each other during the build, and connect each one to PostRSS as a separate feed source if you want them posted to different social accounts or with different formatting.
Start with the deploy pipeline: confirm the feed URL you connected in PostRSS actually reflects your latest deploy by loading it directly in a browser and checking the most recent item’s date and link. If the live feed is current but PostRSS still isn’t posting, check whether the new item’s GUID is genuinely unique compared to previously posted items — if your build process is regenerating GUIDs identically across rebuilds due to a caching quirk in your feed template, the auto-poster may correctly recognize it as already-seen content.
The built-in feed is good enough for the vast majority of use cases, including auto-posting to social media. You’d only need to go beyond it — for example, adding a custom Atom template or a feed with non-standard fields — if a specific downstream service required a format Hugo’s default RSS 2.0 template doesn’t produce, which is uncommon.
It can, if the change affects the URLs used as GUIDs in already-published feed items. Since PostRSS (and most feed readers) track posted items by GUID, changing your permalink structure after posts have already gone out — without preserving the original GUIDs — can cause old posts to look “new” again and get reposted. If you’re restructuring URLs, keep the GUID field pinned to something stable (like a post’s original slug or a manually assigned id) independent of the current permalink format.
No — always connect the production feed URL, not a preview/staging deployment’s URL, which is typically ephemeral (branch previews on Netlify or Vercel get a new URL per deploy) and not intended for long-term external consumption. Connecting a preview URL will eventually break silently when that preview deployment expires or gets replaced.
Hugo gives you RSS for free — check /index.xml and you’re almost certainly already set. Jekyll gives it to you too, as long as jekyll-feed is in your Gemfile, which it usually is if you started from Minima or GitHub Pages’ defaults. Eleventy is the outlier: you have to build the feed yourself, either from the official RSS plugin’s helpers or by copying a known-good template like the one in eleventy-base-blog.
Whichever generator you’re on, the real risk isn’t the absence of a feed — it’s a feed that looks fine in a browser but quietly breaks automation: stale content from a caching issue, relative URLs that turn into broken links in your social posts, or unstable GUIDs that cause the same articles to get reposted every time you redeploy. Run your feed through a validator, confirm it survives a real deploy cycle with a real test post, and check GUID stability specifically before you trust it with unattended posting.
Once that verification is done, connecting the feed to PostRSS takes minutes, and from then on every article your build process publishes gets picked up and pushed to your connected social accounts automatically — no manual cross-posting, no extra step in your git-based workflow, just a working feed URL doing what RSS was built to do.