Cómo actualizar WordPress sin romper el sitio

El 10 de marzo de 2026, WordPress publicó la versión 6.9.2. Era una versión de seguridad con diez correcciones. Ese mismo día publicó la 6.9.3, y su anuncio explica por qué: algunos usuarios avisaron que «the front end of their site was appearing blank after updating to 6.9.2». Traducción nuestra: la parte pública de su sitio aparecía en blanco después de actualizar a la 6.9.2.

Al día siguiente salió la 6.9.4. El equipo de seguridad había descubierto que «not all of the security fixes were fully applied». Traducción nuestra: no todas las correcciones de seguridad habían quedado aplicadas por completo.

Tres versiones en dos días. La lección no es dejar de actualizar. En septiembre, la 7.1.2 corrigió una falla con la que, bajo ciertas condiciones del servidor y del tema activo, un atacante sin cuenta podía llegar a ejecutar código en el sitio. Quedarse quieto también cuesta. Lo que hace falta es actualizar con una salida preparada.

Esta guía es para quien administra su propio sitio en WordPress, con tienda o sin ella. Explica qué se actualiza solo, qué protecciones trae WordPress y dónde terminan, en qué orden actualizar, qué revisar después y qué hacer si algo se rompe.

Esto vas a encontrar abajo.

• Desde la 5.6, de diciembre de 2020, las instalaciones nuevas aplican solas también las versiones mayores, según el manual de administración de WordPress. Si tu sitio es de después y nadie cambió el ajuste, la 7.2 podría instalarse sola en diciembre.
• En lo que va de 2026, la rama vigente de WordPress tuvo 13 versiones en 12 días distintos, sin contar los parches para ramas anteriores. Ocho traían correcciones de seguridad, y dos de ellas salieron con cinco días de diferencia.
• WordPress trae tres redes de seguridad para plugins y temas, de la 5.2, la 6.3 y la 6.6. La de la 6.6 regresa un plugin a su versión anterior si la portada da un error fatal. El carrito no lo revisa.
• La primera versión de mantenimiento llegó entre 7 y 63 días después de cada versión mayor, en las seis más recientes.
• PHP 8.2 deja de recibir parches de seguridad el 31 de diciembre de 2026. WooCommerce 11.6, prevista para febrero de 2027, pedirá PHP 8.1 o más.
• Patchstack calcula una mediana ponderada de 5 horas hasta la primera explotación de una vulnerabilidad, en su informe con datos de 2025.

En México, el 97.3 % de quienes usan internet se conecta con un celular inteligente, según el INEGI. Por eso, la revisión después de cada actualización incluye siempre un teléfono.

Dos avisos antes de empezar. Lo ideal es probar primero en una copia del sitio; más abajo explico cuándo se puede saltar ese paso. Y no recomiendo ningún hosting ni ningún plugin de respaldo: cuando un paso pide una herramienta, digo qué revisar para elegirla.

Las citas de documentos en inglés van en su idioma original, seguidas de una traducción nuestra, y cada una está enlazada en «Fuentes y metodología».

Trece versiones en nueve meses: lo que pasó en 2026

Antes del método, los hechos. Un procedimiento para actualizar tiene que funcionar con el ritmo real de WordPress, y el de 2026 fue intenso.

Las versiones de este año

Entre el 1 de enero y el 8 de octubre de 2026, la rama vigente de WordPress tuvo dos versiones mayores, la 7.0 y la 7.1, y once menores. No cuento los parches para ramas anteriores, de los que hablo más abajo. Una versión mayor trae funciones nuevas. Una menor corrige errores o fallas de seguridad, y se reconoce por el tercer número: 7.1.3. Esta es la lista, armada con los anuncios oficiales.

Versión	Fecha	Tipo	Qué traía, según su anuncio
6.9.1	3 de febrero	Mantenimiento	49 errores corregidos
6.9.2	10 de marzo	Seguridad	Diez fallas de seguridad corregidas
6.9.3	10 de marzo	Corrección	Arreglo para los sitios que quedaron en blanco con la 6.9.2
6.9.4	11 de marzo	Seguridad	Las correcciones de la 6.9.2 que no habían quedado completas
7.0	20 de mayo	Mayor	Funciones nuevas
7.0.1	9 de julio	Mantenimiento	31 errores corregidos
7.0.2	17 de julio	Seguridad	Una falla crítica y una de severidad alta
7.0.3	6 de agosto	Seguridad	Varias correcciones de seguridad
7.0.4	12 de agosto	Seguridad	Ejecución remota de código por un usuario con rol de autor o superior, en sitios con Imagick y Ghostscript
7.1	19 de agosto	Mayor	Funciones nuevas
7.1.1	17 de septiembre	Mantenimiento y seguridad	36 errores y 11 fallas de seguridad
7.1.2	22 de septiembre	Seguridad	Una falla que, bajo ciertas condiciones, permitía ejecutar código sin tener cuenta
7.1.3	6 de octubre	Mantenimiento y seguridad	7 fallas de seguridad y 4 errores

Son 13 versiones en 12 días distintos, porque la 6.9.2 y la 6.9.3 salieron el mismo día. La cuenta de las diez fallas de la 6.9.2 es la de su anuncio, que las lista una por una. Ocho traían correcciones de seguridad. Desde el 17 de julio hubo seis versiones de seguridad en 81 días, separadas por 20, 6, 36, 5 y 14 días.

No hay un día fijo. Según la fecha de sus anuncios, salieron en martes, en miércoles, en jueves y, una vez, en viernes.

Marzo: la versión de seguridad que dejó páginas en blanco

La 6.9.2 era una versión de seguridad. Su anuncio la presenta en una línea: «This is a security release that features several fixes». Traducción nuestra: esta es una versión de seguridad que trae varias correcciones. Y pide actualizar ya: «Because this is a security release, it is recommended that you update your sites immediately». Traducción nuestra: como es una versión de seguridad, se recomienda actualizar tus sitios de inmediato.

Ese mismo día llegaron los reportes de sitios con la parte pública en blanco. El anuncio de la 6.9.3 explica la causa. Algunos temas cargaban sus archivos de plantilla de una forma poco común, que WordPress no soporta oficialmente, y la versión de seguridad los dejó sin funcionar. La respuesta fue rápida: «As a result, the Security Team has decided to address this in a fast follow 6.9.3 release». Traducción nuestra: por eso, el equipo de seguridad decidió atenderlo con una versión 6.9.3 de salida rápida.

Al día siguiente salió la 6.9.4, con las correcciones de seguridad que habían quedado incompletas.

Tres lecciones salen de esos dos días.

1. Una versión de seguridad también puede romper un sitio. No por mala, sino porque toca código del que dependen temas y plugins.
2. El arreglo llegó en horas. Quien tenía activas las actualizaciones automáticas recibió los arreglos sin hacer nada.
3. El sitio que quedó en blanco necesitaba una salida: un respaldo reciente o una forma rápida de regresar. Eso es lo que este artículo arma.

Septiembre: dos versiones en cinco días

El 17 de septiembre salió la 7.1.1. Su anuncio la resume así: «This security and maintenance release features 17 bug fixes on Core, 19 bug fixes for the Block Editor, and 11 security fixes». Traducción nuestra: esta versión de seguridad y mantenimiento trae 17 errores corregidos en el núcleo, 19 en el editor de bloques y 11 correcciones de seguridad.

Cinco días después, el 22, salió la 7.1.2, con una corrección de seguridad. Según su anuncio, un atacante sin cuenta podía, bajo ciertas condiciones, cargar como plantilla un archivo PHP del servidor que estuviera fuera de las carpetas del tema activo. La frase técnica es esta: podía «make page template resolution include a chosen readable local PHP file». Traducción nuestra: hacer que la resolución de plantillas de página incluya un archivo PHP local legible, elegido por él. Y cierra con la consecuencia: «this can lead to remote code execution (RCE)». Traducción nuestra: esto puede llevar a la ejecución remota de código.

Las condiciones dependían del servidor y del tema, así que no todos los sitios estaban expuestos. Pero en un caso inventado, quien revisara a mano una vez al mes, el día 1, habría aplicado las dos el 1 de octubre. La 7.1.1, con 14 días de atraso; la 7.1.2, con 9.

Los parches también llegan a versiones viejas, por cortesía

El anuncio de la 7.1.3 avisa que las correcciones se llevan también a versiones anteriores, y pone el límite: hoy llegan hasta la 4.7. De la 4.7 a la 7.0 hay 24 ramas, además de la actual. La lista oficial de versiones registra que el 6 de octubre salieron también la 7.0.7, la 6.9.10 y la 6.8.11, entre otras.

El mismo anuncio agrega un aviso que conviene leer despacio. «As a reminder, only the most recent version of WordPress is actively supported». Traducción nuestra: como recordatorio, solo la versión más reciente de WordPress tiene soporte activo.

Y una nota técnica de enero de 2026 lo explica mejor: los parches llegan a las versiones viejas, en sus palabras, porque «fixes are backported down to WordPress 4.7 as a courtesy when possible». Traducción nuestra: las correcciones se llevan hacia atrás hasta WordPress 4.7 como cortesía, cuando es posible.

Cortesía no es compromiso. Una versión vieja recibe parches mientras el equipo pueda dárselos, sin promesa de seguir haciéndolo.

Lo que esto dice de cómo actualizar

Hay dos fuerzas que tiran en sentidos contrarios. La seguridad pide actualizar pronto: seis versiones de seguridad en menos de tres meses. Y la 6.9.2 recuerda que una actualización puede dejar un sitio en blanco.

La salida no es elegir una de las dos. Es separar lo que se actualiza solo de lo que se actualiza con plan, tener siempre una forma de regresar y revisar el sitio después de cada cambio. Las siguientes secciones van en ese orden.

Lo que WordPress actualiza solo, y lo que no

Una parte de las actualizaciones ya ocurre sin que toques nada. Saber cuál ya es la mitad del trabajo, porque decide qué te toca a ti. Si apenas estás conociendo la plataforma, el contexto está en qué es WordPress y por qué sigue siendo útil.

Hay cuatro tipos de actualización. Cada uno tiene su regla.

Versiones menores: solas desde 2013

La versión 3.7, del 24 de octubre de 2013, empezó a aplicar sola las versiones de mantenimiento y de seguridad. Trece años después, sigue siendo el comportamiento por defecto. La página del manual que explica el archivo de configuración wp-config.php describe así el valor de fábrica de la constante que lo controla: actualizaciones automáticas del núcleo solo para las versiones menores. Como se verá enseguida, en las instalaciones nuevas desde la 5.6 un ajuste guardado del sitio activa además las mayores.

Los anuncios de seguridad lo recuerdan. El de la 7.1.3 lo dice así: «If you have sites that support automatic background updates, the update process will begin automatically». Traducción nuestra: si tienes sitios que admiten actualizaciones automáticas en segundo plano, el proceso de actualización empezará solo.

Y la pantalla de salud del sitio revisa que funcionen, por una razón que da su documentación. «Background updates ensure that WordPress can auto-update if a security update is released for the version you are currently using». Traducción nuestra: las actualizaciones en segundo plano aseguran que WordPress pueda actualizarse solo si sale una versión de seguridad para la versión que usas.

