Me pasé a la IndieWeb y esto es lo que aprendí

Empujado por mi curiosidad, decidí investigar qué era el tag IndieWeb que aparecía en algunos blogs y toots de Mastodon. Descubrí rápidamente que era algo más que un concepto vacío o un sentimiento de nostalgia por la web de los 90. ¡Era un movimiento con ideas concretas, protocolos y una comunidad activa! Según leía su wiki, cada vez comprendía su postura y la inteligencia de sus propuestas. Tal fue mi entusiasmo que decidí seguir sus consejos y los protocolos que tenían sentido con mi sitio. Después de terminar las pruebas y ajustes, puedo confirmar que la experiencia ha sido muy positiva, he aprendido bastante, ha mejorado un poco más la UX de mi web y he disfrutado del proceso.

Por ello, he decidido escribir este artículo pasando a limpio mis notas de estos últimos meses. Tal vez consiga con ello que alguien más lo descubra, y de paso, mejore la salud de la web. Además, para los más cotillas, te contaré qué piezas he implementado, cuáles descarté y por qué, y qué consejos me han resultado más útiles.

Pero antes, hay que resolver una pregunta fundamental.

Qué es la IndieWeb

La IndieWeb se define a sí misma como "una alternativa centrada en las personas frente a la web corporativa". No propone un software o framework, sino una base ideológica. Abraza deliberadamente la pluralidad de enfoques y proyectos. Como dice su portada: "somos people-focused en vez de project-focused".

Todo empezó en 2010, cuando Aaron Parecki y Tantek Çelik asistieron al Federated Social Web Summit de Portland. Salieron de allí con la sensación de que hacía falta otro enfoque con menos protocolos y más creators. En 2011 se organizó la primera IndieWebCamp en Portland, y desde entonces se celebran cada año por todo el mundo, junto a los Homebrew Website Club, meetups de gente que se junta a mejorar su web personal.

Los 3 pilares que lo definen son:

• Tu contenido es tuyo: cuando publicas algo en la web debería pertenecerte a ti, no a una corporación. Demasiadas empresas han cerrado llevándose los datos de sus usuarios.
• Estás mejor conectado: tus artículos pueden distribuirse a cualquier plataforma, no solo a una, y las respuestas y likes de otros servicios pueden volver a tu sitio para tenerlo todo en un solo lugar.
• Tienes el control: publicas lo que quieras, en el formato que quieras, con URLs legibles y permanentes que siempre funcionarán.

Por lo tanto, podríamos decir que es una comunidad de webs personales e independientes que comparten estos compromisos.

Por ello mismo no te prohíbe usar redes sociales, pero sí lucha contra los jardines vallados.

El enemigo tiene nombre: el silo

Todo el vocabulario IndieWeb se construye por oposición a un concepto: el silo, también llamado jardín vallado. La wiki lo define como un sitio web centralizado, típicamente propiedad de una corporación con ánimo de lucro, que reclama algún derecho sobre el contenido que aportas y restringe el acceso de alguna forma. Sus características:

• Exigen crear una cuenta propia del sitio para participar.
• Solo permiten interactuar con otras cuentas del mismo sitio.
• Y típicamente añaden: términos de servicio restrictivos, reclamación de licencia sobre lo que creas dentro, muros que impiden la indexación, o trabas para importar y exportar tu contenido.

¿Por qué es un problema? Porque los silos mueren, y cuando mueren se llevan tu contenido. La página site-deaths ("donde terminan los viajes increíbles", en referencia al eufemismo corporativo our incredible journey) mantiene una cronología demoledora:

• GeoCities: Yahoo lo cerró el 26 de octubre de 2009. 23 millones de páginas desaparecidas.
• MySpace: en 2019 perdió en una migración de servidores toda la música subida durante sus primeros 12 años, más de 50 millones de canciones de 14 millones de artistas.
• Google+: cerrado en abril de 2019.
• Posterous, FriendFeed, Vine, Yahoo Groups, TinyLetter, Cohost... la lista sigue creciendo, y tiene secciones de "próximas muertes" y de adquisiciones que suelen anticiparlas.

No hace falta ni que el silo muera: la web es frágil por defecto. Según un estudio de Pew Research de 2024, el 38% de las páginas web que existían en 2013 ya no eran accesibles una década después.

La conclusión de la IndieWeb no es "no uses redes sociales". Es más sutil: usa lo que quieras, pero que la copia canónica de tu contenido viva en un dominio que controles tú.

