Driven by curiosity, I decided to find out what the IndieWeb tag that kept showing up on some blogs and Mastodon toots was all about. I quickly discovered it was more than an empty concept or a feeling of nostalgia for the web of the 90s. It was a movement with concrete ideas, protocols and an active community! As I read through their wiki, I understood their position and the intelligence of their proposals more and more. Such was my enthusiasm that I decided to follow their advice and adopt the protocols that made sense for my site. After finishing the tests and adjustments, I can confirm that the experience has been very positive: I have learned a lot, the UX of my website has improved a bit more, and I enjoyed the process.

That is why I decided to write this article, cleaning up my notes from these last few months. Maybe it will help someone else discover it, and along the way, improve the health of the web. And for the nosy ones, I will also tell you which pieces I implemented, which ones I discarded and why, and which pieces of advice turned out to be the most useful.

But first, we need to answer a fundamental question.

The IndieWeb defines itself as "a people-focused alternative to the corporate web". It does not propose a piece of software or a framework, but an ideological foundation. It deliberately embraces a plurality of approaches and projects. As its homepage says: "we are people-focused instead of project-focused".

It all started in 2010, when Aaron Parecki and Tantek Çelik attended the Federated Social Web Summit in Portland. They left with the feeling that a different approach was needed: fewer protocols and more creators. In 2011 the first IndieWebCamp was held in Portland, and they have been celebrated every year around the world ever since, along with the Homebrew Website Club, meetups where people get together to improve their personal websites.

The 3 pillars that define it are:

• Your content is yours: when you post something on the web, it should belong to you, not a corporation. Too many companies have shut down and taken their users' data with them.
• You are better connected: your articles can be distributed to any platform, not just one, and responses and likes from other services can come back to your site so you have everything in one place.
• You are in control: you can post anything you want, in any format you want, with readable and permanent URLs that will always work.

So we could say it is a community of personal, independent websites that share these commitments.

That is also why it does not forbid you from using social networks, but it does fight against walled gardens.

The enemy has a name: the silo

The entire IndieWeb vocabulary is built in opposition to one concept: the silo, also called a walled garden. The wiki defines it as a centralized website, typically owned by a for-profit corporation, that claims some rights over the content you contribute and restricts access in some way. Its characteristics:

• They require you to create a site-specific account to participate.
• They only let you interact with other accounts on the same site.
• And they typically add: restrictive terms of service, license claims over what you create inside, walls that prevent indexing, or barriers to importing and exporting your content.

Why is this a problem? Because silos die, and when they die they take your content with them. The site-deaths page ("Where incredible journeys end", a nod to the corporate euphemism our incredible journey) keeps a devastating chronology:

• GeoCities: Yahoo shut it down on October 26, 2009. 23 million pages gone.
• MySpace: in 2019, during a server migration, it lost all the music uploaded during its first 12 years, more than 50 million songs from 14 million artists.
• Google+: shut down in April 2019.
• Posterous, FriendFeed, Vine, Yahoo Groups, TinyLetter, Cohost... the list keeps growing, and it even has sections for "upcoming deaths" and for acquisitions, which tend to foreshadow them.

The silo does not even need to die: the web is fragile by default. According to a 2024 Pew Research study, 38% of the web pages that existed in 2013 were no longer accessible a decade later.

The IndieWeb's conclusion is not "don't use social networks". It is more subtle: use whatever you want, but make sure the canonical copy of your content lives on a domain you control.

That is why it defines a set of principles to fight against the fragility of the network.

The principles

The community is guided by 11 principles:

1. Own your data: your content, your metadata and your identity live under your domain, and you retain access to them over time.
2. Use and publish visible data: for humans first, machines second. No parallel APIs if the HTML can carry the data.
3. Make what you need: build tools for yourself, not for some hypothetical user. "If you design for some hypothetical user, they may not actually exist; if you make for yourself, you actually do exist."
4. Use what you make: use what you build every day. "If you aren't depending on it, why should anybody else?"
5. Document your stuff: you already have a place to speak your mind, use it to document your processes, ideas and code. You help others and your future self.
6. Open source your stuff: not mandatory, but it helps others get onto the independent web faster.
7. UX before protocols: user experience first, and then the simplest, most minimal protocol sufficient to support it, and nothing more. They sum it up as "UX before plumbing".
8. Modularity: small, loosely coupled pieces, so you don't depend on a specific device, language or platform.
9. Longevity: build for the long web. "If human society is able to preserve ancient papyrus, Victorian photographs and dinosaur bones, we should be able to build web technology that doesn't require us to destroy everything we've done every few years in the name of progress."
10. Plurality: deliberately encouraging diverse approaches makes the community more resilient than any monoculture.
11. And above all, have fun: remember the web of the 90s, GeoCities, loud backgrounds and animated GIFs. "It may have been ugly and badly coded but it was fun. Keep the web weird and interesting."