Versiones mayores: depende de cuándo se instaló tu sitio

Aquí está el dato que ninguna de las cuatro guías de la competencia que revisé dice bien. El manual de administración avanzada de WordPress, actualizado el 1 de julio de 2026, lo pone así. «Starting with WordPress 5.6, new installations have automatic updates enabled for both minor and major core releases by default, unless WordPress detects a version control checkout». Traducción nuestra: desde WordPress 5.6, las instalaciones nuevas tienen activadas por defecto las actualizaciones automáticas de las versiones menores y de las mayores. La excepción es que WordPress detecte que el sitio está bajo un sistema de control de versiones, como Git.

Las instalaciones que ya existían conservaron su comportamiento anterior, según el mismo manual. Para ellas, las mayores se aplican solas solo si alguien las activó.

La 5.6 salió el 8 de diciembre de 2020. De ahí sale una deducción nuestra. Si tu sitio se instaló de esa fecha en adelante y nadie cambió el ajuste, también se actualiza solo a cada versión mayor. La 7.2 está programada para el 8 de diciembre de 2026, en plena temporada de compras; otra página oficial dice el 10.

No tiene por qué ser un problema. Pero conviene que sea una decisión tuya y no una sorpresa.

Plugins y temas: solo los que tú marques

Con los plugins y los temas, la regla es la contraria. Sus actualizaciones automáticas vienen apagadas. La documentación lo dice en una frase. «Since WordPress 5.5, websites Administrators can manually opt-in for automatic updates theme by theme and plugin by plugin». Traducción nuestra: desde WordPress 5.5, los administradores pueden activar manualmente las actualizaciones automáticas, tema por tema y plugin por plugin.

La 5.5 salió en agosto de 2020. Lo que activas se revisa con esta frecuencia: «By default WordPress runs auto-updates twice per day». Traducción nuestra: por defecto, WordPress ejecuta las actualizaciones automáticas dos veces al día.

Y avisa: «By default WordPress sends email notifications to website owners to inform them that plugins and themes were automatically updated». Traducción nuestra: por defecto, WordPress manda correos a los dueños del sitio para avisarles que plugins y temas se actualizaron solos.

Hay una excepción que conviene conocer. Según el manual de administración, en casos especiales WordPress.org puede indicar a los sitios que actualicen un plugin o un tema por su cuenta. Esos casos los decide el equipo de seguridad de WordPress, para corregir vulnerabilidades críticas.

Traducciones

Los archivos de idioma, como el español de México de WordPress y de cada plugin, tienen su propia regla. El manual la da en una línea: «Translation files are auto-updated by default». Traducción nuestra: los archivos de traducción se actualizan solos por defecto.

Cómo saber qué tiene tu sitio

En el panel, entra a Escritorio y luego a Actualizaciones (Dashboard › Updates, en la interfaz en inglés). Arriba, WordPress dice qué tipo de actualizaciones automáticas del núcleo tiene el sitio. El código de esa pantalla, en inglés, tiene dos frases para cuando las automáticas están encendidas.

• «This site is automatically kept up to date with each new version of WordPress». Traducción nuestra: este sitio se mantiene al día automáticamente con cada versión nueva de WordPress. Así se ve cuando las mayores también se aplican solas.
• «This site is automatically kept up to date with maintenance and security releases of WordPress only». Traducción nuestra: este sitio se mantiene al día automáticamente solo con las versiones de mantenimiento y seguridad de WordPress.

Debajo hay un enlace para cambiar de una a otra. En inglés dice «Switch to automatic updates for maintenance and security releases only». Traducción nuestra: cambiar a actualizaciones automáticas solo para las versiones de mantenimiento y seguridad. O, en el otro caso, «Enable automatic updates for all new versions of WordPress». Traducción nuestra: activar las actualizaciones automáticas para todas las versiones nuevas de WordPress. En español verás la traducción oficial de esas frases.

Hay otros dos avisos posibles. Si las automáticas están apagadas del todo: «This site will not receive automatic updates for new versions of WordPress». Traducción nuestra: este sitio no recibirá actualizaciones automáticas de las versiones nuevas de WordPress. Y si WordPress detecta un sistema de control de versiones: «This site appears to be under version control. Automatic updates are disabled». Traducción nuestra: este sitio parece estar bajo control de versiones; las actualizaciones automáticas están desactivadas.

Para los plugins, ve a Plugins, Plugins instalados. Hay una columna con un enlace por plugin para activar o desactivar su actualización automática. Para los temas, entra a Apariencia, Temas, y haz clic en la miniatura de cada uno: el enlace aparece en la ventana que se abre, debajo del autor.

Cuando el hosting o un ajuste deciden por ti

Si en la pantalla de actualizaciones no aparece el enlace para cambiar, alguien ya decidió. Según el código de esa pantalla, el enlace se oculta cuando una constante o un filtro fijan el comportamiento.

Las constantes van en wp-config.php. La principal es WP_AUTO_UPDATE_CORE, con tres valores.

Valor	Qué hace, según el manual
true	Activa las actualizaciones de desarrollo, menores y mayores
false	Las desactiva todas
'minor'	Activa solo las menores

Hay otra constante, AUTOMATIC_UPDATER_DISABLED, que apaga todas las actualizaciones automáticas, incluidas las de seguridad. El manual la desaconseja con claridad: las menores y las traducciones son el mínimo que recomienda dejar encendido.

Algunos hostings y agencias fijan este comportamiento con constantes o filtros, y la nota técnica de la 5.6 aclara que esos ajustes mandan sobre el de la pantalla. Si tu hosting administra WordPress por ti, la pregunta para su soporte es concreta: qué actualizan ellos, cuándo, y si avisan antes.

Mi criterio, y va como criterio: en un blog o en un sitio de servicios, pasaría las versiones mayores a manual. Las aplicaría una o dos semanas después de que salgan, con respaldo y revisión. En una tienda, también a manual, antes de la temporada de compras de fin de año, y aplicaría la 7.2 con calma, en enero. En los dos casos, dejaría encendidas las menores.

Las redes de seguridad que ya trae WordPress

WordPress no deja el sitio solo cuando una actualización sale mal. Trae tres redes para plugins y temas, cada una de una versión distinta. Conviene saber qué atrapa cada una, y sobre todo qué deja pasar.

El modo de recuperación, desde la 5.2

La versión 5.2 salió el 7 de mayo de 2019. Desde entonces, cuando un plugin o un tema provoca un error fatal de PHP, el visitante ve un mensaje de error en lugar de una pantalla en blanco. Hoy, el código de WordPress usa esta frase: «There has been a critical error on this website». Traducción nuestra: hubo un error crítico en este sitio web. En la versión en español verás la traducción.

En la pantalla de acceso y en el panel, el mensaje agrega una instrucción: «Please check your site admin email inbox for instructions». Traducción nuestra: revisa la bandeja del correo de administración del sitio para ver las instrucciones.

Ese correo es la pieza que importa. La nota técnica de la versión, «Fatal Error Recovery Mode in 5.2», explica cómo funciona.

1. WordPress manda un correo a la dirección de administración del sitio, con una explicación del error y un enlace secreto.
2. Al abrir el enlace, el navegador recibe una cookie y entra en modo de recuperación. Hay que iniciar sesión.
3. En ese modo, el plugin o el tema que falló queda en pausa, solo para ese navegador. El panel muestra cuál es y qué error dio.
4. Desde ahí lo desactivas, lo corriges o buscas al autor. Al salir del modo, se borra la cookie.

Mientras tanto, los demás visitantes siguen viendo el sitio roto. El modo de recuperación te deja entrar a arreglar; no arregla nada solo.

Un detalle práctico: el correo va a la dirección que está en Ajustes, Generales. Si esa dirección es de alguien que ya no trabaja contigo, el enlace le llega a esa persona. Revísala hoy.

Si una actualización manual falla al instalarse, desde la 6.3

La 6.3 salió el 8 de agosto de 2023 con una segunda red. Su nota técnica la describe así: si una actualización manual de un plugin o de un tema falla, «the rollback feature will automatically restore the previously installed version». Traducción nuestra: la función de reversión restaura automáticamente la versión que estaba instalada.

Funciona porque WordPress guarda una copia temporal de la versión vieja mientras instala la nueva. Si la instalación falla, regresa la copia a su lugar.

El límite está en lo que cuenta como falla. La misma nota la define como un error durante la instalación del paquete. Si la versión nueva se instala bien y luego rompe el sitio, esta red no actúa. La nota de 2023 dejaba esa revisión para una etapa posterior.

Si un plugin se actualiza solo y provoca un error fatal, desde la 6.6

Esa etapa llegó con la 6.6, del 16 de julio de 2024. La guía de campo de esa versión la presenta como una de sus funciones destacadas: «the automatic rollback of plugin auto-updates upon detecting PHP fatal errors». Traducción nuestra: la reversión automática de las actualizaciones automáticas de plugins al detectar errores fatales de PHP.

Cómo lo hace, según la propuesta técnica que la llevó al núcleo, «Merge Proposal: Rollback Auto-Update». Después de actualizar un plugin, WordPress hace una petición a su propia portada, una petición de bucle invertido (loopback, en inglés), es decir, el sitio se visita a sí mismo. Y busca en la respuesta un error fatal. Si lo encuentra, entonces «the previously installed version of the plugin is restored». Traducción nuestra: se restaura la versión del plugin que estaba instalada. El correo de administración recibe un aviso, y el sitio queda en modo de mantenimiento mientras duran las actualizaciones automáticas.

El plugin no se queda castigado. La propuesta explica que el intento se repite en la siguiente revisión de actualizaciones automáticas.

Lo que la revisión de la 6.6 no ve

Leí el código de la clase que hace las actualizaciones automáticas, WP_Automatic_Updater, en la referencia para desarrolladores. Lo que sigue son deducciones nuestras a partir de ese código. El modo de recuperación es otra cosa: actúa ante un error fatal en cualquier página, pero solo cuando alguien la visita, y no regresa ninguna versión.

• Solo plugins. La revisión de errores fatales y la reversión están dentro de la parte del código que actualiza plugins. Los temas se actualizan sin esa revisión.
• Solo plugins que estaban activos. La revisión corre si el plugin estaba activo antes de actualizarse.
• Solo la portada. La petición va a la dirección principal del sitio. Un error que solo aparece en el carrito, en el pago o en el panel no se ve desde ahí.
• Solo errores fatales de PHP. Un diseño descompuesto, un botón que no responde o un formulario que deja de enviar no son errores fatales. Pasan la revisión.
• Solo actualizaciones automáticas. Si actualizas a mano y el plugin rompe el sitio, la red disponible es el modo de recuperación.

Y un caso raro. Si la petición a la portada falla por sí misma, el código la cuenta como error fatal y regresa la versión anterior. Deducción nuestra: en un sitio que no puede hacerse peticiones a sí mismo, las actualizaciones automáticas de plugins activos se revertirían una y otra vez.

La pantalla de salud del sitio revisa justo eso. Su documentación explica para qué sirven esas peticiones: «Loopback requests are used to run scheduled events and are also used by the built-in editors for themes and plugins to verify code stability». Traducción nuestra: las peticiones de bucle invertido se usan para ejecutar tareas programadas, y los editores de temas y plugins que trae WordPress también las usan para verificar la estabilidad del código. Si ahí aparece un problema con ellas, llévalo a tu hosting.

