For pages that are really just lists you can treat them like posts on a blog.

My directory of indie web directories is one of those, it’s a collection of links that grows over time.

Since my site is built with Hugo, I:

• changed the page into a section
• made a file for each entry

and Hugo made a feed for it.

The only tweak it needed was in the RSS template, so that for this new section the <item><link> would point to the directory instead of my own site, which for me looked a bit like:

{{- $itemLink := .Permalink -}}
{{- if eq .Section "indieweb-directories" -}}
	{{- with .Params.link -}}
		{{- $itemLink = . -}}
	{{- end -}}
{{- end -}}

<item>
  <title>{{ .Title }}</title>
  <link>{{ $itemLink }}</link>

This works well for pages where updates are incremental additions, such as changelogs or collections.

It works less well for pages that are edited in place. You’d need to post what changed, which means keeping a history of revisions - something wikis do by publishing diffs.

Those updates can be harder to read, and while you could do it with Hugo, you’d have to write them manually. There’s no built-in way of creating them.

In my case it works, not because I’ve solved how to signal updates to a page, but because it turns out my page wasn’t even a page in the first place.

These are used by some feed readers to show the full content, which means my posts are now fully readable through RSS.

This is how to do that.

You might already have one

If you’re using a static site generator like Hugo, or a CMS like WordPress, then you might already have an RSS feed.

If not, and you’re writing your site manually, or just want to understand what’s going on, here’s what an RSS feed looks like.

A minimal RSS feed

At a minimum an RSS feed contains:

<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
  <channel>
    <title>Example Blog</title>
    <link>https://example.com/</link>
    <description>Updates from my blog.</description>

    <item>
      <title>Hello World</title>
      <link>https://example.com/hello-world</link>
      <description>My first post.</description>
    </item>

  </channel>
</rss>

Required

<?xml version="1.0" encoding="UTF-8"?>

This line declares the XML version of the file and the encoding that it uses. UTF-8 supports text and emoji.

It’s strongly recommended to include this line so the file is read correctly.

<rss version="2.0">

This is the start of the <rss> element. The version="2.0" tells consumers that the feed conforms to the RSS 2.0 specification, the most widely supported version.

<channel>
  <title>Example Blog</title>
  <link>https://example.com/</link>
  <description>Updates from my blog.</description>

The <channel> declares the feed itself, so <title>, <link> and <description> are used to describe the feed and its contents.

These details should match what’s displayed on your site and will show up for users when adding or managing your feed in their reader.

The <link> should point to the URL of the <channel>, which is the site itself.

<item>
  <title>Hello World</title>
  <link>https://example.com/hello-world</link>
  <description>My first post.</description>
</item>

The <item> tag is used for each post in the feed.

An <item> must contain at least one of:

• <title>
• <description>

which means you could do:

<item>
  <title>My first post</title>
</item>

which is valid, but not very useful, or:

<item>
  <description>Hello, World!</description>
</item>

which is also valid, and slightly more useful, if only for microblogs and notes and other posts without a title.

<item>
  <title>An example</title>
  <link>https://example.com/posts/1</link>
</item>

Title + link is more practical, and may be all you need, but:

<item>
  <title>An example</title>
  <link>https://example.com/posts/1</link>
  <description>Hello, World!</description>
</item>

using all three is most common.

You could use the <description> for the summary of your post or for the whole thing.

There’s no upper limit on the amount of <item>s you can include in a feed, but there are some practical things to consider:

• RSS does not do pagination
• • everything is listed in one file
• if the file gets really big then it takes longer to download
• • aim to keep it under 500KB
• maybe only show your latest posts if you have lots of them

Optional

The fields mentioned above are all that is required for a minimal feed, but there are some optional extras that are recommended.

<item>
  ...
  <guid isPermaLink="true">
    https://example.com/posts/1
  </guid>
</item>

A guid, for “Globally Unique IDentifier”, gives each item in the feed a stable identity. This means feed readers can detect and remove duplicates correctly.

This is usually the permalink of the post. If so, isPermaLink defaults to true and can be omitted, however it it’s not the permalink, like a database ID, or the exact datetime the post was published, you would change isPermaLink to false.

Note that the L in PermaLink is also capitalised.

<item>
  ...
  <pubDate>Sun, 1 Mar 2026 14:00:00 GMT</pubDate>
</item>

The <pubDate> is used to show when an item in the feed was published. It can help feed readers understand the order of your posts and should be added.