Por ello define una serie de principios para luchar contra la fragilidad de la red.

Los principios

La comunidad se rige por 11 principios:

1. Own your data: tu contenido, tus metadatos y tu identidad viven bajo tu dominio, y conservas el acceso a ellos a lo largo del tiempo.
2. Usa y publica datos visibles: para humanos primero, para máquinas después. Nada de APIs paralelas si el HTML puede llevar los datos.
3. Make what you need: construye herramientas para ti, no para un usuario hipotético. "Si diseñas para un usuario hipotético, puede que no exista; si construyes para ti, tú sí existes."
4. Use what you make: usa a diario lo que construyes. "Si tú no dependes de ello, ¿por qué debería hacerlo nadie más?"
5. Document your stuff: ya tienes un sitio donde hablar, úsalo para documentar tus procesos, ideas y código. Ayudas a otros y a tu yo futuro.
6. Open source your stuff: no es obligatorio, pero acelera que otros lleguen a la web independiente.
7. UX antes que protocolos: primero la experiencia de usuario, y después el protocolo más simple y mínimo que la soporte, y nada más. Lo resumen como "UX before plumbing".
8. Modularidad: piezas pequeñas débilmente acopladas, para no depender de un dispositivo, lenguaje o plataforma concretos.
9. Longevidad: construye para la web a largo plazo. "Si la humanidad sabe conservar papiros antiguos, fotografías victorianas y huesos de dinosaurio, deberíamos poder construir tecnología web que no nos obligue a destruir todo lo hecho cada pocos años en nombre del progreso."
10. Pluralismo: fomentar deliberadamente enfoques diversos hace a la comunidad más resistente que cualquier monocultivo.
11. Y por encima de todo, have fun: recuerda la web de los 90, GeoCities, fondos chillones y GIFs animados. "Puede que fuera fea y estuviera mal programada, pero era divertida. Mantén la web rara e interesante."

La numeración es solo una referencia, no una prioridad. La comunidad no exige que los cumplas todos, pero sí que los tengas presentes.

Pero no solo de principios vive la IndieWeb. Hay un conjunto de estándares que ayuda a que tus sitios sean más abiertos, interoperables y resistentes a la desaparición.

Parte técnica

La IndieWeb no inventa una plataforma, sino que define un puñado de estándares pequeños que se componen entre sí. El índice oficial los ordena por edad y grado de implementación.

Vamos uno a uno.

El punto de partida: tu dominio

No es un protocolo, pero es el requisito previo de todo lo demás: un dominio propio usado como tu identidad principal online. Es el primer paso de la guía Getting Started y lo mínimo que la comunidad considera necesario para estar "en" la IndieWeb. Si mañana cambias de hosting o de CMS manteniendo el dominio, todos tus enlaces, lectores y posiciones en buscadores sobreviven al cambio.

microformats2: tu HTML es tu API

microformats2 resuelve un problema: que tu contenido sea legible por máquinas sin publicar ficheros paralelos ni montar una API.

La implementación es elegante, ya que usa clases CSS que debes incorporar al HTML que ya tienes. Los prefijos indican el tipo de dato: h-* para raíces, p-* para texto plano, u-* para URLs, dt-* para fechas y e-* para HTML embebido. Los dos vocabularios esenciales:

h-card es tu identidad: el equivalente online de una tarjeta de visita. Con un mínimo de nombre, URL y foto en tu portada, los lectores muestran tu perfil junto a tus posts y las aplicaciones te reconocen. Funciona como un Gravatar basado en dominio en lugar de email:

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

h-entry es la unidad de contenido: el marcado de un post. La wiki lo llama "el building block clave de la IndieWeb":

<article class="h-entry">
  <h1 class="p-name">Título del artículo</h1>
  <p>Por <a class="p-author h-card" href="https://example.com">Jane Doe</a>,
     <time class="dt-published" datetime="2026-07-19">19 de julio de 2026</time></p>
  <div class="e-content">
    <p>El contenido del post...</p>
  </div>
</article>

Existe también h-feed, que agrupa varios h-entry para convertir tu página de listado en un feed suscribible desde el propio HTML.

La wiki lo resume en una frase que me encanta:

Your website is your API

Para leer, microformats; para escribir, Micropub (luego llegamos).

rel="me": identidad verificada sin autoridad central

rel-me es la pieza más sencilla y la de efecto más inmediato. Un atributo en un enlace que dice "el destino de este enlace representa a la misma persona que esta página":

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