The numbering is just for reference, not a priority. The community does not demand that you fulfill them all, but it does ask you to keep them in mind.

But the IndieWeb does not live on principles alone. There is a set of standards that helps make your sites more open, interoperable and resistant to disappearing.

The technical part

The IndieWeb does not invent a platform; it defines a handful of small standards that compose with each other. The official index orders them by age and breadth of implementation.

Let's go one by one.

The starting point: your domain

It is not a protocol, but it is the prerequisite for everything else: your own domain used as your primary identity online. It is the first step of the Getting Started guide and the bare minimum the community considers necessary to be "on" the IndieWeb. If tomorrow you change hosting or CMS while keeping the domain, all your links, readers and search rankings survive the move.

microformats2: your HTML is your API

microformats2 solves one problem: making your content machine-readable without publishing parallel files or building an API.

The implementation is elegant, since it uses CSS classes that you add to the HTML you already have. The prefixes indicate the data type: h-* for roots, p-* for plain text, u-* for URLs, dt-* for dates and e-* for embedded HTML. The two essential vocabularies:

h-card is your identity: the online equivalent of a business card. With a minimum of name, URL and photo on your homepage, readers show your profile next to your posts and applications recognize you. It works like a domain-based Gravatar instead of an email-based one:

<a class="h-card" href="https://example.com">
  <img src="/photo.png" alt="" />
  Jane Doe
</a>

h-entry is the unit of content: the markup of a post. The wiki calls it "the key building block for the indieweb":

<article class="h-entry">
  <h1 class="p-name">Article title</h1>
  <p>By <a class="p-author h-card" href="https://example.com">Jane Doe</a>,
     <time class="dt-published" datetime="2026-07-19">July 19, 2026</time></p>
  <div class="e-content">
    <p>The post content...</p>
  </div>
</article>

There is also h-feed, which groups several h-entry elements to turn your listing page into a feed you can subscribe to straight from the HTML.

The wiki sums it up in a phrase I love:

Your website is your API

