Add an RSS Feed AI Agents Can Actually Find

Two static-site generators build you a feed with zero configuration. One declares it in <head> on every site we tested. The other only manages it on five of every eight. Same default-on feature, same job, and the entire gap between them is one missing <link> tag. If a declared feed answers 403, see why feeds return 403 behind Cloudflare.

Hugo and Docusaurus both write RSS or Atom to disk the moment you build the site, with no plugin and no setting to turn on. Live-tested across 15 sites on each platform in early September 2026: 8 of 15 Hugo sites serve a real feed at /index.xml, but 2 of those 8 never mention it anywhere in <head>, and a third points its rel="alternate" tag at the homepage instead of the feed. Docusaurus, measured the same way, hit 9 of 15 sites publishing /blog/rss.xml and /blog/atom.xml, and all nine declared both, automatically, with no configuration. The feed existing was never the finish line. The tag that tells a reader, human or machine, where to find it is.

Updated on 4 November 2026: added the Docusaurus, Lovable and Replit sections.

Quick summary

Why a feed that exists can still be invisible

RSS and Atom autodiscovery works on one convention: a <link> element inside <head>, carrying rel="alternate" and a type of application/rss+xml or application/atom+xml, with an href pointing at the feed. A reader, an aggregator, or an agent doing periodic re-checks looks for that tag first. It does not walk a list of common paths hoping one resolves.

Think of it as an unlisted phone number: the line works, you can reach it if you already have the digits, but nobody finds it by looking you up. A blog with a perfectly valid feed at /index.xml and no <link> tag is in exactly that position, reachable by anyone who already knows the URL, invisible to anything that discovers sites the normal way. And the whole reason a feed is worth having is that it gives an outside system a fast, structured, dated list of what changed, instead of forcing it to re-crawl every page to find out. Skip the declaration and you built the shortcut without posting the sign.

This is check E5 in AIScan's content dimension, and it is a narrower check than it sounds: it looks for a working feed and a correct declaration, not for how good the feed's content is.

Path one: your platform already builds the feed, so confirm the tag

If your platform ships a feed by default, the job is verification, not construction.

1. Find your feed's real URL from the table below.
2. Fetch your homepage's HTML and search for rel="alternate": curl -s https://yoursite.com | grep -o 'rel="alternate"[^>]*'.
3. Confirm the href in that tag matches the URL from step 1: not your homepage, and not a stale path left over from a redesign.
4. If the tag is missing, wrong, or absent entirely, fix it where the table says to.

Hugo is the sharp case here, because the gap isn't "no feed"; it's a feed that exists, works, and simply never gets mentioned. If your theme was copied or heavily customized, that one line is exactly the kind of thing that gets lost in the process, and nothing about the site looking finished will tell you it happened.

Path two: your platform has no native feed, so you build both halves

Next.js, Astro, Webflow's custom code path, and Replit's default Express scaffold don't hand you a feed. You write the XML and the declaration yourself.

1. Next.js (App Router): create a route handler at app/rss.xml/route.ts that returns a Response with content-type: application/rss+xml and a hand-built XML string covering your post list. Then declare it once, site-wide, through the Metadata API rather than a hand-written tag: add alternates: { types: { "application/rss+xml": "/rss.xml" } } to your root metadata export, and Next.js renders the <link> tag for you on every page.
2. Astro: install @astrojs/rss and export a GET handler from src/pages/rss.xml.js that calls the package's rss() helper with your post collection. Astro writes a valid feed; it does not add the <link> tag, so add that by hand in your shared layout's <head>. Check the final URL against your astro.config: a global trailingSlash: "always" setting can serve the feed at /rss.xml/ instead of /rss.xml, which breaks the exact URL you just declared.
3. Webflow: each CMS Collection has its own RSS toggle in the Collection's settings, publishing at /<collection-slug>/rss.xml once turned on (the exact label has moved between Webflow versions, so check your own Collection settings panel if this doesn't match what you see). Webflow does not add the discovery tag automatically; add it yourself through a Custom Code head embed in Site Settings.
4. Replit: if your app is a default Express or similar catch-all scaffold, add an explicit route (app.get('/rss.xml', ...)) that returns real XML with the right content type, and add the <link> tag in your HTML template's <head>. A catch-all with no matching route answers everything with your app shell and a 200, including a request for a feed that was never built, and that failure mode will not show up as an error anywhere in your logs.
5. Framer: there is no native feed of any kind on the platform as of this writing. The only path is external: publish your posts through a service that exposes its own feed, such as a headless CMS or a newsletter tool with a public archive, and link to that from your site. Otherwise your Framer site opts out of feed-based discovery entirely.