El núcleo tiene su propia reversión, desde la 3.7

La propuesta de la 6.6 recuerda un antecedente: las actualizaciones automáticas del núcleo tienen reversión desde la 3.7, de 2013. Lo que faltaba era lo mismo para los plugins.

Y WordPress avisa por correo cuando el núcleo se actualiza solo, tanto si sale bien como si falla. Ese correo también va a la dirección de administración.

Mi criterio, y va como criterio: trataría estas redes como lo que son, un paracaídas para el error fatal que tumba una página. No las usaría como razón para actualizar sin respaldo ni para saltarme la revisión. Un carrito roto puede no dar ningún error en la portada y pasar días sin que nadie lo note.

El respaldo, antes de tocar nada

Las redes de WordPress atrapan un tipo de error. El respaldo te deja volver al sitio de antes, sea cual sea la causa. Por eso va primero.

Dos partes: la base de datos y los archivos

Un sitio de WordPress vive en dos lugares, y el manual de administración avanzada los separa con cuidado. La base de datos guarda las entradas, los comentarios y los ajustes; en una tienda, también los pedidos. Los archivos son el núcleo de WordPress, los plugins, los temas, las imágenes que subiste, wp-config.php y .htaccess.

El mismo manual advierte que un respaldo de archivos, por lo general, no incluye la base de datos. Son dos copias distintas, y hacen falta las dos.

Sobre cuándo hacerlo, es directo. «Back up your database regularly, and always before an upgrade». Traducción nuestra: respalda tu base de datos con regularidad, y siempre antes de una actualización.

Y sobre cada cuánto, da dos medidas. «For smaller websites with fewer posts, backups should be made once a week». Traducción nuestra: en los sitios más chicos, con menos entradas, los respaldos deben hacerse una vez por semana. «For high-activity websites with a lot of posts, backups should be made daily». Traducción nuestra: en los sitios con mucha actividad y muchas entradas, deben hacerse a diario.

Lectura nuestra: una tienda que recibe pedidos a diario entra en el segundo grupo, aunque tenga pocas entradas de blog.

Cuántas copias y dónde

El manual pide más de una. «You should keep at least 3–5 recent WordPress backups to stay safe from data loss». Traducción nuestra: deberías guardar al menos de 3 a 5 respaldos recientes de WordPress para protegerte de perder datos. Y las quiere en lugares distintos: el servidor del hosting, un servicio en la nube y una computadora.

La razón es simple. Si el respaldo vive en el mismo servidor que respalda, un problema con ese servidor se lleva las dos cosas. La lógica completa de tener copias en lugares y medios distintos está en la regla de las tres copias, en nuestro artículo sobre almacenamiento en la nube.

También importa el orden. El manual pide respaldar primero la base de datos y después los archivos. Y al restaurar, al revés: «Restore the WordPress files first, then restore/import the database». Traducción nuestra: restaura primero los archivos de WordPress y luego restaura o importa la base de datos.

El que no has restaurado no cuenta

Un respaldo que nunca se ha restaurado es una suposición. El manual sugiere hacer de vez en cuando un respaldo a mano, para confirmar que el automático funciona. Nosotros iríamos un paso más allá: levantar uno completo en una copia del sitio, una vez, y cronometrar cuánto tarda.

El procedimiento, paso por paso, está en el ensayo de restauración de nuestro artículo sobre errores comunes que tiran un sitio. Toma una tarde. El número que sale, cuánto tardaste en tener el sitio de vuelta, es tu tiempo real de recuperación.

El respaldo justo antes

El respaldo diario del hosting es una base. Pero en un ejemplo inventado, si actualizas a las cinco de la tarde y el respaldo se hizo a las tres de la mañana, todo lo que pasó en medio no está en él. En una tienda, eso incluye los pedidos de ese día.

Mi criterio, y va como criterio: antes de una versión mayor de WordPress, de una actualización del plugin de la tienda o de un cambio de PHP, haría un respaldo a mano en ese momento. Le pondría en el nombre la fecha y la versión de la que parto, y bajaría una copia fuera del servidor. Para una versión menor con las automáticas encendidas, me bastaría el respaldo diario.

La copia de prueba

La copia de prueba, que en inglés se llama staging, es un duplicado de tu sitio que, bien configurado, solo ves tú. Ahí actualizas primero. Si algo se rompe, se rompe ahí.

Para qué sirve

La documentación de WordPress lo justifica sin rodeos, en su página «Test Driving WordPress»: «Making changes to a live site could adversely affect your readers». Traducción nuestra: hacer cambios en un sitio publicado podría perjudicar a tus lectores.

Y la página de depuración marca el lugar de las herramientas de diagnóstico. «It is not recommended to use WP_DEBUG or the other debug tools on live sites; they are meant for local testing and staging installs». Traducción nuestra: no se recomienda usar WP_DEBUG ni las demás herramientas de depuración en sitios publicados; están pensadas para pruebas locales y para copias de prueba.

Es decir, la copia es también el lugar donde se investiga un error sin exponerlo a nadie.

Tres formas de tenerla

1. La del hosting. Algunos planes la crean con un botón y permiten pasar los cambios al sitio real. Es la pregunta 8 de nuestra lista en cómo elegir un hosting para una tienda en línea. Si tu plan la tiene, es la forma más corta.
2. En tu computadora. La misma página de pruebas de WordPress sugiere instalarlo en tu propia computadora para probar sin que nadie vea los errores. Necesitas copiar ahí los archivos y la base de datos del sitio.
3. WordPress Playground, para probar una versión. Corre WordPress en el navegador, sin instalar nada. Los anuncios de las versiones de prueba lo ofrecen para ensayar lo que viene. No es una copia de tu sitio, pero sirve como primera prueba de tus plugins principales con la versión nueva.

Que no la vean tus clientes

Una copia de prueba es un sitio más en internet si nadie la cierra. La página de pruebas de WordPress sugiere restringir el acceso a la copia, por ejemplo con el archivo .htaccess del servidor.

En una tienda hay que cuidar algo más. La copia tiene los datos de tus clientes y la configuración de tu pasarela de pago. Para no cobrar ni escribirle a nadie desde la copia, pon la pasarela en modo de prueba y revisa qué correos manda la tienda antes de probar una compra.

Lo que la copia no te dice

La copia no tiene a tus visitantes. Hay problemas que dependen de la carga real del sitio, de una tarea programada que corre a cierta hora o de un servicio externo conectado solo al sitio real. Esos pueden no aparecer en la copia. Por eso la revisión después de actualizar se repite en el sitio publicado.

Mi criterio, y va como criterio: en una tienda, nada pasaría al sitio real sin pasar por la copia, salvo las versiones menores de seguridad, que dejo en automático. En un blog con pocos plugins, usaría la copia para las versiones mayores y para los plugins que tocan el diseño, y actualizaría directo lo demás, con respaldo.

Leer antes de actualizar

Cinco minutos de lectura ahorran sustos. Antes de apretar el botón, conviene saber qué trae cada actualización y si el plugin está listo para la versión de WordPress que tienes.

La nota de cada versión

Cada versión de WordPress tiene un anuncio en el blog oficial, y las mayores tienen además una guía de campo para desarrolladores. El anuncio de una menor dice si trae correcciones de seguridad y si hay que actualizar de inmediato; a veces, también cuántas. Es lo que usamos para la tabla de este año.

Los plugins del directorio oficial tienen en su página un espacio para el registro de cambios, aunque no todos lo llenan con detalle. Ahí se ve si una actualización corrige un error, si cambia algo que usas o si es grande. Cómo numera sus versiones cada plugin depende de su autor, así que lo que manda es el texto, no el número.

Lo que declara cada plugin

Cada plugin declara con qué versiones trabaja. Son tres datos, y el directorio los muestra en un recuadro de cada página.

• Probado hasta (Tested up to). El manual de plugins lo define así: «The version of WordPress that the plugin has been tested against». Traducción nuestra: la versión de WordPress con la que se ha probado el plugin.
• Versión de WordPress mínima (Requires at least). La más baja con la que funciona.
• Versión de PHP mínima (Requires PHP). La más baja de PHP que pide.

Un ejemplo con WooCommerce. El 8 de octubre de 2026, su versión 11.2.0 pedía WordPress 7.0 o superior y PHP 7.4 o superior, y estaba probada hasta la 7.1.3. Una tienda que siga en la 6.9 queda fuera de esa versión.

Y un ejemplo del otro lado. El plugin Health Check & Troubleshooting, pensado para buscar conflictos entre plugins, aparecía en el directorio en su versión 1.7.1, actualizada hace dos años. Su página mostraba este aviso: «It may no longer be maintained or supported and may have compatibility issues when used with more recent versions of WordPress». Traducción nuestra: puede que ya no tenga mantenimiento ni soporte, y puede tener problemas de compatibilidad con versiones más recientes de WordPress.

Un plugin con ese aviso no está roto por fuerza. Pero es el primero que revisaría en la copia de prueba.

Para esa misma tarea, aislar conflictos, existe también un plugin aparte, Troubleshooting. Su página lo presenta como una forma de desactivar plugins y cambiar de tema «without affecting regular visitors to your website». Traducción nuestra: sin afectar a los visitantes normales de tu sitio. El 8 de octubre tenía más de 500 instalaciones activas y una sola reseña, de una estrella. Con ese historial, para aislar un conflicto, la copia de prueba sigue siendo el camino más seguro.

Los plugins que van en pareja

Hay plugins que se actualizan juntos o no se actualizan. Un caso claro son los que tienen una versión gratuita y otra de pago que se apoya en ella.

Elementor lo advierte en su ayuda. «Updating the free version of Elementor without updating the Pro version can lead to compatibility problems and cause issues with your site». Traducción nuestra: actualizar la versión gratuita de Elementor sin actualizar la versión Pro puede provocar problemas de compatibilidad y fallas en tu sitio.

Con WooCommerce pasa algo parecido, pero con WordPress mismo. Su política de soporte, vigente desde la versión 7.8 de 2023, es corta. «Under the new policy, WooCommerce will support the latest version of WordPress and the previous version». Traducción nuestra: con la nueva política, WooCommerce dará soporte a la versión más reciente de WordPress y a la anterior.

Las extensiones de WooCommerce, como pasarelas de pago o envíos, dependen a su vez de la versión de WooCommerce. Una cadena de tres eslabones: WordPress, WooCommerce y la extensión. Si uno se queda atrás, puede frenar a los otros dos.

Los de pago: sin licencia no hay actualización

Los plugins y temas de pago que no vienen del directorio se actualizan con una licencia activa. Si la licencia vence, el aviso de actualización puede dejar de llegar al panel.

Elementor lo explica para su versión Pro. Si no renuevas, «you will no longer be able to update Elementor Pro». Traducción nuestra: ya no podrás actualizar Elementor Pro.

Un plugin que no se puede actualizar es un plugin que no recibe parches de seguridad. Las licencias van en la lista de lo que revisas cada mes, como en qué gastos deberías revisar cada mes.

