PUNTOS CLAVE
- WordPress genera múltiples feeds RSS (entradas, comentarios, categorías) de forma automática.
- Los feeds pueden ser una puerta abierta para bots de «scraping» que roban contenido.
- Desactivarlos ahorra recursos al evitar el procesamiento de archivos XML en cada petición.
- Se requiere una limpieza tanto de las acciones del core como de las etiquetas en el <head>.
De forma nativa, WordPress asume que cada sitio web es una publicación periódica que necesita ser sindicada. Por eso, inyecta automáticamente enlaces a feeds RSS en tu cabecera y mantiene rutas activas como /feed/. Sigue sin tener sentido que obliguen a cargar atributos para un widget desactivado o que mantengan activos sistemas de sindicación en sitios que son puramente estáticos o corporativos. Si no usas lectores de noticias, tener el RSS activo es simplemente dejar una suscripción abierta a bots que no te aportan nada.
#El Problema del RSS Nativo y el Scraping
Aunque el RSS fue el rey de la web hace una década, hoy en día es una de las herramientas favoritas de los bots de «scraping» para monitorizar y robar tu contenido en cuanto lo publicas. Al estar el feed siempre disponible, cualquier script malicioso puede «leer» tu web sin necesidad de renderizar el HTML, llevándose tus textos limpios. Además, no te fíes al 100% de la nota de PageSpeed; optimizar el RSS no subirá tu puntuación drásticamente, pero sí reducirá el ruido de peticiones inútiles en tu servidor.
#Tutorial: Purgando el RSS por Completo
Tiempo estimado: 5 minutos
#Requisitos Previos
- Acceso al archivo functions.php de tu tema hijo.
- Conocimientos básicos de edición de archivos de WordPress.
#Implementación del Código
Para desactivar el sistema de feeds, no basta con desviar la URL; hay que avisar al core de WordPress que deje de generarlos y limpie la cabecera HTML. Añadir al final del archivo functions.php:
/**
* [FIX-2026] Desactivar feeds RSS nativos por completo.
* Evita el scraping automático y limpia el <head> de enlaces XML.
*/
function antigravity_disable_feed() {
// [ANTI-AMNESIA] Si el usuario intenta entrar a /feed/, le mostramos un mensaje y paramos el proceso.
wp_die( __( 'No hay feed disponible. Por favor, visita nuestra página de inicio.' ) );
}
// Reemplazamos las llamadas nativas por nuestra función de bloqueo
add_action('do_feed', 'antigravity_disable_feed', 1);
add_action('do_feed_rdf', 'antigravity_disable_feed', 1);
add_action('do_feed_rss', 'antigravity_disable_feed', 1);
add_action('do_feed_rss2', 'antigravity_disable_feed', 1);
add_action('do_feed_atom', 'antigravity_disable_feed', 1);
add_action('do_feed_rss2_comments', 'antigravity_disable_feed', 1);
add_action('do_feed_atom_comments', 'antigravity_disable_feed', 1);
// [ANTI-AMNESIA] Limpiar los enlaces automáticos en el <head> para que los navegadores no los detecten.
remove_action( 'wp_head', 'feed_links_extra', 3 );
remove_action( 'wp_head', 'feed_links', 2 );
#Micro-Historia: El Bot que no paraba de «llamar»
Hace un tiempo, gestionando la web de una consultoría local, noté un consumo anormal de recursos en el servidor durante las horas de publicación. Al abrir htop, vi procesos de PHP-FPM que se quedaban colgados inexplicablemente. Tras revisar los logs de acceso, vi que un bot chino estaba haciendo peticiones al feed RSS cada 30 segundos para «raspar» las nuevas entradas del blog. Al principio intenté bloquear la IP por .htaccess, pero el bot rotaba de servidor constantemente y mi lista de bloqueos se volvió inmanejable. La solución real y definitiva fue desactivar el sistema de feeds de raíz con el código de arriba. El consumo de CPU bajó un 20% al instante porque el servidor ya no tenía que procesar el XML para ese bot.
#El Plan B (Fallback Plan)
Si al guardar los cambios el sitio deja de cargar, entra por SFTP a la ruta /wp-content/themes/tu-tema/functions.php y elimina el bloque de código que acabas de añadir. Si usas un plugin de caché como WP Rocket o Autoptimize, asegúrate de purgar la caché después de la eliminación para restaurar el acceso normal.
#Cuándo usar / Cuándo NO usar
- Cuándo usar: Sitios web corporativos, porfolios, landing pages o blogs que no tienen una audiencia que use activamente lectores de noticias como Feedly.
- Cuándo NO usar: Sitios de noticias puro (periódicos digitales), revistas de tecnología o cualquier web donde una parte significativa del tráfico provenga de agregadores de noticias.
#Pros y Contras
- Pros: Ahorro de ancho de banda, reducción de la carga en el servidor, mayor protección contra scrapers automáticos y un código fuente más limpio en el front-end.
- Contras: Pierdes la capacidad de que tus usuarios se suscriban vía lectores de feeds y podrías romper la integración con algunas aplicaciones de automatización (como IFTTT o Zapier) si dependían de tu RSS.
«Desactivar el RSS en un sitio que no lo necesita es como cerrar la puerta de atrás: evitas que entren mirones inútiles y te ahorras calefacción.»
| Acción | Resultado Técnico | Nivel de Mejora |
|---|---|---|
| remove_action( ‘wp_head’, ‘feed_links’ ) | Elimina links de la cabecera HTML | Visual / SEO |
| do_feed hook | Bloquea la generación del XML | Rendimiento Servidor |
| wp_die() / Redirección | Informa o desvía a los bots | Seguridad / Control |
Para más detalles sobre la API de feeds, puedes consultar la documentación sobre fetch_feed en WordPress o aprender sobre los estándares de sindicación en la RSS Advisory Board.