For reading, microformats; for writing, Micropub (we'll get there).

rel-me is the simplest piece and the one with the most immediate effect. An attribute on a link that says "the destination of this link represents the same person as the current page":

<a href="https://mastodon.social/@jane" rel="me">Mastodon</a>

Verification requires reciprocity: your website links to the profile and the profile links back to your website, both with rel="me". With that you get distributed identity verification, with no central authority involved. It is exactly the mechanism behind Mastodon's green verified checkmark: if your page links to your profile with rel-me and your profile links back, Mastodon shows your domain as verified. It is also supported by Threads, PixelFed, GitHub, Keybase and Wikipedia.

On top of rel-me sits RelMeAuth: authenticating on services with your personal URL, delegating the identity proof to an OAuth provider (like GitHub) that your homepage links to. It is the foundation of services like IndieLogin.

Webmention: conversations between sites

Webmention is the star standard, a W3C Recommendation since January 12, 2017, and the modern successor of Pingback. It solves conversations between sites: comments, likes, replies and reposts from web to web, with no platform in between. Many people use it as a replacement for Disqus.

The flow is deliberately simple:

1. I write a post that links to an article of yours.

2. My server visits your article and looks for your endpoint: an HTTP header Link: <...>; rel="webmention" or a <link rel="webmention"> in the HTML.

3. It sends a POST with only two parameters: source (my post) and target (yours).

   POST /webmention HTTP/1.1 Host: your-site.com Content-Type: application/x-www-form-urlencoded

   source=https://my-site.com/my-post&target=https://your-site.com/your-article

4. Your server verifies the mention: the specification requires downloading the source and checking that it really contains a link to the target. Without that verification, anyone could fabricate fake mentions.

5. Once verified, your site decides what to do with it. And here is where microformats comes in: by parsing the h-entry of the source you know whether it is a reply (u-in-reply-to), a like (u-like-of) or a repost (u-repost-of), and the author's h-card lets you display their name and photo like in any comment section.

If this sounds like a social network to you, that's because it is! Every site is a node in the network, and the links between them form the social graph.

It is not a perfect system, since it suffers from the same problems as any other decentralized network, which is why there are a couple of extensions that attack its weak points:

• Vouch, against spam: the webmention carries a third parameter with the URL of a "voucher", a site you already know that links to the sender's domain. It shifts the filtering cost from the receiver to the sender.
• Salmention, to propagate threads: if someone replies to a comment on my post, the original post finds out by re-sending update webmentions to everyone involved.

You don't escape spam or moderation. However, it is a good foundation for building a distributed comment system.

What if your website has no backend? You are not left out: webmention.io receives webmentions on your behalf. You add a <link> in your HTML pointing to the service and it gives you an API to query and display them. It is exactly what you need if you use a static site generator like Hugo, Jekyll or Eleventy.

IndieAuth: your domain as your login

IndieAuth answers the question: what if your identity for signing in were your URL, instead of "you on Google" or "you on Facebook"? Technically it is OAuth 2.0, the standard for authentication and authorization. Both users and applications are identified by URLs, which removes the need for prior client registration ("IndieAuth uses DNS as a replacement for client registration"), and PKCE is mandatory (a security mechanism that prevents an attacker from stealing the access token).

The flow in a nutshell: you type your domain in the login form, the service fetches your page and discovers your authorization server via rel="indieauth-metadata", redirects you there, you authenticate however you prefer (password, email, RelMeAuth), and the service receives confirmation that you control that URL. It is a living standard that the community considers stable.

Micropub: publish from any client

Micropub, a W3C Recommendation since May 2017, separates the publishing interface from your site's software: any application (web, iOS, Android) can create, edit and delete posts on your domain. It replaces the old MetaWeblog and AtomPub, which depended on sharing your password, with OAuth tokens obtained via IndieAuth.

The beautiful part is its vocabulary: it does not invent one, it is serialized microformats. Creating a post is a POST with h=entry and the same h-entry properties:

curl https://your-site.com/micropub \
  -d h=entry \
  -d "content=Hello world" \
  -H "Authorization: Bearer XXXXXXX"

If you are already used to working with REST APIs, it will feel very natural.

WebSub: real-time feeds

WebSub, formerly known as PubSubHubbub, a W3C Recommendation since January 2018, removes feed polling: instead of a thousand readers asking your server every half hour whether there is something new, you notify a hub when you publish and the hub instantly notifies all subscribers via webhooks. It reduces the load on your server and updates arrive without delay.

Many feed readers and aggregators support WebSub, such as Feedly or NewsBlur.

Microsub: the decoupled reader

Microsub is the youngest standard and still a draft. Think of it as the infrastructure that ties everything together into a social reading application.

There are 2 layers: a server that does the plumbing (managing subscriptions, fetching and parsing feeds, normalizing data) and a client that only renders the reading interface. This way clients compete on UX and your subscriptions are portable between them. Combined with Micropub to reply from the reader and Webmention to notify, it forms the complete architecture of the IndieWeb "social reader".

Publishing strategy: POSSE, PESOS and backfeed

Besides the principles and the protocols, the IndieWeb offers a mental model for coexisting with social networks without giving them your content:

POSSE (Publish on your Own Site, Syndicate Elsewhere): publish on your site first and then push copies to the networks, each one with a link to the original. It is the recommended technique. Your friends keep reading you where they already are, you keep the canonical copy, and if the network shuts down or bans you tomorrow, you lose nothing. The term was coined by Tantek Çelik in 2012, and it is practiced by everyone from Cory Doctorow on Pluralistic to Molly White, who repopularized it in 2024. A nice detail from the wiki: linking to the original from the copy is also "internet aikido" against spammers who copy posts, because they copy the link that credits you too.

PESOS (Publish Elsewhere, Syndicate to your Own Site): the reverse path, publishing on the silo and archiving a copy on your site afterwards. The wiki is honest about its advantages (silo apps are very polished, and it is asynchronous: if your website goes down, you can still publish), but considers it inferior: you publish subject to the silo's terms from the very first second, your copy is not the canonical one and you inherit its limits, like character caps or links wrapped in t.co.

Backfeed: the reverse syndication of interactions. The likes, replies and reposts that your POSSE copies receive on the networks come back to your original post as webmentions. This way the full conversation is archived on your domain, safe from the next silo death. The reference service is Bridgy: it watches your copies on Mastodon, GitHub, Flickr, Reddit or Bluesky and sends you a webmention for each interaction.

In short: you publish on your site, you syndicate to the silos with a link back, and the reactions come back home converted into webmentions.

Relationship with the Fediverse, RSS and friends

It may surprise you, but the IndieWeb does not live isolated from the Fediverse. Fun fact: protocols like Webmention, Micropub and WebSub came out of the same place, the W3C Social Web Working Group. The same group also gave birth to the famous ActivityPub, the protocol of the Fediverse. They are first cousins, although they follow different philosophies.

The Fediverse federates servers: your identity is @user@instance, and if you don't run your own instance, you depend on someone else's. The wiki does not mince words: joining a Mastodon instance means going "from one silo, to a perhaps more open source-based and more open standards supporting silo, yet still dependent on another central org", with the aggravating factor of the admintax, the brutal cost of moderating and maintaining an instance. The IndieWeb federates websites: your identity is your domain and federation is just one more channel.

However, they are not incompatible. Bridgy Fed is the bridge that converts your h-card, your h-entry and your webmentions to ActivityPub (and Bluesky's AT Protocol) and vice versa. The result is that your domain becomes a Fediverse account of the form @example.com@example.com where people can find and follow you from Mastodon, and replies come back to your post as backfeed. Mastodon understands that your profile and your posts live on your site.

RSS/Atom feeds, however, are a different story, since the IndieWeb considers them formats with structural problems. The argument is the DRY principle: the content is already in your HTML, so maintaining a parallel XML copy is a "maintenance tax", a separate code path that can drift out of sync, weighs more (there are Atom files up to 4.5 times larger than their HTML equivalent) and offers a terrible experience when a human clicks on the feed link. Their alternative is h-feed: the HTML itself as the feed. But as so often happens, being technically superior does not mean being accepted. They themselves admit that very few readers support microformats. Therefore, they recommend h-feed for the IndieWeb and RSS/Atom for the rest of the planet.

How to get started

The Getting Started guide recommends these steps, in this order:

1. Get your domain and use it as your primary identity online. A concrete tip they give: consider the registrar's whois privacy options, but only if you fully trust the provider, because ownership disputes get complicated if you are not listed as the legal owner.
2. Set up hosting: a managed service if you are starting out (they mention GitHub Pages, Netlify, Neocities...), self-hosting if you know what you are doing.
3. Create your pages: static site generator, handwritten HTML or a CMS, it doesn't matter. There is no official technology, and that is deliberate (the plurality principle).
4. Syndicate to other platforms (POSSE) with links back to the original.
5. Add microformats: rel="me" links to your profiles on the homepage and h-entry markup on your posts.
6. Validate your work with IndieWebify.me, which checks your rel-me, your h-card and your h-entry step by step.
7. Join the community: share what you build even if it is a single page, and document it on the wiki for the next person.

For those who want a more gradual path there is IndieMark, a scale of levels, an orientation guide for developers.

What I have implemented (and what I have not)

I promised you at the beginning that I would tell you which pieces I implemented, which ones I discarded and why. Here is the list:

• ✅ Webmention, sending and receiving. Sending is automated with a daily task that notifies the external links of new articles, with a 24-hour margin to fix typos before telling anyone. I use the receiving side to include a list of references at the end of each article. However, I keep it separate from my comments, since those are managed by email.
• ✅ h-entry on every article and h-card on the homepage, verified with mf2py.
• ✅ rel="me" in the footer pointing to Mastodon, GitHub and Org Social, with its corresponding green checkmark.
• ❌ Micropub and IndieAuth: a conscious decision. My publishing interface is my editor and git; articles are versioned markdown. A publishing endpoint gives me nothing.
• ❌ WebSub: evaluated and discarded. Since my publishing is deliberately delayed by 24 hours, "real time" does not justify the complexity.
• ❌ h-feed: my article cards are reused in other contexts, such as the suggestions that appear inside each article, and marking them up would generate ambiguous h-entries for parsers. If I had designed the templates with this structure in mind, it would have been different. RSS covers that role just fine.

But the advice that helped me the most is not technical, it is about philosophy and web design ethics. Scattered across the wiki, it is worth gold with or without the IndieWeb. My selection:

• Plain HTML is the most durable format. You can read the whole web without using JavaScript.
• Cool URIs don't change: design permalinks you can maintain forever. For example, I can change the slug of an article and it will still work.
• Gradual commitment, silo by silo: no exodus needed. Every type of content you start publishing on your own site first is a step forward in owning your data.
• Think about extreme longevity: the wiki seriously discusses what happens to your website when you die, from the "dead man's switch" that hands the keys to someone you trust, to the practical problem Peter Molnar sums up as: "who's going to pay for your domain if you're not?".

And... have fun. An imperfect, weird personal website is worth more than a spotless template you are bored of maintaining.