PYMEsign
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.
Idea central: actualizar no es presionar un botón. Es gestionar un cambio con inventario, copia recuperable, pruebas, ventana de trabajo, responsables y plan de vuelta atrás.
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.
Una onza de prevención vale una libra de cura.
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
Nota: el farero es una historia compuesta para explicar mantenimiento preventivo; no describe un incidente real de un cliente.
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. |
Importante: una versión mínima permite instalar; una versión soportada y probada reduce riesgo. La decisión debe considerar también tema, extensiones y código propio.
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.
Antes de avanzar: registrá fecha y hora de la copia, ubicación, alcance, responsable, tiempo estimado de restauración y evidencia de una prueba reciente.
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.
Prueba de negocio: en dos teléfonos reales, encontrá un servicio, abrí un caso, descargá una ficha y enviá una consulta. Medí el recorrido completo, no sólo la portada.
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
DESCARGÁ LA CHECKLIST
Actualización segura para WordPress y Joomla
Antes, durante y después: actualizá sin poner en riesgo tu sitio.