Wix is a genuine gap, not an oversight. We could not confirm a documented root feed path first-party: /blog-feed.xml and /blog/feed.xml both hard-404 on Wix's own marketing site, which doesn't run Wix Blog, and its homepage carries no rel="alternate" tag at all. If you run a Wix Blog site, check your own <head> for the tag before assuming any specific path; don't copy a URL from a guide that hasn't verified it against your account type.

Platform sections

Jump to a platform: Docusaurus, Lovable, Replit. The Hugo, WordPress, Ghost, Squarespace, Next.js, Astro, Webflow, Wix and Framer notes are in the two paths above.

Docusaurus

Docusaurus is the platform where the feed usually exists before you ask for it. @docusaurus/preset-classic includes the blog plugin, and the blog plugin writes RSS and Atom files on every production build. According to the plugin's reference page, retrieved 4 November 2026, the feed "works by extracting the build output, and is only active in production". So the fix is rarely "add a feed". It is "find out why yours is missing", and there are four causes:

feedOptions: {
  type: 'all',
  limit: 50,
},

• type: 'all' adds JSON Feed at /blog/feed.json next to RSS and Atom. The specs behind the check are JSON Feed 1.1 and RFC 4287 (Atom).
• limit defaults to 20 posts. Raise it, or set it to null, if agents should see your full history.
• Author emails. RSS only shows an author when that author has an email in blog/authors.yml.
• Subpath deploys. If baseUrl is /repo-name/, request the feed at that prefix.

You never add the <link> tag yourself: the plugin injects rel="alternate" for every feed type it generates, which is why 9 of 9 Docusaurus sites in our September test declared both. A site running a second blog instance gets a second feed, so check that each one is declared and returns 200. Verify with curl -s https://yoursite.com/blog/rss.xml | head -c 300 (it should start with <?xml version="1.0" and an <rss version="2.0" element) and the head grep from the verification section below. The complete platform walkthrough is in the Docusaurus section of the setup guide.

Lovable

A sitemap tells a crawler what exists. It does not tell an agent what changed since last week, and that gap is what check E5 grades. On a Lovable app E5 fails for one of two reasons: no feed file exists, or one exists but nothing in <head> points at it. Which fix applies depends on which of Lovable's two templates the project runs.