Mi criterio, y va como criterio: antes de cada ronda de actualizaciones, revisaría tres cosas por plugin. Si su versión nueva pide algo que no tengo, si viene en pareja con otro y si su licencia sigue viva. Para un sitio con quince plugins, calculo unos diez minutos. Y si un plugin trae en el directorio el aviso de que puede no tener mantenimiento, buscaría su reemplazo antes de que falle.

El orden de una actualización

Con la lectura terminada, toca actualizar. Son siete pasos. Este es el orden en que los haría. Valen para una ronda completa, con versión mayor; para una menor de seguridad, el orden se acorta, como se explica al final.

1. Elige el momento

Una actualización pone el sitio en mantenimiento mientras dura. La página de errores comunes de WordPress lo dice así: «When WordPress updates, it automatically installs a .maintenance file». Traducción nuestra: cuando WordPress se actualiza, instala automáticamente un archivo .maintenance.

Mientras ese archivo existe, el visitante ve el mensaje que trae el código: «Briefly unavailable for scheduled maintenance. Check back in a minute». Traducción nuestra: no disponible por unos momentos por mantenimiento programado; vuelve a intentarlo en un minuto. El aviso dura lo que dura la actualización. Según el código, a los diez minutos WordPress deja de mostrarlo aunque el archivo siga ahí. Aun así, no actualices cuando más gente compra.

Tres momentos a evitar: el viernes en la tarde, la víspera de una campaña y los días de mayor venta, como el Buen Fin. Si algo falla, quieres tener tiempo y estar disponible.

2. Respaldo y lista de lo pendiente

Haz el respaldo justo antes. Ya vimos por qué. Luego anota qué vas a actualizar: el núcleo, cada plugin y el tema, con la versión de la que partes y la versión a la que vas. Si algo se rompe, esa lista te dice qué cambió.

3. Primero, en la copia de prueba

Haz primero la ronda completa en la copia. Si pasa la revisión ahí, la repites en el sitio real. Si no, ya sabes qué plugin falla. Y lo supiste antes que un cliente.

4. El núcleo

En Escritorio, Actualizaciones, el botón de actualizar descarga e instala la versión nueva. La documentación lo llama actualización en un clic, y dice que funciona en la mayoría de los servidores. Si el servidor no deja escribir los archivos, WordPress pide datos de FTP.

Tras una versión mayor, WordPress puede pedirte actualizar la base de datos al entrar al panel. Hazlo en ese momento, con el respaldo a la mano.

El núcleo va antes que los plugins por una razón documentada. En el procedimiento de actualización manual del manual de WordPress, instalar las versiones nuevas de plugins y temas es el paso 11 de 13, después de correr la actualización del núcleo. Para la actualización en un clic, la documentación no fija un orden.

Un caso aparte: si tu sitio está más de dos versiones mayores atrás, el manual de administración sugiere avanzar por etapas, para evitar conflictos y bajar el riesgo de dañar la base de datos.

5. Plugins y tema

Actualiza los plugins uno por uno, o en grupos chicos, y revisa la portada entre uno y otro. Si actualizas veinte de golpe y el sitio se rompe, tienes veinte sospechosos. Uno por uno, tienes uno.

Si el plugin falla al instalarse, la reversión de la 6.3 te devuelve la versión anterior. Si se instala y provoca un error fatal, entra el modo de recuperación.

El tema va al final de este paso. Si usas un tema hijo, la actualización llega al tema padre, y tus cambios viven en el hijo. Si editaste el tema directamente, sin tema hijo, la actualización borra tus cambios.

6. La caché

Si tu sitio usa un plugin de caché, o el hosting tiene su propia caché, vacíala al terminar. La guía de actualización manual de WordPress incluye ese paso al cerrar una actualización. De otro modo, algunos visitantes pueden seguir viendo páginas guardadas antes del cambio. Lo que hace la caché, y por qué conviene tenerla, está en cómo mejorar la velocidad de tu sitio web.

7. Revisar antes de dar por terminado

La actualización no termina cuando el panel dice que salió bien. Termina cuando revisaste el sitio como lo usa un cliente. La siguiente sección dice qué revisar.

El orden corto, para una versión de seguridad

Cuando sale una versión menor de seguridad, el orden cambia. Si tienes encendidas las actualizaciones automáticas de las menores, WordPress la aplica solo, y lo tuyo es revisar el sitio cuando llegue el correo. Si las tienes apagadas, el respaldo diario basta como red, y la versión se aplica el mismo día, antes que cualquier otra actualización.

Mi criterio, y va como criterio: unos días antes de una versión mayor, me pondría al día con las actualizaciones pendientes de los plugins, en una ronda aparte. Así, el día de la versión mayor cambia una sola cosa: primero el núcleo y después lo que llegue para la versión nueva, como en el manual. Con una versión de seguridad, el núcleo va primero y el mismo día, sin esperar a nada.

Qué revisar después de actualizar

El panel puede verse perfecto con la tienda rota. Por eso la revisión se hace del lado del cliente, en el sitio publicado, y con una lista fija. Una lista fija tiene una ventaja: con el tiempo, cualquier cambio salta a la vista.

Las mismas páginas, cada vez

Arma una lista de cinco direcciones y guárdala. Para un sitio de servicios, por ejemplo, serían estas.

1. La portada.
2. Una entrada del blog con imágenes.
3. La página de servicios o de precios.
4. La página de contacto.
5. Una página que use el plugin más importante del sitio: reservas, cursos o tienda.

Ábrelas en una ventana privada del navegador, la de incógnito, sin sesión iniciada. Así ves lo mismo que un visitante y no lo que ve un administrador.

En cada una, busca lo obvio. Que cargue, que se vea completa, que el menú abra y que los botones lleven a donde deben.

El formulario y el correo

Un formulario puede verse bien y no enviar nada. Llena el de contacto con tus datos y comprueba que el mensaje llegue al correo de destino. Si tienes formulario de suscripción, prueba también ese, y revisa que el aviso de privacidad siga enlazado. Cómo se arma ese formulario y qué pide la ley está en empezar una lista de correo.

La tienda, hasta el pago

En una tienda, la revisión llega hasta el final de la compra. El equipo de WooCommerce publicó una lista para revisar después de cambiar de versión de PHP, y nos parece útil para cualquier actualización grande. Incluye el pago, los cobros, el envío y los impuestos, los pedidos, las tareas programadas, el tema, las extensiones y el código propio.

En la práctica, en la copia de prueba y con la pasarela en modo de prueba, son cuatro pasos.

1. Agrega un producto al carrito y cambia la cantidad.
2. Llega a la página de pago y revisa el costo de envío y el IVA.
3. Completa un pedido de prueba.
4. Revisa que el pedido aparezca en el panel y que lleguen los correos de confirmación.

En el sitio real, al menos los dos primeros pasos.

En el celular

En México, según la ENDUTIH 2025 del INEGI, el «97.3 % de las personas usuarias de internet se conectó a la red mediante un teléfono celular inteligente (smartphone)». Esta parte no se salta.

Abre las mismas cinco páginas en un celular. Que el menú abra, que no haya desplazamiento hacia los lados y que los botones se toquen con el pulgar. Lo que en escritorio se ve bien puede descomponerse en la pantalla angosta de un teléfono.

La pantalla de salud del sitio

En Herramientas, Salud del sitio (Tools › Site Health), WordPress corre sus propias pruebas. Separa los resultados en problemas críticos y mejoras recomendadas. Después de una actualización, busca si apareció algo nuevo en la primera lista.

Ahí sale, por ejemplo, este aviso cuando PHP es viejo: «Your site is running an outdated version of PHP, which requires an update». Traducción nuestra: tu sitio usa una versión de PHP desactualizada, que necesita una actualización. Y ahí se ve si las actualizaciones automáticas y las peticiones de bucle invertido funcionan.

Los días siguientes

Hay fallas que no aparecen en la primera hora. Una tarea programada que corre de noche, un correo que se manda una vez al día, un reporte semanal. Durante la semana que sigue, lee los correos que te manda WordPress, revisa que lleguen los pedidos y, si tu hosting lo ofrece, mira su registro de errores.

Mi criterio, y va como criterio: tendría la lista de revisión escrita, con las direcciones y lo que hay que comprobar en cada una, para no depender de la memoria. Calculo unos diez minutos en un sitio de servicios y unos veinte en una tienda, con el pedido de prueba. Y la haría también cuando el sitio se actualiza solo, el día que llega el correo.

Si algo se rompió: qué hacer, en orden

A veces pasa. Lo que sigue está ordenado por síntoma, y cuando WordPress lo documenta, digo dónde.

Primero, no toques nada más

No actualices otro plugin para ver si se arregla. No borres nada. Anota la hora, qué actualizaste y qué ves. Si el sitio vende, decide ahora si vas a restaurar el respaldo de inmediato o si tienes unos minutos para investigar. Con una tienda caída en temporada alta, restaurar primero e investigar después puede salir más barato.

El aviso de error crítico

El aviso es este: «There has been a critical error on this website». Traducción nuestra: hubo un error crítico en este sitio web. Significa que hubo un error fatal de PHP, y el modo de recuperación está hecho para cuando lo provoca un plugin o un tema. La página de errores comunes de WordPress pide, para este caso, revisar primero el correo de administración del sitio.

Ahí debe estar el mensaje del modo de recuperación, con el nombre del plugin o del tema y un enlace. Al abrirlo, inicias sesión y ves el plugin en pausa. Al desactivarlo, el sitio debería volver para todos. Después, con calma, revisa en la copia de prueba qué pasó con su versión nueva.

Si el correo no llegó, la misma página sugiere activar la depuración en wp-config.php y leer el archivo de registro, como se explica en «Ver el error sin mostrárselo a nadie».

La pantalla en blanco, sin mensaje

La página de errores comunes describe la pantalla en blanco como el síntoma de errores de PHP o de la base de datos, sin información visible. Las causas que da son un conflicto entre plugins o un problema del tema.

Si no puedes entrar al panel, el remedio va por FTP o por el administrador de archivos del hosting. La página de preguntas sobre problemas de WordPress, actualizada el 3 de julio de 2026, da estos pasos.

1. Entra a la carpeta wp-content.
2. Cambia el nombre de la carpeta plugins, por ejemplo a plugins.hold. Eso desactiva todos los plugins.
3. Entra al panel, a la página de Plugins. WordPress avisa que no encuentra los plugins y los deja desactivados.
4. Regresa la carpeta a su nombre original. Los plugins siguen desactivados, y los activas uno por uno hasta encontrar el que rompe el sitio.

Ojo con el orden del paso 3. Deducción nuestra: si regresas el nombre de la carpeta sin pasar antes por la página de Plugins, los plugins podrían seguir activos, y el sitio, igual que antes.

Si con los plugins desactivados el sitio no vuelve, el sospechoso es el tema. La página de errores comunes indica cambiar, en wp-content/themes, el nombre de la carpeta del tema activo.

El aviso de mantenimiento que no se quita

El aviso es el que trae el código para el mantenimiento: «Briefly unavailable for scheduled maintenance. Check back in a minute». Traducción nuestra: no disponible por unos momentos por mantenimiento programado; vuelve a intentarlo en un minuto. Si no se quita, la actualización se interrumpió con el archivo .maintenance todavía en su lugar. La página de errores comunes lo dice así: «The maintenance file may not have been removed properly». Traducción nuestra: puede que el archivo de mantenimiento no se haya borrado bien.

