Cómo configurar las actualizaciones automáticas del núcleo de WordPress (WP_AUTO_UPDATE_CORE)

Desde WordPress 3.7, la plataforma actualiza partes de sí misma automáticamente sin que nadie haga clic en nada. La mayoría de los propietarios de sitios son vagamente conscientes de ello, pero pocos tienen una imagen clara de qué se actualiza exactamente, cuándo y cómo cambiar el valor por defecto. Esta guía repasa los cuatro niveles de actualizaciones automáticas que admite el núcleo de WordPress, qué hace realmente cada nivel y cuál es la opción adecuada según gestiones un único sitio, una cartera de agencia o una configuración de hosting gestionado.

Qué actualiza WordPress automáticamente por defecto

De fábrica, toda instalación de WordPress en 2026 hace lo siguiente sin preguntar:

• Actualizaciones menores del núcleo. Pasar de 6.5.1 a 6.5.2 ocurre automáticamente, en segundo plano, el mismo día en que se publica la versión. Estas versiones son correcciones de errores y parches de seguridad. Están diseñadas explícitamente para ser seguras de instalar sin pruebas.
• Actualizaciones de archivos de traducción. Los paquetes de idioma se actualizan automáticamente.
• Versiones de seguridad del núcleo para ramas más antiguas. Aunque tu sitio siga en 6.4 porque no hayas hecho una actualización mayor, las correcciones de seguridad se retroportan y se aplican automáticamente.

Lo que no ocurre automáticamente por defecto:

• Actualizaciones mayores del núcleo. Pasar de 6.5 a 6.6 requiere un clic manual. WordPress muestra el aviso en el escritorio pero no la instala por sí solo.
• Actualizaciones de plugins y temas. Ambas pueden habilitarse por elemento desde la interfaz de administración (desde WordPress 5.5), pero ninguna está activada por defecto. Son un tema aparte y no las controla WP_AUTO_UPDATE_CORE.

El motivo de esta separación es buena ingeniería: las versiones menores se publican bajo una política estricta de "sin cambios disruptivos", por lo que actualizarlas en silencio supone realmente un riesgo bajo. Las versiones mayores introducen ocasionalmente nuevas APIs o cambian comportamientos en los que pueden basarse temas y plugins, y subir silenciosamente una versión mayor en producción ha causado históricamente suficientes roturas como para que el proyecto eligiera el valor por defecto conservador.

Los cuatro niveles de actualizaciones automáticas del núcleo

La constante WP_AUTO_UPDATE_CORE en wp-config.php controla todo esto. Acepta cuatro valores:

• true: Todas las actualizaciones del núcleo se instalan automáticamente, tanto menores como mayores. La opción agresiva.
• 'minor': El valor por defecto si la constante no se define en absoluto. Solo se instalan automáticamente las versiones menores y de seguridad. Las mayores quedan manuales.
• 'beta' y 'rc': Lo usan sitios que quieren versiones previas al lanzamiento. Solo es realista en un entorno de staging o de pruebas, nunca en producción.
• false: Todas las actualizaciones automáticas del núcleo están deshabilitadas. El sitio no hace nada por sí mismo. Tú eres responsable de cada parche, incluidas las correcciones de seguridad.

Establecer cualquiera de estos valores es una sola línea en wp-config.php, en cualquier punto por encima del comentario /* That's all, stop editing! Happy publishing. */:

define('WP_AUTO_UPDATE_CORE', true);

o

define('WP_AUTO_UPDATE_CORE', 'minor');

Guarda el archivo, no hace falta reiniciar nada. WordPress comprueba si hay actualizaciones según una programación (dos veces al día por defecto) y aplica lo que la configuración actual permita.

¿Qué configuración tiene sentido para cada tipo de sitio?

La respuesta honesta depende de tres cosas: cuántas pruebas se hacen antes de que una versión salga a producción, quién se da cuenta cuando algo se rompe y lo bueno que sea el plan de copias de seguridad.

Sitio estándar en producción, sin contrato de mantenimiento dedicado

