Fuentes RSS
Cómo utilizan los motores de búsqueda las fuentes RSS 2,0 y Atom 1,0 como canal de descubrimiento de contenido nuevo: Feedfetcher, robots.txt, WebSub y por qué una fuente complementa pero nunca reemplaza a un sitemap XML.
Idiomas
Google y Bing aceptan fuentes RSS 2,0 y Atom 1,0 como señal de descubrimiento tipo sitemap, pero una fuente solo muestra tus URLs modificadas recientemente, por lo que complementa un sitemap XML completo en lugar de reemplazarlo. Google rastrea las fuentes con Feedfetcher, un rastreador separado que ignora robots.txt (bloquéalo con un 4xx, no con una desautorización). Las fuentes son un canal de extracción; WebSub las convierte en push para Google, mientras que IndexNow es ahora la señal push preferida de Bing. Las fuentes ayudan a la velocidad de descubrimiento, no a los rankings, y como los sitemaps, nunca garantizan la indexación.
Evidence for this claim RSS 2.0 defines a channel of items with metadata such as title, link, description, publication date, and GUID. Scope: RSS 2.0 feed format; consumer behavior varies. Confidence: high · Verified: RSS 2.0 Specification Evidence for this claim Google accepts RSS 2.0 and Atom 1.0 feeds as sitemap submissions, generally covering recent URLs; submission aids discovery but does not guarantee indexing. Scope: Current Google sitemap format support. Confidence: high · Verified: Google Search Central: Build and submit a sitemapTL;DR — Un feed RSS o Atom es un archivo XML que enumera tus páginas más recientes. Los motores de búsqueda pueden usarlo para encontrar contenido nuevo más rápido: puedes enviar el feed en Google Search Console o Bing Webmaster Tools, igual que un sitemap. Pero un feed solo muestra URLs recientes, por lo que funciona junto con un sitemap XML completo, no en lugar de uno. Y como un sitemap, ayuda a que una página sea encontrada; no hace que rankees más alto.
Qué es un feed RSS
Un feed RSS (Really Simple Syndication) o feed Atom es un archivo XML que tu sitio publica y que enumera tu contenido más reciente, generalmente las últimas docenas de publicaciones. La mayoría de las plataformas de blogs y CMS lo generan automáticamente. Los lectores usan los feeds para seguir tus actualizaciones en un lector de feeds, pero el mismo archivo cumple una doble función: los motores de búsqueda pueden leerlo para descubrir tus URLs más nuevas.
Cómo lo usan los motores de búsqueda
Un feed funciona de manera muy similar a un sitemap. Pueden ocurrir dos cosas:
- Lo envías. En Google Search Console o Bing Webmaster Tools, puedes agregar la URL del feed como un sitemap. El motor entonces lo revisa en busca de páginas nuevas.
- Los rastreadores lo encuentran por sí solos. Si colocas una pequeña etiqueta de autodescubrimiento en el
<head>de tu página — una línea<link rel="alternate" type="application/rss+xml">— un rastreador puede detectar tu feed sin que envíes nada.
De cualquier manera, el motor obtiene tu feed periódicamente y nota las URLs recientemente agregadas o modificadas en él.
Lo único que debes recordar
Un feed no reemplaza tu sitemap XML. Un feed solo enumera tu contenido reciente; no incluirá tus páginas más antiguas ni archivos. El consejo de Google es usar ambos: el sitemap para una cobertura completa de todo tu sitio, y el feed como una señal de frescura para lo que acaba de cambiar.
Y al igual que un sitemap, un feed solo ayuda con el descubrimiento: lograr que una página sea encontrada y rastreada. No garantiza que la página sea indexada, y no mejora tus rankings.
¿Quieres la versión más profunda — Feedfetcher (el rastreador de feeds separado de Google), por qué ignora robots.txt, WebSub, y cómo la guía de Bing ha cambiado hacia IndexNow? Cambia a la pestaña Avanzado.
Evidence for this claim RSS 2.0 defines a channel of items with metadata such as title, link, description, publication date, and GUID. Scope: RSS 2.0 feed format; consumer behavior varies. Confidence: high · Verified: RSS 2.0 Specification Evidence for this claim Google accepts RSS 2.0 and Atom 1.0 feeds as sitemap submissions, generally covering recent URLs; submission aids discovery but does not guarantee indexing. Scope: Current Google sitemap format support. Confidence: high · Verified: Google Search Central: Build and submit a sitemapTL;DR — RSS 2,0 y Atom 1,0 son aceptados por Google como formato de sitemap, y otros motores pueden admitir el envío de feeds bajo su guía actual para webmasters. Un feed solo muestra tus URLs recientemente modificadas, por lo que complementa un sitemap XML completo — nunca lo reemplaza. Los feeds son un canal de extracción; WebSub puede agregar notificaciones de publicación-suscripción, mientras que IndexNow es un protocolo separado de notificación de URLs utilizado por los motores participantes. Los feeds ayudan a la velocidad de descubrimiento, no a los rankings, y como los sitemaps, nunca garantizan la indexación.
Un feed es una señal de descubrimiento en formato de sitemap
Si tu CMS ya publica un feed RSS o Atom, los motores de búsqueda pueden usarlo de la
misma manera que usan un sitemap — como una lista de URLs para descubrir. Google es explícito:
“Google accepts RSS 2.0 and Atom 1.0 feeds,” y “if your CMS generates an RSS
or Atom feed, you can submit the feed’s URL as a sitemap.” (traducción) «Google acepta feeds RSS 2.0 y Atom 1.0» y «si tu CMS genera un feed RSS o Atom, puedes enviar la URL del feed como un sitemap». Ese espacio de envío en
Google Search Console acepta una URL de feed tan fácilmente como un sitemap.xml.
El problema es el alcance. Un sitemap XML completo tiene como objetivo catalogar cada URL de tu sitio; un feed es una ventana móvil de tus elementos más recientes. Google lo dice claramente: “This feed only provides information on recent URLs.” (traducción) «Este feed solo proporciona información sobre URLs recientes». Así que un feed es una señal de frescura, no un índice completo de tus páginas. Así es exactamente como lo enmarco en el hub Discovery — Google acepta feeds como formato de sitemap, pero un feed solo muestra tus URLs recientemente modificadas.
Aquí son ciertas dos cosas distintas, y vale la pena mantenerlas separadas: el feed
está actualizado porque qué URLs están actualmente listadas en él — esa parte es
estructural y confiable. Lo que hace el valor de pubDate/updated de cada elemento
cuando un proveedor obtiene el feed es una pregunta aparte; Google y Bing no publican
una especificación detallada sobre exactamente cómo ponderan esos campos de fecha, así
que trátalos como contexto útil que proporcionas, no como una garantía de procesamiento
documentada.
Los feeds complementan un sitemap — no lo reemplazan
Este es el mito que vale la pena desmentir de entrada: “un feed RSS reemplaza mi sitemap XML.” No es así. La recomendación documentada de Google es usar ambos — el sitemap para una cobertura integral de todo el sitio (páginas antiguas, archivos, todo), y el feed RSS/Atom como la capa de frescura para lo que acaba de cambiar. Elimina el sitemap y conserva solo el feed, y tu archivo de URLs antiguas pierde su ruta de descubrimiento más confiable.
Una nota práctica sobre lo que los feeds pueden contener: un feed mRSS (Media RSS) puede darle a Google detalles sobre contenido de video, pero los feeds RSS/Atom solo pueden describir videos — no imágenes ni noticias. Para el descubrimiento de imágenes todavía necesitas un sitemap de imágenes, y para Google News envías a través de canales específicos de News. El feed es una ayuda de descubrimiento, no un conducto universal de metadatos.
Feedfetcher: el rastreador de feeds de Google para News y WebSub — y la trampa de robots.txt
Aquí está la parte que la mayoría de los artículos omiten, y vale la pena ser preciso sobre el alcance: la documentación propia de Feedfetcher de Google lo describe de manera limitada como “how Google crawls RSS or Atom feeds for Google News and WebSub.” (traducción) «cómo rastrea Google los feeds RSS o Atom para Google News y WebSub». Ese es el uso documentado — Google no dice en esa página que Feedfetcher es lo que maneja cada feed que envías como sitemap en Search Console, así que no lo generalizaré a una afirmación sobre la ruta de envío de sitemaps. Dos cosas que la documentación propia de Feedfetcher sí establece, para el contexto de News/WebSub que nombra:
- Ignora robots.txt — por diseño. Google lo afirma directamente: Feedfetcher
no obedece las reglas de robots.txt, porque se trata como si actuara en nombre de
un humano que se suscribió explícitamente al feed — “a direct agent of the human
user, not as a robot.” (traducción) «un agente directo del usuario humano, no como un robot». Así que si tu plan para “bloquear el feed de
los rastreadores” es un
Disallowen robots.txt, no detendrá a Feedfetcher. Para bloquear realmente a Feedfetcher, devuelve un 4xx (404 o 410) para la URL del feed — no un disallow. Este es el mismo tipo de error que intentar desindexar una página con robots.txt: estás usando el control equivocado. - Rastrea solo la URL del feed, no los enlaces dentro de él. Google es explícito en que “unlike normal web crawlers, Feedfetcher isn’t discovering links to crawl at all; instead, it crawls a single URL that’s provided to it.” (traducción) «a diferencia de los rastreadores web normales, Feedfetcher no descubre enlaces para rastrear; en su lugar, rastrea una única URL que se le proporciona». También dice que Feedfetcher “shouldn’t retrieve feeds from most sites more than once every hour on average,” (traducción) «no debería recuperar feeds de la mayoría de los sitios más de una vez por hora de promedio», aunque los sitios que se actualizan con frecuencia pueden actualizarse más a menudo. Lo que Google no documenta es qué sucede después con las URLs dentro de un feed que envías como sitemap general de Search — esa transferencia no está descrita en esta página, así que trátala como no documentada en lugar de asumir que fluye a través de Feedfetcher.
Cómo usa Bing los feeds — y por qué IndexNow cambió el panorama
Bing acepta un amplio conjunto de formatos de sitemap: XML, RSS 2,0, mRSS, Atom 0,3 y Atom 1,0, y texto plano. Los feeds RSS/Atom son un ajuste natural para blogs que publican con frecuencia, e históricamente Bing monitoreaba esos feeds para detectar contenido nuevo.
Pero la guía moderna de Bing ha evolucionado. Su guía de sitemaps de 2025 enfatiza XML
con lastmod preciso más IndexNow como la pila preferida, y notablemente deja de
resaltar RSS/Atom. La razón está en las propias palabras de Bing sobre IndexNow: “Instead
of Bing continually monitoring RSS and similar feeds or frequently crawling websites
to check for new pages… websites will notify Bing directly about relevant URLs
changing on their website.” (traducción) «En lugar de que Bing monitoree continuamente RSS y fuentes similares o rastree sitios web con frecuencia para buscar páginas nuevas… los sitios web notificarán directamente a Bing sobre las URLs relevantes que cambian en su sitio web.» En otras palabras, IndexNow está diseñado para reemplazar el antiguo patrón de “Bing monitorea tu fuente RSS” con un push explícito. RSS todavía funciona con Bing y enviarlo requiere poco esfuerzo, pero si estás eligiendo dónde invertir para la frescura en Bing, IndexNow es la recomendación principal ahora.
Pull vs push: dónde encaja WebSub
Las fuentes son fundamentalmente un canal de pull — el motor vuelve a obtener tu fuente según su propio horario. Para convertirlo en push, agregas WebSub (anteriormente PubSubHubbub). Google lo admite: “If you use Atom or RSS, you can use WebSub to broadcast your changes to search engines, including Google.” (traducción) «Si usas Atom o RSS, puedes usar WebSub para transmitir tus cambios a los motores de búsqueda, incluido Google.» En lugar de esperar a que se vuelva a hacer pull, tu fuente transmite el cambio a los motores suscritos, por lo que la actualización llega más cerca del tiempo real. El modelo mental más simple para los dos motores:
- Google: fuente RSS/Atom para descubrimiento por pull, WebSub para hacer push de los cambios de la fuente.
- Bing: RSS/Atom aceptado, pero IndexNow es el push preferido para notificación en tiempo real.
WebSub es el complemento push de RSS — de la misma manera que lastmod e IndexNow son complementos push en el lado de los sitemaps. (Más sobre todo el panorama de pull/push en el hub de Discovery).
Configurar una fuente para el descubrimiento
Una lista de verificación breve y práctica:
- Publica una fuente válida RSS 2,0 o Atom 1,0 (la mayoría de los CMS lo hacen automáticamente). Usa URLs absolutas dentro de ella y mantén el número de elementos en tu ventana reciente.
- Agrega una etiqueta de autodescubrimiento en el
<head>de tu página para que los rastreadores puedan encontrarla:<link rel="alternate" type="application/rss+xml" title="Feed" href="/feed.xml">. - Envía la URL de la fuente como un sitemap en Google Search Console y en Bing Webmaster Tools. El autodescubrimiento solo puede funcionar, pero el envío explícito es más confiable.
- Para la frescura en Google, agrega WebSub; para la frescura en Bing, implementa IndexNow.
- No bloquees la fuente en robots.txt esperando que Feedfetcher lo obedezca — usa un 4xx si realmente necesitas bloquearla.
Los límites — igual que los sitemaps
Tres límites honestos a tener en cuenta:
- Solo URLs recientes. Una fuente es una señal de frescura, no una cobertura completa. Mantén el sitemap XML para todo lo demás.
- Sin garantía de indexación. El descubrimiento no es indexación. Una fuente hace que una URL se encuentre y se rastree antes; si se indexa es una decisión separada.
- No es una señal de ranking. Las fuentes aceleran el descubrimiento y pueden ayudar a que el contenido nuevo se detecte antes de que se acumulen los backlinks, pero no hay ningún beneficio de ranking más allá de eso — exactamente igual que un sitemap.
Resumen de IA
Una versión condensada de la versión avanzada:
- Los feeds son una señal de descubrimiento en formato sitemap. Google acepta RSS 2,0 y Atom 1,0; Bing acepta RSS 2,0 además de Atom 0,3/1.0 (y mRSS). Envía la URL del feed como sitemap, o exponla mediante una etiqueta de autodescubrimiento
<link rel="alternate">. - Un feed solo cubre URLs recientes. Complementa un sitemap XML completo; nunca lo reemplaza. Google recomienda usar ambos.
- Feedfetcher es el rastreador de Google para feeds RSS/Atom, documentado específicamente para Google News y WebSub; Google no afirma que sea el rastreador detrás de cada feed enviado como sitemap en Search. Ignora robots.txt por diseño; para bloquearlo, devuelve un 4xx, no un disallow. Solo obtiene la URL del feed (no sigue enlaces dentro del feed).
- La identidad del feed no es un control de Search. Un
guid/idda a un elemento una identidad estable dentro del feed; no es una directiva canónica.X-Robots-Tag: noindexen una respuesta de feed requiere que el rastreador ya pueda acceder a él, y no es control de acceso. - Pull vs push: los feeds son pull. WebSub los convierte en push para Google (difusión de cambios del feed). Para Bing, IndexNow es ahora el push en tiempo real preferido, reemplazando el antiguo patrón de “Bing monitorea tu RSS”.
- mRSS puede llevar detalles de video; los feeds no pueden describir imágenes ni noticias.
- Límites: solo URLs recientes, sin garantía de indexación y sin beneficio de ranking; los feeds aceleran el descubrimiento, nada más.
Documentación oficial
Documentación de fuentes primarias de los motores de búsqueda.
- Crear y enviar un sitemap — aceptación de RSS 2,0 / Atom 1,0, envío de un feed como sitemap, la advertencia de “solo URLs recientes”, mRSS para video y WebSub.
- Feedfetcher — cómo funciona el rastreador de feeds dedicado de Google y por qué ignora robots.txt (bloquéalo con 4xx).
- Mejores prácticas para sitemaps XML y feeds RSS/Atom (2014) — la recomendación de Google de “usar ambos”: sitemap para cobertura, feed para frescura.
- Uso de feeds RSS/Atom para descubrir nuevas URLs (2009) — el anuncio original de Google de los feeds como método de descubrimiento.
Bing / Microsoft
- Mantener el contenido descubrible con sitemaps en la búsqueda impulsada por IA (julio de 2025) — la guía actual de Bing que enfatiza XML +
lastmod+ IndexNow. - Envía hasta 10 000 URLs al día a Bing (2019) — la declaración de Fabrice Canel sobre reemplazar el monitoreo de RSS con notificación directa.
Citas de la fuente
Declaraciones públicas de Google y Bing. Cada enlace es un enlace profundo que salta al pasaje citado en la página de origen.
Google — los feeds como formato de descubrimiento
- “Google accepts RSS 2.0 and Atom 1.0 feeds.” (traducción) «Google acepta feeds RSS 2.0 y Atom 1.0.» — Documentación de Google Search Central. Ir a la cita
- “If you use Atom or RSS, you can use WebSub to broadcast your changes to search engines, including Google.” (traducción) «Si usas Atom o RSS, puedes usar WebSub para difundir tus cambios a los motores de búsqueda, incluido Google.» Ir a la cita
Bing / Microsoft
- “Instead of Bing continually monitoring RSS and similar feeds or frequently crawling websites to check for new pages, discover content changes and/or new outbound links, websites will notify Bing directly about relevant URLs changing on their website.” (traducción) «En lugar de que Bing monitoree continuamente RSS y feeds similares o rastree sitios web con frecuencia para buscar nuevas páginas, descubrir cambios de contenido y/o nuevos enlaces salientes, los sitios web notificarán directamente a Bing sobre las URLs relevantes que cambian en su sitio.» — Microsoft Bing, sobre IndexNow / envío de URLs. Ir a la cita
Lista de verificación de auditoría de configuración del feed
Repasa esto antes de considerar un feed “terminado”. Es el mismo terreno que los pasos de configuración de la pestaña Avanzado, reformulado como una lista de aprobado/reprobado:
- El feed se valida como RSS 2,0 o Atom 1,0 bien formado — sin XML roto, ampersands sin escapar ni etiquetas sin cerrar.
- Cada elemento tiene un
<link>real y distinto que apunta a una URL absoluta (no una ruta relativa, no un marcador de posición). - Cada elemento tiene un
pubDate(RSS) oupdated/published(Atom) — un feed sin fechas no da a los rastreadores nada por lo que juzgar “reciente”. - El número de elementos coincide con tu ventana reciente real (aproximadamente tus últimas docenas de publicaciones) — no truncado a 3-5, no inflado a todo tu archivo.
- Contenido completo vs. resumen es una elección deliberada, no un valor predeterminado — sopesa la conveniencia del lector en los lectores de feeds frente a las licencias, la exposición a republicación/raspado, y cuánto quieres proteger el clic a tu propio sitio. Esto no es un factor de clasificación documentado de Google Search de una u otra manera; elijas lo que elijas, mantén el marcado del elemento válido y su identidad de entrada (guid/id) estable.
- La etiqueta de autodescubrimiento está presente en
<head>:<link rel="alternate" type="application/rss+xml" title="Feed" href="/feed.xml">. - La respuesta HTTP del feed tiene el
Content-Typecorrecto (application/rss+xmloapplication/atom+xml), notext/html. - La URL del feed se envía como sitemap en ambas Google Search Console y Bing Webmaster Tools.
- La URL del feed no está deshabilitada en
robots.txtsi realmente quieres que Feedfetcher y los lectores de feeds la alcancen (una deshabilitación no detendrá a Feedfetcher de todos modos — consulta la pestaña de anti-patrones). - Un sitemap XML completo aún existe y se envía por separado — el feed es la capa de frescura, no todo el mapa.
- WebSub configurado si quieres descubrimiento push para Google; IndexNow configurado si quieres descubrimiento push para Bing.
Los modelos mentales
1. Feed = capa de frescura, sitemap = mapa completo. No preguntes “feed o sitemap” — no es una elección. El sitemap responde “qué existe en este sitio”, el feed responde “qué cambió recientemente”. Usa ambos; el feed nunca sustituye la cobertura del sitemap.
2. Pull vs. push, y qué motor quiere cuál. Un feed por sí mismo es pull — el motor lo vuelve a buscar en su propio horario. WebSub lo convierte en push para Google. IndexNow es el canal push preferido de Bing y ha superado “monitorear el feed RSS”. Si tu objetivo es un descubrimiento más rápido para un motor específico, empareja el canal con el motor: WebSub para Google, IndexNow para Bing.
3. Feedfetcher no es Googlebot.
El bot dedicado de Google para buscar feeds tiene sus propias reglas — lo más importante,
ignora robots.txt. Cualquier decisión de control sobre una URL de feed debe tomarse teniendo en cuenta
el comportamiento de este rastreador, no el de Googlebot.
4. La regla de decisión para “¿ayuda un feed a este sitio?” Un feed se justifica cuando: (a) publicas contenido nuevo o actualizado con la frecuencia suficiente como para que “reciente” sea una ventana significativa y móvil, y (b) quieres esa señal de frescura disponible para más que solo motores de búsqueda (lectores de feeds, suscriptores de WebSub, agregadores de terceros). Un sitio que rara vez cambia obtiene poco extra de un feed más allá de lo que el sitemap ya proporciona.
5. Descubrimiento, no indexación, no posicionamiento. Cada decisión aquí se encuentra dentro del mismo límite que un sitemap: un feed solo puede acelerar si una URL es encontrada y rastreada. No tiene influencia en las decisiones de indexación ni en los rankings.
Formatos de feed: qué se acepta, qué se requiere
Aceptado como señal de descubrimiento en formato de sitemap
| Formato | Aceptado por Google | Aceptado por Bing | Notas |
|---|---|---|---|
| RSS 2,0 | Sí | Sí | El valor predeterminado más común en CMS |
| Atom 1,0 | Sí | Sí | |
| Atom 0,3 | No | Sí | La documentación de Bing lo menciona; trátalo como heredado |
| mRSS (Media RSS) | Solo video | Sí (como formato de sitemap) | Google: solo metadatos de video, no un sitemap general |
| JSON Feed | No listado | No listado | Formato de lector de feeds; ningún motor lo documenta como entrada de sitemap |
Elementos mínimos útiles por elemento
| Elemento | RSS 2,0 | Atom 1,0 | Por qué importa para el descubrimiento |
|---|---|---|---|
| Enlace del elemento | <link> | <link href> | La URL real a rastrear: debe ser absoluta |
| Fecha | <pubDate> | <updated> / <published> | Permite al motor juzgar qué es “reciente” |
| Título | <title> | <title> | Contexto para humanos/lectores de feeds, no una entrada de ranking |
| ID único | <guid> (recomendado) | <id> (requerido) | Evita que el mismo elemento se vuelva a procesar como nuevo |
Pull vs. push, por motor
| Motor | Pull (el feed en sí) | Equivalente push |
|---|---|---|
| RSS/Atom, re-rastreado periódicamente | WebSub | |
| Bing | RSS/Atom, re-rastreado periódicamente | IndexNow (preferido sobre el monitoreo de feeds) |
Bloquear Feedfetcher: haz esto, no aquello
| Objetivo | Herramienta incorrecta | Herramienta correcta |
|---|---|---|
| Evitar que Feedfetcher lea la URL del feed | robots.txt Disallow (ignorado) | Devuelve un 4xx (404/410) para la URL del feed |
Identidad del feed vs. controles de búsqueda: no son el mismo mecanismo
El guid/id de un feed y su link son parte de la especificación del feed, no directivas
de búsqueda. No los uses para hacer un trabajo de canonicalización o control de acceso
para el que nunca fueron diseñados:
| Mecanismo | Función real | Lo que NO consigue |
|---|---|---|
guid de RSS / id de Atom | Da a un elemento una identidad estable dentro del feed, para que un consumidor sepa “mismo elemento, no lo vuelvas a mostrar” | No le dice a Google ni a Bing qué URL de página es la principal |
link del elemento (RSS) / link href (Atom) | Apunta a un lector de feeds o rastreador a la URL de destino | No es una señal de canonicalización por sí solo |
Relación de URL principal (rel="canonical", o un encabezado HTTP Link) | Un mecanismo separado que implementas en la propia respuesta del artículo para consolidar URLs duplicadas | No se infiere automáticamente del guid/id/link de un feed |
X-Robots-Tag: noindex en la respuesta del feed | Puede aplicar una directiva de búsqueda a una respuesta no HTML como un archivo de feed, pero solo surte efecto una vez que el rastreador ya puede acceder a esa respuesta | No es una herramienta de control de acceso y no evitará que el feed se obtenga o se sindique |
| Autenticación HTTP / una URL privada | Realmente restringe quién puede recuperar el feed en absoluto | No se logra con ninguna de las filas anteriores |
Errores a evitar
Intentar bloquear Feedfetcher con robots.txt.
Feedfetcher está documentado para ignorar robots.txt por diseño: se trata como
actuando en nombre de un humano suscrito, no como un rastreador autónomo. Una
regla Disallow en la URL del feed no le afecta. En su lugar: si realmente
necesitas evitar que Feedfetcher lea un feed, devuelve un 4xx (404 o
410) para esa URL.
Tratar el feed como un reemplazo del sitemap XML. Un feed solo lista elementos recientes: eliminar el sitemap porque “el feed lo cubre” pierde el descubrimiento de cada página más antigua y de los archivos. En su lugar: mantén ambos; la propia guía de Google es usar el sitemap para una cobertura completa y el feed como la capa de frescura encima de él.
Enviar un feed sin elemento pubDate/updated.
Sin una fecha en cada elemento, no hay nada que un rastreador (o un lector de
feeds) pueda usar para juzgar qué es realmente reciente. En su lugar: asegúrate
de que cada elemento lleve una fecha real y precisa, no una marca de tiempo de
compilación que sea la misma en todos los elementos.
Sin etiqueta de autodescubrimiento en <head>.
Sin <link rel="alternate" type="application/rss+xml" href="...">, los rastreadores
y los lectores de feeds solo pueden encontrar el feed si lo envías o enlazas
explícitamente en algún lugar. En su lugar: añade la etiqueta de
autodescubrimiento para que el feed se anuncie solo en cada página.
Dejar que el número de elementos del feed se dispare o se reduzca. Un feed con todo tu archivo deja de ser una señal de “reciente”; un feed truncado a 2-3 elementos puede perder un lote de publicaciones del mismo día. En su lugar: ajusta el número de elementos a tu cadencia real de publicación — suficiente para cubrir el intervalo entre rastreos sin convertirse en un segundo sitemap.
Asumir que el envío de RSS significa un descubrimiento más rápido en Bing hoy. Esto solía ser una suposición razonable; la propia guía de Bing se ha movido desde entonces hacia IndexNow como la señal en tiempo real preferida, enmarcada explícitamente como un reemplazo para “monitorear continuamente RSS”. En su lugar: mantén el envío de RSS (es de bajo esfuerzo y sigue funcionando), pero trata a IndexNow como la palanca principal para la frescura de Bing, no el feed.
Comprueba que el feed realmente funciona
Comprobaciones de aprobado/reprobado para después de publicar o cambiar un feed — cada una con la señal de fallo y cuándo activar la reversión.
Prueba: el feed es XML bien formado
- Prueba a ejecutar: Carga la URL del feed en el Validador de feeds W3C.
- Resultado esperado: “This is a valid RSS/Atom feed” sin errores (las advertencias sobre elementos opcionales son aceptables).
- Interpretación del fallo: Un error de validación suele significar XML mal formado, un carácter sin escapar o un elemento requerido que falta — el feed puede seguir renderizándose en un navegador pero fallar para analizadores más estrictos.
- Ventana de monitoreo: Inmediata — vuelve a comprobar justo después de cualquier cambio en la plantilla del feed.
- Disparador de reversión: Cualquier error del validador (no advertencia) significa revertir el cambio de plantilla hasta que vuelva a validar sin problemas.
Prueba: cabecera Content-Type correcta
- Prueba a ejecutar:
curl -I https://example.com/feed.xmly lee la cabeceraContent-Type. - Resultado esperado:
application/rss+xml(RSS) oapplication/atom+xml(Atom) — notext/htmlnitext/plain. - Interpretación del fallo: Un Content-Type
text/htmlsuele significar que la ruta del feed está siendo servida por el manejador equivocado (un catch-all del CMS, una capa de caché que reescribe cabeceras). - Ventana de monitoreo: Inmediata.
- Disparador de reversión: Content-Type incorrecto en la URL del feed en vivo — arregla la configuración del servidor antes de depender del feed para el descubrimiento.
Prueba: envío del sitemap aceptado
- Prueba a ejecutar: Envía la URL del feed en Sitemaps en Google Search Console y en Sitemaps en Bing Webmaster Tools.
- Resultado esperado: El estado muestra “Success” (Google) o un estado procesado/válido (Bing). Ningún motor documenta un recuento garantizado de URLs descubiertas ni una ventana de procesamiento comprometida — un recuento de URLs descubiertas distinto de cero es una buena señal, pero trátalo como una observación, no como un requisito de aprobado/reprobado por sí solo.
- Interpretación del fallo: Un estado “Couldn’t fetch” o “General HTTP error” suele significar que la URL del feed está bloqueada, devuelve un estado no-200 o se agota el tiempo de espera.
- Ventana de monitoreo: Volver a comprobar uno o dos días después del envío es una regla práctica, no un SLA documentado — vuelve a comprobar después de cualquier cambio de servidor o CDN que toque la ruta del feed.
- Disparador de reversión: Envío atascado en un estado de error después de una re-comprobación — investiga la respuesta del servidor antes de asumir que el motor lo “resolverá” por sí solo.
Prueba: la etiqueta de autodescubrimiento está presente y es correcta
- Prueba a ejecutar: Ver el código fuente de una página que debería exponer el feed y
confirmar que la etiqueta
<link rel="alternate" type="application/rss+xml">(oatom+xml) está presente con elhrefcorrecto. - Resultado esperado: La etiqueta existe en
<head>, y elhrefresuelve a la misma URL del feed que validaste anteriormente. - Interpretación del fallo: Una etiqueta ausente significa que los rastreadores basados en autodescubrimiento
y los lectores de feeds no pueden encontrar el feed sin un envío explícito; un
hrefincorrecto significa que apunta a un feed obsoleto o muerto. - Ventana de monitoreo: Inmediata — verifica justo después de cualquier cambio de plantilla.
- Disparador de reversión: Etiqueta ausente o apuntando a la URL incorrecta en una página en vivo.
Prueba: Feedfetcher no puede ser bloqueado por robots.txt (confirmando que el problema no te afecta)
- Prueba a ejecutar: Revisa
robots.txtpara ver si hay una reglaDisallowque cubra la ruta del feed, y luego confirma que la URL del feed sigue devolviendo200al obtenerla directamente. - Resultado esperado: Si quieres que el feed sea rastreado, devuelve
200— una regla de desautorización en robots.txt por sí sola no habrá detenido a Feedfetcher, pero vale la pena confirmar que el feed no también esté devolviendo un código distinto de 200 por una razón no relacionada. Si tenías la intención de bloquear a Feedfetcher, la URL debería devolver un4xx, no depender de la desautorización. - Interpretación del fallo: Un
200cuando querías bloquear a Feedfetcher significa que el bloqueo no está realmente en vigor — la línea de robots.txt se está ignorando, como se documenta. - Ventana de monitoreo: Inmediata.
- Disparador de reversión: El estado de la URL del feed no coincide con tu intención (bloqueada cuando debería estar abierta, o viceversa).
Ponte a prueba: RSS Feeds
Cinco preguntas rápidas sobre cómo los motores de búsqueda usan los feeds RSS y Atom para el descubrimiento. Elige una respuesta para cada una y luego comprueba.
Registro de cambios
Actualizado el 13 ago 2026.
Resumen editorial y detalles registrados del cambio.Detalles del cambio
-
Los detalles del cambio están disponibles actualmente en inglés.
La comparación completa no está disponible: no se archivó una instantánea anterior para esta revisión.
Actualizado el 3 ago 2026.
Resumen editorial y detalles registrados del cambio.Detalles del cambio
-
Los detalles del cambio están disponibles actualmente en inglés.
La comparación completa no está disponible: no se archivó una instantánea anterior para esta revisión.
Actualizado el 18 jul 2026.
Resumen editorial y detalles registrados del cambio.Detalles del cambio
-
Los detalles del cambio están disponibles actualmente en inglés.
-
Los detalles del cambio están disponibles actualmente en inglés.
-
Los detalles del cambio están disponibles actualmente en inglés.
-
Los detalles del cambio están disponibles actualmente en inglés.
La comparación completa no está disponible: no se archivó una instantánea anterior para esta revisión.