¿Por qué WordPress se actualizó solo? Quién lo hizo y cómo tomar el control

Entras a tu sitio y la versión cambió. O un plugin trae una pantalla nueva que nadie pidió. No tocaste nada, así que la pregunta es lógica: ¿quién actualizó mi WordPress?

La respuesta corta es que hay hasta cuatro «responsables» posibles, y saber cuál fue es lo que te permite decidir qué dejar automático y qué no.

Los cuatro que pueden actualizar tu sitio

1. WordPress mismo. Desde hace años instala solo las versiones menores y de seguridad (por ejemplo, de 7.1.1 a 7.1.2). Es lo normal y es bueno.
2. Tú, sin darte cuenta. En Escritorio → Actualizaciones existe la opción de actualizar automáticamente a todas las versiones nuevas, incluidas las mayores. Y en Plugins y Apariencia → Temas cada elemento tiene su enlace «Activar actualizaciones automáticas». Basta un clic de hace meses.
3. El panel del hosting. Si instalaste WordPress con Softaculous o lo administras con WP Toolkit en cPanel, ambos tienen sus propias reglas de actualización, independientes de WordPress. Es la causa más común de «se actualizó solo».
4. Un servicio externo. Paneles como ManageWP, MainWP o Jetpack pueden programar actualizaciones si alguna vez conectaste el sitio.

Para saber quién fue: revisa primero WP Toolkit o Softaculous (ambos guardan un historial de actualizaciones), después la pantalla de Actualizaciones. Si recibiste un correo con el asunto «Tu sitio se ha actualizado», fue WordPress.

Qué conviene dejar automático

No existe una respuesta única, pero esta regla funciona en la mayoría de los sitios:

• Versiones menores y de seguridad del núcleo: siempre automáticas. Son pequeñas, rara vez rompen algo y cierran agujeros conocidos.
• Versiones mayores del núcleo: manuales, unos días después del lanzamiento y con respaldo previo. Así dejas que otros encuentren los problemas primero.
• Plugins sencillos y muy usados: automáticos. Desde WordPress 6.6, si una actualización automática de plugin provoca un error fatal, WordPress la revierte solo.
• WooCommerce, constructores visuales y plugins de pago: manuales, idealmente probados antes en una copia de prueba.
• Traducciones: automáticas. No tienen riesgo.

Control fino con constantes en wp-config.php

Si prefieres que la regla quede escrita y no dependa de un clic en el escritorio, agrega una de estas líneas a wp-config.php, antes de la línea que dice «That’s all, stop editing»:

// Solo versiones menores y de seguridad (lo recomendado)
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

// O: todas las versiones, incluidas las mayores
// define( 'WP_AUTO_UPDATE_CORE', true );

// O: ninguna actualización automática del núcleo
// define( 'WP_AUTO_UPDATE_CORE', false );

Evita AUTOMATIC_UPDATER_DISABLED. Muchos tutoriales antiguos la recomiendan, pero apaga absolutamente todo, incluidos los parches de seguridad y las traducciones. Es la forma más fácil de terminar con un sitio desactualizado sin darte cuenta.

Nivel pro: un mu-plugin con tus reglas

Con filtros puedes ir más lejos: actualizar solo ciertos plugins, bloquear otros aunque alguien active el enlace en el escritorio, y recibir correo solo cuando algo falla. Guarda esto como wp-content/mu-plugins/cwp-actualizaciones.php y ajusta las listas:

<?php
/**
 * Plugin Name: Reglas de actualizaciones (Curso WordPress)
 * Description: Decide qué se actualiza solo y qué no.
 */

// Plugins que SIEMPRE se actualizan solos (carpeta del plugin).
const CWP_AUTO_SI = array( 'akismet', 'wordfence', 'wp-mail-smtp' );

// Plugins que NUNCA se actualizan solos, aunque alguien active el enlace.
const CWP_AUTO_NO = array( 'woocommerce', 'elementor', 'elementor-pro' );

add_filter( 'auto_update_plugin', function ( $actualizar, $item ) {
	$carpeta = isset( $item->slug ) ? $item->slug : '';
	if ( in_array( $carpeta, CWP_AUTO_NO, true ) ) {
		return false;
	}
	if ( in_array( $carpeta, CWP_AUTO_SI, true ) ) {
		return true;
	}
	return $actualizar; // El resto: lo que diga el escritorio.
}, 20, 2 );

// Las traducciones siempre.
add_filter( 'auto_update_translation', '__return_true' );

// Correos: solo cuando una actualización automática falla.
add_filter( 'auto_core_update_send_email', function ( $enviar, $tipo ) {
	return 'fail' === $tipo || 'critical' === $tipo;
}, 10, 2 );
add_filter( 'auto_plugin_update_send_email', '__return_false' );
add_filter( 'auto_theme_update_send_email', '__return_false' );

¿Por qué mu-plugin y no functions.php? Porque un mu-plugin no depende del tema: si cambias de tema o el tema falla, las reglas siguen funcionando. Además nadie puede desactivarlo por error desde la pantalla de Plugins.

Revisar y cambiar todo desde la terminal

Si tienes acceso SSH, WP-CLI te muestra el estado completo en segundos, algo muy útil cuando administras varios sitios:

# ¿Qué plugins tienen actualización automática activa?
wp plugin auto-updates status --all

# Activarla en uno o desactivarla en otro
wp plugin auto-updates enable akismet
wp plugin auto-updates disable woocommerce

# Lo mismo para temas
wp theme auto-updates status --all

# ¿Qué está pendiente de actualizar?
wp core check-update
wp plugin list --update=available

Y si una actualización automática rompió algo

1. Si ves la pantalla de «error crítico», revisa tu correo de administrador: WordPress te envía un enlace al modo de recuperación para entrar y desactivar el plugin culpable.
2. Si el problema es de un plugin, puedes volver a la versión anterior con WP-CLI: wp plugin install nombre-del-plugin --version=1.2.3 --force.
3. Si fue el tema o el núcleo, restaura el respaldo de la noche anterior. Por eso las actualizaciones automáticas y los respaldos diarios siempre deben ir juntos.

¿No logras descubrir quién actualizó tu sitio? Cuéntanos en el foro cómo instalaste WordPress y qué panel usa tu hosting, y te ayudamos a encontrarlo.