Configuración recomendada: true (todas las actualizaciones automáticas).

La intuición de que "las actualizaciones mayores automáticas son peligrosas" está en gran medida desfasada. Las actualizaciones mayores de WordPress llevan años siendo estables, y la alternativa realista es "nadie actualiza el sitio durante seis meses porque no hay contrato para ello, y un agujero de seguridad conocido permanece abierto". Un sitio WordPress sin mantenimiento es un peor desenlace que la actualización automática muy puntual que rompe algo. Si una versión mayor rompe el sitio, restaurar desde una copia de seguridad es más rápido que el tiempo que pasarías persiguiendo la actualización manual más adelante. La automatización es la victoria.

Hosting gestionado (Raidboxes, Kinsta, WP Engine, Cloudways, SiteGround)

Configuración recomendada: lo que haga el panel del hosting, normalmente 'minor' a nivel de WordPress.

La mayoría de los hostings gestionados ejecutan su propio flujo de actualización por encima de WordPress. Hacen primero una instantánea, instalan la versión mayor en un clon de staging, ejecutan una comparación visual básica y solo entonces la aplican a producción. Eso es notablemente más seguro que las actualizaciones automáticas estándar. Si estás en este tipo de hosting, configurar WP_AUTO_UPDATE_CORE a algo distinto del valor por defecto suele entrar en conflicto con la lógica del propio hosting. Déjalo en paz, deja que el hosting haga lo suyo y revisa el panel del hosting para ver el historial de actualizaciones.

Cartera de agencia con contrato de mantenimiento

Configuración recomendada: 'minor' en producción, true en staging.

Si un contrato de mantenimiento especifica que pruebas las actualizaciones antes de que salgan a producción, la agencia es la red de seguridad. Producción debería seguir recibiendo automáticamente las versiones menores y de seguridad (que no son opcionales desde el punto de vista de la seguridad), pero las actualizaciones mayores pasan por el flujo de pruebas de la agencia. Los entornos de staging son el lugar adecuado para establecer el valor más agresivo, de modo que los testers detecten roturas pronto.

Instalación WordPress personalizada con fuerte personalización de tema o plugin

Configuración recomendada: 'minor', más un proceso de pruebas real para las actualizaciones mayores.

Los sitios que se han personalizado mucho (cabeceras reconstruidas, bloques de Gutenberg personalizados, integraciones extrañas con constructores de páginas, endpoints REST personalizados) son justo el caso en el que una actualización mayor puede romper algo sutil. La configuración por defecto 'minor' es el suelo correcto: no renuncies a los parches de seguridad, pero trata las mayores como una tarea aparte con una pasada real de pruebas.

Sitio de alta disponibilidad que absolutamente no puede romperse

Configuración recomendada: false para el núcleo, más un proceso real de despliegue.

Este es el único caso en el que tiene sentido desactivar por completo las actualizaciones automáticas del núcleo. Banca, sanidad, entornos regulados donde cada cambio pasa por un proceso de despliegue. Ten en cuenta que aceptas la plena responsabilidad de aplicar manualmente los parches de seguridad en horas tras una publicación, en cada sitio. La mayoría de los equipos que eligen esta configuración también monitorizan la lista de correo de seguridad de WordPress y tienen un pipeline de despliegue capaz de publicar parches el mismo día.

Cómo verificar que tu configuración está activa

1. En el escritorio de WordPress, ve a Herramientas, Salud del sitio, Información.
2. Despliega la sección Constantes de WordPress.
3. Busca WP_AUTO_UPDATE_CORE. Si muestra tu valor, la constante se está leyendo.
4. Para una comprobación más a fondo, mira Actualizaciones en la barra lateral del escritorio. Las actualizaciones automáticas recientes aparecen ahí con marcas de tiempo.

Si el valor de la constante no aparece en Salud del sitio, la causa más probable es que se haya establecido después de que el archivo ya la definiera antes (gana el primer define, y PHP emite un aviso que quizá no veas), o que hayas editado el archivo wp-config.php equivocado.

