RSS 2.0 o Atom: cuál es mejor según los feeds reales (93% frente a 5%)
Si la pregunta es cuál de los dos gana en la práctica, la respuesta tiene un número: el 93% de los feeds distintos que los usuarios de Proofite tienen suscritos declara <rss version="2.0">, frente al 5% en Atom 1.0, un 1% en la sintaxis RDF de RSS 1.0 y otro 1% que ya no es un feed, sea una página HTML o directamente ninguna respuesta (censo del 23 de agosto de 2026). Dieciocho a uno para un formato que nunca pasó por un organismo de estandarización. Pero ese recuento es la mitad menos interesante de la historia: el 88% de esos feeds RSS 2.0 declara además el namespace de Atom. La elección excluyente, en la práctica, casi nadie la hace.
La guerra de formatos acabó en fusión, no en victoria
Ocho de cada nueve feeds son las dos cosas a la vez. No son documentos Atom: el elemento raíz sigue siendo <rss version="2.0">. Dentro llevan piezas de Atom, y casi siempre la misma: <atom:link rel="self">, es decir, la dirección canónica del propio feed.
Ese elemento cumple una función que RSS 2.0 por sí solo no tiene. Un agregador que recibe el documento por otra vía —reenviado, copiado, cacheado— no sabe de dónde volver a descargarlo si el feed no dice cuál es su dirección. Atom lo resolvió en su modelo de datos; RSS 2.0 lo tomó prestado. Nadie firmó una tregua, pero el resultado se parece bastante: RSS 2.0 como contenedor, Atom como vocabulario de relleno.
Para quien publica, la pregunta útil no es el formato
Si se administra un sitio, discutir «RSS o Atom» consume un tiempo que rinde más en otra cosa: qué elementos mete el generador en cada <item>. Los dos formatos ocupan lugares distintos —uno es el envoltorio, el otro aporta las piezas que faltan—, así que la decisión no es entre ellos, sino entre un feed completo y un feed pobre.
La objeción razonable existe y conviene decirla entera. Atom es el estándar del IETF (RFC 4287, diciembre de 2005) y tiene mejor ingeniería: modelo de datos más preciso, un único formato de fechas, idioma declarable elemento a elemento, distinción explícita entre texto plano y HTML, tipo MIME registrado. Si alguien escribe un generador desde cero, Atom es la opción sensata. Para quien ya publica con un CMS, lo que conviene es lo que el CMS produce, porque todos los lectores más usados leen ambos formatos sin problemas.
RSS 1.0 perdió como sintaxis y ganó como vocabulario
Solo el 1% de los feeds usa la sintaxis RDF de RSS 1.0. Y el 89% de los feeds RSS 2.0 declara xmlns:dc, el namespace de Dublin Core, el vocabulario de metadatos que adoptó precisamente RSS 1.0.
La rama derrotada de la escisión de diciembre de 2000 sobrevive despiezada dentro del formato que la venció. dc:creator para el autor, dc:date para la fecha: eso es RSS 1.0 funcionando dentro de RSS 2.0 todos los días, en millones de documentos.
Un apunte que se repite mal en muchos artículos: RSS 1.0 no lo publicó el W3C. Lo publicó el RSS-DEV Working Group, un grupo independiente que usó tecnología del W3C (RDF) pero no tenía nada que ver con el consorcio.
Casi nada de esto es una decisión editorial
Ordenadas por difusión sobre el total de feeds válidos, las extensiones quedan así: dc 90%, atom 82%, content 75%, sy 49%, slash 48%, wfw 46%, media 35%, itunes 7%.
Las seis primeras son, en ese orden aproximado, los namespaces que WordPress emite por defecto. No hay detrás una discusión de redacción sobre metadatos: hay una plantilla. Cuando un medio como Xataka o Infobae publica un feed con content:encoded (texto completo del artículo), sy (frecuencia de actualización sugerida), slash (número de comentarios) y wfw (feed de comentarios de esa entrada concreta), lo más probable es que nadie lo haya decidido: venía puesto.
Las dos que sí suelen ser una decisión son media (Media RSS: miniaturas, duraciones, licencias) e itunes (categoría, duración, portada). Esas se añaden porque alguien las necesita.
El tipo MIME está mal en más de un tercio de los casos
Solo el 63% de los feeds válidos llega con el content type correcto: 61% como application/rss+xml y 2% como application/atom+xml. El 37% restante viaja mal etiquetado: application/xml en el 22% de los casos, text/xml en el 14%, y uno servido como text/html.
La causa es histórica y tiene gracia. application/rss+xml nunca se registró en la IANA. Hubo dos intentos como Internet Draft y los dos caducaron, porque detrás de RSS no había un organismo reconocido que llevara el trámite hasta el final. application/atom+xml sí está registrado, por la vía normal del IETF. El tipo MIME más usado del mundo de los feeds es, formalmente, un tipo MIME que no existe.
Ese error apenas molesta a los lectores; a los navegadores sí
Un agregador mira el contenido, no la cabecera: abre el documento, lee la primera etiqueta y actúa. Por eso el 37% mal etiquetado no rompe casi nada en la práctica.
Donde se nota es en el navegador. Un application/rss+xml recibido en Chrome o Firefox a menudo provoca la descarga del archivo en lugar de mostrarlo, y el lector que hizo clic en «RSS» acaba con un .xml en la carpeta de descargas sin entender qué ha pasado. Varios publicadores han vuelto a text/xml a propósito por ese motivo. Es una decisión defendible, aunque sea formalmente peor.
Otro dato de higiene: el 2% de los feeds se sigue sirviendo por HTTP sin cifrar.
El <enclosure>, la pieza que nunca entró en crisis
El 21% de los feeds contiene al menos un <enclosure> y el 7% declara el namespace itunes, que es la definición estricta de podcast.
<enclosure> se introdujo en RSS 0.92, en diciembre de 2000, a propuesta de Tristan Louis y por insistencia de Adam Curry. Se quedó tres años sin público. Hoy sostiene una industria entera: Spotify, Apple Podcasts y el resto no alojan los episodios, indexan feeds RSS públicos. Cuando un programa cambia de plataforma sin perder oyentes, lo que se mueve es la dirección de un XML.
El número de versión no indica una progresión
La confusión más habitual es leer «RSS 1.0» como algo anterior a «RSS 2.0». Las fechas dicen lo contrario: RSS 1.0 salió el 6 de diciembre de 2000 y RSS 2.0 en agosto de 2002. Son ramas separadas, con sintaxis incompatibles, nacidas de una escisión. Netscape había publicado RSS en marzo de 1999; UserLand se quedó la rama XML en junio de 2000; el RSS-DEV Working Group publicó la suya en diciembre. UserLand respondió con la 0.92 diecinueve días después.
version="2.0" no significa «segunda versión»: significa «rama de UserLand». Y esa especificación tuvo once revisiones publicadas entre 2002 y 2009, todas declarando el mismo número.
La peor avería de un feed es el silencio
Un feed puede responder con un 200, XML impecable y tipo MIME correcto, y estar muerto. Si el <item> más reciente tiene más de seis meses, es una fuente apagada que no genera ningún error. En un agregador, ese silencio se lee como «no hay noticias», que es distinto de «esta fuente ya no publica».
El contexto importa porque nadie sigue tres feeds. Un lector activo de Proofite sigue 70 fuentes: 30 feeds RSS, 20 búsquedas web, 19 newsletters y 1 perfil social, repartidas en 8 cajas temáticas (medición de julio de 2026). Con ese volumen, dos fuentes apagadas pasan inadvertidas durante meses. Y la redundancia es alta: sobre 4 digests reales con 37 entradas, el 27% de las entradas procedía de dos o más cabeceras contando el mismo hecho —un caso real combinaba Coindesk, Wired y prensa generalista sobre la misma ronda de financiación—, lo que tapa aún mejor los huecos.
Lista de comprobación
- Mirar la primera etiqueta. Si no es
<rss,<rdf:RDFo<feed, no es un feed. Ese criterio descartó el 1% de las direcciones del censo. - Comprobar que existe
<atom:link rel="self">. - Dar a cada
<item>su<guid>, conisPermaLink="true"cuando coincida con la URL del artículo. Evita duplicados cuando se corrige un titular. - Poner el autodiscovery en el
<head>:<link rel="alternate" type="application/rss+xml" title="RSS" href="...">. La convención la formalizó el RSS Advisory Board en 2006. - Pasar el feed por validator.w3.org/feed. Señala también fallos que empeoran la lectura sin impedirla, como las fechas ambiguas.
- Para saber si una fuente está viva, mirar la fecha del último item, no la ausencia de novedades.
- Servir el feed por HTTPS.
Preguntas frecuentes
¿RSS 2.0 o Atom: cuál es mejor?
Atom está mejor diseñado; RSS 2.0 es lo que usa el 93% de los feeds que la gente suscribe de verdad. Para escribir un generador nuevo, Atom. Para publicar con un CMS existente, lo que ya emite el CMS, porque todos los lectores más usados leen ambos. La elección excluyente es en gran medida un debate teórico: el 88% de los feeds RSS 2.0 incluye elementos de Atom.
¿RSS 1.0 es posterior a RSS 2.0?
No, aunque el número lo sugiera. RSS 1.0 es de diciembre de 2000 y RSS 2.0 de agosto de 2002, pero no son versiones consecutivas: son ramas rivales con sintaxis incompatibles. Un número más alto no equivale a versión más nueva.
¿Un tipo MIME incorrecto rompe el feed?
Casi nunca. Los agregadores se fijan en el contenido del documento, no en la cabecera HTTP, así que el 37% de feeds mal etiquetados funciona igual. El problema aparece en los navegadores, que ante application/rss+xml a veces descargan el archivo en lugar de mostrarlo.
¿Cómo sé si un feed está muerto?
Por la fecha del item más reciente. Un feed apagado responde correctamente y no produce ningún error, simplemente deja de traer novedades. El umbral práctico son seis meses sin publicaciones nuevas.
¿Qué es <atom:link rel="self"> y por qué importa?
Es la dirección canónica del propio feed, declarada dentro del documento. RSS 2.0 puro no tiene forma de decir «me descargas desde aquí», y sin esa línea un agregador que recibe el XML por otra vía no sabe dónde volver a buscarlo.
¿Los podcasts usan RSS o algo propio?
RSS, con el elemento <enclosure> que existe desde diciembre de 2000. El 21% de los feeds del censo lleva al menos un <enclosure> y el 7% declara el namespace itunes. Las plataformas de escucha no alojan los episodios: indexan feeds RSS públicos.
---
Nota de método. Las cifras proceden del censo de las direcciones de feed distintas que los usuarios de Proofite tienen suscritas realmente, descargadas y clasificadas el 23 de agosto de 2026 leyendo el elemento raíz y los namespaces declarados en cada documento. Los datos de fuentes por usuario y de redundancia entre cabeceras salen del análisis automático de digests generados en julio de 2026, no de declaraciones de los editores ni de encuestas. No es una muestra representativa de la Web: son las fuentes que ha elegido seguir una comunidad de lectores activos, ya filtradas hacia sitios vivos y cuidados. Por eso aquí solo el 1% resulta inalcanzable; en una muestra aleatoria de la Web esa proporción sería mucho mayor. Datos en bruto, una línea por feed, disponibles a petición.