El remedio es borrarlo. Está en la carpeta principal del sitio, junto a wp-config.php. Por FTP, búscalo con la opción de mostrar archivos ocultos, porque su nombre empieza con un punto.

Un detalle del código: WordPress deja de hacerle caso a ese archivo cuando lleva más de diez minutos. Si el aviso sigue mucho después, conviene buscar la causa con tu hosting. Y si la actualización quedó a medias, repítela, o actualiza a mano como indica la documentación.

Ver el error sin mostrárselo a nadie

Para saber qué falla, WordPress puede escribir sus errores en un archivo en lugar de mostrarlos. La página de depuración da cuatro líneas para wp-config.php, que van antes del comentario que pide dejar de editar.

Línea	Qué hace
define( 'WP_DEBUG', true );	Enciende el modo de depuración
define( 'WP_DEBUG_LOG', true );	Guarda los errores en un archivo
define( 'WP_DEBUG_DISPLAY', false );	Evita que los errores se vean en las páginas
@ini_set( 'display_errors', 0 );	Refuerza lo anterior desde PHP

El archivo queda, por defecto, en wp-content/debug.log. Ábrelo y busca el último error. Un error de PHP trae la ruta del archivo donde ocurrió, y esa ruta pasa por la carpeta del plugin o del tema que falló.

Dos cuidados. Primero, el que ya citamos de la propia página: estas herramientas están pensadas para pruebas locales y copias de prueba, no para sitios publicados. Segundo, la página del archivo de configuración advierte que un registro en una carpeta pública es un riesgo de seguridad. Si lo activas en el sitio real, que sea por minutos: lees el error, regresas las líneas a como estaban y borras el archivo.

Regresar un plugin a la versión anterior

Hay cuatro caminos, de más corto a más largo.

1. Si la actualización falló al instalarse, la reversión de la 6.3 ya lo hizo por ti.
2. Desde el panel, si tienes el archivo ZIP de la versión anterior. Desde la 5.5, al subir en Plugins, Añadir nuevo, un plugin que ya está instalado, WordPress compara las versiones. Si la que subes es más vieja, avisa: «You are uploading an older version of a current plugin». Traducción nuestra: estás subiendo una versión anterior de un plugin instalado. Y ofrece un botón, «Replace current with uploaded». Traducción nuestra: reemplazar el actual con el que subiste.
3. Si tienes acceso a WP-CLI, el comando wp plugin install acepta dos opciones que, juntas, instalan una versión anterior encima de la actual. Con --version, según su documentación, «get that particular version from wordpress.org, instead of the stable version». Traducción nuestra: obtiene esa versión en particular de wordpress.org, en lugar de la estable. Con --force, el comando «will overwrite any installed version of the plugin, without prompting for confirmation». Traducción nuestra: sobrescribe la versión instalada del plugin, sin pedir confirmación.
4. Si no, restaura del respaldo la carpeta del plugin, o el respaldo completo.

Regresar un plugin es un remedio temporal. Su versión anterior puede tener la falla de seguridad que la nueva corrige. Mientras tanto, busca en el registro de cambios y en el foro de soporte del plugin si alguien reportó lo mismo.

Regresar WordPress a la versión anterior

WP-CLI también lo permite. El comando wp core update acepta una versión concreta, y con la opción --force instala aunque sea más vieja que la actual. La documentación describe esa opción así: «Update even when installed WP version is greater than the requested version». Traducción nuestra: actualiza aunque la versión instalada de WordPress sea mayor que la solicitada.

Que se pueda no quiere decir que convenga. Una versión anterior del núcleo tiene las fallas de seguridad que la nueva corrigió. Con la 7.1.2, por ejemplo, regresar a la 7.1.1 reabriría la falla que permitía ejecutar código.

Cuándo restaurar el respaldo completo

Restaura el respaldo completo cuando no sabes qué cambió, cuando el problema está en la base de datos o cuando una tienda tiene que volver a vender ya. Restaura en el orden del manual: primero los archivos, luego la base de datos.

Antes de restaurar una tienda, anota los pedidos que entraron después del respaldo. El respaldo no los tiene, y habrá que capturarlos o atenderlos por fuera.

Mi criterio, y va como criterio: con una tienda caída, si en quince minutos no encuentro la causa, restauraría el respaldo de antes de la actualización y seguiría investigando en la copia de prueba. Con un blog tendría más paciencia. Y no regresaría el núcleo a una versión vieja salvo por horas, mientras sale el arreglo.

Actualizar desde la terminal con WP-CLI

WP-CLI es la línea de comandos oficial de WordPress. Con ella, buena parte de lo anterior se hace escribiendo órdenes, sin clics. La página de WordPress sobre cómo actualizar la sugiere para quien se siente cómodo en una terminal.

Necesitas acceso por SSH a tu servidor y que el hosting tenga WP-CLI instalado. Si a tu plan le falta cualquiera de las dos, salta esta sección. Casi todo lo que hace WP-CLI aquí tiene un equivalente en el panel.

Ver antes de tocar

Dos comandos sirven para saber qué hay pendiente. Ninguno cambia nada.

• wp core check-update muestra si hay una versión nueva de WordPress.
• wp plugin update --all --dry-run muestra qué plugins se actualizarían. La documentación describe la opción --dry-run así: «Preview which plugins would be updated». Traducción nuestra: muestra por adelantado qué plugins se actualizarían.

Actualizar por partes

WP-CLI permite separar lo que en el panel va junto. Eso es lo valioso.

• wp core update --minor actualiza el núcleo solo a versiones menores. Su documentación lo explica con un ejemplo: «Only perform updates for minor releases (e.g. update from WP 4.3 to 4.3.3 instead of 4.4.2)». Traducción nuestra: solo hace actualizaciones a versiones menores, por ejemplo de la 4.3 a la 4.3.3 en lugar de a la 4.4.2.
• wp plugin update --all --exclude=woocommerce actualiza todos los plugins menos los que nombres. La opción --exclude recibe, según su documentación, una «Comma separated list of plugin names that should be excluded from updating». Traducción nuestra: una lista separada por comas de los plugins que no se deben actualizar.
• wp core update-db ejecuta la actualización de la base de datos que a veces pide una versión mayor.

Así, en una tienda, puedes dejar WooCommerce fuera de la ronda y actualizarlo después, en la copia de prueba. Lo demás puede ir en grupos chicos.

Comprobar los archivos del núcleo

wp core verify-checksums compara tus archivos de WordPress con los originales. Su documentación lo resume en una línea: «Verifies WordPress files against WordPress.org’s checksums». Traducción nuestra: verifica los archivos de WordPress contra las sumas de verificación de WordPress.org.

Sirve después de una actualización que falló a medias, para saber si quedó algún archivo del núcleo distinto al oficial. También sirve si sospechas que alguien modificó tu sitio. Es una revisión rápida.

El modo de mantenimiento, a mano

wp maintenance-mode activate pone el sitio en mantenimiento, y wp maintenance-mode deactivate lo quita. wp maintenance-mode status dice en qué estado está. Es útil si vas a hacer varios cambios seguidos. Así nadie compra a medias.

Una versión concreta

wp core update --version=7.1.3 instala exactamente esa versión, aunque más adelante haya otra más reciente. La documentación lo dice así: «Update to a specific version, instead of to the latest version». Traducción nuestra: actualiza a una versión específica, en lugar de a la más reciente. Para ir a una versión más vieja que la instalada se agrega --force, con los cuidados de «Regresar WordPress a la versión anterior».

Esta es la lista, para tenerla a la mano.

Comando	Qué hace
wp core check-update	Muestra si hay versión nueva del núcleo
wp plugin update --all --dry-run	Muestra qué plugins se actualizarían, sin actualizar
wp core update --minor	Actualiza el núcleo solo a versiones menores
wp core update	Actualiza el núcleo a la versión más reciente
wp core update-db	Ejecuta la actualización de la base de datos
wp plugin update --all --exclude=woocommerce	Actualiza todos los plugins menos el excluido
wp core verify-checksums	Compara los archivos del núcleo con los oficiales
wp maintenance-mode activate	Pone el sitio en mantenimiento
wp maintenance-mode deactivate	Quita el modo de mantenimiento
wp maintenance-mode status	Dice si el sitio está en mantenimiento
wp plugin install nombre --version=1.2.3 --force	Reinstala un plugin en la versión indicada
wp core update --version=7.1.2 --force	Instala esa versión del núcleo, aunque sea más vieja que la actual

Los números de versión de la tabla son ejemplos.

PHP: la actualización que no aparece en el panel

PHP es el lenguaje en el que está escrito WordPress. Corre en el servidor, y su versión no se cambia desde Escritorio, Actualizaciones, sino desde el panel del hosting. Por eso se olvida, y por eso se queda atrás.

Las fechas de cada versión

El proyecto PHP publica cuánto dura el soporte de cada versión. Primero hay soporte activo, con correcciones de todo tipo. Después, solo parches de seguridad. Y después, ninguna corrección.

Versión de PHP	Salió	Soporte activo hasta	Parches de seguridad hasta	El 8 de octubre de 2026
8.2	8 de diciembre de 2022	31 de diciembre de 2024	31 de diciembre de 2026	Solo seguridad, por 84 días más
8.3	23 de noviembre de 2023	31 de diciembre de 2025	31 de diciembre de 2027	Solo seguridad
8.4	21 de noviembre de 2024	31 de diciembre de 2026	31 de diciembre de 2028	Soporte activo
8.5	20 de noviembre de 2025	31 de diciembre de 2027	31 de diciembre de 2029	Soporte activo

La 8.1 y las anteriores ya no aparecen en la tabla de versiones con soporte. El 31 de diciembre de 2026 pasan dos cosas: la 8.2 deja de recibir parches de seguridad y la 8.4 termina su soporte activo, aunque sigue con parches de seguridad hasta 2028.

Lo que pide WordPress

WordPress tiene dos números: el mínimo con el que funciona y el que recomienda. Una nota técnica de enero de 2026 los fijó para la 7.0: «The minimum recommended version of PHP will remain at 8.3, but the new minimum supported version of PHP will be 7.4.0». Traducción nuestra: la versión mínima recomendada de PHP seguirá en 8.3, pero la nueva versión mínima con soporte será la 7.4.0.

La misma nota explica qué pasa con los sitios que se quedaron en PHP 7.2 o 7.3: siguen en la rama 6.9 de WordPress, sin pasar a la 7.0. Es la cadena en su forma más simple. Un PHP viejo detiene al núcleo.

La página de requisitos de WordPress dice que también funciona con PHP 7.4 o superior, y agrega la advertencia. «However, these versions have reached their official End Of Life and may expose your site to security vulnerabilities». Traducción nuestra: sin embargo, estas versiones ya llegaron a su fin de vida oficial y pueden exponer tu sitio a vulnerabilidades de seguridad.

Según la tabla de compatibilidad de WordPress, actualizada el 19 de agosto de 2026, la 7.0 y la 7.1 trabajan con PHP de la 7.4 a la 8.5.

Lo que pide WooCommerce