<rss version="2.0"
xmlns:atom="http://www.w3.org/2005/Atom">

Changing the <rss> tag to include xmlns:atom="http://www.w3.org/2005/Atom" is also optional but recommended.

This tells whatever is reading the feed that anything defined with atom: comes from the Atom specification, and lets you use extra tags defined by the Atom spec.

This isn’t useful by itself, but it is used when you also add:

<atom:link
href="https://example.com/index.xml"
rel="self"
type="application/rss+xml" />

which defines the URL of the feed and helps feed readers know the canonical URL of the feed itself, which helps prevent duplicate subscriptions.

<lastBuildDate>Sun, 1 Mar 2026 14:00:00 GMT</lastBuildDate>

The <lastBuildDate> can be used by feed readers to know if the feed has changed.

Set it to the date of the most recent post.

<language>en-gb</language>

You should declare the language of the feed. It’s small, but it’s technically correct.

Things to remember

RSS is pretty simple but dealing with XML means you have to remember a few things.

XML must be well-formed

Writing an RSS feed is still writing XML, and so it must obey the rules of an XML file.

This means the file must not have any missing closing tags, or mix ups with the order in which you close them.

It also means you must handle special characters, otherwise the file is invalid and won’t be understood.

For example:

<title>Special & Character</title>

won’t work, because of the &, which must be escaped:

<title>Special &amp; Character</title>

No unescaped HTML in the description

The same happens with the <description> tag, which usually holds the summary or the contents of the post, and must not include unescaped HTML characters.

The first option is to escape all of the HTML in the description:

<description>&lt;p&gt;Hello, World!&lt;/p&gt;</description>

or the more common option is to wrap the HTML content in the description in a CDATA tag:

<description><![CDATA[
<p>Hello, World!</p>
]]></description>

where CDATA tells whatever is reading the XML file that everything inside this is raw text.

Dates must be written as RFC 822

If you do use <pubDate> or <lastBuildDate> to show dates you must ensure they are written using the RFC 822 format :

<pubDate>Sun, 1 Mar 2026 14:00:00 GMT</pubDate>

Serve the file with the correct Content-Type

When your server responds to a request to show the feed it should send:

Content-Type: application/rss+xml

so that feed readers recognise it as an RSS feed.

Most static web hosting handles this for you, I only mention it in case you are setting up a server and are messing with the Content-Type of the files you serve.

How to check your feed

There are a few ways to check you’ve written your feed correctly.

Open it in a browser

The file should open and look similar to what you wrote it as. If it doesn’t open, there’s a problem, and if it shows an error then you need to fix it.

Use a validator

You can use validator.w3.org/feed to validate your feed. It can work with the URL of your feed online or you can paste in its contents if you’re still working on it.

Add it to your reader

The best test is to add your own feed to your reader and check it looks the way you want.

Make sure it’s showing in the order you expect and you can edit posts without making duplicates in your reader.

Full example

Here is a condensed version of my own RSS feed, containing two articles and a note.

The note doesn’t have a <title>, which influenced the URL used for its <guid>.

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0"
	xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
		<title>Paul Tibbetts</title>
		<link>https://paultibbetts.uk/</link>
		<description>Recent posts by Paul Tibbetts</description>
		<generator>Hugo</generator>
		<language>en-gb</language>
		<lastBuildDate>Sun, 01 Mar 2026 12:41:46 +0000</lastBuildDate>
		<atom:link href="https://paultibbetts.uk/feed.xml" rel="self" type="application/rss+xml" />
		<item>
			<title>How to create an RSS Feed</title>
			<link>https://paultibbetts.uk/2026/03/01/how-to-create-an-rss-feed/</link>
			<pubDate>Sun, 01 Mar 2026 16:33:46 +0000</pubDate>
			<guid>https://paultibbetts.uk/2026/03/01/how-to-create-an-rss-feed/</guid>
			<description>In my last post I recommended starting with RSS to make your site followable. This is how to do that.</description>
		</item>
		<item>
			<title>Ways to make your feed followable</title>
			<link>https://paultibbetts.uk/2026/03/01/ways-to-make-your-feed-followable/</link>
			<pubDate>Sun, 01 Mar 2026 11:36:03 +0000</pubDate>
			<guid>https://paultibbetts.uk/2026/03/01/ways-to-make-your-feed-followable/</guid>
			<description>You’ve got 3 posts on your site and you want people to be notified about new ones. Here’s all the ways I can think of doing that.</description>
			</item>
		<item>
			<title>2026-02-15 14:54:58</title>
			<link>https://paultibbetts.uk/2026/02/15/2026-02-15-145458/</link>
			<pubDate>Sun, 15 Feb 2026 14:54:58 +0000</pubDate>
			<guid>https://paultibbetts.uk/2026/02/15/2026-02-15-145458/</guid>
			<description>Launched: infra.paultibbetts.uk A documentation site for the infrastructure that runs paultibbetts.uk.</description>
		</item>
	</channel>
