Cómo actualizar tu desarrollo web WordPress sin romperlo

WordPress necesita actualizaciones, pero una actualización sin pruebas también puede crear un incidente. El sitio llevaba años funcionando. Recibía consultas, mostraba proyectos y nadie recordaba la última vez que se había revisado la tecnología. Una mañana, el panel informó que había actualizaciones pendientes. Parecía una tarea de cinco minutos: hacer clic, esperar y volver al trabajo.

Pero el responsable dudó. ¿La plantilla seguiría funcionando? ¿Los formularios llegarían al CRM? ¿El servidor admitía la nueva versión? ¿Existía una copia completa o sólo una promesa genérica del hosting? En un sitio B2B, una actualización no afecta únicamente páginas: puede interrumpir un recorrido comercial, borrar evidencia de medición o dejar inaccesible un canal de consulta.

El borrador original ya señalaba los pilares correctos -backup, requisitos del servidor, compatibilidad de plantilla y plugins, HTTPS, contraseñas y experiencia móvil-. El problema es que varios valores técnicos pertenecían a otra época. La idea sigue vigente; las referencias deben actualizarse y convertirse en un proceso verificable.

Qué incluyen los servicios de actualización WordPress seguros

En un faro costero, el trabajo más importante no ocurre durante la tormenta. Ocurre en las mañanas tranquilas: limpiar la lente, revisar el combustible, probar el mecanismo y confirmar que la luz de respaldo encienda. Cuando el mar se vuelve oscuro, ya no queda tiempo para descubrir que una pieza estaba desgastada.

El mantenimiento web tiene la misma lógica. Los incidentes suelen parecer repentinos, pero muchas veces se incuban durante meses: una extensión abandonada, una versión de PHP fuera de soporte, una copia que nunca se restauró o un formulario que dejó de enviar mensajes después de un cambio menor.

Benjamin Franklin escribió, al hablar de prevención de incendios, que una onza de prevención vale una libra de cura. En una empresa, esa prevención se traduce en una hora para inventariar y probar antes de arriesgar días de interrupción, pérdida de datos o daño reputacional.

“Una onza de prevención vale una libra de cura.” – Benjamin Franklin, 1735

Actualizar qué: las capas que sostienen el sitio

Capa	Qué incluye	Dueño habitual
Infraestructura	Sistema operativo, servidor web, PHP, base de datos, certificados, almacenamiento y copias.	Hosting o infraestructura
Núcleo del CMS	WordPress o Joomla y sus cambios de seguridad, compatibilidad y base de datos.	Responsable técnico
Extensiones	Plugins, componentes, módulos, librerías y conectores.	Proveedor / desarrollador
Presentación	Tema, plantilla, constructor visual, estilos y código personalizado.	Diseño / desarrollo
Operación	Formularios, analítica, CRM, correos, pagos, buscador, usuarios y permisos.	Negocio + tecnología
Contenido	Páginas, medios, documentos, metadatos, enlaces y redirecciones.	Marketing / comunicación

Un panel puede mostrar que WordPress o Joomla está actualizado y, aun así, dejar atrás una extensión, PHP o una integración externa. También puede ocurrir lo contrario: el CMS admite una versión moderna del servidor, pero una plantilla antigua no. Por eso la pregunta no es “¿está actualizado el sitio?”, sino “¿qué componentes tiene, quién los mantiene y hasta qué versión son compatibles?”.

El inventario convierte un conjunto invisible de dependencias en una lista gobernable. Sin él, cada actualización es una apuesta.

Los requisitos de 2020 ya no son una referencia segura

El texto original recomendaba PHP 7.2 o superior y MySQL 5.6 o superior. Esos valores no deben repetirse como objetivo actual. En agosto de 2026, WordPress.org recomienda PHP 8.3 o posterior, MariaDB 10.11 o MySQL 8.0 y HTTPS. La página oficial aclara que versiones antiguas todavía pueden ejecutar WordPress, pero algunas ya llegaron al fin de soporte y pueden exponer el sitio a vulnerabilidades.

En Joomla, los requisitos dependen de la rama concreta y del salto que se quiera realizar. El sistema de actualización y las extensiones pueden declarar versiones mínimas de Joomla, PHP y base de datos; el chequeo previo advierte incompatibilidades. En una actualización mayor, no conviene adivinar: hay que consultar la matriz de la versión destino, las notas de publicación y cada extensión crítica.

El hosting puede informar la versión actual, pero la empresa necesita algo más: saber si puede cambiarla, cuánto tiempo conserva la versión anterior, cómo restaura archivos y base de datos, qué límites tiene el plan y quién interviene si la actualización falla.