WooCommerce sube sus requisitos por su cuenta. Su versión 11.2.0, en el directorio el 8 de octubre de 2026, ya pedía PHP 7.4 o superior y WordPress 7.0 o superior. Y su equipo anunció el siguiente salto el 29 de septiembre. «WooCommerce 11.6, planned for February 2027, will require PHP 8.1 or newer». Traducción nuestra: WooCommerce 11.6, prevista para febrero de 2027, pedirá PHP 8.1 o una versión más nueva.

El mismo anuncio da el margen. La 11.3 mostrará un aviso, pero «WooCommerce 11.3 continues to work on those PHP versions». Traducción nuestra: WooCommerce 11.3 sigue funcionando en esas versiones de PHP. Y explica que WordPress, por lo general, no ofrece la actualización de un plugin cuando el servidor no cumple la versión de PHP que el plugin declara.

¿A cuántas tiendas les toca? La propuesta que el equipo publicó el 8 de septiembre da una idea. Según los datos de uso que WooCommerce recibe de las tiendas que aceptan compartirlos, cerca de 7 % usaba PHP 7.4 y cerca de 2 % PHP 8.0.

Y un detalle de los parches. Según el mismo anuncio, las correcciones de vulnerabilidades muy graves se llevan a versiones anteriores, pero «Other fixes generally ship only for the latest WooCommerce release». Traducción nuestra: las demás correcciones, por lo general, salen solo para la versión más reciente de WooCommerce.

La cadena: PHP, plugin, núcleo

Las tres actualizaciones están atadas. Este es un ejemplo inventado, con fechas reales.

1. Una tienda corre en PHP 8.0 y WordPress 7.1, con WooCommerce al día.
2. En febrero de 2027 sale WooCommerce 11.6, que pide PHP 8.1. La tienda no recibe la actualización.
3. La tienda sigue en la rama anterior de WooCommerce, que recibe solo las correcciones más graves.
4. Cuando una extensión de pagos pida la versión nueva de WooCommerce, tampoco podrá actualizarla.

El eslabón que se quedó atrás no fue el plugin. Fue PHP.

Cómo se cambia sin romper

WordPress tiene una página dedicada a esto, y su argumento principal es simple: «PHP becomes more efficient with each new version». Traducción nuestra: PHP se vuelve más eficiente con cada versión nueva. Los pasos que propone, resumidos, son estos.

1. Haz un respaldo.
2. Actualiza WordPress, el tema y los plugins, y revisa que el sitio funcione.
3. Revisa la compatibilidad de tus plugins y temas con la versión nueva de PHP, con una herramienta de revisión si la tienes, sabiendo que no es infalible.
4. Pide el cambio a tu hosting, o hazlo en su panel.

Para saber qué versión usas, entra a Herramientas, Salud del sitio, pestaña Información, sección Servidor. En una tienda, WooCommerce lo muestra también en WooCommerce, Estado, en el apartado del entorno del servidor. Lo que pesa la versión de PHP en la velocidad de una tienda está en cómo acelerar una tienda WooCommerce.

Mi criterio, y va como criterio: si mi sitio estuviera en PHP 8.2 o en una versión anterior, haría el cambio antes del 31 de diciembre, pero no durante el Buen Fin. Iría a 8.3 o a 8.4, primero en la copia de prueba, con una compra completa si es tienda. Y lo haría en una semana distinta de la de la 7.2, para que si algo falla sepa cuál de los dos cambios fue.

Plugins en automático: cuáles sí y cuáles no

Las actualizaciones automáticas de plugins vienen apagadas. Encenderlas es una decisión con argumentos de los dos lados. Y los dos lados tienen datos.

El argumento a favor

El informe anual de Patchstack, «State of WordPress Security in 2026», con datos de 2025, empieza por el tamaño del problema. «Overall 11,334 new vulnerabilities were found in the WordPress ecosystem in 2025». Traducción nuestra: en total, en 2025 se encontraron 11,334 vulnerabilidades nuevas en el ecosistema de WordPress. Y sigue con dónde están: «91% of new vulnerabilities were found in plugins, and 9% were found in themes». Traducción nuestra: el 91 % de las vulnerabilidades nuevas estaba en plugins y el 9 % en temas.

En el núcleo, el mismo informe contó 6, de prioridad baja. El riesgo, en su mayor parte, está en los plugins.

Y para esta decisión pesa el dato de la velocidad: «the weighted median time to first exploit is 5 hours». Traducción nuestra: la mediana ponderada del tiempo hasta la primera explotación es de 5 horas. Una mediana es el valor del medio de una lista: la mitad de los casos queda por debajo.

Con las automáticas encendidas, WordPress revisa dos veces al día. ¿Cuánto tarda entonces en aplicarse un parche? La cuenta está en la ventana de exposición, en nuestro artículo sobre plugins. En la cuenta teórica de ese artículo, en automático la espera promedio es de unas 6 horas, y revisando una vez por semana, de tres días y medio. Con las seis versiones de seguridad del núcleo de julio a octubre de este año, revisar a mano cada lunes habría dado 4.7 días de espera promedio, por una cuenta propia.

El argumento en contra

El mismo informe trae un dato que enfría el entusiasmo. «46% of vulnerabilities did not receive a fix from the developer in time for public disclosure». Traducción nuestra: el 46 % de las vulnerabilidades no recibió una corrección de su desarrollador a tiempo para su divulgación pública. Cuando no hay parche, la actualización automática no tiene nada que aplicar.

Y está lo que vimos de la red de la 6.6. Regresa el plugin si la portada da un error fatal, pero no ve un carrito que deja de cobrar ni un formulario que deja de enviar. La propia documentación de las actualizaciones automáticas lo advierte antes de que las actives. «Before enabling auto-updates on your plugins and themes, you may want to make sure you’re able to rollback to a previous version of your website in case things go wrong». Traducción nuestra: antes de activar las actualizaciones automáticas en tus plugins y temas, conviene que te asegures de poder regresar tu sitio a una versión anterior si algo sale mal.

Un reparto por tipo de plugin

Las dos cosas son ciertas. Los parches tienen que llegar rápido, y un plugin central no se debe actualizar a ciegas. La salida es repartir.

Mi criterio, y va como criterio: lo decidiría plugin por plugin, con esta tabla en la mano, y siempre con el respaldo diario funcionando.

Tipo de plugin	Automático	Por qué
Plugins chicos y estables: formularios simples, SEO, utilidades	Sí	Si fallan, no tumban la venta; prueba el formulario cuando llegue el correo de la actualización
Seguridad y respaldo	Sí	Su trabajo es estar al día
El plugin central del negocio: tienda, reservas, cursos	No	Se actualiza en la copia de prueba, con revisión completa
Constructor de páginas o plugin que dibuja el diseño	No	Un cambio puede descomponer el diseño sin dar error fatal
Plugins que van en pareja, como una versión gratuita y otra Pro	No	Se actualizan juntos, a mano
Plugins de pago fuera del directorio	Depende	Si su licencia lo permite, como los chicos; si no, a mano

Y leería los correos que manda WordPress después de cada actualización automática. Si un plugin se revirtió, el correo lo dice, y conviene saberlo el mismo día.

Versiones mayores: el día uno o unas semanas después

Con las mayores, la pregunta es otra: actualizar el día que salen o esperar a la primera versión de mantenimiento. Los datos de las últimas seis ayudan a decidir.

Cuánto tardó la primera versión de mantenimiento

Esta tabla cruza la fecha de cada versión mayor con la de su primera versión de mantenimiento, según la lista oficial de versiones.

Versión mayor	Salió	Primera de mantenimiento	Días	Errores corregidos, según su anuncio
6.6	16 de julio de 2024	6.6.1, 23 de julio de 2024	7	No consultado
6.7	12 de noviembre de 2024	6.7.1, 21 de noviembre de 2024	9	No consultado
6.8	15 de abril de 2025	6.8.1, 30 de abril de 2025	15	No consultado
6.9	2 de diciembre de 2025	6.9.1, 3 de febrero de 2026	63	49
7.0	20 de mayo de 2026	7.0.1, 9 de julio de 2026	50	31
7.1	19 de agosto de 2026	7.1.1, 17 de septiembre de 2026	29	36, más 11 de seguridad

La espera va de 7 a 63 días, con una mediana de 22. Esperar a la primera versión de mantenimiento puede ser una semana o dos meses.

Y lo que corrige no es poco. La 6.9.1, según su anuncio, «includes fixes for 49 bugs throughout Core and the Block Editor». Traducción nuestra: incluye correcciones para 49 errores en el núcleo y en el editor de bloques.

Mientras esperas, los parches siguen llegando

Esperar no deja el sitio sin parches. La lista oficial lo muestra: el 17 de septiembre, el mismo día que la 7.1.1, salió la 7.0.5; el 22, la 7.0.6; y el 6 de octubre, la 7.0.7.

Pero recuerda el aviso de la sección de 2026: solo la versión más reciente tiene soporte activo, y lo demás llega como cortesía.

Lo que no conviene: quedarte dos versiones atrás

Esperar unas semanas es una cosa. Quedarse atrás es otra.

Deducción nuestra a partir de la política de WooCommerce: cuando salga la 7.2, su soporte cubrirá la 7.2 y la 7.1, y una tienda en la 7.0 quedará fuera. Y la versión 11.2.0 de WooCommerce ya pide la 7.0, así que una tienda en la 6.9 ya no la recibe.

Si tu sitio ya está más de dos versiones mayores atrás, recuerda la sugerencia del manual: avanzar por etapas, no de un salto.

Mi criterio, y va como criterio: aplicaría las versiones menores de seguridad el mismo día, sin excepción. Con las mayores, en un sitio sencillo, esperaría una o dos semanas y miraría si salió la primera de mantenimiento. En una tienda, esperaría a esa versión. La probaría en la copia y elegiría una semana tranquila.

El calendario de aquí a febrero

Los próximos cuatro meses juntan tres cosas: la 7.2, el fin de los parches de PHP 8.2 y la temporada de compras de fin de año en México. Conviene verlas juntas.

7.2: las fechas

La página del ciclo de la 7.2, actualizada el 6 de octubre de 2026, da este calendario.

Fecha	Etapa	Días desde el 8 de octubre
20 de octubre	Beta	12
27 de octubre	Beta 2	19
3 de noviembre	Beta 3	26
10 de noviembre	Beta 4	33
17 de noviembre	Candidata a versión final	40
24 de noviembre	Candidata 2	47
1 de diciembre	Candidata 3	54
7 de diciembre	Ensayo	60
8 de diciembre	WordPress 7.2	61

Hay una diferencia entre dos páginas oficiales. La lista de versiones de la documentación marca la 7.2 para el 10 de diciembre. La página del ciclo dice 8. Ninguna explica la diferencia. Cualquiera de las dos cae en diciembre, después del Buen Fin.

Las versiones beta y las candidatas son para probar. No son para tu sitio. En el anuncio de la primera candidata de la 7.1, el equipo lo pidió con todas sus letras: «Please do not install, run, or test this version of WordPress on production or mission-critical websites». Traducción nuestra: por favor, no instales, ejecutes ni pruebes esta versión de WordPress en sitios en producción o de misión crítica. Si quieres adelantarte, pruébala en WordPress Playground o en la copia de prueba, con tus plugins principales.