</rss>

Here’s all the ways I can think of doing that.

Email

Some sites let you send out your posts as emails.

Don’t do it. It can be tempting, because it’s easy, but emails are for emails.

There are better options for your feed.

RSS

RSS stands for “Really Simple Syndication”.

It’s a standard format for publishing a feed so apps can subscribe to your updates.

Feed readers and podcast apps use it.

It looks a bit like this:

<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
  <channel>
    <title>RSS Example Site</title>
    <link>https://example.com/</link>
    <description>Example site description.</description>

    <item>
      <title>Hello, World!</title>
      <link>https://example.com/hello-world.html</link>
      <description>My first post.</description>
    </item>

  </channel>
</rss>

You would host a file like this, link to it from the <head> part of your pages, and readers would check it occasionally for updates.

Its simplicity means it’s supported by almost all feed reading apps.

Because of this I’d say RSS is the best starting point for letting users subscribe to your posts and is worth adding to your site first, before the other alternatives.

Atom

RSS isn’t the only way to create an XML feed. Atom is another standard which is more formally specified.

In the early 2000’s, after Atom’s launch, there was a time called the “RSS vs Atom wars”. There was no real winner. Atom was decided to be technically better, but by then RSS had already become dominant.

These days you can add a few Atom elements to your RSS feed, like a rel=self link, to get the best of both worlds.

JSON

JSON feed is the one of the newer standards. It works in the same way as RSS and Atom but the data is presented as JSON instead of XML.

Web development has moved on from XML and these days JSON-based things are much more common. The idea is that by using JSON we allow developers to build new things like feed readers using modern techniques and tooling, instead of ones used only for legacy publishing steps like an XML-based feed.

It looks a bit like this:

{
  "version": "https://jsonfeed.org/version/1.1",
  "title": "Example JSON Feed Site",
  "home_page_url": "https://example.com/",
  "feed_url": "https://example.com/feed.json",
  "items": [
    {
      "id": "2026-02-28-153000",
      "url": "https://paultibbetts.uk/notes/2026-02-28-153000/",
      "content_html": "<p>Hello world</p>",
      "date_published": "2026-02-28T15:30:00Z"
    }
  ]
}

JSON feed is already supported by many feed readers and, at least in theory, makes it easier than XML-based feeds to make new ones.

I’d say it’s worth adding to your site after you’ve got an RSS feed, since those are more universally supported right now.

Microformats

Microformats is a standard for marking up the contents of your posts, and in doing so makes your feed followable without any other files.

Classes like h-entry and h-card help others to understand the content you’re publishing, and the h-feed class is used to identify feeds. This means readers using apps that understand microformats can subscribe to your content directly, without needing an XML or JSON file.

Right now most feed readers expect RSS or Atom feeds, so whilst I would suggest adding microformats, I would do it after adding an RSS feed.

Social media

There’s also social media, where you would post a link to your content on another site, like Facebook or Instagram.

It’s a great way to get your posts in front of users across the web on the apps they’re already using, but it’s no longer on your own site and you’re now at the mercy of whatever the algorithms think of your content.

I’d consider doing this as an extra, and only after making your own feed available.

For more information on posting out to social media the IndieWeb.org wiki has a great page called Publish Own Site, Syndicate Elsewhere (POSSE) .

ActivityPub

Another option is to use the ActivityPub protocol for your content.

ActivityPub is what powers Fediverse apps like Mastodon and making your content available through it makes your site part of the Fediverse itself. Readers can then subscribe using whatever Fediverse app they want.

This involves a lot of work, and is difficult to implement for static sites, so hosted solutions like Bridgy Fed can be used to do this for you.

All of the above

The best option could even be to do all of the above, to give your readers freedom to choose the method that works for them.

If you want the most compatible way to let others follow your posts: start with RSS.

Then add alternatives after.