La verificación exige reciprocidad: tu web enlaza al perfil y el perfil enlaza de vuelta a tu web, ambos con rel="me". Con eso consigues verificación de identidad distribuida, sin ninguna autoridad central de por medio. Es exactamente el mecanismo del tick verde de Mastodon: si tu página enlaza a tu perfil con rel-me y tu perfil enlaza de vuelta, Mastodon muestra tu dominio como verificado. Lo soportan también Threads, PixelFed, GitHub, Keybase o la Wikipedia.

Sobre rel-me se construye RelMeAuth: autenticarte en servicios con tu URL personal, delegando la prueba de identidad en un proveedor OAuth (como GitHub) al que tu home enlaza. Es la base de servicios como IndieLogin.

Webmention: conversaciones entre sitios

Webmention es el estándar estrella, W3C Recommendation desde el 12 de enero de 2017, y el sucesor moderno del Pingback. Resuelve las conversaciones entre sitios: comentarios, likes, respuestas y reposts de web a web, sin plataforma intermedia. Mucha gente lo usa como sustituto de Disqus.

El flujo es de una simplicidad deliberada:

1. Escribo un post que enlaza a un artículo tuyo.
2. Mi servidor visita tu artículo y busca tu endpoint: una cabecera HTTP Link: <...>; rel="webmention" o un <link rel="webmention"> en el HTML.
3. Le envía un POST con solo dos parámetros: source (mi post) y target (el tuyo).

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

source=https://mi-sitio.com/mi-post&target=https://tu-sitio.com/tu-articulo

1. Tu servidor verifica la mención: la especificación obliga a descargar el source y comprobar que de verdad contiene un enlace al target. Sin esa verificación, cualquiera podría fabricar menciones falsas.
2. Una vez verificada, tu sitio decide qué hacer con ella. Y aquí entra microformats: parseando el h-entry del source se sabe si es una respuesta (u-in-reply-to), un like (u-like-of) o un repost (u-repost-of), y el h-card del autor permite mostrar su nombre y su foto como en cualquier sección de comentarios.

Si te parece una red social, ¡es que lo es! Cada sitio es un nodo de la red, y los enlaces entre ellos forman el grafo social.

No es un sistema perfecto, ya que sufre los mismos problemas que cualquier otra red descentralizada, por ello hay un par de extensiones que atacan sus puntos débiles:

• Vouch, contra el spam: la webmention lleva un tercer parámetro con la URL de un "avalista", un sitio que tú ya conoces y que enlaza al dominio del emisor. Traslada el coste del filtrado del receptor al emisor.
• Salmention, para propagar hilos: si alguien responde a un comentario de mi post, el post original se entera reenviando webmentions de actualización a todos los implicados.

No te libras ni del spam ni de la moderación. Sin embargo, es una buena base para construir un sistema de comentarios distribuido.

¿Y si tu web no tiene backend? No estás fuera: webmention.io recibe las webmentions por ti. Añades un <link> en tu HTML apuntando al servicio y te ofrece una API para consultarlas y mostrarlas. Es justo lo que necesitas si usas un generador de sitios estáticos como Hugo, Jekyll o Eleventy.

IndieAuth: tu dominio como login

IndieAuth responde a la pregunta: ¿y si tu identidad para iniciar sesión fuera tu URL, en vez de "tú en Google" o "tú en Facebook"? Técnicamente es OAuth 2.0, el estándar de autenticación y autorización. Tanto usuarios como aplicaciones se identifican mediante URLs, lo que elimina el registro previo de clientes ("IndieAuth usa DNS como sustituto del registro de clientes"), y PKCE es obligatorio (un mecanismo de seguridad que evita que un atacante robe el token de acceso).

El flujo resumido: escribes tu dominio en el formulario de login, el servicio descarga tu página y descubre tu servidor de autorización vía rel="indieauth-metadata", te redirige allí, te autenticas como tú prefieras (contraseña, email, RelMeAuth), y el servicio recibe la confirmación de que controlas esa URL. Es un living standard que la comunidad considera estable.

Micropub: publica desde cualquier cliente

Micropub, W3C Recommendation desde mayo de 2017, separa la interfaz de publicación del software de tu sitio: cualquier aplicación (web, iOS, Android) puede crear, editar y borrar posts en tu dominio. Sustituye a los antiguos MetaWeblog y AtomPub, que dependían de compartir tu contraseña, por tokens OAuth obtenidos vía IndieAuth.