La 7.2 traerá también un tema por defecto nuevo, según la misma página. Lo que ya trae el editor, versión por versión, está en lo que trae el editor de bloques.

El Buen Fin cae en medio

El Buen Fin 2026 va del viernes 13 al martes 17 de noviembre, según notas de prensa del 31 de agosto que recogieron el anuncio de los organizadores. El último día coincide con la candidata a versión final de la 7.2.

Para una tienda, esa semana no es para actualizar nada que no sea de seguridad, ni siquiera un plugin chico. Para un blog con afiliados, tampoco es buena idea mover el diseño en plena campaña.

Diciembre: la 7.2, PHP 8.2 y las fiestas

Diciembre junta la 7.2, el 8 o el 10, y el fin de los parches de PHP 8.2, el 31. En medio están las compras de Navidad, que en el comercio mexicano se estiran hasta el Día de Reyes, el 6 de enero.

Si tu sitio instala por su cuenta las versiones mayores, la 7.2 llegará sin que hagas nada. Si no quieres que eso pase en temporada, este es el momento de cambiar el ajuste, como se explica en «Cómo saber qué tiene tu sitio».

Enero y febrero

Después de Reyes, el calendario se despeja y hay margen. Es buen momento para la 7.2, si saliste de diciembre en la 7.1, y para el cambio de PHP, si lo dejaste pendiente, en semanas distintas. Y en febrero de 2027 está prevista WooCommerce 11.6, la que pedirá PHP 8.1.

Un plan por semanas

Este es el plan que propongo, como criterio, para una tienda. Para un blog o un sitio de servicios, se puede comprimir.

Cuándo	Qué hacer
Esta semana	Revisa en Escritorio, Actualizaciones si las mayores se aplican solas; revisa la versión de PHP en Salud del sitio; haz el ensayo de restauración
Del 20 de octubre al 6 de noviembre	Prueba la beta de la 7.2 en Playground o en la copia, con tus plugins principales; si estás en PHP 8.2 o anterior, cambia a 8.3 u 8.4, primero en la copia
Del 9 al 18 de noviembre	Congelado: solo actualizaciones de seguridad, del núcleo o de plugins
Del 19 de noviembre al 7 de diciembre	Actualiza plugins con calma, en la copia y luego en el sitio
Diciembre	Tienda: decide si la 7.2 espera a enero; blog: actualiza cuando salga la primera de mantenimiento o tras una o dos semanas
Del 7 al 31 de enero	Si el cambio de PHP quedó pendiente, primero PHP; una semana después, la 7.2, en la copia primero
Febrero de 2027	WooCommerce 11.6, si tu PHP ya es 8.1 o más

Mi criterio, y va como criterio: para una tienda, congelaría todo lo que no sea de seguridad del lunes anterior al Buen Fin al día siguiente de que termine. Y no movería la 7.2 hasta después de Reyes. Para un blog, aplicaría la 7.2 en diciembre, una o dos semanas después de que salga, con la revisión de siempre.

Siete mitos sobre actualizar WordPress

Siete ideas que circulan sobre las actualizaciones, y el dato de esta guía que corrige cada una.

«Si no toco nada, no se rompe nada»

No tocar también rompe, más despacio. En lo que va de 2026, la rama vigente de WordPress tuvo ocho versiones con correcciones de seguridad, una de ellas para una falla que, bajo ciertas condiciones, permitía ejecutar código sin tener cuenta. Y los requisitos suben: WooCommerce 11.2.0 ya pide WordPress 7.0, y WooCommerce 11.6 pedirá PHP 8.1. Un sitio quieto termina sin poder instalar los parches que necesita.

«Las actualizaciones automáticas solo traen parches»

Depende de cuándo se instaló tu sitio. El manual de administración de WordPress dice que, desde la 5.6, las instalaciones nuevas tienen activadas por defecto las actualizaciones automáticas de las versiones mayores. La pantalla de Escritorio, Actualizaciones dice cuál es tu caso.

«Si algo falla, WordPress lo regresa solo»

Regresa algo en tres casos, y con límites. El núcleo tiene reversión en sus actualizaciones automáticas desde la 3.7. La 6.3 regresa un plugin o un tema cuando su actualización manual falla al instalarse. Y la 6.6 regresa un plugin activo cuando su actualización automática provoca un error fatal en la portada. El modo de recuperación, desde la 5.2, no regresa nada: te deja entrar a desactivar el plugin que falló. Un carrito que deja de cobrar no entra en ninguno de esos casos.

«Antes de actualizar hay que desactivar todos los plugins»

Ese paso es de la actualización manual, cuando subes los archivos por FTP. La documentación lo incluye ahí. Para la actualización en un clic desde el panel, la misma página no lo pide. Lo que sí pide antes de cualquier actualización es un respaldo.

«Una versión de seguridad no puede romper nada»

La 6.9.2 era una versión de seguridad, y algunos sitios quedaron con la parte pública en blanco por la forma en que su tema cargaba plantillas. WordPress sacó la 6.9.3 el mismo día. Las versiones de seguridad se aplican pronto, pero con respaldo y con revisión, como cualquier otra.

«Con el respaldo del hosting basta»

Depende de tres cosas que conviene preguntarle a tu hosting: si guarda la base de datos y los archivos, dónde los guarda y cuándo se hizo el último. El manual de WordPress pide de 3 a 5 respaldos recientes, en lugares distintos, y uno siempre antes de actualizar. En un ejemplo inventado, un respaldo diario de las tres de la mañana no tiene los pedidos de la tarde.

«Mi sitio es viejo: mejor ya no lo toco»

Un sitio viejo es el que más necesita el procedimiento, no el que menos. Si está más de dos versiones mayores atrás, el manual sugiere avanzar por etapas. Si su PHP es 7.2 o 7.3, WordPress ya no pasa de la rama 6.9. Y si su tema o sus plugins están abandonados, el problema no es la actualización: es lo que corre sin parches.

Preguntas frecuentes

¿WordPress se actualiza solo?

En parte. Desde la 3.7, de 2013, aplica por su cuenta las versiones menores de mantenimiento y seguridad, y los archivos de traducción. Las versiones mayores se aplican por su cuenta en las instalaciones nuevas desde la 5.6, de diciembre de 2020, salvo que alguien cambie el ajuste. Los plugins y los temas se actualizan por su cuenta únicamente si tú lo activas, uno por uno, desde la 5.5. Hay una excepción. En casos especiales, el equipo de seguridad de WordPress.org puede indicar una actualización automática para corregir una vulnerabilidad crítica.

¿Cómo sé si mi sitio va a instalar la 7.2 solo?

Entra a Escritorio, Actualizaciones. Si arriba dice que el sitio se mantiene al día con cada versión nueva de WordPress, la 7.2 se instalará sola cuando salga. Si dice que solo con las versiones de mantenimiento y seguridad, no. El enlace de debajo cambia de una opción a otra. Si no hay enlace, una constante o un filtro, a veces puestos por el hosting, ya fijaron el comportamiento.

¿Es seguro activar las actualizaciones automáticas de plugins?

Para los plugins chicos y estables, con un respaldo diario funcionando, tiene sentido: Patchstack calcula una mediana ponderada de 5 horas hasta el primer intento de explotación de una vulnerabilidad. Para el plugin central del negocio, como la tienda o las reservas, conviene actualizar a mano y en la copia de prueba. La reversión automática de la 6.6 solo detecta errores fatales en la portada.

¿Qué hago si aparece el mensaje de error crítico después de actualizar?

Revisa el correo de administración del sitio. WordPress manda ahí un enlace para entrar en modo de recuperación, con el nombre del plugin o del tema que falló. Desde ese modo lo desactivas, y el sitio debería volver. Si el correo no llegó, activa el registro de errores en wp-config.php sin mostrarlos en pantalla, lee el archivo wp-content/debug.log y desactiva el plugin que aparezca ahí. Si no puedes entrar al panel, cambia por FTP el nombre de su carpeta.

¿Por qué mi sitio dice que no está disponible por mantenimiento?

Porque se está actualizando. Durante una actualización, incluidas las automáticas, WordPress crea un archivo .maintenance en la carpeta principal del sitio y muestra ese aviso. Si sigue después de unos minutos, la actualización se interrumpió antes de borrarlo. Bórralo por FTP o desde el administrador de archivos del hosting. Según el código, WordPress deja de hacerle caso a los diez minutos; si la actualización quedó a medias, repítela.

¿Qué se actualiza primero, WordPress o los plugins?

Para la actualización en un clic, la documentación no fija un orden. En la actualización manual, el manual de WordPress pone primero el núcleo y después los plugins y los temas. Una forma práctica de seguirlo: ponerte al día con los plugins unos días antes de una versión mayor, y el día de la versión, núcleo primero. Con una versión de seguridad, el núcleo va primero y el mismo día. Siempre con respaldo y, si el sitio vende, en la copia de prueba primero, salvo las versiones de seguridad.

¿Cada cuánto hay que actualizar?

Las versiones de seguridad, el día que salen; si las automáticas están encendidas, WordPress lo hace solo. En 2026 hubo seis versiones de seguridad entre el 17 de julio y el 6 de octubre. Revisando a mano cada lunes, cada una habría esperado 4.7 días en promedio; el día 1 de cada mes, 18.3. Son cuentas propias. Los plugins, al menos una vez por semana. Y las mayores, con plan.

¿Puedo regresar a la versión anterior de WordPress?

Sí, con WP-CLI, usando wp core update con la versión que quieres y la opción --force. No conviene como solución. La versión anterior tiene las fallas de seguridad que la nueva corrigió. Si una actualización rompió el sitio, restaura el respaldo de antes, encuentra el plugin o el tema que choca en la copia de prueba y vuelve a actualizar.

¿Qué versión de PHP necesito?

WordPress 7.0 y 7.1 funcionan con PHP 7.4 o superior, pero WordPress recomienda 8.3 o superior. PHP 8.2 deja de recibir parches de seguridad el 31 de diciembre de 2026. Si tienes tienda, WooCommerce 11.6, prevista para febrero de 2027, pedirá PHP 8.1 o superior. Para entonces, ni la 8.1 ni la 8.2 tendrán parches de seguridad, así que lo recomendable es 8.3 o más. Lo ves en Herramientas, Salud del sitio, pestaña Información.

¿Necesito un plugin de respaldo o una copia de prueba de pago?

Depende de tu hosting. Lo que necesitas es un respaldo que incluya base de datos y archivos, guardado fuera del servidor y que ya hayas restaurado una vez, y un lugar donde probar antes de tocar el sitio real. Si tu hosting da las dos cosas, no hace falta más. Si no, eso es lo que tiene que resolver el plugin o el servicio que elijas.

Lo que este artículo no pudo verificar

Esto quedó fuera o a medias. Conviene saberlo antes de usar cualquier cifra de arriba.

