Actualizar tu web sin romper producción

Actualizar WordPress, PHP del servidor, temas o librerías de un sitio estático es necesario: seguridad, compatibilidad, rendimiento. Postergar años termina en «no podemos actualizar nada porque todo depende de todo». La solución no es no tocar nunca; es tener entorno de prueba, copia verificada y procedimiento repetible. En desarrollo web monto esto para clientes; aquí lo documento para que lo hagas tú o sepas qué pedir.

Por qué se rompe al actualizar

• Plugins abandonados que no siguen la API nueva de WordPress.
• PHP 7.x → 8.x rompe funciones deprecadas en código viejo del tema.
• Conflictos entre plugins que solo aparecen con el orden de carga actualizado.
• Caché agresiva (Cloudflare, plugin de caché) que oculta el error hasta que un cliente lo ve.
• Cambios en base de datos sin migración reversible.
• Actualizar en viernes tarde sin nadie disponible si falla — error humano, no técnico.

Concepto de staging

Staging es una copia de tu sitio en URL privada (staging.tudominio.com o subdominio del hosting) donde pruebas cambios antes de producción. Debe ser lo más parecida posible al entorno real: misma versión mayor de PHP, mismos plugins, datos recientes (anonimizados si hay RGPD estricto).

Opciones según presupuesto:

• Subdominio en el mismo hosting — barato; cuidado de no indexar en Google (robots noindex, autenticación básica).
• Entorno local con Local WP o DDEV — gratis, bueno para cambios de tema; menos fiel si el servidor real es muy distinto.
• Segundo despliegue en Cloudflare Pages / Netlify para sitios estáticos — rama staging en Git.
• Plugin de staging (WP Stagecoach, etc.) — cómodo pero revisa que copie también uploads pesados.

Checklist antes de tocar producción

1. Copia completa de ficheros + base de datos (WordPress) o commit Git etiquetado (estático). Ver copias de seguridad.
2. Lista de plugins y versiones anotada por si hay que revertir uno concreto.
3. Ventana de mantenimiento comunicada si hay riesgo de corto corte.
4. Acceso FTP/SSH y panel por si hay que renombrar carpeta de plugin vía filesystem.
5. Modo mantenimiento preparado (plugin o página estática) para no mostrar errores PHP al público.
6. Prueba en staging de la misma secuencia que harás en prod: primero plugins, luego tema, luego core (o el orden que recomiende tu proveedor).

Orden recomendado en WordPress

Regla práctica que evita muchos sustos:

1. Actualizar plugins de uno en uno o en grupos pequeños; comprobar tras cada tanda.
2. Actualizar tema hijo o comprobar changelog del tema padre.
3. Actualizar WordPress core cuando plugins y tema son compatibles.
4. Actualizar PHP del servidor solo tras verificar compatibilidad en staging con la versión nueva.

Automatizar «actualizar todo» sin mirar es la lotería. En sitios críticos (WooCommerce con ventas diarias), haz copia snapshot del hosting si el proveedor lo ofrece — rollback en un clic.

Sitios estáticos (Eleventy, Hugo, Astro)

Menos superficie de ataque, pero igual hay dependencias npm. Flujo sano:

• Rama main despliega producción; rama staging despliega preview.
• npm outdated y changelogs antes de npm update mayor.
• CI que ejecuta build; si falla, no despliega.
• Etiqueta Git v2026.07.01 antes de cada release importante.

Este sitio (informatico.info) sigue ese patrón: Eleventy, build en CI, sin plugins WordPress que despierten a las 3 AM.

Qué hacer cuando ya se rompió

1. No entres en pánico ni pulses diez veces «actualizar otra vez».
2. Activa modo mantenimiento si hay pantalla blanca o error 500 visible.
3. Si acabas de actualizar un plugin, renómbralo por FTP (plugin-mal → desactivado) y recarga.
4. Restaura copia de base de datos y ficheros si el daño es amplio — por eso el backup antes no es opcional.
5. Documenta qué versión falló para no repetir hasta que haya fix.