Lo bonito es su vocabulario: no inventa uno, es microformats serializado. Crear un post es un POST con h=entry y las mismas propiedades del h-entry:

curl https://tu-sitio.com/micropub \
  -d h=entry \
  -d "content=Hola mundo" \
  -H "Authorization: Bearer XXXXXXX"

Si ya estás acostumbrado a interactuar con APIs REST, sentirás que es muy natural.

WebSub: feeds en tiempo real

WebSub, antes conocido como PubSubHubbub, W3C Recommendation desde enero de 2018, elimina el polling de los feeds: en vez de que mil lectores pregunten a tu servidor cada media hora si hay algo nuevo, tú avisas a un hub cuando publicas y el hub notifica al instante a todos los suscriptores mediante webhooks. Reduce la carga de tu servidor y las novedades llegan sin espera.

Muchos lectores y agregadores de feeds soportan WebSub, como Feedly o NewsBlur.

Microsub: el lector desacoplado

Microsub es el estándar más joven y aún es un borrador. Considéralo como la infraestructura que une todo en un software de lectura social.

Hay 2 capas: un server que hace la fontanería (gestionar suscripciones, descargar y parsear feeds, normalizar datos) y un cliente que solo pinta la interfaz de lectura. Así los clientes compiten en UX y tus suscripciones son portables entre ellos. Combinado con Micropub para responder desde el lector y Webmention para notificar, forma la arquitectura completa del "social reader" IndieWeb.

Estrategia de publicación: POSSE, PESOS y backfeed

Además de los principios y los protocolos, la IndieWeb aporta un modelo mental para convivir con las redes sociales sin regalarles tu contenido:

POSSE (Publish on your Own Site, Syndicate Elsewhere): publica primero en tu sitio y después empuja copias a las redes, cada una con un enlace al original. Es la técnica recomendada. Tus amigos siguen leyéndote donde ya están, tú conservas la copia canónica, y si mañana la red cierra o te banea, no pierdes nada. El término lo acuñó Tantek Çelik en 2012, y lo practican desde Cory Doctorow en Pluralistic hasta Molly White, que lo repopularizó en 2024. Un detalle fino de la wiki: enlazar al original desde la copia es también "aikido de internet" contra los spammers que copian posts, porque copian también el enlace que te acredita.

PESOS (Publish Elsewhere, Syndicate to your Own Site): el camino inverso, publicar en el silo y archivar después una copia en tu sitio. La wiki es honesta con sus ventajas (las apps de los silos están muy pulidas, y es asíncrono: si tu web se cae, sigues publicando), pero lo considera inferior: publicas sometido a los términos del silo desde el primer segundo, tu copia no es la canónica y heredas sus límites, como el recorte de caracteres o los enlaces envueltos en t.co.

Backfeed: la sindicación inversa de las interacciones. Los likes, respuestas y reposts que tus copias POSSE reciben en las redes vuelven a tu post original como webmentions. Así la conversación completa queda archivada en tu dominio, a salvo de la próxima muerte de silo. El servicio de referencia es Bridgy: vigila tus copias en Mastodon, GitHub, Flickr, Reddit o Bluesky y te envía una webmention por cada interacción.

En resumen: publicas en tu sitio, sindicas a los silos con enlace de vuelta, y las reacciones regresan a casa convertidas en webmentions.

Relación con el Fediverso, RSS y compañía

Te va a sorprender, pero la IndieWeb no vive aislada del Fediverso. Como dato curioso, protocolos como Webmention, Micropub y WebSub salieron del mismo sitio, el Social Web Working Group del W3C. Del mismo grupo nació también el famoso ActivityPub, el protocolo del Fediverso. Son primos hermanos, aunque responden a filosofías distintas.

El Fediverso federa servidores: tu identidad es @usuario@instancia, y si no administras tu propia instancia, dependes de la de otro. La wiki no se muerde la lengua: unirse a una instancia de Mastodon es pasar "de un silo a otro silo, quizá más open source, pero aún dependiente de otra organización central", con el agravante del admintax, el coste brutal de moderar y mantener una instancia. La IndieWeb federa webs: tu identidad es tu dominio y la federación es solo un canal más.

Sin embargo no son incompatibles. Bridgy Fed es el puente que convierte tu h-card, tus h-entry y tus webmentions a ActivityPub (y AT Protocol de Bluesky) y viceversa. El resultado es que tu dominio se convierte en una cuenta del Fediverso del tipo @example.com@example.com donde te pueden buscar y seguir desde Mastodon, y las respuestas vuelven a tu post como backfeed. Mastodon entiende que tu perfil y tus posts viven en tu sitio.