• Qué parte de los sitios usa cada versión de WordPress y de PHP. La página de estadísticas de WordPress.org muestra sus datos en gráficas, y no logramos leer los porcentajes.
• Cuántos sitios quedaron en blanco con la 6.9.2. El anuncio de la 6.9.3 habla de algunos usuarios, sin cifra.
• Cuántas veces se activa en la práctica la reversión de la 6.6. No encontré datos públicos. Lo que dice este artículo sobre sus límites sale del código, no de mediciones.
• La fecha exacta de la 7.2. La página del ciclo dice 8 de diciembre y la lista de versiones dice 10.
• Los textos de la interfaz en español. Las frases de la pantalla de actualizaciones se citan en inglés, tal como están en el código. La traducción que veas depende de tu versión y de tu idioma.
• Lo que hace cada hosting con las actualizaciones. Cada proveedor puede fijar el comportamiento con constantes, filtros o herramientas propias, y no revisé ninguno en particular.
• La experiencia de uso del plugin Troubleshooting. Su página mostraba una sola reseña, de una estrella, que describe fallas al salir del modo de prueba. Es un caso, sin verificar, y por eso el artículo no lo recomienda ni lo descarta.
• Si WooCommerce 11.6 saldrá en febrero. Su equipo la da como prevista, no como fecha cerrada.
• Las fechas de El Buen Fin 2026 en el sitio oficial. No se pudo abrir; se usaron las que publicó la prensa.

Fuentes y metodología

Las traducciones del inglés de este artículo son nuestras, y cada cita está enlazada a su original en esta sección. Las fuentes se consultaron el 8 de octubre de 2026, salvo donde se indica otra fecha.

Fuentes primarias

Versiones y anuncios de WordPress

• Categoría de anuncios de versiones del blog oficial de WordPress: fechas y títulos de 2022 a 2026.
• Lista de versiones de WordPress, modificada el 6 de octubre de 2026: fechas de cada versión y de las versiones con parches de las ramas anteriores, y la 7.2 prevista para el 10 de diciembre.
• Anuncios de 2026, todos en el blog oficial: 6.9.1, de Aaron Jorbin; 6.9.2, «WordPress 6.9.3 and 7.0 beta 4» y 6.9.4, de John Blackbourn; 7.0.1, de Estela Rueda; 7.0.2, 7.0.3 y 7.0.4, de John Blackbourn; 7.1.1, de Aaron Jorbin; 7.1.2, de John Blackbourn; y «WordPress 7.1.3 Maintenance and Security Release», de Jake Spurlock, del 6 de octubre de 2026.
• Anuncio de la primera candidata de la 7.1, de Benjamin Zekavica, del 5 de agosto de 2026: formas de probar y advertencia para sitios en producción.
• Anuncios de la 3.7, del 24 de octubre de 2013; de la 5.2, del 7 de mayo de 2019; y de la 5.5, del 11 de agosto de 2020.
• Página de WordPress 7.2 en el sitio del equipo de desarrollo, modificada el 6 de octubre de 2026: calendario de betas, candidatas y lanzamiento el 8 de diciembre, y tema por defecto nuevo.

Notas técnicas del equipo de desarrollo

• «Fatal Error Recovery Mode in 5.2», de Felix Arntz, del 16 de abril de 2019.
• «Core major versions auto-updates UI changes in WordPress 5.6 – Correction», de Jb Audras, del 24 de noviembre de 2020: valores por defecto para instalaciones nuevas y existentes.
• «New in 6.3: Rollback for failed manual plugin and theme updates», de Andy Fragen, del 11 de julio de 2023.
• «Merge Proposal: Rollback Auto-Update», de Andy Fragen, del 19 de abril de 2024; el ticket 58281, cerrado en la 6.6; y la «WordPress 6.6 Field Guide», de JuanMa Garrido, del 25 de junio de 2024.
• «Dropping support for PHP 7.2 and 7.3», de John Blackbourn, del 9 de enero de 2026.
• «PHP Compatibility and WordPress Versions», actualizada el 19 de agosto de 2026.

Documentación de WordPress

• Manual de administración avanzada: «Upgrading WordPress», actualizada el 1 de julio de 2026; archivo wp-config.php; «Debugging in WordPress», actualizada el 23 de septiembre de 2026; «Common WordPress errors», actualizada el 28 de agosto de 2025; respaldos, actualizada el 4 de junio de 2026; y «Test Driving WordPress», actualizada el 7 de julio de 2025.
• Documentación para usuarios: «Updating WordPress», actualizada el 15 de septiembre de 2024; «Site Health screen», actualizada el 12 de julio de 2026; y «Plugin and themes auto-updates», actualizada el 13 de enero de 2023.
• Requisitos de WordPress y página sobre actualizar PHP.
• Manual de plugins: «Plugin Readmes», actualizada el 11 de marzo de 2026, y encabezados del plugin.

Código de WordPress, en la referencia para desarrolladores

• core_auto_updates_settings(): los textos de la pantalla de actualizaciones.
• WP_Fatal_Error_Handler::display_default_error_template(): el mensaje de error crítico.
• wp_maintenance() y wp_is_maintenance_mode(): el aviso de mantenimiento y la regla de los diez minutos.
• WP_Automatic_Updater, con sus métodos update() y has_fatal_error(): la revisión de errores fatales y la reversión de plugins.

WP-CLI

• Comandos wp core update, wp core update-db, wp core verify-checksums, wp plugin update, wp plugin install y wp maintenance-mode.

Directorio de plugins

• WooCommerce: versión 11.2.0, requisitos y versión probada.
• Health Check & Troubleshooting, leída también en las copias del directorio en inglés británico y sudafricano.
• Troubleshooting.

PHP y WooCommerce

• PHP, versiones con soporte: fechas de soporte activo y de seguridad.
• WooCommerce, «Revisiting WordPress Core Support Policy for WooCommerce», del 23 de febrero de 2023.
• WooCommerce, «Proposed change: Requiring PHP 8.1 or newer for WooCommerce 11.5 and beyond», de Brian Coords, del 8 de septiembre de 2026: uso de PHP 7.4 y 8.0 entre tiendas con seguimiento.
• WooCommerce, «New Requirement for WooCommerce 11.6: PHP 8.1+», de Brian Coords, del 29 de septiembre de 2026.

Seguridad, otros fabricantes y México

• Patchstack, «State of WordPress Security in 2026», con datos de 2025, actualizado el 25 de febrero de 2026.
• Elementor, «What will happen to my website(s) if I don’t renew Elementor Pro?», publicada el 19 de abril de 2020 y modificada el 3 de junio de 2026: actualizar la versión gratuita sin la Pro, y lo que pasa sin licencia.
• INEGI, Encuesta Nacional sobre Disponibilidad y Uso de Tecnologías de la Información en los Hogares 2025, resultados, del 16 de junio de 2026: conexión por celular inteligente.
• El Buen Fin 2026, del 13 al 17 de noviembre, según Uno TV y Chilango, los dos del 31 de agosto de 2026.

Cálculos y supuestos

Todas las cuentas son propias y están en un guion que las recalcula.

• Versiones de 2026: se contaron las versiones de la rama vigente publicadas del 1 de enero al 8 de octubre de 2026, sin betas, sin candidatas y sin los parches para ramas anteriores: 13, en 12 días distintos. Con correcciones de seguridad, 8: la 6.9.2, la 6.9.4, la 7.0.2, la 7.0.3, la 7.0.4, la 7.1.1, la 7.1.2 y la 7.1.3.
• Separación entre versiones de seguridad, del 17 de julio al 6 de octubre: 20, 6, 36, 5 y 14 días; 81 días en total.
• Revisión manual el día 1 de cada mes, ejemplo propio: espera de cada versión de seguridad hasta el siguiente día 1. Da 15, 26, 20, 14, 9 y 26 días, 110 en total y 18.3 en promedio.
• Revisión manual cada lunes, ejemplo propio: espera hasta el lunes siguiente. Da 3, 4, 5, 4, 6 y 6 días, 4.7 en promedio.
• Las diez fallas de la 6.9.2: contadas en la lista de su anuncio, una por una, en dos lecturas.
• Ramas con parche por cortesía: de la 4.7 a la 7.0 hay 24 ramas, contando 4.7, 4.8 y 4.9, las diez de la 5 y las diez de la 6, y la 7.0.
• De la versión mayor a la primera de mantenimiento: días entre las fechas de la lista oficial. Da 7, 9, 15, 63, 50 y 29; mediana, 22.
• Errores de la 7.1.1: 17 del núcleo más 19 del editor de bloques, 36.
• Espera de 6 horas con las automáticas: la mitad del ciclo de 12 horas que documenta WordPress, como en nuestra guía de plugins. Supone que el parche sale en un momento cualquiera del ciclo.
• Días hasta cada fecha: contados desde el 8 de octubre de 2026. Del 8 de octubre al 31 de diciembre van 84 días.
• Redondeo: hacia arriba desde el medio; promedios, a un decimal.

Comprobaciones cruzadas

• Cada cita se leyó dos veces, en fragmentos cortos. Cuando una lectura resumía en lugar de citar, se volvió a leer hasta tener el texto exacto. Lo que solo se leyó una vez va en paráfrasis, sin comillas.
• La propuesta de la reversión de la 6.6. Dos lecturas dieron dos redacciones distintas de la frase sobre la petición a la portada; por eso esa parte va parafraseada, y la cita es solo la que coincidió.
• El alcance de la reversión de la 6.6. La descripción de una charla de WordCamp Europe 2025 habla de temas y plugins. La propuesta técnica, la guía de campo y el código hablan solo de plugins. El artículo sigue al código.
• Las versiones mayores en automático. El manual de 2026 y la nota técnica corregida de 2020 coinciden: activadas por defecto en las instalaciones nuevas desde la 5.6. Una nota anterior, del 2 de noviembre de 2020, decía otra cosa y quedó corregida.
• La fecha de la 7.2. Dos páginas oficiales dan dos fechas, 8 y 10 de diciembre. El artículo da las dos.
• Las fechas de versión. Se cruzaron la categoría de anuncios, la lista de versiones y cada anuncio.
• El plugin Health Check. Tres copias del directorio mostraron la misma versión y el mismo tiempo sin actualizar, pero distinto número de instalaciones y de versión probada. El artículo usa solo lo que coincidió.
• El orden núcleo y plugins. Una de las páginas revisadas pone los plugins antes que el núcleo. El manual de WordPress, para la actualización manual, pone el núcleo antes. El artículo sigue al manual y lo explica.
• Coherencia con la serie. Las cifras de Patchstack coinciden con las de nuestra guía de plugins, y las de PHP con las de la guía para acelerar WooCommerce.

Limitaciones

• Las deducciones sobre la reversión de la 6.6 salen del código vigente el 8 de octubre de 2026. La 7.2 puede cambiarlo.
• Los datos de Patchstack son de su propia base de vulnerabilidades, de 2025, y no se pueden comparar con el conteo de correcciones de los anuncios de WordPress de 2026.
• Las cifras de uso de PHP en tiendas son de WooCommerce, con datos de las tiendas que aceptan compartirlos.
• No se probó ninguna actualización en un sitio propio para este artículo.
• Los nombres de los menús en español pueden variar según la traducción de tu WordPress.
• Los documentos de WordPress, WooCommerce, PHP, Patchstack y Elementor se leyeron en inglés; las traducciones son nuestras.

Declaración de intereses

Este artículo no contiene enlaces de afiliado, y no hay relación comercial con Automattic, WordPress.org, WooCommerce, Patchstack, Elementor, los autores de los plugins mencionados ni ninguna empresa de hosting. Si en el futuro se agregan enlaces de afiliado, esta declaración se cambia el mismo día.