TanStack Start. Ask Lovable to add a route file named src/routes/feed[.]xml.ts. The brackets are required: TanStack Router reads [.] as a literal period (checked against TanStack's server routes docs, 26 September 2026). Export a GET handler that reads your posts table and returns a Response with Content-Type: application/rss+xml; charset=utf-8. It runs on your own domain and updates itself, so there is no republish step. Declare the feed once in src/routes/__root.tsx, inside the head function's links array, per TanStack's document head guide.

React + Vite. There is no server to run a handler, so the feed is a plain file. Ask Lovable to generate public/feed.xml with your current posts as Atom or RSS entries and publish; files in public/ are served from the root, the same way robots.txt and llms.txt are. It works but it is frozen: every new post means editing the file and republishing. The tag is a one-time edit to the single index.html shell. If the rendering gap on E3 and C3 already has you considering the migration, doing it once covers this check too.

Verify with curl -sI https://yoursite.com/feed.xml (expect 200 and a feed content type) and the head grep below. Two exclusions: a preview-only Lovable URL fails every content check because it carries x-robots-tag: noindex, nofollow, so connect a custom domain first; and a feed with fewer than about five items reads as thin. If the scan still fails after a deploy, check the item dates first: a pubDate set to build time on every item reads as staleness. More in the Lovable section of the setup guide and the Lovable title, meta and schema fixes.

Replit

A Replit app can serve /feed.xml two completely different ways, and which one applies depends on a setting you may never have opened: the Deployment type under Adjust settings in the Publishing tool. Per Replit's deployment-types documentation (verified 28 September 2026), "Static Deployments are not compatible with Replit Apps created using Agent", so an Agent-built app is Autoscale by default. The response headers tell you which one is live:

curl -sI https://yourapp.replit.app/ | grep -i '^server\|^x-powered-by'

Autoscale or Reserved VM. Add app.get('/feed.xml', ...) that assembles the feed from whatever holds your content and sets Content-Type: application/rss+xml; charset=utf-8. Register it before any catch-all such as app.get('*', ...): a wildcard above it returns your app shell with a 200, which a status-code check misses.

Static Deployment. Set the public directory (dist for a typical Vite project) and make your build emit feed.xml there. A hand edit to the deployed file lasts only until the next publish, and a feed shipped once and never rebuilt keeps passing E5 while telling agents nothing has changed. If curl shows the wrong content type, a [[deployment.responseHeaders]] entry in .replit scoped to path = "/feed.xml" overrides it, because Content-Type is not a reserved header (Replit's Static Deployment configuration page, 28 September 2026).

Declare it with <link rel="alternate" type="application/rss+xml" title="Your Site" href="/feed.xml" /> in the template that renders your <head> on every route; on Static, edit the built index.html or your generator's layout and check that every page inherited it. Use application/atom+xml or application/feed+json to match what you built. More in the Replit section of the setup guide and the Replit llms.txt walkthrough.

Verify it, don't assume it

Two checks, in order of effort:

1. Fetch and grep. curl -s https://yoursite.com/your-feed-path should return XML starting with <?xml and either <rss version="2.0"> or <feed xmlns="http://www.w3.org/2005/Atom">. If you get HTML instead, your route isn't matching and something else, often a catch-all, is answering in its place.
2. Confirm the declaration matches the file. curl -s https://yoursite.com | grep -o 'rel="alternate"[^>]*href="[^"]*"' should print a type of application/rss+xml or application/atom+xml and an href that, fetched on its own, returns the same XML from step 1. A <link> tag pointing at your homepage, the exact failure the Hugo sweep found, passes a glance and fails this test immediately.

For a third-party read, run npx aiscan-cli yoursite.com or paste the URL at aiscan.site and read check E5. It confirms the feed resolves and is declared; it does not yet independently verify that the declared href and the working feed are the same URL, so the manual step above is still worth the ten seconds even after a clean score.

What this doesn't cover

A feed is not a substitute for llms.txt, a sitemap, or a correct 404; it's one more discovery surface, and check E5 grades only this one. It also won't help a site that publishes nothing on a schedule: a single static landing page with no blog or changelog has nothing worth putting in a feed, and adding an empty one just to pass a check is wasted effort. And a feed can silently break after you change themes or redesign your site, since the <link> tag lives in a template file that a new design doesn't automatically carry forward, so re-run the grep above after any theme change, not just once at launch.

On WordPress, this specific check needs nothing extra: wp_head() handles it without a plugin. If you're also cleaning up robots.txt, robots meta, schema, or llms.txt on the same WordPress site, ThinkRank manages all of those from one plugin instead of three fighting over the same files, which is the more common source of AI-readiness regressions than the feed tag ever is.

Next step

Run npx aiscan-cli yoursite.com (or paste your URL at aiscan.site) and read check E5 alongside D1 and C2. A site that declares its feed correctly alongside a correct robots.txt and llms.txt gives an agent three ways to find what changed instead of one. For the full platform-by-platform setup rather than just the feed, the Hugo and Docusaurus guides cover this same measurement in context, and every platform walkthrough on the blog is collected at /guides.

For adoption numbers rather than setup steps, what 340 sites with a blog actually ship breaks E5 down by format and platform.