Sin embargo, los feeds RSS/Atom son otro cantar, ya que la IndieWeb los considera formatos con problemas estructurales. El argumento es el principio DRY: el contenido ya está en tu HTML, mantener una copia XML paralela es un "impuesto de mantenimiento", una ruta de código separada que puede desincronizarse, pesa más (hay ficheros Atom hasta 4,5 veces mayores que su HTML equivalente) y ofrece una experiencia terrible cuando un humano hace clic en el enlace del feed. Su alternativa es h-feed: el propio HTML como feed. Pero como ocurre en muchas ocasiones, ser técnicamente más apropiado no implica ser aceptado. Ellos mismos admiten que muy pocos lectores soportan microformatos. Por lo tanto, recomiendan h-feed para la IndieWeb y RSS/Atom para el resto del planeta.

Cómo empezar

La guía Getting Started recomienda estos pasos, en este orden:

1. Consigue tu dominio y úsalo como tu identidad principal online. Consejo concreto que dan: valora las opciones de privacidad whois del registrador, pero solo si confías plenamente en el proveedor, porque las disputas de titularidad se complican si no figuras como propietario legal.
2. Configura el hosting: un servicio gestionado si empiezas (citan GitHub Pages, Netlify, Neocities...), self-hosting si sabes lo que haces.
3. Crea tus páginas: generador estático, HTML a mano o CMS, da igual. No hay tecnología oficial, y eso es deliberado (principio de pluralismo).
4. Sindica a otras plataformas (POSSE) con enlaces de vuelta al original.
5. Añade microformats: enlaces rel="me" a tus perfiles en la home y marcado h-entry en tus posts.
6. Valida tu trabajo con IndieWebify.me, que comprueba tus rel-me, tu h-card y tus h-entry paso a paso.
7. Únete a la comunidad: comparte lo que hagas aunque sea una sola página, y documéntalo en la wiki para el siguiente.

Para quien quiera un camino más gradual existe IndieMark, una escala de niveles, una guía orientativa para desarrolladores.

Lo que he implementado (y lo que no)

Te prometí al inicio que te contaría qué piezas he implementado, cuáles descarté y por qué. Aquí va la lista:

• ✅ Webmention, envío y recepción. El envío, automatizado con una tarea diaria que notifica los enlaces externos de los artículos nuevos, con 24 horas de margen para corregir erratas antes de avisar a nadie. La recepción la uso para incluir un listado de referencias al final de cada artículo. Sin embargo lo tengo separado de mis comentarios ya que se gestionan por email.
• ✅ h-entry en cada artículo y h-card en la portada, verificados con mf2py.
• ✅ rel="me" en el footer hacia Mastodon, GitHub y Org Social, con su tick verde correspondiente.
• ❌ Micropub e IndieAuth: decisión consciente. Mi interfaz de publicación es el editor y git; los artículos son markdown versionado. Un endpoint de publicación no me aporta nada.
• ❌ WebSub: evaluado y descartado. Como mi publicación va retrasada 24 horas a propósito, el "tiempo real" no compensa la complejidad.
• ❌ h-feed: mis tarjetas de artículo se reutilizan en otros contextos, como las sugerencias que aparecen dentro de cada artículo, y marcarlas generaría h-entries ambiguas para los parsers. Si hubiera diseñado las plantillas con esta estructura en mente, habría sido diferente. RSS cumple ese papel de sobra.

Pero los consejos que más me han ayudado no son técnicos, sino de filosofía y ética de diseño web. Repartidos por la wiki, valen oro con o sin IndieWeb. Mi selección:

• El HTML plano es el formato más duradero. Puedes leer toda la web sin usar JavaScript.
• Cool URIs don't change: diseña permalinks que puedas mantener para siempre. Por ejemplo, puedo cambiar el slug de un artículo y aun así seguirá funcionando.
• Compromiso gradual, silo a silo: no hace falta un éxodo. Cada tipo de contenido que pasas a publicar primero en tu sitio es un paso adelante en la propiedad de tus datos.
• Piensa en la longevidad extrema: la wiki discute en serio qué pasa con tu web cuando mueras, desde el "dead man's switch" que entrega las llaves a alguien de confianza hasta el problema práctico que resume Peter Molnar: "¿quién pagará tu dominio si tú no estás?".

Y... diviértete. Una web personal imperfecta y rara tiene más valor que una plantilla impoluta que te aburre mantener.