CMS	PHP	Base de datos	Transporte	Cómo decidir
WordPress	PHP 8.3+	MariaDB 10.11+ o MySQL 8.0+	HTTPS requerido	Referencia recomendada por WordPress.org en 2026.
Joomla	Según versión destino	Según versión destino	HTTPS recomendado	Confirmar en chequeo previo, requisitos y notas de la rama.

Un backup no existe hasta que puede restaurarse

El consejo de hacer una copia antes de actualizar es correcto, pero “el hosting hace backups mensuales” no alcanza como control. La frecuencia debe responder a cuánto dato puede perder la empresa. Un sitio institucional que cambia una vez al mes no tiene el mismo riesgo que un e-commerce, un portal de clientes o un sitio que recibe formularios todos los días.

Una copia completa de WordPress o Joomla incluye, como mínimo, archivos y base de datos. La base contiene páginas, usuarios, configuración y otros registros; los archivos contienen medios, temas, extensiones y configuraciones que no siempre están dentro de la base.

WordPress recomienda conservar varias copias recientes y en ubicaciones distintas. Joomla insiste en practicar la restauración. Ese es el punto que suele faltar: un archivo comprimido puede estar incompleto, corrupto o depender de una contraseña que nadie encuentra. Probar la restauración en un entorno separado convierte una copia en un plan real de recuperación.

La actualización segura ocurre primero fuera de producción

Cuando el sitio es comercialmente importante, el lugar para descubrir incompatibilidades es un entorno de staging, no la web pública. Staging es una copia aislada donde se puede ensayar el cambio, revisar errores y probar recorridos sin afectar a los visitantes.

La copia debe parecerse lo suficiente al entorno real: misma rama de PHP, base de datos comparable, extensiones y configuración. También debe protegerse para evitar indexación, correos involuntarios, cobros de prueba o exposición de datos personales.

WordPress y Joomla recomiendan revisar compatibilidad y respaldar antes de actualizar. Joomla incorpora un chequeo previo que informa sobre servidor, configuración y extensiones. En ambos casos, una luz verde automática no reemplaza las pruebas del negocio: el sistema no sabe si un formulario llegó a ventas, si un PDF crítico abre o si una conversión sigue registrándose.

Antes, durante y después

Momento	Controles principales
Antes	Inventario, versiones, responsables, backup completo, restauración probada, staging, compatibilidad, pruebas y rollback.
Durante	Ventana de mantenimiento, registro de cambios, orden definido, monitoreo, acceso técnico y criterio para detenerse.
Después	Validación funcional, seguridad, rendimiento, analítica, formularios, base de datos, cachés y comunicación.
Seguimiento	Observación durante 24-72 horas, errores, correos, conversiones, experiencia móvil y documentación final.

Ordenar el cambio reduce la incertidumbre

No existe un orden universal para todos los sitios. En una actualización menor puede bastar con copiar, actualizar componentes compatibles, validar y cerrar. En una migración mayor, quizá sea necesario pasar por versiones intermedias, sustituir extensiones, adaptar la plantilla o reconstruir funciones.

Lo importante es que el orden esté documentado y probado. Cambiar simultáneamente CMS, PHP, plantilla, servidor y plugins dificulta saber qué provocó un error. Separar cambios permite observar, comparar y volver atrás con más precisión.

1. Congelá cambios de contenido y registrá el estado inicial.

2. Generá una copia completa y comprobá que sea recuperable.

3. Cloná el sitio en staging y protegé datos, correos e indexación.

4. Revisá notas, requisitos, compatibilidad y extensiones abandonadas.

5. Aplicá el orden ensayado y registrá cada versión modificada.

6. Ejecutá pruebas técnicas y recorridos comerciales críticos.

7. Definí si se aprueba, se corrige o se revierte antes de tocar producción.

8. Repetí en producción dentro de una ventana, validá y monitoreá.

Qué probar en un sitio B2B

Área	Prueba mínima
Acceso	Home, servicios, casos, recursos, contacto y páginas privadas.
Captación	Formularios, mensajes de confirmación, CRM, correo y consentimiento.
Contenido	Buscador, filtros, descargas, imágenes, enlaces y caracteres especiales.
Usuarios	Inicio de sesión, recuperación, roles, permisos y edición.
Integraciones	Analítica, etiquetas, mapas, chat, pagos, APIs y automatizaciones.
SEO	URLs, canonicals, robots, sitemap, redirecciones y datos estructurados.
Seguridad	HTTPS sin contenido mixto, cuentas, 2FA si aplica, registros y permisos.
Experiencia	Móvil, teclado, navegadores relevantes, velocidad y estabilidad visual.