Qué puede salir mal con las actualizaciones automáticas del núcleo

Tres modos de fallo son realistas y conviene conocerlos:

• La actualización falla parcialmente. La descarga o la extracción se rompe a mitad de proceso, a menudo porque el hosting no tiene suficiente espacio en disco, ha alcanzado un límite de inodos o por un problema de red temporal. WordPress deja un archivo .maintenance en la raíz y el sitio muestra "Brevemente no disponible por mantenimiento programado" para siempre. Solución: conéctate por SFTP a la raíz, elimina el archivo .maintenance y vuelve a ejecutar la actualización desde el escritorio.
• La actualización tiene éxito pero un plugin empieza a lanzar errores. Especialmente tras una actualización mayor, un plugin sin mantenimiento puede romperse contra las nuevas APIs del núcleo. Solución: ten lista una copia de seguridad, identifica el plugin roto a partir del registro de errores (o desactivando los plugins uno a uno) y, o bien actualiza el plugin, o bien sustitúyelo.
• La actualización se omite silenciosamente. Razones comunes: DISALLOW_FILE_MODS está definido en wp-config.php (lo que bloquea todas las actualizaciones, automáticas o no), los permisos de archivo del directorio de WordPress impiden a PHP escribir, o el sitio usa Git para el control de versiones y WordPress detecta el directorio .git y deshabilita las actualizaciones como medida de seguridad. La página de Salud del sitio normalmente marca estos casos.

Actualizaciones automáticas y DISALLOW_FILE_MODS

Las dos constantes interactúan de una forma que pilla a la gente desprevenida. DISALLOW_FILE_MODS (cubierta en nuestra base de conocimiento dentro del tema del editor de archivos) bloquea todas las modificaciones de archivos desde el lado de WordPress, incluidas las actualizaciones automáticas del núcleo. Si ambas constantes están definidas:

define('DISALLOW_FILE_MODS', true);
define('WP_AUTO_UPDATE_CORE', true);

El resultado es que DISALLOW_FILE_MODS gana. WordPress no actualizará nada automáticamente. Esto rara vez es lo que la gente pretende. O quieres un sitio bloqueado que se actualice desde fuera (pipeline de despliegue, WP CLI), en cuyo caso DISALLOW_FILE_MODS = true es lo correcto y WP_AUTO_UPDATE_CORE es irrelevante. O quieres que el sitio se actualice solo, en cuyo caso DISALLOW_FILE_MODS no debería estar definida.

¿Y las actualizaciones automáticas de plugins y temas?

Las actualizaciones automáticas de plugins y temas son un mecanismo aparte que llegó con WordPress 5.5. Se configuran por elemento desde el escritorio (lista de Plugins, el enlace "Activar actualizaciones automáticas" en cada fila) o globalmente mediante filtros. La recomendación general: activa las actualizaciones automáticas para cualquier plugin en el que confíes en la disciplina de publicación de su mantenedor, y déjalas desactivadas para los plugins que publican cambios disruptivos con regularidad. Las versiones mayores de WooCommerce, en particular, suelen merecer la pena retenerlas para una actualización manual con una prueba rápida.

Si quieres habilitar las actualizaciones automáticas de plugins de forma programática para todos los plugins, este filtro lo hace:

add_filter('auto_update_plugin', '__return_true');
add_filter('auto_update_theme', '__return_true');

Mete eso en un pequeño plugin must-use bajo wp-content/mu-plugins/ en lugar de en functions.php, para que un cambio de tema no lo desactive.

La conclusión para las actualizaciones del núcleo: para la mayoría de los sitios en 2026, la configuración por defecto 'minor' es conservadora en la dirección equivocada. O bien estableces WP_AUTO_UPDATE_CORE a true y dejas que la plataforma se mantenga al día, o bien te comprometes a un proceso de mantenimiento real que se ocupe manualmente de las mayores en un plazo razonable. El término medio de "configuración por defecto y nadie vigilando" es lo que produce sitios WordPress sin parchear y dos versiones por detrás, y ese es el verdadero estado de alto riesgo.