Table of contents
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.
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.
Quick summary
| Question | Short answer |
|---|---|
| What does a feed need besides existing? | A <link rel="alternate" type="application/rss+xml"> (or atom+xml) tag in <head>, pointing at the feed's real URL |
| Fastest check | curl -s https://yoursite.com | grep -o 'rel="alternate"[^>]*' |
| Which check this is | AIScan's E5, in the content dimension |
| Auto-declared, no edits needed | Docusaurus (9 of 9 tested), Squarespace, Ghost, WordPress |
| Builds the file but not the tag | Hugo (2 of 8 tested sites silent), Next.js, Astro |
| No native feed at all | Framer, Replit's default Express scaffold |
| Format | RSS 2.0 or Atom 1.0; either is fine, readers and agents parse both |
| Documented gap | Wix: no confirmed root feed path found first-party, verify on your own site before assuming one |
| What AIScan's E5 can't see yet | Whether the <link> target actually resolves to the feed, or quietly points at your homepage instead |
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.
- Find your feed's real URL from the table below.
- Fetch your homepage's HTML and search for
rel="alternate":curl -s https://yoursite.com | grep -o 'rel="alternate"[^>]*'. - Confirm the
hrefin that tag matches the URL from step 1: not your homepage, and not a stale path left over from a redesign. - If the tag is missing, wrong, or absent entirely, fix it where the table says to.
| Platform | Feed path | Declared automatically? | If it's missing |
|---|---|---|---|
| Docusaurus | /blog/rss.xml and /blog/atom.xml | Yes, 9 of 9 sites tested declared both | Nothing to fix; re-check after a theme swap |
| WordPress | /feed/ | Yes, via wp_head() | A broken or custom theme can drop the wp_head() call; restore it |
| Ghost | /rss/ | Yes, via the theme's {{ghost_head}} helper | Confirm {{ghost_head}} still renders in your theme's <head> partial |
| Squarespace | <page-url>?format=rss | Yes, injected on every page automatically | Nothing to fix |
| Hugo | /index.xml | No, it depends on the theme; 2 of 8 tested sites omitted it, and one pointed the tag at the homepage instead | Add a <link rel="alternate" type="application/rss+xml" href="{{ \"index.xml\" | absURL }}"> line to the theme's <head> partial |
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.
- Next.js (App Router): create a route handler at
app/rss.xml/route.tsthat returns aResponsewithcontent-type: application/rss+xmland 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: addalternates: { types: { "application/rss+xml": "/rss.xml" } }to your rootmetadataexport, and Next.js renders the<link>tag for you on every page. - Astro: install
@astrojs/rssand export aGEThandler fromsrc/pages/rss.xml.jsthat calls the package'srss()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 yourastro.config: a globaltrailingSlash: "always"setting can serve the feed at/rss.xml/instead of/rss.xml, which breaks the exact URL you just declared. - Webflow: each CMS Collection has its own RSS toggle in the Collection's settings, publishing at
/<collection-slug>/rss.xmlonce 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. - 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. - 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.
Verify it, don't assume it
Two checks, in order of effort:
- Fetch and grep.
curl -s https://yoursite.com/your-feed-pathshould return XML starting with<?xmland 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. - Confirm the declaration matches the file.
curl -s https://yoursite.com | grep -o 'rel="alternate"[^>]*href="[^"]*"'should print atypeofapplication/rss+xmlorapplication/atom+xmland anhrefthat, 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.
| Check | Pass looks like | Fail looks like |
|---|---|---|
| Fetch the feed URL directly | Starts with <?xml, then <rss or <feed | Starts with <!DOCTYPE html> |
Fetch the homepage and read the tag's href | Resolves to the exact same XML as above | 404s, redirects elsewhere, or matches the homepage's own bytes |
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.
Frequently asked questions
My platform already builds a `/feed/` URL. Do I need to do anything else?
Check that it's declared. A working feed with no <link rel="alternate"> tag in <head> is reachable only by someone who already has the URL. Run the grep command in the verification section above against your own homepage before assuming it's handled.
I added the `<link>` tag but AIScan (or a feed reader) still can't find my feed. What's wrong?
Fetch the href from your own tag directly. If it 404s, redirects somewhere unexpected, or returns HTML instead of XML, the tag is pointing at the wrong path, often a leftover from a redesign or a theme migration that moved the feed without updating the declaration.
My feed loads fine at its URL but a validator flags errors. What does that mean?
The file exists and is being served, but its XML doesn't fully conform to RSS 2.0 or Atom: a missing required element, a malformed date, or invalid characters in a title are the usual causes. Paste the feed into the W3C Feed Validation Service to get the specific line; most autodiscovery consumers tolerate small issues, but a validator error is worth fixing before it compounds.
Does Wix have a documented RSS feed for my blog?
Not one we could confirm first-party. The common guessed paths hard-404 on a non-blog Wix site, and the homepage carries no autodiscovery tag. If you run Wix Blog, check your own site's <head> rather than trusting a path from any guide, this one included.
Should I use RSS 2.0 or Atom?
Either. Both formats express the same information: a list of dated items with titles, links, and content. Every mainstream reader, aggregator, and agent that consumes feeds handles both, so use whichever your platform generates by default rather than building a second format nobody asked for.
My theme update removed the `<link rel="alternate">` tag from `<head>`. How do I stop that from happening again?
You mostly can't prevent it, but you can catch it fast: add the grep command from this guide to whatever you already run after a deploy, even a one-line manual check, because a theme change is the single most common way this tag disappears, and nothing else about the site will look broken when it does.
Does adding an RSS feed help directly with AI Overviews or being cited by ChatGPT?
Not directly, and no one should promise that it does. What it does is give any system that periodically re-checks your site, including AI crawlers looking for what's new, a fast, structured way to find recent changes instead of re-fetching every page. That's a discovery improvement, not a ranking or citation guarantee.
How do I know if my `rel="alternate"` `href` actually points at the feed and not my homepage?
Fetch the href value on its own and check the first bytes. Real feed content starts with <?xml followed by <rss or <feed; a homepage returns <!DOCTYPE html>. This exact mistake, the tag technically present but pointing at the homepage, showed up in one of every eight Hugo sites we tested, so a tag existing is not proof it's correct.
Related guides
The complete AI readiness setup for Docusaurus in 2026
Docusaurus is the framework most likely to be sitting between an AI agent and the answer it is looking for. It runs a very large share of the developer documentation on the web, and developer…
The complete AI readiness setup for Hugo in 2026
Hugo hands you every byte your site emits. No plan tier decides which files exist, no editor panel hides a toggle, no vendor writes a robots.txt on your behalf. That ownership is the whole appeal,…
The complete AI readiness setup for Squarespace in 2026
Squarespace hands you a finished website and a finished discovery layer at the same time. The robots.txt is written for you, the sitemap is generated for you, and the RSS feed already exists and is…
The complete AI readiness setup for Framer in 2026
A brandnew Framer site scores better on an agent readiness scan than a new site on almost any other hosted builder, and that is exactly what makes the remaining gaps hard to see. Framer prerenders…