HTTPS, contraseñas y actualizaciones: tres controles distintos

El certificado HTTPS cifra la conexión entre navegador y servidor. Es imprescindible, pero no certifica que el CMS esté actualizado, que una extensión sea segura ni que las cuentas tengan permisos adecuados. Un candado no convierte automáticamente al sitio en confiable.

Las contraseñas robustas también son necesarias, aunque deben acompañarse con cuentas individuales, mínimo privilegio, baja inmediata de accesos, autenticación multifactor cuando sea posible y registro de responsables. Compartir un usuario administrador impide saber quién cambió qué.

Finalmente, actualizar componentes reduce exposición a fallas conocidas, pero requiere un proceso continuo. OWASP recomienda inventariar componentes y dependencias, vigilar vulnerabilidades, retirar lo que no se usa y obtener paquetes de fuentes oficiales. La seguridad no es una instalación; es una rutina.

Compatibilidad móvil y navegadores: medir en lugar de suponer

El artículo original mencionaba estadísticas de 2020 y comparaba Chrome, Firefox e Internet Explorer. Ese enfoque quedó obsoleto: Internet Explorer dejó de ser una referencia general y la participación de cada navegador cambia según país, sector y audiencia.

La decisión correcta parte de la analítica del propio sitio y de los recorridos de mayor valor. Probá al menos los navegadores y dispositivos que concentran tráfico real, más una combinación razonable de pantallas y tecnologías de asistencia. Si el portal se usa en campo, incluí conexiones lentas, equipos modestos y condiciones de luz reales.

Para rendimiento, las Core Web Vitals actuales observan carga (LCP), respuesta a interacciones (INP) y estabilidad visual (CLS). Google recomienda evaluar el percentil 75 de las visitas y considera buenos, como referencia, LCP de hasta 2,5 segundos, INP de hasta 200 milisegundos y CLS de hasta 0,1. Son señales de experiencia, no un sustituto de probar si la tarea comercial se completa.

Cuándo actualizar, cuándo migrar y cuándo rediseñar

Decisión	Cuándo suele tener sentido
Actualizar	El CMS está soportado, las extensiones tienen continuidad y la arquitectura sigue sirviendo al negocio.
Reemplazar componentes	Una plantilla o extensión bloquea la versión destino, pero el resto del sistema es recuperable.
Migrar	La plataforma o rama perdió soporte, hay dependencias abandonadas o el costo de sostenerla supera el cambio.
Rediseñar	El problema principal es propuesta, navegación, contenido o conversión; la tecnología sola no lo resolverá.
Reconstruir	No hay inventario, backups confiables ni ruta de actualización, y el riesgo acumulado es mayor que rehacer.

Un plan mínimo de mantenimiento

Frecuencia orientativa	Revisión
Continuo / diario	Disponibilidad, errores críticos, seguridad gestionada y copias según pérdida aceptable.
Semanal	Actualizaciones de seguridad y extensiones, formularios, espacio, registros y alertas.
Mensual	Restauración de muestra, usuarios, rendimiento, enlaces, analítica y conversiones.
Trimestral	Inventario, licencias, proveedores, extensiones sin soporte, accesibilidad y recorrido móvil.
Anual	Arquitectura, versión mayor, continuidad, costos, plan de recuperación y alineación con objetivos.

La frecuencia real debe ajustarse al volumen de cambios, datos, transacciones, criticidad y capacidad de recuperación. Un calendario genérico no reemplaza la evaluación del riesgo.

Por dónde empezar

Si hoy no sabés qué versiones sostienen el sitio, no empieces por actualizar. Pedí un inventario del CMS, PHP, base de datos, tema, extensiones, integraciones, licencias, usuarios y backups. Después identificá qué componentes están fuera de soporte o no tienen un responsable claro.

Elegí un recorrido comercial crítico y documentá cómo comprobarlo antes y después del cambio. Esa lista transforma una tarea técnica en un criterio de negocio: el sitio está actualizado cuando sigue siendo seguro y cuando las personas todavía pueden hacer lo que la empresa necesita.

Preparamos la guía editable “Checklist de actualización segura para WordPress y Joomla: antes, durante y después”. Incluye inventario, matriz de compatibilidad, control de backups y restauración, plan de pruebas, ventana de mantenimiento, rollback, validación y calendario de seguimiento.

Descargala y completala con tu proveedor de hosting, desarrollo, marketing y responsable comercial. La mejor actualización no es la que termina más rápido: es la que deja evidencia de que el sitio puede seguir trabajando y de que existe una salida si algo falla.

Te puede interesar

Transformación digital: una hoja de ruta antes de comprar