Si no tienes copia y el hosting tampoco, entramos en recuperación forense — mucho más caro. Prevención gana siempre.

Cloudflare y caché

Si usas Cloudflare, tras desplegar cambios puede hacer falta «Purge Everything» o purgar URLs concretas. Si no ves cambios, comprueba si estás mirando staging o producción y si el navegador tiene caché local (ventana privada para probar).

Monitorización mínima post-actualización

• Formulario de contacto envía y llega.
• Checkout o botón de reserva funciona.
• Login de administración accesible.
• SSL válido y sin mixed content en consola del navegador.
• Monitor uptime (UptimeRobot gratuito) durante 48 h.

Base de datos: el backup que olvidan

En WordPress el contenido vive en MySQL/MariaDB. Copiar solo wp-content por FTP deja fuera entradas, pedidos WooCommerce y configuración de plugins. Un backup de BD debe ser dump SQL o herramienta que lo incluya, con prueba de import en staging. Antes de actualizar plugins de comercio, exporta también pedidos del trimestre por si necesitas conciliación manual tras rollback. Parece excesivo hasta que un plugin de envíos borra tarifas.

Cuándo pedir ayuda

Si llevas años sin actualizar, el salto de PHP 7.4 a 8.3 en un WordPress con veinte plugins custom no es tarde de viernes en solitario. Contrata ventana con alguien que haya hecho rollbacks antes — soporte o proyecto en desarrollo web.

Entornos PHP: la bomba de relojería silenciosa

Muchos hostings «baratos» dejan PHP 7.4 o 8.0 años sin avisar. WordPress y plugins modernos asumen 8.1 o 8.2. El síntoma no siempre es error explícito: pantallas en blanco parciales, editor que no carga, WooCommerce que no calcula envíos. Antes de subir PHP en producción, clona el sitio en subdominio con la versión nueva y recorre: home, checkout, formulario, login admin, export PDF si usas plugin de facturas. Si algo falla, identifica plugin culpable antes de tocar prod.

Si tu hosting no ofrece selector de PHP, es señal para plantear migración a VPS o proveedor serio — tema de infraestructura, no solo «actualizar web».

Plugins de caché y minificación

WP Rocket, W3 Total Cache y similares aceleran, pero tras actualizar tema o WooCommerce conviene purgar toda la caché y probar en ventana privada. He visto tiendas «rotas» que en realidad servían JS viejo minificado durante días. Documenta cómo purgar caché para que no dependa solo de ti.

Entornos con varios editores

Si varias personas editan WordPress o el CMS, acordad quién actualiza plugins y quién publica entradas. Dos personas pulsando «actualizar todo» el mismo día multiplica el riesgo. Mejor un responsable técnico y ventana fija — por ejemplo primer martes de mes tras revisar staging — o un mensaje en el grupo interno «no tocar plugins esta semana, hay despliegue pendiente».

Rollback: el plan B obligatorio

Antes de pulsar «actualizar» en producción, define cómo vuelves atrás: snapshot del hosting, copia SQL nombrada con fecha, tag Git, o los tres. El rollback falla si solo copiaste ficheros y la base ya migró esquema. Practica rollback en staging una vez al año; cuando lo necesites de verdad irás con prisa y sin documentación.

Plantilla de registro (copia y pega)

Guarda una fila por actualización en una hoja:

• Fecha y hora
• Qué se actualizó (plugin X 4.2 → 4.3, PHP 8.2 → 8.3)
• ID de copia de seguridad o tag Git
• Resultado de pruebas en staging (OK / fallo)
• Quién aprobó pasar a producción

En seis meses agradecerás el historial cuando algo «de repente» deje de funcionar y en realidad cambió hace dos actualizaciones. Comparte el registro con quien te dé soporte: ahorra horas de adivinar qué versión tenías instalada.